Ask HN: Have you ever inherited a codebase that you liked?

Usually my first instinct is to hate it but then as I spend more time on it I start understanding it better, sometimes takes a couple of months :)

I have inherited a couple of 10 years+ codebases at my current place, I would say that usually the best ones have small functions that are well documented instead of crazy abstractions. They also were built without trying to be too clever.

They use the bare minimum of the language to get the job done and do one thing only and well.

Some other code bases are much harder to grasp .. usually abusing abstractions everywhere or using libraries / programming constructs that aren’t widespread.

One that I despise is a huge asynchronous Python application built years ago with twisted.. nothing feels pythonic and it’s so hard to follow the flow of the program.

Not inheriting, but I enjoy working on code that I wrote awhile ago. What I enjoy about it is 1) seeing how I've progressed as a coder, and 2) fixing my shit code before anyone else lays eyes on it. It also forces me to really think about my code, and why I did what I did.

I’ve worked with some exceptional code off of GitHub. But at work? Never

The worst engineer in the world is the one that worked on your current project before you... even if that person was you a year ago!

“Who wrote this sh!t?!?” >git blame Oh, it was me... well I’m sure there’s a good explanation.

I think once.

It was a relatively straightforward rails site written by a person who didn't break any norms. I knew right where everything was before I started. It was quite nice, and then I probably ruined it.

No, because they inevitably lack at least one (usually all) of the following:

- A working CI pipeline.

- Comprehensive tests.

- Enforced linting/formatting.

- A script (or at least documentation) to set up a dev env from scratch (including resetting it if it already exists).

- Documentation of things which would take days or weeks to discover when working without the original developers, such as high-level trade-offs, code style which is not enforceable using linting (such as "Use Foo.frobnicate rather than the built-in frobnicator because …") references to issue trackers, former non-committing project-related people such as business analysts, separate documentation, credentials etc.

That said, I keep getting more and more picky about what it means to have a good code base, so in a few years I'm sure this list will be woefully incomplete.

Yes, definitely.

Customer supplied some code that I had to incorporate into a new JEE app (actually J2EE back then).

I liked that code because it was just way cleverer than anything I ever expected to find in an enterprise Java app. It implemented a trie to return a list of partial recordings to make a full sentence (which was the input).

It was space and time efficient, but also extremely clear, logical, and easy to incorporate into our code base.

And best of all I was able to use those ideas to solve a similar problem in the next project.

Came very close once, alas I changed teams at the wrong time and that particular codebase ended up at someone else's hands but I got to take a look. While disappointed it was not going to be my assignment, it made me regain a little bit of hope in the field, it's truly not all code that is perpetually full of warts.

Inherited maybe the wrong word. But worker on. Most code I have worked on was great with the exception of python codebases. But that's not really something the original devs could do much about. In contrast to others here I don't dislike clever code as long as it well applied. Nothing is more irritating then an advanced concept being used in the wrong place. Good clever code often teaches me something.

I've inherited a massive codebase that was inefficient, however the database schema design was excellent, which let me focus on optimising stored procedures and the front end in general.

Relational database schema is the bedrock foundation of a good codebase (for business apps especially)

"Hell is someone else's code" (to rephrase Sartre)

On the contrary, I love underengineered codebases, which is why I love working at startups. There's a certain thrill to replacing 4000 lines of code with 400. Usually these are the same code copy pasted in 8 different places, so I plug it all into a helper class, reduce 4 hours of work into 10 minutes, and feel really productive.

I inherited overengineered ones a few times and it's terrible. There's the Chesterton's Fence to be careful of, where some thing seemed pointless but fenced off an obscure bug. The pre-Kotlin Android era also had a lot of hacks to reduce boilerplate, which ended up being a tradeoff between spending 1/3 of your time dealing with easily fixed dumb bugs from copypasted code, or spending 1/3 of your time dealing with complex bugs from testing issues, code that reduced boilerplate, old things that were deprecated in new APIs, and so on.

Nope, not ever. Five years, 3 companies, every single codebase has been a nightmare. The funny thing is that in all these companies, everyone talks the talk and uses all the standard buzzwords about test driven development, clean code and all, it just doesn't quite seem to reflect in the actual output.

Once yes. Most of the prior people were still with the company. They had design document, file comments, function comments, and a few (very few) inline comments. All code development was done under contract, where the documentation and code reviews were deliverables.

Twice no. One was a massive in-house project that had evolved over the years. There was a former developer, but he was not very good, and only wanted to add more bells and whistles. He got frustrated with my efforts to document the code and left. It was used to help test other code, but was the most horrid thing.

Second was 5 years ago, person left, and left literally no documentation. We had a weeks overlap, and he demonstrated the code, but in the thousands of lines of code there were a handful of comments that just had the date and his initials.

For me I need to be able to understand what the intent was of the code. Then I can either debug the indent (i.e. bad logical thinking), or implementation (not coded to do what you want).