Absolutely, I feel I could be employed tomorrow in a language or stack that I haven’t even heard of and start being productive by the end of the week!
I seriously think you owe it to yourself to practice learning something new every week. It often takes one afternoon to get a “taste” and small side project to get beyond that.
Every programming language. Is literally just a template for instructions, and every technology just an abstraction over some crud somewhere.
My experience is that learning a new language -at a basic level- can be done quickly (like a couple of weeks, not days).
But learning it at an advanced level, is a whole different matter.
I've been writing Swift since, literally, a few hours after it was announced, in 2014. I write Swift every day (like, seven days a week), and have been, since that first day.
I feel as if I have only had "mastery" of the language for the last couple of years. There's still plenty for me to learn, and they keep adding more stuff.
But the language isn't the big deal. The deal for me, is the fundamental SDK/API/Framework. That has been an ongoing project since 1986. As soon as I learn one API, they change it up (and sometimes, the entire OS).
During that time, I've written in 68K ASM, Pascal, Object Pascal, C, C+- (the weird THINK C variant), C++. ObjC, and Swift. I've worked with MacApp, OpenDoc(!), Think Libraries (Pascal and C), PowerPlant, and Cocoa (and its expression in iOS, WatchOS, AppKit, and TVOS).
I've always considered hiring folks to be an investment. As a manager, I always looked for folks that had the fundamentals down, and assumed that I could train them into what we need. Most of the work we did, was way beyond anything you'd find in textbooks. I was under no illusion that I could hire folks that would be able to start on it right away.
That was why my team was always one that I wanted to keep whole and cohesive, over many years. I can't even imagine today's 18-month engineer lifetime. I kept my engineers for many years, and that wasn't easy.
But as far as employees being an “investment” let’s look at things from the employee side.
For context: these numbers I’m about to cite are correct to within a first approximation on the “enterprise dev” side where most of the 2.7 million developers work and in most major cities in the US that are not on the west coast or in NYC
Let’s say you hire a
Junior/mid level developer and offer them $100K which is fair knowing they are going to do “negative work” for the first few months as an investment. Two years later, they have experience and now can apply for companies that are looking for experienced iOS developers. Their market rate shot up to $135k.
Because of salary compression and inversion, you’re not going to be able to pay them 35% more in two years because of HR policies. Yet you can bring in new experienced iOS developers at market rate. If he’s smart your employee is going to jump ship, wasting a lot of your “investment”.
As a hiring manager, knowing that statistically I’m only going to get two years out of an employee, why wouldn’t I just poach the person you just trained and pay them the $135K you couldn’t?
Another scenario is that now that developer has been reading r/cscareerquestions and decided to “grind leetcode and work for a FAANG”. Now he’s looking at $200K+ as a mid level developer adding yet more bloat to the Facebook app.
> You couldn’t compete with that if you wanted to.
Unfortunately, I was forced to.
My company was one that paid “competitive” salaries.
That’s code for “below average.”
This filtered out 90% of applicants, right there.
So the ones that applied, did so, out of genuine interest in the company and the technology (we were a “marquee” company).
I was forced to look for “diamonds in the rough,” and became fairly good at evaluating whether or not someone could handle the tech and the learning.
I kept them, by being a really good manager. I treated them with respect, didn’t burn them out, and shielded them from a lot of the corporate BS. They appreciated that, and stayed.
When our team was finally rolled up, after just short of 27 years, the employee with the least tenure had ten years. These were seasoned C++ image processing professionals.
Most of those 2.7 million developers I spoke about will never make low end FAANG money and that’s perfectly fine.
I had my first house built in the burbs of Atlanta in 2002 making $60k (2500 square feet) and my second house built in the northern burbs (3200 square feet) making $135K in 2016 [1].
I only fell into a remote role at BigTech in 2020 at 46 years old after declining a chance to interview for a software development position and being offered a chance to interview for a position in the Professional Services division doing cloud consulting [2].
I was perfectly happy living the upper middle class lifestyle in 2020 making only $150k with my wife making $20K working part time.
In fact, I’m excited to get back to working at small companies on the high end of enterprise dev comp because my department became too “Amazonian” this year and my shit tolerance level is extremely low.
[1] 2002-2012 was a decade of bad life and career decisions that I didn’t recover from completely until 2018.
[2] I did my bid, saved money and paid off debt and our bills are actually $1000+ lower per month now than they were when I started.
> you’re not going to be able to pay them 35% more in two years because of HR policies
Seems like you just identified the issue. You're right, of course, that the "invest in employees" approach doesn't work at companies that have a corporate policy to not invest in employees.
Investing in employees is a top-down strategy, not a bottom-up one. If there isn't support for it at the top, then you're right, it won't work.
I think all the "a few days" and "a week" stuff that generates these kinds of debate is a total red herring. Yes, it's hyperbole. But it's also true that people with experience successfully applying a bunch of different technologies are great hires onto a team using a technology they don't yet know. It's just a process measured in months rather than days. But if you need to hire someone because you have something that needs to get done this week, then you've already screwed up.
And then it gets back to my other argument. Are you going to pay someone the same that doesn’t fit your technical needs as you would someone who does? If you pay them less, are your raise policies going to allow you to get them to market value once they do have the skillset or are they going to end up job hopping?
Personally, I would not take this into consideration when deciding how much to pay people.
I recognize that there are a lot of different niches in our industry, and presumably in some of those niches this narrow focus on what technology is being used makes sense, but that hasn't been my experience.
In my experience, you want people who are both pragmatic and flexible about learning, evaluating, choosing, and teaching others new tools.
I do recognize this may be a somewhat privileged view. I think I've been fortunate to spend my career in organizations where software is the profit center rather than a cost center supporting the rest of the business. My experience is that these companies have focused their hiring, compensation, and performance expectations on fundamentals and figure-it-out-itude rather than any specific technology stack.
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 new features? Sure.
I did a trial week before joining my current gig full-time. I had pretty much no typescript experience, came into a large TS react/nodejs app and had a pull request on the 2nd day for a new feature.
I wouldn't try to work on a Haskell or OCaml codebase, they are different enough that I'm not confident I could pick them up quickly. But most mainstream languages are similar enough that it really shouldn't be that hard to pick them up and be productive.
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 Android Studio release is a box of surprises what quirks it has.
I think it really depends on what your definition of "productive" is.
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.
Are you trying to find a job as a journeyman developer (nothing wrong with that) or are you trying to lead a team or be a senior where you are expected to be productive from day one and maybe mentor developers and be more strategic?
Would you hire me someone who not only doesn’t know anything about Android development but doesn’t even follow the ecosystem and the current trends?
If I was looking for a job, I'd say that I have no professional Android experience but I'm confident that I could hit the ground running at a senior level and mentor juniors for Android.
I mean, in this hypothetical scenario, I've decided that I want a job as an Android developer. So I would take my own time to learn Android whilst interviewing. By the time I got a job, I'm confident I'd hit the ground running.
I wouldn't try to apply for a job to lead an Android team without at least working in one first. I'm sure some people do, but I'm not that confident ;).
> Would you hire me someone who not only doesn’t know anything about Android development but doesn’t even follow the ecosystem and the current trends?
I wouldn't hire you because you don't sound like you think you could do it.
If I was interviewing someone and they said something like: "I have no experience with Android, but I know Kotlin and I'm confident I could pick it up. I did a similar thing with x,y,z" then sure.
> If I was looking for a job, I'd say that I have no professional Android experience but I'm confident that I could hit the ground running at a senior level and mentor juniors for Android
I can say I’m a little teapot. But without demonstrated experience, why would you hire me over one of the million developers with experience and have at least shipped an app?
> If I was interviewing someone and they said something like: "I have no experience with Android, but I know Kotlin and I'm confident I could pick it up. I did a similar thing with x,y,z" then sure.
Yes because “positive thoughts” without experience means you can be effective
Already with that response you have proved not to understand the Android ecosystem.
No it doesn't have an amazing backwards compatibility, specially depending on what is cool in one Google IO, and already legacy in the new one, without replacement, like e.g. Tango, Sceneform, Fragments.
There are policy rules how old an Android app is allowed to be in Play Store.
I don't care what platform you are targeting: unless the entire purpose of your product is to take advantage of the feature (which is sometimes fair), you never ever ever EVER integrate whatever is "cool" from the latest keynote.
Regardless, while Android requires you to compile new apps with the latest toolchains to release, and you might have to update some stuff in your manifest, they do not force you to use new APIs, they do not require you to stop supporting old versions of Android, and I've seldom run into a backwards compatibility issue that wasn't some corner case involving the weird intents we have to use (as our app relies on being a VPN).
Time to acquaint yourself with Play Store policies and what should be the minimum API version for uploading new app versions, which do force to use new APIs, that is the whole point behind it.
Besides the whole Android example, was just that, I can give several examples of technology stacks where having a passable knowledgeable of a programming language, without the associated frameworks that are being used in the company, makes the candidates a no hire, unless they really excel themselves at the interview, assuming HR even cares to call them in.
sigh, look again: you have mixed up "target" with "min" :/. This is a critical distinction that you can't just gloss over: you simply are NOT forced to use new APIs just because you bumped the target... at build time it might activate the ability to choose to use some new APIs if you want to, but the biggest effect it has is at runtime to affect the various subtle--and extremely limited--backwards compatibility behaviors I mentioned (similar to how iOS uses the version of UIKit you linked your app against) which tend to mostly limit specific scenarios where security issues or bugs were found in older designs.
FWIW, I am seriously the build engineer for an Android app distributed in the Play Store (and have maintained apps for Android since the platform launched and it was still called the Android Market), and I'm telling you: you are not just wrong, you are being loudly wrong... not just about this (where the wrongness frankly feels egregious at this point), but your entire point: I have taught classes at the university level on how to rapidly pick up programming environments, and the lead UI developer I hired for our company had almost no experience in the toolkit we are using before we hired him and he's doing fine with it.
As of the rest, in most companies I worked on, unless the higher ups are bypassing the hiring process, due to networking and acquaintances, such CVs never get through HR first round of filters.
>There are policy rules how old an Android app is allowed to be in Play Store.
yup, but we're not talking about new feature to removed in 2 years level of radical changes. It's still something coporate uses and coporate doesn't latch on every cool feature.
You can probably expect your newest API app to work in 5 years if you don't touch it. You probably can NOT expect it to work in 10 years. That just means you need to make sure you're never 3+ years behind on using deprecated features.
> 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 new features? Sure.
As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”?
And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap.
> As someone with experience, are you actually applying for jobs where you would just be pulling stories off the board doing “feature work”?
I dislike the whole Agile stories/points/sprints thing, so probably not those jobs. But if you're asking if I'm applying to jobs where I write code, then yep! I love writing code and building things.
> And let’s take your example. What’s the chance of me being productively able to create a feature in a Typescript/React app seeing that I haven’t done front end work since 2015 and even then it was server side rendering with ASP.Net MVC and bootstrap.
I don't know what other experience you have, but probably. At my previous job, I got a bunch of silicon production test engineers, that spend most of their day writing VBA, "productive" in React within a week.
I setup the base of the application and sorted out the routing, state management and abstractions for dealing with our data. But they were writing views and features after a week pretty well. I had to point out some performance issues in code reviews but that was mainly it.
> I don't know what other experience you have, but probably. At my previous job, I got a bunch of silicon production test engineers, that spend most of their day writing VBA, "productive" in React within a week.
It depends on your definition of “production”. I got a couple of developers who had spent a decade+ supporting a PowerBuilder app and writing stored procedures.
Their C# code was a horrible mess.
My former CTO (55 years old and his idea of research was coding POCs - smart guy), said he wouldn’t hire “old people” any more to do front end work because their front end designs weren’t as good as people who started out doing front end work and have been doing it for years.
All of his back end developers/architects were older.
If your resume shows you job hop regularly, then I’m going to want you to be productive very quickly.
If your resume gives me the impression that you are likely to still be working here for enough years, then I’ll give you time to get up to speed. If you were a really great front end developer in 2015, I suspect you can figure out Typescript/React.
I sucked back then too at front end development :).
I knew enough to copy/paste/pattern match an existing page and make the necessary change. But you start me with a blank slate and give me a mock-up, I would end up using tables and frames like it’s 1999.
During Covid I had a colleague, mainly web/js/angular dev, join the Android team. It was a new project to him, so he had 0 idea of the business problems, flows, etc.
In a timeframe of 1-2 weeks he was making PRs. It needed quite some reviews from me, usually because he didn't know about "how it should behave" on Android, or what the best practices were in terms of using Kotlin or following our architecture. After 2-3 months he was as proficient coding as I basically (but we all know, coding is 50%).
i did this with php and python in two different jobs. i had very little php experience and never worked with any php framework before, but the team i was in consisted mostly of junior developers, so i ended up writing better code than any of them except the team lead. laravel was also very easy to understand.
at another job i started with only some rudimentary python experience. they had an inhouse framework, so being deeply familiar with python frameworks and libraries would not have even helped me. they knew i had experience in other languages and it worked out pretty well.
most recently i had an interview where it was very clear that i haven't done any work on go before. at least during the interview that was not an issue. after the interview they wanted me to send them code examples of previous work. i didn't get the job, but i don't think lack of go experience was the problem.
I seriously think you owe it to yourself to practice learning something new every week. It often takes one afternoon to get a “taste” and small side project to get beyond that.
Every programming language. Is literally just a template for instructions, and every technology just an abstraction over some crud somewhere.