Generative AI Is Not Going To Build Your Engineering Team For You - Stack Overflow
Software is an apprenticeship industry. You can’t learn to be a software engineer by reading books. You can only learn by doing…and doing, and doing, and doing some more.
To me, being a senior engineer is not primarily a function of your ability to write code. It has far more to do with your ability to understand, maintain, explain, and manage a large body of software in production over time, as well as the ability to translate business needs into technical implementation. So much of the work is around crafting and curating these large, complex sociotechnical systems, and code is just one representation of these systems.
What does it mean to be a senior engineer? It means you have learned how to learn, first and foremost, and how to teach; how to hold these models in your head and reason about them, and how to maintain, extend, and operate these systems over time. It means you have good judgment, and instincts you can trust.
By not hiring and training up junior engineers, we are cannibalizing our own future. We need to stop doing that.
It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day.
Sociotechnical systems consist of software, tools, and people; understanding them requires familiarity with the interplay between software, users, production, infrastructure, and continuous changes over time.
You may save time by not having to type the code in from scratch, but you will need to step through the output line by line, revising as you go, before you can commit your code, let alone ship it to production.
If what you need is effectively copy-paste with a template—any time you could generate the code you want using sed/awk or vi macros—generative AI is quite good at this.
One of the engineers I work with, Kent Quirk, describes generative AI as “an excitable junior engineer who types really fast”.
Disposable code is rare; code that needs to work over the long term is the norm.
Your effort is worth more when it is invested into someone else’s apprenticeship. It’s an opportunity to pass on the lessons you’ve learned in your own career.
When it comes to hiring, we tend to valorize senior engineers almost as much as we underestimate junior engineers.
This is an apprenticeship industry, and productivity is defined by the output and carrying capacity of each team, not each person.
In terms of writing and shipping features, some of the most productive engineers I’ve ever known have been intermediate engineers. Not yet bogged down with all the meetings and curating and mentoring and advising and architecture, their calendars not yet pockmarked with interruptions, they can just build stuff.
The smallest unit of software ownership is not the individual, it’s the team.
A monoculture can be spectacularly successful in the short term—it may even outperform a diverse team. But they do not scale well, and they do not adapt to unfamiliar challenges gracefully.
the most effective mentor is usually someone just one level ahead, who vividly remembers what it was like in your shoes.
Components can be automated, but complexity can only be managed.
large software systems are unpredictable and nondeterministic, with emergent behaviors
Writing code is but a sliver of what professional software engineers do, and arguably the easiest part.
