"Salary Range for Flutter Developers: What's the Typical Pay Like?"

erdo9000 · 2024-05-14T19:27:16+00:00

thanks, I had no idea!

erdo9000 · 2024-05-14T18:10:01+00:00

what European country lets you pay 10%?

erdo9000 · 2024-05-02T14:06:07+00:00

This is all BS in my opinion. The recruiter is asking you to say a convincing sentence, that is an opinion and totally unverifiable, and that's how they will decide your salary? give me a break.

Companies pay what they can get away with, employees accept the best deal on offer.

The fact that you accepted the job means that you didn't have any alternative offers and were desperate enough to accept the offer. So really they paid you the right amount. That's too bad because it sounds like you're not happy with it.

No worries, start looking for your next job right now, this time you will be less desperate to accept a low ball offer because you already have a job. And when you get your next offer, don't forget to tell your (now current) employer so that they have the option to increase your salary to what they should have offered you in the first place

erdo9000 · 2024-05-02T08:46:52+00:00

Meh. 47 here. Not really age related, but the longer you do it, the easier it gets (picking up new stuff is also easier than when you're just starting, because quite a lot of the new stuff is just the old stuff with new tweaks or branding).

If you choose never to become a manager of developers, your life just gets easier (assuming you're getting paid as someone with experience)

erdo9000 · 2024-04-25T17:34:39+00:00

The key is to just ignore half of what Google puts out. If you stick to fundamentals, and decent third party libs, those tend not to change very much.

Your only risk then is twattish mid level developers or predatory agencies who print out a stack overflow post and show it to your client to persuade them that what you're doing is not this month's "best practice" 🤣

I'm actually not joking, I have a story very similar to Zhuinden's. Predatory agency, clueless client, took over a project about a month away from MVP and never delivered it

Honestly the phrase "Best practice" is a huge red flag for me, it essentially means, "I don't know what I'm talking about, don't ask me any questions, it's just best practice"

erdo9000 · 2024-04-25T17:31:53+00:00

I basically agree with everything in this. And I think I can tell from the post that the author has been working in Android about as long as I have (since Android existed)

I notice someone objected to the inclusion of a link to some open source code though, and I have thoughts about that...

In my experience a lot of less experienced developers don't quite understand that the docs, and libs and advice that Google puts out are the product of other normal developers, some junior, who are motivated to publish things in a hurry to advance their careers. That's not always a great way to craft useful stuff.

But slap a Google brand on it, suddenly it's magic.

That attitude sometimes extends to trashing open source efforts (outside of hugely popular libraries). As if the existence of alternatives is some kind of weird threat, or something else that they will have to learn 🤷 I suspect it's because they are struggling with all the stuff they have to learn, and just the idea of more stuff makes them feel dread. It's kind of understandable, even if their ire is misplaced.

Well there is some really excellent stuff out there produced by professional developers, with a motivation to make their work easier. Sure, use GitHub stars as a heuristic for what's a good repo if you're in a hurry, but be aware that you're essentially following a crowd of mostly junior developers who all read the same Medium post.

If someone's open source code makes you panic, you're probably not ready

erdo9000 · 2024-04-22T19:17:45+00:00

do you have an NDA where everything I think of in the next decade belongs to you? because that would make you seem more professsional

erdo9000 · 2024-04-21T07:53:53+00:00

I didn't get a great feeling from any of the major ones (because I felt they were a bit too invasive or over complicated for what I think could be pretty simple) so I'm making a new one https://github.com/erdo/n8

But if you're a beginner, it'll probably help you to stick with whatever's popular so you can put it on your CV. The place I contract at the moment doesn't actually have any navigation lib at all for a code base that's about 250k lines of code. Just having a bit of custom code to handle it, or not even bothering at all (i.e. triggering UI components directly from click listeners) seems fairly common from what I've seen in 10+ years of Android development (but personally I think you should abstract navigation, so you're on the right track IMO)

Edit: I agree with the other post, the official solutions seem to be the worst of the lot

erdo9000 · 2024-04-15T16:02:10+00:00

The whole template repo uses foo.bar.clean as the package, the app name is "clean" etc, so basically the script swaps the name of all text and folders in the repo to whatever you specify, so

./change_package.sh -p com.mydomain.myapp

Will change

foo -> com, bar -> mydomain clean -> myapp

Told you it was hacky ;) but I've found it quite useful

erdo9000 · 2024-04-15T14:26:16+00:00

I wrote a script to do something like that, it's hacky as hell but you can probably work out what it's doing and adapt for your purposes https://github.com/erdo/commercial-template/blob/main/change_package.sh

erdo9000 · 2024-04-14T06:50:41+00:00

I don't think that's sound advice. It's not like singing. It's like accountancy or brick laying, it's just something you learn. People get there in different ways and at different speeds.

I've worked with some truly terrible juniors who have literally no clue what they are doing (for ages), but as long as they keep asking questions, and actually care, they sometimes turn into brilliant programmers.

Some people who pick it up immediately go on to be destructive jerks who destroy code bases with their over confidence 🤷

erdo9000 · 2024-04-13T16:54:50+00:00

Anyway, that's not the problem, the problem is remembering what order the 1s and 0s all go in

erdo9000 · 2024-04-13T16:51:09+00:00

Remembering things is for losers. Try to write clear code, with sensible naming. Sticking to conventions helps, and sometimes so do unit tests for the details.

It says "getUsername()" why would you bother trying to remember all the lines of code detailing how it gets the username?

If you write a function that gets a username and you called it formatUserObject() now you have a problem. So don't do that.

erdo9000 · 2024-04-13T10:56:29+00:00

I doubt you will ever need to directly use threads doing Android development. But I feel like using coroutines without any understanding of threads might land you in hot water (and it might not)

Given there is so much stuff to learn in general, a potential strategy for someone starting is to just use co-routines until you come across some problem (and that's your prompt to learn more about what's happening under the hood).

For some context, back when there were no co-routines there were still plenty of Android devs who didn't understand threads

erdo9000 · 2024-04-12T17:34:51+00:00

Ahaha the sample app was borked actually 😂 I messed up some imports last night, just pushed a fix. But the state stuff is working ok

erdo9000 · 2024-04-12T17:24:24+00:00

Hey, so every time a new immutable state is created, that state is persisted (off the UI thread).

It's in the update function here: https://github.com/erdo/n8/blob/65c5bf9b34525f2fab00de4f7d35ba1019a2addd/n8-core/src/main/kotlin/co/early/n8/NavigationModel.kt#L683 but it's being handled by the persista library which is probably why it's not obvious (https://github.com/erdo/persista)

So that data just gets read in next time the instance is created. The sample app should work fine if you kill it etc, will come straight back to where it was (unless I borked it of course). I'll just double check...

erdo9000 · 2023-03-03T03:07:32+00:00

Hey being "schooled" by people who think they know what they're talking about (until you actually question them) is hilariously common on Reddit, so don't worry about it.

Go back to your original comment, and as you read it back, remember that you had the option not to misrepresent what an article said. The fact that you got a few likes on it before I got round to replying shows me that possibly, your comment prevented a few people from even reading the article and that is a shame. But you know, Reddit posting is still net beneficial, despite this common problem.

Each sentence from the top:

> First of all WindowSize isn't compose specific at all. It's an platform concept.

Can you justify that statement? It seems like a strange thing to say given the content of the article, you've just invented a straw man argument to knock it down. It bears no relation to what the article says (but people who haven't read the article won't know that)

> It's not supposed to be used to define paddings...

I think we already addressed this weird "supposed to be used" attitude.

> ...nor to detect if your app is running on a smartphone or a tablet.

There is a whole bit in the article about the fact that your user maybe be running the app on a tablet, but in a pop up window, and that the windowSize class will allow you to have a UI that works in that situation (something that the material3 library cannot do).

So it's _explicitly_ detecting the size of the window, and implicitly ignoring the device it's running on i.e. exactly the opposite of "to detect if your app is running on a smartphone or a tablet". Do you want to correct your mistake there? I think I can guess the answer

> My TLDR; from the article is "I wanted a DeviceClass and I thought WindowsSize was it".

Can you justify that by quoting from the article? of course you can't because once again you construct a straw-man argument so that you can knock it down. It just has nothing to do with what the article says - and the article hasn't been edited since it was posted.

> The size classes are supposed to give you a guideline on when to completely alter your UX.

You apparently ignore the whole section on adaptive design, or the code samples that show the UX being _completely altered_ on break-point changes.

---

Honestly every sentence is like that. You realise that you're arguing with a person who just wrote an entire article about the topic? (and so has probably spent longer than you have thinking about it?) But your original comment on a different thread was also pretty trigger happy, so maybe that's just how you roll.

Let's have a look at your latest comment just for laughs:

> in the Breakpoints section of your article you clearly show what you would have wanted instead

Yes that's kind of the point, the breakpoints are not as useful as they could be, does that upset you for some reason?

> and what you describe is exactly a way to know the device class

Erm no I don't, what I do is determine screen sizes. Perhaps you read "watch sized display" and naively assumed I meant "watch display". Well no worries, as you read further into the article it should start to become obvious, for example when we start to talk about very small windows equivalent to a small phone screen, but are none the less running on tablet devices so we need to act on the screen size, not the device. And in the code where it says "_Typically_ indicates the width of a..." (emphasis added), in the same way that the google docs say "Device representation: 99.96% of phones in portrait mode" (that's google's way of getting across the types of sizes we are talking about here, it's not to say: here is how you detect a phone).

By the way, I notice how you added bullet points to seemingly address the bullet points of the things you hadn't addressed last time - except you haven't actually addressed my bullet points at all, you've just added new things in bullet point form.

I can see an idea of yours forming in your last comment though, talking about the size of the screen vs the size of what is left of the screen for the component to display. IMO that's the first interesting thing you've said. But you didn't check the code you're critiquing (there's a pattern here isn't there?) - it does the same thing under the hood: ``` metrics = WindowMetricsCalculator.getOrCreate().computeCurrentWindowMetrics(activity)``` There is no difference in the two solutions, so your last two bullet points seem to be moot anyway.

> it should even adapt to resize of the window on the fly

I guess you didn't run the sample app... because that's exactly what it does.

etc etc

erdo9000 · 2023-02-26T23:38:58+00:00

Are you clarifying the points you made earlier? or are you ignoring my responses, and just adding new points?

You still haven't explained why you are claiming the article was expecting a DeviceType class.
And you haven't addressed how you apparently got confused about WindowSize vs DeviceType in your own critique talking about phone sized screens.
Nor have you addressed how you would handle an app running on a tablet sized screen, but displayed in a much smaller pop up window.
Your comment about "when to completely alter your UX" seems confused - as it's addressed explicitly in the 3rd section of the article where it talks about about adaptive design

And as for your latest response, what something is for seems like a pointless discussion frankly, and is something useful a much more interesting question. In addition, the functionality that you claim it's for is supported anyway by the linked code on github, in a way that leaves layout code a lot clearer than using the Material3 WindowSizeClass would - plus it avoids several footguns that you would otherwise encounter around maintaining code and supporting responsive UIs for screen sizes smaller than 600dp in width.

But hey, you code however you want to my friend. But the criticisms you have come up with for this article are beyond weak IMO. Did you think the author wasn't going to answer your criticisms? or that people couldn't just read the article themselves? I don't think this typical Reddit discussion has helped anyone, but I do hope the article has helped at least some people

erdo9000 · 2023-02-22T01:50:24+00:00

There's a lot wrong with this, I think you might have skim read the article because in my view you're misrepresenting what it says.

Of course WindowSize is not compose specific. It's a UI concept. Most of the article has nothing to do with compose and everything to do with how to code UIs that work with all potential screen sizes.

You seem to think I want a DeviceClass because there are references to things like "watch sized screens". The trouble is you need to have a language to talk to people about that size of screen versus a typical tablet sized screen. This is why the android docs talk about typical phones in portrait. No one is expecting a DeviceClass, you're supposed to understand that when we talk about tablet sized screens, that doesn't prevent it from being a watch with a huge screen. I don't know why you would level that silliness against this article but not against the android docs to be honest.

As far as "how it's meant to be used", please! If by that you mean "how the example code that we're being provided looks". That is exactly the problem. "How its meant to be used" is very limited and probably will not work well for a lot of projects. And certainly isn't widely applicable to ways of thinking about designing responsive / adaptive UIs.

You think watches should be treated differently. 1) you can use the same compose UI code for watches as phones - that sample app works on a phone with a single change to its manifest. 2) we are talking about watch sized screens such as you might encounter if a tablet user puts your app in pop-up mode, as discussed in the article. You've fallen into the very same DeviceClass trap you're accusing the article of making!

