Ask HN: What is the best code base you ever worked on?

I agree, the best code base is always a zero-line code base.

So true!

I spend so much time obsessing over how what I am about to write ties in with what has already been written; or fuming over the stupidity of earlier decisions (usually made by myself). A blank slate is incredibly refreshing.

This sounds like wonderful! Maybe one day I can have a few of these “babies” that I can lovingly raise, providing joy to both the dev and the customer.

> Any codebase that I had complete control over.

No excuses. Code ownership is important. Sometimes it works for a team, sometimes only for individuals.

But not having to submit to core teams, architects and self-proclaimed experts of all kinds is a blessing.

I now work for an organization that discourages code ownership, and it struggles on many fronts:

        1. core teams are dysfunctional
        2. people find niches and stick to them
        3. top talent is leaving, although pay is good and business creates real value for citizens
        4. there is virtually no horizontal communication
        5. mediocre ones rise to the level of their incompetence and  infest the lives of others
        6. and so on and so forth...

And I think the root cause of all this is lack of individual (code) ownership.

Also nice is when an entire community has agreed to architect a codebase more or less the same. You're basically psychic when that happens.

> Any codebase that I had complete control over.

Anyone other than myself would instantly observe it as the the worst codebase they have ever seen.

This is very much true. Initially when I joined the industry I used to work for a product from its inception. So I was aware of what section of the code affects what part of the product. Although I hadn't worked on all of those, I kept an eye for the all the changes that were coming in. I knew where I should look immediately a bug is reported even if it is not something related to my line of work.

Recently I switched teams and now I find myself taking up bugs that are only related to my line of work. Not being familiar with the codebase decreases productivity and wants you to rely on other people in the team for most of the time.

> Once you're really familiar with the codebase, you know where dragons be, and you can make changes more easily.

This is an interesting, and often overlooked, point. A month or two ago someone asked us, the Fossil SCM maintainers, if we'd be open to them refactoring the tree to something which better matches modern sensibilities (i'm paraphrasing here). Despite its many proverbial dragons, the long-time maintainers are comfortable with it and know where those dragons are and how to defeat them (or, in some cases, sneak around them), so, despite our collective geek tendencies to prefer "perfect code," we're happier with the dragons we know than those we don't. (That's not to say that fossil's code is awful, but its structure varies significantly from what one might write today if one was to start such a project from the ground up.)

I also echo the code ownership part.

I have a part-time gig where I maintain accounting software for a former client of mine. It takes up a few months' weekends a year.

I wrote about 60-70% of it when I was working for the owner of the software. It's something where as long as the client's happy, and they get new integrations and updates on time, they could keep using it for a decade longer.

I had almost complete ownership of the architecting of the software. It's broken down into a few microservices (think database, core business logic, reporting, auth, logging etc). The best thing I did at the time was pushing to use gRPC even though management felt it was too new tech.

The UI is in Angular, pain-free periodic upgrades. I've even rewritten some perf-sensitive code in Rust, and everyone's happy with snappier calculations.

The code hygiene is relatively good.

The only downside's that if someone else were to take over the code, they'd struggle (it's one of those things where I'm wearing many hats). I've been fortunate to be a professional accountant who moved into software engineering, so everything makes sense to me.

> Any codebase that I had complete control over.

This is probably one of the pillars of good codebases, or at least decoupling the bits that you don't control as well as you can (this includes external services). I remember needing to write a wrapper around another JWT library, but because it was quite important, I aimed for >95% test coverage, some of the tests acted as documentation for how to use the code, there was also a nice README, there was CI configuration for pushing the build artifacts to Maven and suddenly even managing dependency updates became easy because of the test suite. Years later, it's been integrated in a bunch of services and "just works".

