alt Hacker NewsThere 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.
Replies
>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.
> 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
Thank you for this.
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.