I couldn't agree more. Writing code was always the easiest part of the job (sure, it has its hard moments where you have to solve complex problems, but that's the fun part). The hardest parts for me have always, always been:
- dealing with non-technical project managers
- dealing with "rockstar" developers that only want to work on greenfield projects
- maintaining legacy
- trying to anticipate potential design flaws or observability blindspots
- dealing with nasty bugs in production (and reproducing the bug!) and trying to get the right people in a room to solve them
All in all, the human aspect was always the hardest part, and as this article clearly states, is now even harder. You can't replace decades of crisis situation that might not have been documented, late nights spinning prod back up or using our human friendships to get devops guys to help us out with admin tasks! (Costs a few beers, instead of millions of tokens!)
tpmoney · 2h ago
On the other hand, LLMs actually can help with a lot of these “human aspect” problems, which to my mind boils down mostly to transferring information between humans is hard.
The focus on just the writing code aspect skips over that some of these models can be really good at reading code, faster than you can as a human, and pointing you in the right direction. Maintaining legacy code is hard for a number of reasons but one of those is that reading code is like trying to read someone else’s mind. If you don’t have the same mental view of the software they do, it’s going to be harder to understand what it’s doing. Lots of anticipating flaws comes from knowing best practices and from either direct experience, or having read other peoples experiences and extrapolating that to your code. Likewise finding bugs is often a lot of code reading combining with experience to identify things that look wrong and then testing that theory.
LLMs can help with all of this, and even better they don’t have to be exactly right so long as they don’t drive you down a non-existent rabbit hole. You can ask an LLM why some code might be exhibiting a behavior or where some behavior is implemented and the LLM can very quickly get you most of the way there. They don’t have to be right about how a shell script gets called to point you to the shell script being the location something happens. They don’t have to be right that the bottle neck in your code is at line 4583 to get you to a buried hot loop with bad performance.
Sure they’re not replacement for a dev with 10 years experience with the system and who was there when the specs were written. But you don’t always have that resource at your disposal. Sometimes you’re working on a system that was written decades ago for a world that doesn’t exist anymore, patched by teams that have since come and gone who also didn’t have that knowledge and held together by sheer force of will and developer grit. On a project like that, anything that can help you search that code base quickly and especially with fuzzy descriptions is absolutely a boon.
ajd555 · 1h ago
You're right, I certainly agree with your assessment that it can be an invaluable tool to search through codebases quickly! No team can process it that quickly, especially if, like you say, this was written by a team that no longer exists.
kevin42 · 4h ago
The same thing came up in the early 2000s when businesses tried offshoring software development. It turns out that translating business requirement to technical design and implementation is one of the hard parts of software development. In a pure waterfall model, this works ok, but you rarely know what you want until the end users see it. This is while agile is so important.
I hate to say it, but with over 30 years experience as a software developer in various roles, writing code has never been the hard part of delivering a successful project.
devstein · 4h ago
Couldn't be more spot on. This is exactly why I started Dosu https://dosu.dev/ to reimagine on the "knowledge" side of software engineering.
- dealing with non-technical project managers
- dealing with "rockstar" developers that only want to work on greenfield projects
- maintaining legacy
- trying to anticipate potential design flaws or observability blindspots
- dealing with nasty bugs in production (and reproducing the bug!) and trying to get the right people in a room to solve them
All in all, the human aspect was always the hardest part, and as this article clearly states, is now even harder. You can't replace decades of crisis situation that might not have been documented, late nights spinning prod back up or using our human friendships to get devops guys to help us out with admin tasks! (Costs a few beers, instead of millions of tokens!)
The focus on just the writing code aspect skips over that some of these models can be really good at reading code, faster than you can as a human, and pointing you in the right direction. Maintaining legacy code is hard for a number of reasons but one of those is that reading code is like trying to read someone else’s mind. If you don’t have the same mental view of the software they do, it’s going to be harder to understand what it’s doing. Lots of anticipating flaws comes from knowing best practices and from either direct experience, or having read other peoples experiences and extrapolating that to your code. Likewise finding bugs is often a lot of code reading combining with experience to identify things that look wrong and then testing that theory.
LLMs can help with all of this, and even better they don’t have to be exactly right so long as they don’t drive you down a non-existent rabbit hole. You can ask an LLM why some code might be exhibiting a behavior or where some behavior is implemented and the LLM can very quickly get you most of the way there. They don’t have to be right about how a shell script gets called to point you to the shell script being the location something happens. They don’t have to be right that the bottle neck in your code is at line 4583 to get you to a buried hot loop with bad performance.
Sure they’re not replacement for a dev with 10 years experience with the system and who was there when the specs were written. But you don’t always have that resource at your disposal. Sometimes you’re working on a system that was written decades ago for a world that doesn’t exist anymore, patched by teams that have since come and gone who also didn’t have that knowledge and held together by sheer force of will and developer grit. On a project like that, anything that can help you search that code base quickly and especially with fuzzy descriptions is absolutely a boon.
I hate to say it, but with over 30 years experience as a software developer in various roles, writing code has never been the hard part of delivering a successful project.