Come to think of it, things always get less pleasant once you add a bunch of complex dependencies and libraries/frameworks. Need to make a few RESTful Web APIs in Java? Something like Dropwizard will probably give you fewer headaches than Spring (or Spring Boot) and all of its inherent complexity, in the case of the former you might even need to do configuration in XML and that has honestly never been pleasant. If you need to integrate with a bunch of other stuff and want something opinionated, going for Spring Boot will make sense then, but for simple use cases it's overkill. Same for ASP.NET, Ruby on Rails, Laravel and many others, while they might be easier to use, updates (especially across major versions) and breaking changes will give you a headache and just add a bunch of churn to the project.

Similarly, if you need a message queue, externalizing that into RabbitMQ might make a lot of sense, same with storing files in an S3 compatible store, using something like Redis or Valkey for key-value storage, as well as not trying to shove too much logic into your RDBMS. Just pick whatever tool feels best for the given task at hand, instead of shaping things into what they're not (using the database for blob storage, for example), unless you have a whole bunch of constraints to contend with. Otherwise, sometimes you just get the worst of both worlds, like needing to use Oracle for a project, not having easily launchable local environments (because Oracle XE doesn't support some features), having to share DB instances with others during development and also running into weird obscure issues like DATABASE LINK queries taking 100 times longer in some cases, even when executing the same SELECT query on the remote DB works without issues.

To not go into a rant, I'd sum it up like this: be in control, isolate the things that you cannot control, pick the correct technologies, do the simplest thing that you can get away with without overengineering and think about the person who'll have to maintain, debug and grow the system in the following months and years (which might also be yourself, sans knowledge about what the code did, if you don't make it explain itself or don't comment the non-trivial stuff).

> And God (PM) forbid, if you ever find yourself with some extra free time you might even reduce the size of dragons over time.

Honest question, what is the company like where you can do that? Everywhere I've worked (only been working in industry for 6 years) has had such rigid agile development that even when I do find myself with free time, there's no flexibility to work on things that haven't been assigned to you and the best I can do is work on profiling/debugging tools.

Your successors just hope you can only remember 3 things at once so you end up with elegant designs rather than one of those monsters who can remember "to add a new wrinkle to this feature, just edit these 25 files."

Such a great point. I audibly groan when I come across Python meta-programming.

While not an advanced feature, I have a similar response when I see lots of decorators in Python. They quickly become a debugging nightmare.

I can see a few cases where that depends...

Really simple languages: Ruling out meta-programming is really going to limit you in Lua for example. Just being able to do `mySocket:close()` instead of `Socket.close(mySocket)` involves meta-programming.

Older languages: For C++ the "simple" features are going to include raw pointers and macros. Maybe it's not so bad to allow smart pointers and templates to avoid those

Depends who is providing it.

Django and pydantic meta programming usually make the code easier to deal with.

In shop written meta programming usually sucks.

I worked at GOV.UK for a few years on what was effectively specialised CMSs all written in Rails. Mostly basic CRUD stuff. A contractor came along and built the most insane CMS I've ever seen. I found out later it was flavor of the Java Repository Pattern using dependency injection. It became so difficult to work with that the last thing I worked on there was to delete it and rebuild it using standard Rails patterns.

The KISS philosophy exists for a reason and that includes over-using advanced language features just to show off.

Having just removed a metaclass from my Python code I totally agree.

I think one should not use advanced language features just because, but I also think one should not avoid using advanced language features where it is useful.

Why would the code base be worse when advanced language features are used?

I disagree with this, but I understand where it's coming from. I think you have a form of whiplash from things like: - Novices overusing the new shiny. - Java/C++/etc Jr programmers overusing design patterns. - Perl programmers solving everything with regexes. - Small startups with GraphQL, or any other large enterprise tool. - Metaprogramming, Maco's, Dependency injection, Recursion, etc when a simpler solution is a better fit.

IMHO, a "best codebase" will be just a bit more advanced than I am, with good resources for me to grok it. I want to be able to learn from it. I also don't want to be so far out of my depth that I can't make a reasonable contribution.

