I’ve been a software developer all my life, and I’d like to think that I’m pretty good at it. I might not be a math or finance genius, but in terms of the process of developing software: from the very start of figuring out what users want and what they actually need, all the way towards the end of dotting the i’s and rolling out a piece of software that is sleek, elegant and maintainable, I consider myself a craftsman. I care about providing a polished experience to my end users and writing maintainable code that is well structures and well tested. I hate concepts that are poorly named and abstractions that don’t make sense. Sadly, I am finding that this kind of attention to detail just isn’t a useful skill to have when it comes to professional software development.
Why not? In my experience, neither managers not developers really care about maintainable software because no one stays at a company for longer than a couple of years, so they’re not exposed to any of the fallout from making bad technical decisions. Forgot to write tests? Doesn’t matter — the manager wants the thing rolled out right away so let’s just launch it. We might pay lip service to the idea of cleaning it up later, but we all know that never happens. Vice versa: everyone I know who has stayed at the same company for a long time has developed powerful auras of uncaring, and the idea of code quality just bounces off them.
As far as professional software development goes, change is clearly the most profitable career path: you deliver results rapidly and you leave before it needs to be maintained, which makes sense, because your salary will grow faster if you keep switching jobs.
This is also where the major challenge in professional software development lies: whether as a manager, tech lead or senior developer, how do you deal with people whose strategy is either that of “I am going to produce the most awesome unmaintainable thing and then I’m out of here”, or “I’ve been here forever, do whatever you want, I don’t care”? This is where the interests of a corporate software developer and “craftsman” software developer diverge. The latest trend of vibe coding only reinforces this trend — clearly it’s an acceptable strategy to just let an LLM loose on your codebase with only superficial instructions. Now, instead of ten trained developers, you’ve got one hundred randos who can all produce software that helps the company make money — a 10x increase in output and productivity — at least for the next two years. After that, all the people who vibe coded your product have moved on the next fad and your uncaring lifer developers are left to take out the trash. Good luck with that.
So how do you deal with this kind of situation? Well, if you’re one of the people who switches jobs every few years, great news! You’ve got nothing to worry about because you’ll be gone by the time the shit hits the fan. If you’re a lifer or a craftsman, well good luck. Even at the most generous of companies you’ll be hard-pressed to find a manager that will let you spend several quarters rewriting vibe-coded spaghetti messes without having any immediate profit impact to show for it. Other than leaving, the only thing I’ve ever seen work in this kind of situation is this: let it fail. If you can’t deliver a feature quickly because the spaghetti code is too difficult to untangle, don’t work yourself to death trying to get it to work. Let it fail. Let your manager or lead developer feel the impact of their bad technical leadership. Let the company feel the financial impact of writing unmaintable software. It’s the only way to actually get resources devoted to fixing the underlying problems.
Does the “let it fail” approach actually work? I have no idea. In my experience I’ve seen it happen a couple of times. In one case, there were always one or two developers on hand who somehow saved a situation from blowing up into a catastrophe.. every week. Eventually, all the other craftsman developers left, including myself. In another case, the approach did actually lead to proper post-mortems and a drastic change in the hiring budget and quality of the candidates we interviewed, but at the same time, management saw that as an opportunity to further increase the workload, leading to a net zero effect which turned out to be a great example of induced demand, with the new (human) resources being put to work on producing more hastily written slop instead of actually cleaning up the mess they were hired to clean up.
I guess what I’m saying is: I’ve personally not seen a counterexample to “the best strategy as a professional software developer is to quickly produce code that is average at best and then change jobs“. I would love to be proven wrong on that, but I am also deeply skeptical.