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

Generally bad, good, great? How much variance?

Comments

[Christopher Wright]

[Jon Randy 🎖️]

From the sublime to the ridiculous. Mostly towards the latter

[Lucas Barret]

I have not worked in a lot for now.
But I would say pretty much good and even great :)

[ImTheDeveloper]

Pretty bad if I've authored them.
I envy every other I look at 😂

[Shasheesh Purohit]

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.

[Matthew Daly]

Variable from absolutely god-awful to acceptable. Certainly none that made me weep over how elegant they were.

[Ben Sinclair]

While working on anything that does financial transactions...

It's all floats down here.

[Visakh Vijayan]

From poor to good. Yet to reach really good.

[Mike Stemle]

I tend to think all code is wonderful, but there’s always work to do. I’m that weirdo who likes reading code, even challenging code.

[Randall]

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.

[Alan Barr]

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.

[Tyler V. (he/him)]

Getting better each time I start a new project 😅

[Kittisak Ma]

Initially, I wrote code that wasn't up to par. However, as I delved deeper into the Clean Code concept and started using tools like SonarQube, my coding skills improved significantly.

[Erik Dietrich]

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.

[Ryan Brown]

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.