It would be cool if newer (imperative) languages had a clear protocol to delimit the simple core of the language from the advanced, library-building features. Like Rust has `unsafe` blocks, imagine a `advanced` or `metaprogramming` block that is required in order to use advanced metaprogramming features. Then you could tell a junior to implement $MUNDANE_INTEGRATION without use of `advanced`, and that constraint could be statically verified in PRs, etc.

It seems like it would vastly simplify language evolution. The core language can have rigid limits on changes and follow the Zen of Python or whatever, while the `advanced` language extensions can be a bit looser. Features could graduate from advanced to core without breaking anything. You get a single powerful+expressive language with a "porcelain interface" without necessarily giving juniors ammo to shoot themselves in the foot.

I worked with someone who insisted on using fx for DI in go. It's so antithetical to the entire Go philosophy, I don't even think it's an "advanced feature". It's just bringing Java cruft to a language where it isn't necessary and making everything worse.

Sounds fun. I have a similar policy but only every other year. It means I know what the hell I am talking about when in meetings with people who have slow or inefficient services. It also means my job of mostly telling other people how to solve problems is still a lot of fun for me.

Go micro-service with pretty loose deadlines

Sounds like A Money Printer, congrats.

IMHO library code is especially challenging, as cruft has a tendency to accumulate, historical behavior needs to be preserved, and APIs are set in stone once they’re built.

"Any code that does a lot of useful and complex things must be an arcane, barely maintainable mess that can only be understood by deep study."

"Every code base I have ever worked on was a legacy nightmare. Every "greenfield" project I joined turned into a legacy nightmare within weeks"

I am sorry to say this, but it really sounds like you were either really, really unlucky, or part of the reason why it became a mess.

Complicated things are complicated. Nothing can ever change that and it requires study to understand it.

But it still does matter a lot, how one organizes the whole thing. How it is structured, documented(!), refactored. Are there competent people in charge who understand it all and kick peoples asses if they make even a temporary mess or forget to document, or do random people make changes wherever they see fit, because a deadline is ticking?

Modularisation is usually the key. Small modules do one thing and are as seperated as much as possible with as little side effects as possible.

And if one has to ship things, it is not always possible to keep it pure and if the code is not intended to live forever then this is often fine. But if the codebase is supposed to stay, then there needs to be the time to clean up the hacks. Or don't and then you end up scared touching anything.

That being said, the technologies you mentioned, I would not like to touch either..

Something in your answer triggered a flash back to when I worked for a phone company, 20 years ago. One team, under the leadership of our questionable chief architect, had produced our new, all encompassing backend system. This was to be the corner stone of all future development and integration, dog slow and complicated as it where. I worked as a .Net developer and had the misfortune to be among the first to integrate with this monster. Try as I might, I could not get .Net to interoperate with these services. Finally I figured out that the SOAP services was using some old deprecated versions. Going back to the architect, I ask "did you build this on Apache Axis, and please say Axis2", but no, it was just Axis, a deprecated version, that would generate webservices not supported by newer .Net version. That wasn't an problem, because: "None of our project have upgraded to those .Net versions yet"... DUDE, we've launched a brand new system based on that .Net version a year ago, and what was you f-ing plan for the future, to redo every single service using Axis2?

This guy had based a brand new system on a framework/library that was no longer maintained, even before the system was launched.

Let me guess, it was very well funded and there were no fake deadlines and cross-team dependencies, am I correct or am I very correct?

I am almost sure this is because the system would have to pass a certification procedure somewhere, and for that they would need this level of clarity. Am I right?

I'd love to know if working like this is enjoyable or a chore.

+1 to this.

I remember my boss asking me to build a MacOS UI we had on Windows with this. I was very sceptical that it would go anywhere.

But no, it worked. I was just open mouth shocked to see the GUI worked pretty flawlessly in Windows.

Thank you!

What is Google3?

It was wonderful to work with. :-) It's one of the things I truly miss from Google.

Google3 codebase very consistently has clean code, but some of the architecture there is very much not great.

