💾 Archived View for gemini.panda-roux.dev › log › entry › 36 captured on 2022-04-29 at 11:45:29. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
Posted on Monday October 4, 2021
I was inspired by ew0k's post on warmedal.se today, as it deals with a subject that I am familiar with myself; namely, maintaining legacy software.
In this post, ew0k describes a scenario in which they picked apart an ugly piece of script that had grown over the years into something oversized and ultimately useless.
Below are my thoughts on the subject of legacy code. I have a lot of feelings about this, as you'll see. I apologize for the ranting quality in advance.
I've been maintaining and extending legacy systems for a decade now. I don't enjoy it very much (who does?), but it pays the bills and I'm grateful to be able to earn a middle-class wage doing something I am good at.
There have been a few occasions when I've put my foot down and insisted on rewriting some feature in its entirety; sadly, however, time-constraints and the demands of customers often preclude such luxuries. Typically, band-aid solutions are the only way to satisfy management. So it goes.
Something a former coworker taught me to value is consistency and personal growth. Consistency in everything; personal growth as a rule. Having been confounded by my own sloppy work several years after the fact, I've become dogmatic in my pursuit of the former. It's real important to me that I can maintain my own damned code, you know? Learning new things feels good.
Sadly many of the veteran developers I've worked with do not value quality or consistency. The companies themselves don't give a shit about the quality of their products, and are happy to continually fix the same issue as it comes up again and again throughout the years. The developers, in turn, internalize this attitude, and the cycle continues ad infinitum. The result is that a culture of "good enough" is tempered over the years until it's baked into every facet of the company's development process. It's band-aids all the way down. What's most important to the company owner (and by extension management, sales, etc.) is shipping software to the customers they're desperate to please.
Turnover exacerbates this process exponentially. Developers come and go over the years: they bring with them a naive disregard for standards and consistency (again, the company couldn't care less), and when they leave they take with them the sole knowledge of how "this one temporary (7000-line) workaround" was ever supposed to work. It goes without saying that the "comments" feature of a language is only ever used for turning things on and off without explanation, or if you very lucky, leaving an unhelpful witty remark above a "clever hack" they devised.
To quote ew0k:
Every time a new requirement was introduced a programmer had just added it, because they didn't want to do the work required to understand their job.
It's astounding the lengths that some developers are willing to go to in order to avoid giving a single shit about the work they do, especially when they aren't actively incentivized to do so. I've seen coworkers repeatedly re-inventing constructs that are built into the .NET framework because they just, somehow in their 20 years on the job, have never bothered to look for an alternative.
I don't know if it's a generational thing or what, but it's frankly disturbing how content some people are to just settle into their happy little mediocrity bubble where they don't have to think, and never even for a second think that maybe there's a better way to do things.
ew0k ended their post with a piece of advice:
A part of your job is to understand the requirements and codebases you work with. This isn't just about the code either: if you properly understand the requirements you'll often end up writing less code
I have tried to coach others on taking a similar attitude, to mixed results.
With the veterans it's hopeless. They've "Always done things this way" and, when presented with an alternative will remark how "That's cool," and settle right back into the habits they've seared into their brainstems. Don't waste your time.
In my experience a lot of programmers don't want that. They just like to code.
With younger developers, especially those just entering the labor force, I've seen about a 50/50 split in results. Some folks are overwhelmed by the new-ness of the professional environment, and put too much stock in the perceived authority (and thus competence) that the veterans possess. They then proceed to shut off their critical thinking faculties out of fear that going against the grain will result in termination or something, and carefully emulate the patterns of the "masters" as closely as they can.
On the other hand, when newer developers feel supported and encouraged to grow, they'll find that when they try new things they'll often achieve much more reliable and consistent results. It's a joy to see folks actively engaged with things they enjoy in this way. Change is scary but growth is extraordinarily satisfying, and we ought to foster this sort of attitude in less-experienced workers in any way that we can, as a rule.
Challenging ourselves to go against the status quo is the only way we can learn and grow as professionals (and as people).
That coworker who mentored me years ago had encouraged me to question the company's long-established traditions. The eventual result was that I felt comfortable challenging myself and learning new skills on the job, and more confident in myself overall.
The company still doesn't give a shit; their attitudes won't ever change. They will happily exploit my labor no matter my outlook. A more reliable product just means fewer support calls as far as they're concerned. What matters to me is that I feel like I'm spending eight-to-ten hours per day learning and challenging myself, for my own sake, to do work I'm proud of. That's rewarding as hell.
- panda-roux -