There's No Limit to How Bad Code Can Get
zachkehs.com
There's No Limit to How Bad Code Can Get
1–10 of 87 posts
Re: There's No Limit to How Bad Code Can Get
#2If you have ever worked with low-cost offshore contractors, you know this it true…
Re: There's No Limit to How Bad Code Can Get
#3The worst I have experienced:
A 30,000-line .cs file.
A giant monolithic program tangled together by Singleton abuse, 6-deep nested if/else blocks, and the list goes on.
There are too many to count. And this is a sight I see every single day.
This is the exact landscape I encounter at many companies when I go in for maintenance work.
Encapsulation completely shattered as a direct reflection of the subcontracting power hierarchy, among other things...
Code that completely disregards collaboration, utilizing outdated algorithms in the name of "optimization" and making it utterly unmaintainable for anyone else.
We learn about ADTs, Result-first approaches, Composition Roots, and code hygiene, yet at some point, code that simply "works" becomes what ships to production.
Communities advocate for building "good software," but the reality in the field is that most of it is "code written just to clock out for the day." I hear "it works, so don't touch it" in dozens of different variations.
The quality of an open-source project contrasts sharply with that of delivered enterprise software. People settle for the "if it works, it's fine" mindset because in open source, the code itself represents personal reputation, whereas in contract deliveries, meeting the deadline is ultimately the core objective...
It feels like the world is always polarized.
Re: There's No Limit to How Bad Code Can Get
#4If you have ever worked with low-cost offshore contractors, you know this it true…
So true.
I worked one place where I had a team of 4 offshore devs replace my two good people. Three months of some of the worst quality work I’ve ever seen. And I was responsible for it on paper.
Decided fuck it, promoted one of them to manager and gave him a project to finish in 3 months, leading the other 3.
In that three months I redid that entire project, did their current project and a week of another one. All in a 25 hour week calendar.
Then I quit.
Re: There's No Limit to How Bad Code Can Get
#5If you have ever worked with low-cost offshore contractors, you know this it true…
A lot of people are going to get a painful lesson in this if companies keep using LLMs to do all their programming.
Re: There's No Limit to How Bad Code Can Get
#6The worst I have experienced: A 30,000-line .cs file. A giant monolithic program tangled together by Singleton abuse, 6-deep nested if/else blocks, and the list goes on. There are too many to count. And this is a sight I see every single day. This is the exact landscape I encounter at many companies when I go in for maintenance work. Encapsulation completely shattered as a direct reflection of the subcontracting powe…
Last place I worked they had an ASP.Net MVC controller with basically the entire product in it. The .cs file was nearly 2 megs.
Re: There's No Limit to How Bad Code Can Get
#7One of my first jobs, was as a maintenance engineer, on a 100KLoC+ codebase of 1979s-era FORTRAN IV.
No comments.
No subroutines (what we now call “functions”).
No variable name longer than 4 characters.
Fun. The most effective debug tool, was a Ouija board. It made me an expert WAGger.
It was the main reason that I am so anal about code Quality, these days. I never want to subject anyone else to that.
BTW: with today’s LLMs, there’s really no excuse for badly-documented, or badly-formatted code. You can write a thousand lines of commercial-grade spaghetti, and tell the LLM to format and document it.
Re: There's No Limit to How Bad Code Can Get
#8The worst I have experienced: A 30,000-line .cs file. A giant monolithic program tangled together by Singleton abuse, 6-deep nested if/else blocks, and the list goes on. There are too many to count. And this is a sight I see every single day. This is the exact landscape I encounter at many companies when I go in for maintenance work. Encapsulation completely shattered as a direct reflection of the subcontracting powe…
I was mainly .NET dev in the first 8 years of my career and it's a pretty common thing among .NET shops/corporates. Most .NET devs I worked with seemed to be on average older guys who are stuck in .NET Framework 3.x days. I joined a place that used .NET 5 and one guy was still writing hash code and equal methods for every single data class he made(by hand too). When I asked him why, he said that he didn't know he doesn't have to do that anymore. Those people are mostly alright/mediocre devs who just refuse to keep up with the times, clock in, clock out, don't think too much, just write some more code to make it work. If someone a decade ago started some convoluted architectural pattern, they'll just continue doing it, no thought given as to why or what for, whether things can be done better.
While I have different, but equally annoying issues with Node/Js world I work in now, I don't miss those .NET days.
Re: There's No Limit to How Bad Code Can Get
#9The worst I have experienced: A 30,000-line .cs file. A giant monolithic program tangled together by Singleton abuse, 6-deep nested if/else blocks, and the list goes on. There are too many to count. And this is a sight I see every single day. This is the exact landscape I encounter at many companies when I go in for maintenance work. Encapsulation completely shattered as a direct reflection of the subcontracting powe…
Last place I worked they had an ASP.Net MVC controller with basically the entire product in it. The .cs file was nearly 2 megs.
I've had a very similar experience. Ironically, simple frameworks like WinForms, or tools that promise easy and rapid development, often turn into the absolute worst-case scenarios for maintenance.
This tendency is especially strong in code-behind frameworks. Because the domain logic directly relies on the state of UI controls, the business logic becomes entirely entangled with the view itself. And what is the result? Every single architectural layer ends up stuffed inside a specific event handler.
I could understand if this came from a small outsourcing shop, but what baffled me was that this was the codebase of the top company in the world in that specific domain.
And to top it off, you sometimes have to integrate with an SDK where the methods are literally named function1, function2, and so on. It is always a thrilling experience.
Re: There's No Limit to How Bad Code Can Get
#10The worst I have experienced: A 30,000-line .cs file. A giant monolithic program tangled together by Singleton abuse, 6-deep nested if/else blocks, and the list goes on. There are too many to count. And this is a sight I see every single day. This is the exact landscape I encounter at many companies when I go in for maintenance work. Encapsulation completely shattered as a direct reflection of the subcontracting powe…
I was mainly .NET dev in the first 8 years of my career and it's a pretty common thing among .NET shops/corporates. Most .NET devs I worked with seemed to be on average older guys who are stuck in .NET Framework 3.x days. I joined a place that used .NET 5 and one guy was still writing hash code and equal methods for every single data class he made(by hand too). When I asked him why, he said that he didn't know he doe…
Older developers in the Node ecosystem still sometimes write callback hells, but it's true that it's less prevalent than in the .NET world.
The problem is that I am the one who has to maintain that code. The reality is that code ultimately follows the prevailing trends and paradigms of its era. Most developers tend to stop growing around their 5th to 7th year (this is purely my observation). They settle into the complacency of having shipped a single complete program, an experience they usually hit around their 4th year. As a result, when you do actual maintenance work, you end up facing things like C++98 code or .NET codebases where the dependency graph is a complete disaster.
Compounding the issue is that these types of companies have very little technical exchange with the outside world. And that specific way of writing code ends up acting as a sort of gatekeeping mechanism.
Sometimes, I feel like programming ultimately boils down to how well you can read and adapt to these shifts in paradigms. The coding trends of today will likely become the outdated legacy of tomorrow, and someone might eventually tell me, "You write old code." It is always a difficult problem.