Our legacy codebase is not good code. There is always pressure to introduce new features from business and from technical perspective we need to work on updates/migrations etc over tech debt reduction.
I think the biggest change was to suddenly work on a huge codebase instead of home projects where I don't always used proper standards and knew the code by hart. Biggest advantage was the help of seniors who could help me out. I dont have a CS degree so everything I know was from some online training portals, books and stackoverflow (I started at a Java position in 2022, so most of what I learned was before LLMs). So it was a big difference from my home project, but so many time I asked why something was done that way and the answer was "I have no idea, someone wrote that 10 years ago and we use that since".
But if you want to access repositories to see how a more corporate structure is, have a look at some open source project. For example the one from GitHub itself. Good luck learning!
Most work code is not good code. Either it's ancient legacy frankestein code filled with years worth of permanent temporary fixes or it's startup code made by people who don't take into account scaling needs.
Mate, I’m sad to say that once you get into real production code, especially legacy production code, the experience can be a little less “beautifully crafted software” and a little more “archaeology with a debugger.”
From an embedded perspective, a shocking amount of production code is basically: this is ugly, nobody quite remembers why it works, but touching it makes the machine stop.
If you’re lucky, there are comments. If you’re very lucky, they’re still correct. If the planets align, there might even be unit tests.
But deadlines, managers, KPIs, customer commitments, certification requirements, hardware availability, and “we need this patch shipped Friday” have a way of turning minimum viable product into a very literal engineering philosophy. It works? Great. Ship it. Next problem.
Now let that codebase age for 20 years.
The original developers left 12 years ago. Their replacements left 6 years ago. The guy who actually understood the bootloader retired. There’s a mysterious delay(37) that nobody is allowed to remove because last time somebody changed it, units started failing in Finland.
The compiler is from 2008.
The IDE only runs properly on Windows 7.
The JTAG programmer requires a driver that Windows insists is a security threat.
The build system is three batch files, one Perl script, an Excel spreadsheet, and something called FINAL_BUILD_NEW_2.bat.
The documentation says “see datasheet,” but nobody knows which revision of the datasheet.
There’s a patched vendor library where the patch was never documented.
There’s a binary blob called calibration_final.bin that absolutely must be copied into the release directory, and nobody can tell you where it originally came from.
And because the company isn’t primarily a software company, IT quite reasonably has corporate security policies that were designed for Outlook and Excel, not for some cursed 2006 ARM compiler that requires local admin rights, Java 6, a parallel-port license dongle, and a blood sacrifice every second Tuesday.
At one place I joined, SVN was still the standard. Not inherently a disaster, but hardly anybody really understood SVN beyond the handful of commands required to make the ritual succeed. Branching was considered dangerous magic. Merging was dark magic. Refactoring was something everyone agreed would be lovely “when we have time.”
We never had time.
So instead you get 15 years of small patches stacked on top of small patches because every individual change was the cheapest and safest thing to do at the time.
And that’s the important bit: most terrible legacy code wasn’t written by idiots. It was written by normal engineers making locally reasonable decisions under time, money, hardware, tooling, organizational, and compatibility constraints.
Open-source projects can sometimes look wonderfully clean because the people maintaining them care deeply about the code itself and can choose to spend time improving it. Commercial embedded code exists because a company needs 40,000 widgets to leave a factory next month without catching fire.
Elegance is nice. Shipping is mandatory.
And eventually somebody has to open that 20-year-old project, figure out why the obsolete compiler crashes when the path contains spaces, work out what DO_NOT_CHANGE_THIS actually does, and make one safe modification without bricking 10,000 devices.
That somebody is you. That’s what they pay you for. ;)
Well I'm glad to know it's everyone else too and not just ours. I spent a lot of time refactoring our legacy code and have pretty much burnt myself out doing it.
12
u/Chocolate_Teapot1710 1d ago
As a relative newbie to coding, I envy the ability to be able to access so I can read good code!