How would you describe the quality of the codebases you've worked on in your career?

It's gone down over time! At my first software job we had a very high quality codebase and a lot of effort was put into keeping it that way. As a junior, I didn't know how to do that, and code reviews for my code lasted for weeks sometimes, with hundreds of comments and change requests. It could be frustrating, but in hindsight it was good for me.

Now I work at a startup where most of the founding engineers were juniors. Basically our codebase is like what I might have built at my first job if I had been given completely free reign. We have a lot of technical debt slowing us down, and there are some real facepalm moments when looking at the existing code, but we are getting better.

The range of quality is wide as the universe itself, but not just the range, the obscurity of some tools and languages also.

Worked almost for a year on the framework so obscure that search results on any search engine known to humankind leads to single source and it is its poorly written documentation. It was written in Pike (which was actually interesting, but didn't get to use it much). This was server-side website coupled with client-side VueJS components. Data-flow was crazy as we needed server-based data to show on client-side and when you change something, server needed to process the input from client-side without refreshing the page.

Files with 40k+ lines that required compass and Antikythera mechanism to navigate through the codebase. Crazy.

But also worked in a company where I had great team leader that pushed code quality as number 1 on the list of requirements for every project. If I have to single out most satisfying work that I've done, I would mention work done for this team.

There are more horror stories, some more some less scary, but I wanted to share those two.

For a number of years, I had a management consulting practice oriented mainly around running static analysis on codebase to build a relational model of it, and then helping management make decisions around it (often retire/evolve/abandon/rewrite type things). During this time, I assessed a lot of codebases and also robo-analyzed something like 1K of them for seed data to place clients in percentiles on concerns like coupling, cohesion, dependency management, etc.

FWIW, I'd generalize some observations:

1. The main determining factor for our (developers as a whole) collective assessment of the code seems to be, subconsciously, "did I write it" (good) vs "did a teammate write it" (depends what I think of the teammate) vs "did an unknown, departed party write it" (bad). Sort of tongue in cheek in the oversimplification, but largely true.
2. Most codebases were worse than leadership thought in terms of cost of change, better than developers thought in terms of maintainability.
3. Just about every codebase has something in it that transcends bad and gets into "astonishing" territory, but that rarely defines the whole codebase.
4. Rewriting a codebase is almost always a bad idea without substantial change in the team structure.

YMMV.

Missed opportunities.

Futures not achieved are only branches of the past: dead branches. - Italo Calvino

Short, tall, deep, shallow. The most rewarding experiences are well-formed APIs and content management systems. It takes years for that to happen, and most projects are destined for the wastebasket of history.

Your time is a gift to the next person, make the most of it.

From the sublime to the ridiculous. Mostly towards the latter

Well most of the time what I felt like was, the developers try to keep the codebase as generic and scalable (good basically) as possible but the product team always have requirements on such UNREALISTIC deadlines that it keeps adding to the tech debt with codebase getting very bad.

In my first job, my first project was an authentication and authorization service. I got to start from zero, so the codebase looked like I wanted. Built a REST API with PHP, MVC, etc. it was nice.

The second task was maintaining an GUI. It was a 2 year old project, built by an external company that didn't work with us anymore. It was a window manager that ran in the browser. The idea was nice, but the architecture was a disaster. They would run PHP on the server that generated JavaScript dynamically, a bit like the GWT does with Java. Problem was, the generated JS code was horrible. On every click it would generate hundreds LoC, deeply containing deeply nested "with" statements and send it to the client for execution. It was just after the release of PHP4, when classes were introduced to the language, so they tried to rewrite the code to OOP, but they had no experience in doing so. In the end there was one big class in a file with 10k LoC that did everything.

Over the course of a year, I rewrote the whole GUI in ExtJS4 with an REST server in PHP, and then left the company.

I like that they called the REST server a HTTP-API, because back in the days, people would use the word API for all kind of things, and not just HTTP APIs. I was quite confused when I left the company and saw that people were only using HTTP APIs anymore. Even with the rise of native mobile apps, HTTP stayed. I would have expected devs to drop to TCP or UDP when you have a native app, but whelp.

Anyway... after that I worked at a start-up where a prodigy coder tried to pull off a web service with the newest tech he could find. I think he rewrote that whole codebase at least 3 times each time he pulled an all-nighter during the weekend. First in CoffeeScript, then in ES6, and then he switched Flummox for Redux. The codebase was so overengineered, with so many indirections, I didn't really know what was going on. That was the project where I learned React, not even a year after it was released, lol.

Next project was in React Native. I thought, I know React and JS, and React-Native is supposed to make mobile development easier. Greenfield again, pretty nice from the start. But then I learned that React-Native doesn't save me from interacting with the native app code in Java and ObjectiveC. Well, it didn't, at least not until Expo became mainstream.

Another adventure was the REST API I got from the backend developer. He would send JSON responses hand-rolled via string-concatenation. No tests, so every time something on the backend changed, there the JSON was broken because some " or . was missing.

That was the time I started blogging here on Dev.to. For fun, and to promote my freelance work. After I did another freelance project, companies wanted to hire me for tech writing, so I stopped doing bigger projects and started writing full-time. Now, most of my codebases are for my articles, and not very big, which is a quite nice place to be in.

Frightening, Faulty, Functional, and occasionally beautiful.

Fit for purpose (or not), Fit for use (depending on how you use it)

I started working at a single (then two) product company, and worked hard to bring up the quality of the codebase from the cargo-cult-coding introduced by the CS Major Manager and the much maligned previous developers. (Monolithic singletons so as to check the Object Oriented box as an example

For the last 10+ years I've been at a non-it company that has a substantial in-house built collection of smaller apps and utilities. These have of course varied providence including fully contracted build, in house built by contractors and in house built by employees plus every combinations of these. Some solutions are as small as a single script consisting of less than 30 loc. Others are full on multi-component ecosystems of interdependent tools.

In most cases the quality of the code was moderately correlated with the individual contributors. We had several High-Quality devs pass though and I've been lucky to learn from them. Some have been instrumental in my own developer journey. When I have to review/revise a project that was created by them, it is generally a much more pleasant experience than some of the others.

I endeavour to continue their legacy, and improve.

I was gifted with public feedback recently from one of them who had left and returned as a contractor. It was that when @ryencode writes code, it's build properly and is easy to understand and extend. Coming from one of my former mentors, it was an amazing boost.

I've seen everything: bad, good, excessively complex. For example, some of the codebases I've found in a single phrase:

• we don't know what we're doing, dump everything into a single file
• we know what we're doing but we're too late, do what you have to do
• we write perfect clean code, use DDD with events for this simple CRUD application