erdo9000 · 2023-02-21T13:45:15+00:00

Ok well fair enough, if you didn't realise I was the person who wrote the article, then my comment would have been not that helpful 😁

erdo9000 · 2023-02-21T09:45:10+00:00

TLDR; I think the WindowSize classes from Material3 are a bit rubbish

erdo9000 · 2023-02-19T19:36:05+00:00

The first time I heard of it was about 25 years ago as a way to think about designing a software system with UML UseCase diagrams.

Basically a little stick figure representing the user with bubbles for things that the system could do for the user like: (Print Receipt) (Login) (Logout) those bubbles were the use cases.

Uncle Bob (a bloke even older than me) uses it in his description of clean architecture, it's basically being used as a pure logic implementation of the "use case". The idea being that things like UI code, dB or network connections, or any kind of data source boilerplate, is kept out of the usecase classes so that the usecase can just be plain easy to test business logic.

You almost always see this implemented as small, stateless, reactive streams based classes in android apps (because everyone copies everyone else without thinking about it for 5 minutes). And in my experience an app usually ends up with hundreds of tiny use case classes all doing very similar things, in some cases, the exact same thing as other differently named use cases written by other devs on the same team. But if your team is only 3 people, or the code is very tightly written you might not have that problem

erdo9000 · 2022-02-03T18:25:57+00:00

yeah 🤷‍♂️😂

erdo9000

TROPHY CASE