161–170 of 308 posts
I spent quite some cycles into flutter|dart, ended up with React Native for mobile and wxWidgets for cross platform desktop GUI(electron.js is too fat for me and wxWidgets 3.2 looks decent). RN(javascript) and wxWidgets(c++) are both job friendly, unlike Dart, which is a language I actually enjoy, but there are not a lot jobs for it anywhere.
When I hire for my team, I never mention the stack. I don't care. I am hiring software engineers, and what I value is mindset and ability.
I'll throw you in at the deep end. Learn the language, libs, tooling, infra on the job and the team will support you. Because you're awesome. That's why I hired you.
edit: Sound _less_ unintionally arrogant.
Earlier quoted context omitted.
(not op) This is not hamstringing. It’s a matter of preference. I prefer jeans to a tie and a costume. I prefer Emacs and Vim to Vscode. I choose jobs that allow me to wear jeans and code in Emacs.
There are plenty of jobs that will let you do that. Most of them will not be writing software that is built on X.
Earlier quoted context omitted.
Thanks very much for posting this, totally agree. I get frustrated when I hear all these missives about how easy it is for any good developer to learn a new language "in a couple days". I think this paragraph was key: > Learning a language is easy. Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc. That said, I still nearly always hire for general skills and n…
And you are probably not going to pay me the same as someone who already have the experience you are looking for (and you probably shouldn’t). Because of the stupidity of hiring and raise practices (not your fault as a hiring manager), you can get HR to open a job req at market rates. But it’s a lot harder to get HR to allow you to give your current employees raises to get them at market rate. That investment is then…
if someone gives you two years of good work and moves on because you aren't giving them what _they_ need, or because their father got ill, you still came out way ahead. you should be a human and accept that.
You cant only pick "winners" but you almost need to develop a sixth sense for what will be a valuable and long term addition to your finite toolbox.
Looking at tech attributes is just the start. business and community context, complementarity with other pieces etc are all the subtle factors that may help avoid wasting energy in short lived pursuits.
Earlier quoted context omitted.
I used to say just this. And I did native Android dev for many years, but I gave it up around 2019. When I finally checked out, native Android was a teetering mess of compatibility libraries, half-baked never-finished “new ways of doing things”, lacking docs, forever-bugs, and overall neglect. Simple ui would take you 5x as long as equivalent css and have you dropping down to low level drawing in frustration. Back th…
Jetpack Compose, and Kotlin coroutines, mixed with kotlin multiplatform code, came and made many things nicer, especially UI. With so many libraries and so many ways of doing things with so many opinions it’s still hard to digest of course. It’s better than non native for performance and experience but many companies will of course care more about the money saved from a sub native experience with fewer developers.
I currently work at an agency doing Android apps (not a typical pump and dump agency mind you, I've been the lead on this single project for 5 years and we've had them as a client for 8+), and I'm so happy to see our client buck that.
They've had us on a native app that we've been supporting for the entire 8 years, and had deep technical issues from before us ("lets reinvent the web browser for UI"). They had a secondary internal team (known to us, no hidden surprise, you're gone stuff) working to replace us with a greenfield cross platform app (I think react native). That project went on for a year before they cut their losses and said "cross platform can't be good enough."
We're now in the planning phase of a complete greenfield rewrite of the existing app to take advantage of Compose + Kotlin, and ditch 12 years of tech debt and I'm practically ecstatic.
Earlier quoted context omitted.
Yes because I know Java (hypothetically I haven’t touched Java since two years after it was introduced) I can become an efficient Android developer “in a few days”. Better yet, since I did Windows CE development for ruggedized devices using C# Compact framework back between 2007-2010, I should have no problem picking up iOS development “in a few days” and start being a productive member of a team right? Or better yet…
Thanks very much for posting this, totally agree. I get frustrated when I hear all these missives about how easy it is for any good developer to learn a new language "in a couple days". I think this paragraph was key: > Learning a language is easy. Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc. That said, I still nearly always hire for general skills and n…
Earlier quoted context omitted.
Not iOS, but I'm fairly confident I could be productive in an Android codebase in a week. The only reason I don't think I could do iOS is because I'd need to use a OSX, and I think it would take me longer to become productive in OSX. It also depends on what you mean by "productive", would I want to lead a team to create a new app from scratch? Probably not. Go into an existing app and start fixing bugs and creating n…
As someone that has done on and off Android programming as hobby since NDK was introduced in Android 2.2, and regularly follows ADB Podcast, I doubt it. Every Android version is basically a reboot in many parts of the framework, the device fragmentation is hardly any better than J2ME days, several features are only documented via samples or Google IO talks, Gradle plugins require rewrites between upgrades, and each A…
Let me try and quantify it. I looked through my apps that I installed from F-Droid, then looked at their GitHub issues and picked one [0]. I bet I could implement that in less than a week with 0 Android development experience.
> Every Android version is basically a reboot in many parts of the framework, the device fragmentation is hardly any better than J2ME days, several features are only documented via samples or Google IO talks, Gradle plugins require rewrites between upgrades, and each Android Studio release is a box of surprises what quirks it has.
Does any of that really matter if you're hiring someone into an existing org? Doesn't Android have amazing backwards compatibility? I'm sure I have some dice app from 2012 that still runs. The company is probably targeting some version of Android and isn't changing to the latest one every time a new version is released.
Earlier quoted context omitted.
Thanks very much for posting this, totally agree. I get frustrated when I hear all these missives about how easy it is for any good developer to learn a new language "in a couple days". I think this paragraph was key: > Learning a language is easy. Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc. That said, I still nearly always hire for general skills and n…
I always read "learn" in this context as "be familiar enough with the basic language properties that I can pick the rest up on the job, get things done, and not be too dangerous, or annoying in code review" and when I read it that way I agree. Some of the best devs I have hired had no prior experience in the stack. I'm not hiring for Python or C#, I am hiring a software engineer and the skills I value are all transfe…
Earlier quoted context omitted.
And you are probably not going to pay me the same as someone who already have the experience you are looking for (and you probably shouldn’t). Because of the stupidity of hiring and raise practices (not your fault as a hiring manager), you can get HR to open a job req at market rates. But it’s a lot harder to get HR to allow you to give your current employees raises to get them at market rate. That investment is then…
its fundamentally wrong to treat your employees learning process as a long term investment that you maintain ownership of. paying someone for two months to come up to speed is an investment. if they become productive in your environment, that investment is very quickly paid off. if they don't, then your at-risk investment didn't pay off. the return is the work that you got from them afterwards. you don't get to claim…
If I hired someone with the experience I was looking for, then they gave me 2 years of productive work.
Why would I train someone new instead of just poaching your developer at market rates?