Some is great, some not so much.

Some of Verizon's code was much more elegant (though much smaller scope) from an API perspective, and really leaned into advanced type systems in a way Google has not.

+1

I can not understate how much I agree with parent comment.

The opposite of move fast, build a shitty prototype and iterate is a deliberate problem solving approach undertaken by the highest caliber of engineers. The actual challenges to be addressed are effectively addressed right at the design stage.

The result is a thing of immense beauty and elegance.

I will forever be grateful for the opportunity I had to see this magnificent piece of engineering in action.

I honestly can't tell if this comment is sarcastic...

google3 is a quagmire and it's getting worse by the day

  It is part of our human condition to long for hard lines and clear concepts. When we have them we have to either face the fact that some realities elude them, or else bind ourselves to the inadequacy of the concepts.

I agree but would add that within the codebase there are also vastly different experiences. The search ads serving stack for example is phenomenal, it is >10 years old, very complex and gets contributions from hundreds of engineers every week, yet it is quite easy to understand what is going on anywhere and it has great performance. But I also had to work with other code which had been through 3 rewrites, none of which had ever been totally completed, so there were overlapping paradigms everywhere and working with it was just a nightmare. Tests never caught anything leading to several post mortems.

It was certainly great up to like 2015, perhaps later?

You could spend all day finding fun code to read.

I always like the main signal (eg sigsev) handler.

Go, SQLite, Redis are the three that came to mind for me. Simple, readable, fairly flat hierarchy.

This is the approach I tried to take as an IC frontend on a building management system dashboard about a year ago. It was basically me and one other frontend, one full-stack, and a QA or 2, plus a manager. My manager I guess had written a lot of the code we'd be interacting with, and I guess was somewhat protective and reluctant to delegate authority over decisions around it. It was a big refactoring project, and I just encouraged my colleagues to take the things they wanted, like rebuilding the state management system. We'd discuss the requirements and why it was necessary, and I'd look for reasons to agree rather than disagree, then we'd be off. Something burnout has taught me is that the marginal differences between one implementation detail or another are not worth getting hung up on unless they pose a real problem, especially when someone else gets to decide that doing it fast is priority (sprints).

Great example as it shows that code base really is a side consideration and a proxy to team quality.

Another reminder that soft skills multiply the effectiveness of hard skills.

Otherwise known as "you are not your code" and "you are not your ideas." Essentially, criticism against your code is not a personal attack (and other corollaries). Its definitely something I aspire to, but its surprisingly hard to get right.

Good for you. Magical moments in careers are hard to find in my experience but they are so satisfying when you get there.

Glad whomever was over this didnt just drop the "dont rewrite" joel spolsky article and fight making it happen.

Similar thing.

Had time and autonomy from a client, so took sweet time examining the domain, the existing systems et al. Spent a few months writing the basis and the framework around what will be done, based on years and years of experience I had with bad frameworks and codebases, combined with working on the same domain for their parent company years ago.

And it worked. We delivered features insanely fast, hundreds of forms were migrated, feature generators would create 90% of the boilerplate code and the code was small, readable and neatly clustered. Maintaining it was a piece of cake, leading to us not having enough work after a while so I negotiated our time to half a week for the same money.

After a while, client deemed us too expensive to pay for only 2.5 days of work - after all, how does it make sense - if we are paying them that much, they should work 5 days!

So they cut us out. Two things happened:

1. Devs that got moved to other projects in the company told me they didn't know development could be so smooth and tried to replicate it in future projects, even tho they say it failed a lot of lessons they picked up from the framework were highly relevant in their future careers.

2. The company found a cheaper developer, he said "this is unusable and has to be rewritten" and rewrote it into "clean code", taking longer than the original project took. At least he works 5 days a week now.

Bazel Python does not cross compile IIRC. How was this achieved?

I assume you avoided identifying (or even hinting at) this "great technology" on purpose, but could you persuaded to divulge what it was?

What is this niche language attracting super programmers?