This blew up way more than I expected. Thanks everyone for the comments, I read almost all of them.
For the sake of not repeating myself, I would like to clarify/state some things.
1. I did not intend to signal that SWE will disappear as a profession, but would rather undergo transformation, as well as shrinking in terms of the needed workforce.
2. Some people seem to be hanging up to the idea that they are doing unimaginably complicated things. And sure, some people do, but I doubt they are the majority of the SWE workforce. Can LLM replace a cobol developer in financial industry? No, I don't think so. Can it replace the absurd amount of people whose job description can be distilled to "reading/writing data to a database"? Absolutely.
3. There seems to be a conflicting opinion. Some people say that code quality matters a lot and LLMs are not there yet, while other people seems to focus more on "SWE is more than writing code".
Personally, based on some thinking and reading the comments, I think the best way to future-proof a SWE career is to move to position that requires more people skills. In my opinion, good product managers that are eager to learn coding and combine LLMs for code writing, will be the biggest beneficiaries of the upcoming trend. As for SWEs, it's best to start acquiring people skills.
Moving from an engineering role to a product role is a massive career change. I don't think this is reasonable advice, even with the current technological revolution, unless you have a deep, personal interest in product management.
Code quality does not affect final product quality IMHO.
I worked in companies with terrible code, that deployed on an over-engineered cloud provider using custom containers hacked with a nail and a screwdriver, but the product was excellent. Had bugs here and there, but worked and delivered what needs to be delivered.
SWEs need to realize that code doesn't really matter. For 70 years we are debating the best architecture patterns and yet the biggest fear of every developer is working on legacy code, as it's an unmaintainable piece of ... written by humans.
> Code quality does not affect final product quality IMHO.
What we need, admittedly, is more research and study around this. I know of one study which supports my position, but I'm happy to admit that the data is sparse.
The parent point isn't that shitty code doesn't have defects but rather that there's usually a big gap between the code (and any defects in that code) and the actual service or product that's being provided.
Most companies have no relation between their code and their products at all - a major food conglomerate will have hundreds or thousands of IT personnel and no direct link between defects in their business process automation code (which is the #1 employment of developers) and the quality of their products.
For companies where the product does have some tech component (e.g. refrigerators mentioned above) again, I'd bet that most of that companies developers don't work on any code that's intended to be in the product, in such a company there simply is far more programming work outside of that product than inside of one. The companies making a software-first product (like startups on hackernews) where a software defect implies a product defect are an exception, not the mainstream.
Having poor quality code makes refactoring for new features harder, it increases the time to ship and means bugs are harder to fix without side effects.
It also means changes have more side effects and are more likely to contain bugs.
For an MVP or a startup just running off seed funding? Go ham with LLMs and get something in front of your customers, but then when more money is available you need to prioritise making that early code better.
Much like science in general, these topics are never -- and can never be -- considered settled. Hence why we still experiment with and iterate on architectural patterns, because reality is ever-changing. The real world from whence we get our input to produce desired output is always changing and evolving, and thus so are the software requirements.
The day there is no need to debate systems architecture anymore is the heat death of the universe. Maybe before that AGI will be debating it for us, but it will be debated.
Maybe I'm a lousy developer, true. But I do know now that your code does not matter. Unlike any other creative profession, what matters is the final output, and code is not the final output.
If companies can get the final output with less people, and less money, why would they pass on this opportunity? And please don't tell me that it's because people produce maintainable code and LLMs don't.
Exactly because lines pf code is not the ultimate result but rather a mean to an end - software _engineering_ profession is not at risk in any way.
If you don’t get it - you are not lousy, just not experienced enough or as I say - not doing engineering. Which is fine. Then your fear is grounded.
Because only the non creative professions like devops, sre, qa to some extent, data engineering to some extent are at _some_ risk of being transformed noticeably.
It's a good advice indeed. But there is a slight problem with it.
Young people can learn and fight for their place in the workforce, but what is left for older people like myself? I'm in this industry already, I might have missed the train of "learn to talk with people" and been sold on the "coding is a means to an end" koolaid.
My employability is already damaged due to my age and experience. What is left for people like myself? How can I compete with a 20 something years old who has sharper memory, more free time (due to lack of obligations like family/relationships), who got the right advice from Carmack in the beginning of his career?
The 20-year-old is, maybe, just like you at that age: eager and smart, but lacking experience. Making bad decisions, bad designs, bad implementations left and right. Just like you did, way back when.
But you have made all those mistakes already. You've learned, you've earned your experience. You are much more valuable than you think.
Source: Me, I'm almost 60, been programming since I was 12.
I think the idea of meritocracy has died in me. I wish I could be rewarded for my knowledge and expertise, but it seems that capitalism, as in maximizing profit, has won above everything else.
You are rewarded for something that is useful to the market, i.e. to other people (useful enough so they agree to pay you money for it). If something you know is no longer useful, you will not be rewarded.
It was true 100 years ago, it was true 20 years ago, and it is true now.
It's good advice, but not easy to follow, since knowing what to do and doing it are very different things.
I think that what he means is that how successful we are in work is closely related to our contributions, or to the perceived "value" we bring to other people.
The current gen AI isn't the end of programmers. What matters is still what people want and are willing to pay for and how can we contribute to fulfill that need.
You are right that young folks have the time and energy to work more than older ones and for less money. And they can soak up knowledge like a sponge. That's their strong point and older folks cannot really compete with that.
You (and everyone else) have to find your own strong point, your "niche" so to speak. We're all different, so I'm pretty sure that what you like and are good at is not what I like and I'm good at and vice-versa.
All the greats, like Steve Jobs and so on said that you've got to love what you do. Follow your intuition. That may even be something that you dreamed about in your childhood. Anything that you really want to do and makes you feel fulfilled.
I don't think you can get to any good place while disliking what you do for a living.
That said, all this advice can seem daunting and unfeasible when you're not in a good place in life. But worrying only makes it worse.
If you can see yourself in a better light and as having something valuable to contribute, things would start looking better.
> All the greats, like Steve Jobs and so on said that you've got to love what you do.
This is probably true for them but the other thing that can happen is that when you take what you love and do it for work or try to make it a business you can grow to hate it.
I guess it also depends on how much you love your work. If there wasn't that much interest in the first place, I suppose you can grow to hate it in time. If that happens, maybe there's something else you'd rather do instead?
?? Not sure what you mean. Carmack's advice is not specific to any particular point in your career. You can enact the principle he's talking about just as much with 30 YOE as you can with 2. It's actually easier advice to follow for older people than younger, since they have seen more of the world and probably have a better sense of where the "rough edges" are. Despite what you see on twitter and HN and YC batches, most successful companies are started by people in their 40s.
> How can I compete with a 20 something years old who has sharper memory, more free time (due to lack of obligations like family/relationships),
Is it a USA/Silicon Valley thing to miss the arrogance and insufferability most fresh grads have when entering the workforce?
It's kind of tone-deaf to attempt to self-victimize as someone with significant work experience being concerned of being replaced by a demographic that is notoriously challenged to build experience.
I think coding will stay as a hobby. You know, like there are people who still build physical stuff with wires and diodes. None of them are doing it for commercial reasons, but the ability to produces billions of transistors on a silicon die did not stop people from taking electrical engineering as a hobby.
But the problem is that the majority of SWs are like that. You can blame them, or the industry, bust most engineers are writing code most of the time. For every Tech Lead who does "people stuff", there are 5-20 engineers who, mostly, write code and barely know that entire scope/context of the product they are working on.
> bust most engineers are writing code most of the time.
the physical act of writing code is different than the process of developing software. 80%+ of the time working on a feature is designing, reading existing code, thinking about the best way to implement your feature in the existing codebase, etc. not to mention debugging, resolving oncall issues, and other software-related tasks which are not writing code
GPT is awesome at spitting out unit tests, writing one-off standalone helper functions, and scaffolding brand new projects, but this is realistically 1-2% of a software developer's time
Everything you have described, apart from on-call, I think LLMs can/will be able to do. Explaining code, reviewing code, writing code, writing test, writing tech docs. I think we are approaching a point where all these will be done by LLMs.
You could argue about architecture/thinking about the correct/proper implementations, but I'd argue that for the past 7 decades of software engineering, we are not getting close to a perfect architecture singularity where code is maintainable and there is no more tech debt left. Therefor, arguments such as "but LLMs produce spaghetti code" can be easily thrown away by saying that humans do as well, except humans waste time by thinking about ways to avoid spaghetti code, but eventually end up writing it anyways.
people using GPT to write tech docs at real software companies get fired, full stop lol. good companies understand the value of concise & precise communication and slinging GPT-generated design docs at people is massively disrespectful to people's time, the same way that GPT-generated HN comments get downvoted to oblivion. if you're at a company where GPT-generated communication is the norm you're working for/with morons
as for everything else, no. GPT can explain a few thousand lines of code, sure, but it can't explain how every component in a 25-year-old legacy system with millions of lines and dozens/scores of services works together. "more context" doesn't help here
It's a good point, and I keep hearing it often, but it has one flaw.
It assumes that most engineers are in contact with the end customer, while in reality they are not. Most engineers are going through a PM whose role is to do what you described: speak with customers, understand what they want and somehow translate it to a language that the engineers will understand and in turn translate it into code. (Edit), the other part are "IC" roles like tech-lead/staff/etc, but the ratio between ICs and Engineers is, my estimate, around 1:10/20. So the majority of engineers are purely writing code, and engage in supporting actions around code (tech documentation, code reviews, pair programming, etc).
Now, my questions is as follows -- who has a bigger rate of employability in post LLM-superiority world: (1) a good technical software engineer with poor people/communication skills or (2) a good communicator (such as a PM) with poor software engineering skills?
I bet on 2, and as one of the comments says, if I had to future proof my career, I would move as fast as possible to a position that requires me to speak with people, be it other people in the org or customers.
(1) is exactly the misunderstanding i'm talking about, most creative jobs are not defined by their output (which is cheap) but by the way they reach that output. Software engineers that thought they could write their special characters in their dark room without the need to actually understand anything will go away in breeze (for good).
This entire field was full of hackers, deeply passionate and curious individuals who want to understand every little detail of the problem they were solving and why, then software becomes professionalized and a lot of amateurs looking for a quick buck came in commoditizing the industry. With LLM will go full-circe and push out a lot of amateurs to give again space to the hackers.
For the sake of not repeating myself, I would like to clarify/state some things.
1. I did not intend to signal that SWE will disappear as a profession, but would rather undergo transformation, as well as shrinking in terms of the needed workforce.
2. Some people seem to be hanging up to the idea that they are doing unimaginably complicated things. And sure, some people do, but I doubt they are the majority of the SWE workforce. Can LLM replace a cobol developer in financial industry? No, I don't think so. Can it replace the absurd amount of people whose job description can be distilled to "reading/writing data to a database"? Absolutely.
3. There seems to be a conflicting opinion. Some people say that code quality matters a lot and LLMs are not there yet, while other people seems to focus more on "SWE is more than writing code".
Personally, based on some thinking and reading the comments, I think the best way to future-proof a SWE career is to move to position that requires more people skills. In my opinion, good product managers that are eager to learn coding and combine LLMs for code writing, will be the biggest beneficiaries of the upcoming trend. As for SWEs, it's best to start acquiring people skills.