The 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.

▲

atraac 17 hours ago | parent | next [-]

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.

	▲	jdw64 17 hours ago \| parent [-]
		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.

▲

grebc 2 hours ago | parent | prev | next [-]

6 deep is some rookie numbers, get those indent levels up.

I actually have no problem with most the code in one file vs. lots of little files. That said right click "Go to definition" is a lovely feature in VS.

▲

PhilipRoman 17 hours ago | parent | prev | next [-]

I can believe that... We've had logging macros break because line numbers no longer fit in an u16

I would love a TV show like "Hell's kitchen" except it's code bases and development processes.

▲

aDyslecticCrow 17 hours ago | parent | prev | next [-]

> 6-deep nested if/else blocks

We found a 4000 Loc single-file single-function c program running a functional safety domain. With nesting so deep that you need to change the font-size or get a wider monitor. We're not allowed to touch or replace it because it's pre-certified.

	▲	SoftTalker 17 hours ago \| parent [-]
		Deeply nested if/else blocks are logically the same if you split them up into classes or functions that perform the same logic. They are harder to understand, harder to re-use, harder to work with in an editor... but should not be harder to test (you need to test all the possible use cases either way).

▲

sdcfgy 18 hours ago | parent | prev [-]

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.

	▲	jdw64 17 hours ago \| parent [-]
		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.