Comment by gyomu
3 days ago
There are two kinds of developers.
There's the kind that, when given a problem, will jump in, learn what they need to learn to solve the parts they don't fully understand yet, deliver meaningful iterative results, talk to people as needed, keep you posted on their progress, loop in other team members and offer/request help to/from them, take initiative on the obvious missing parts that would benefit the project as a whole, etc.
And then there's the rest.
Within the first few years of someone's career, you can quickly tell which kind they are. It's almost impossible to turn someone from the latter group into the former.
Yes, everything else is a façade. You can be a "senior" developer with 30 years of experience and still be in the latter group. And you can be fresh out of college and be in the former.
Now some people are extremely good at other skills (politics, interpersonal communication, bullshit, whatever you want to call it) and will be able to seem to be in the first group to the people who matter (managers, execs, etc) while actually being in the second group. But then we're not talking about actual software-making skills anymore.
You can also totally be in the first group and be underpaid, never promoted, etc. There's little correlation with actually career success.
I'd color this a little. I think there's also an engineering mindset some people have, and some don't. And over 10 years in, I'm still not sure if it can be trained or not. Some people are just really good at seeing the technical solutions in terms of engineering: Where does the data live, where does it go. How does it get there, how does it change. How does it break, how will we know, how will we fix it, how will we cope with its shortcomings. All of those questions to some people are a relatively quick and intuitive part of scoping and design. And for others its like a constant cliff they run into midway through their projects, or worse (and far more common) a set of bugs that are "tech debt" (for someone else to inherit) as the slap the "Mission Accomplished" on yet another project.
I've seen people that are very proactive and generally fall into your former group, but also don't quite seem to think like an engineer. I really want it to be trainable - I am trying - but IDK if it is or not.
>It's almost impossible to turn someone from the latter group into the former.
Only if you're constrained by the same short-term thinking as US businesses. The way to do that is more of an apprenticeship model when someone observes/works closely with someone from the first group over years.
Even then, the businesses don't want to pay for that, and why should the workers give that away for free? They want people to churn out code because they've chosen to hire micromanagers that need constant updates and babysitting through communication.
My experience is that that plainly does not work. I work with developers of both types, and the junior ones who are part of the first group are limited in their ability by experience, but they have an inquisitive mind and don't give up quickly when they encounter something they don't understand.
Much more experienced developers of the second type just throw their hands up and give up (or now: turn to AI). I've worked closely with them to try and reform them. Maybe I'm doing it all wrong, but it has never succeeded.
With the ones from the first group it can work that way: you can show them how you approach problems and they will ask questions and pick up patterns and you'll see them improve.
> Even then, the businesses don't want to pay for that, and why should the workers give that away for free?
Businesses would need a high likelihood that they can reap the rewards of upskilling employees. Why invest a lot of money and high-talent attention into someone who might quit? At the same time, I'll happily pay three times as much for a truly skilled senior developer. I think the employee's incentives are much more aligned: it will increase their market value, it's an investment into their wealth, not the business'.
>My experience is that that plainly does not work.
The apprenticeship model isn't in practice at any scale in software, I don't see how you could believe that. Practically every career start is self-taught or university to junior positions which is not the high-attention, one-on-one focus you'd get.
>Why invest a lot of money and high-talent attention into someone who might quit?
What happens if you don't and they stick around? You might say 'well, I'd just fire them' but then you are going to have a culture of people always having one foot out the door. And a high amount of position switching in the industry has led us to what we have today where people don't really stay and build for the long-term, and shoddy code bases also drive people to quit.
An apprenticeship model also helps if you can do 3-5 year agreements for training where you see the most benefit from the person in the last 1-2 years.
As good as it has been for my career, switching often probably needs to slow down (while raises go up) and apprenticeships go into effect for better quality training.
All this assuming there isn't another major leap in AI competency though.
I highly agree. Let us stop talking about software dev and look behind the curtain a bit...
I want to point at the discouraging framing of developers who learn to be helpless whenever they are stuck in an organization for long enough where they start to believe they cannot do better and there is something that cannot be changed.
The majority of people I met started out in the former group but have been reshaped by the environment they are in.
If you are in the former group and find yourself turning into someone from the latter group, becoming unrecognizable to your past self, ask yourself if you have been reshaped by the organizational experience you were having and where that spark went.
The chance is very high the organization figured out how to keep you in your position or you have internalized things about your professional self at face value that do not depict reality outside the org and that start to affect deeper layers like your confidence and outlook.
You start to identify with the made up labels or arbitrary hurdles of reaching some next level that will change everything. Essentially you are in a box and you developed tunnel vision, could be dept, org, branch or industry wide.
Just bash your head against a project away from work for 3 months on the side and gauge for yourself how capable you are with no economic intention disregarding time and value investments and so on. Repeat this long enough to fill any gaps in knowledge you encounter and at some threshold the coin flips again.
You will do DevOps but you are no DevOps guy, you do Frontend but you are no Frontend guy. Just a free flowing human walking through the layers that create something real.
There is an art in unplugging yourself from economics and thinking in organizational hierarchies and patterns and I think if most of us see it for what it is, software would turn into a calmer place, grounded closer in reality.
> There's the kind that, when given a problem, will jump in, learn what they need to learn to solve the parts they don't fully understand yet, deliver meaningful iterative results, talk to people as needed, keep you posted on their progress, loop in other team members and offer/request help to/from them, take initiative on the obvious missing parts that would benefit the project as a whole, etc
You're framing this person as a good developer, and sure. Probably some people who behave like this are good. MANY people who are like this leave mountains of problems in their wake. It takes a very special person to be able to build good quality with this kind of approach.
You're basically taking about someone getting the right answer on the fly at full speed
It's much more likely to get a subtly wrong answer, which is then dropped on that second group to manage and maintain going forward, while the fast moving person is hurried along to go drop a subtly wrong solution on another project with another team. This has happened to me many times in my career
> There's the kind that, when given a problem, will jump in, learn what they need to learn to solve the parts they don't fully understand yet, deliver meaningful iterative results, talk to people as needed, keep you posted on their progress, loop in other team members and offer/request help to/from them, take initiative on the obvious missing parts that would benefit the project as a whole, etc.
I would rather tweak that a bit and say, we need a kind that has two things: 1. aptitude - not genius or 10x something just plain being able to think clearly and having problem solving skills 2. care i.e. not just dump whatever hack works in the short-term and declare victory. It doesn't imply that you obsess over perfection and ignore deadlines etc. But basic care about the solution being sensible, good code quality and not causing a new set of problem due to shortcuts. Both are things we routinely expect from programmers and I see less and less of them. #2 is rarer than #1.
Thank you for this.