[2Pacalypse-]

Any codebase that I had complete control over.

No, but more seriously, I've found that familiarity with the codebase is more important than having it be perfectly engineered. Once you're really familiar with the codebase, you know where dragons be, and you can make changes more easily. And God (PM) forbid, if you ever find yourself with some extra free time you might even reduce the size of dragons over time.

This brings me to my final point. Any codebase that I really enjoyed working with was the one that was constantly evolving. I don't mean rewriting everything from scratch every few months, but as long as I have permission (and time) to refactor the things that have been bothering me for months as patterns emerge, I'm a happy bee.

[sam_lowry_]

> 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.

[Aeolun]

I’ve had exactly the same issues but because I couldn’t change anything without getting approval from 16.5 code owners on every PR submitted. It’s a real pain if you start modifying your coding for ‘least code owners hit’ instead of ‘best architecture’.

[rsanek]

I like how my workplace does it -- there are rigorous codeowners and usually you only need approval from 1-2. if you do need approval from 5+, you can request a select 'super' codeowner review which will approve it for all.

[ownagefool]

I think core teams being helpful or harmful really comes down to the individuals.

The problem is at this level, most orgs don't have anyone to really judge or contest competency, so they hire the salesmen rather than the doers and when they don't, they tend to cheap out and just get inexperienced people.

Logically it makes a bunch of sense, though.

Why rebuild yet another platform? Why is your central platform bad? Usually it's not self-service, sometimes it's because it's built in cumbersome ways, other times its because it actually enforces good standards on you rather than just giving app your apps admin.

It's difficult for the person who hires the core team to differentiate between those complaints, unless they themselves both have the technical competency and the empathy to really understand the problem. They usually don't.

Point being, done well, it's great, but most folks can't do it well.

[nevi-me]

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.

[idrios]

> 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.

[arp242]

Usually at smaller companies with just a handful of developers. Can be a "start-up", or just a smaller business running fine with small teams. Or sometimes in a larger company where there's a small team doing its own thing.

There's up-and-downsides to everything. The pay is usually less, and "fewer processes" often also means fewer processes surrounding HR and such. This can mean you're subject to the whims and mood swings of one person. I was once fired over a pretty far-fetched misunderstanding, but 1) they didn't mention it because "I should know myself", so I didn't really have a chance to clear it up, and 2) when I got fired they agreed it was a complete misunderstanding and that they made a huge mistake, but fired me anyway because that was the road already taken now. Great ... thanks ... It's hard to imagine that happening at a larger company with an actual HR department and stuff.

Also: a Wikipedia-esque "be bold" attitude helps. Obviously refactoring things just for the craic isn't a good idea, but if there's something that can really make an impact then I'd just do it and send a PR, regardless of what I've been assigned. Obviously "refactor everything" on your own initiative isn't a good idea, but usually there's tons of smaller stuff that really helps: "introduce new function/package that helps reduce boiler plate", "split up this difficult to understand function", things like that.

Most PMs will realize they don't have a 100% in-depth understanding of the code, and will trust you when you say it helps you do your work better. Usually it's fine as long as you apply proper judgement and don't spend too much time on it. That said, there are some places where this really isn't appreciated regardless. IMHO that's pretty dysfunctional and when I start looking for somewhere else to work.

[james_marks]

Counter-point: whitespace PR’s, refactors I didn’t ask for, aren’t attached to a larger initiative, etc actively annoy me as an owner.

Every PR takes time to manage, compounds complexity, and carries risk. We only get so many out a week, and I want them to count.

Maybe it sometimes goes in hand with disfunction, but I’m guessing there’s more going on there.

[arp242]

> apply proper judgement

[sgbeal]

> 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.)

[blitzar]

> 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.

[sam_lowry_]

For that, there is a saying: "code as if your kids will maintain it".

But I think it does not convey the right meaning. When I code something I will have to maintain for a long time, I try to make it as simple as possible for my future, older, less motivated and weary self.

The worst codebases are written by people who landed the gig a few months before and do not expect to stay around longer than a year or two.

[null_glyph]

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.

[threatofrain]

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.

[lanstin]

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."

[KronisLV]

> 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).