What made this particular codebase stand out above others? What did the original authors of the code do well?
Documentation? Tests?
Perhaps nothing about the code itself, but rather the surrounding environment?
What was the nicest codebase you've inherited without the original author(s)?
1–10 of 74 posts
Re: What was the nicest codebase you've inherited without the original author(s)?
#2[deleted]
Re: What was the nicest codebase you've inherited without the original author(s)?
#319 upvotes, 1 hour, no answers...
How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code?
Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is.
Sorry OP, I got nothing positive!
Re: What was the nicest codebase you've inherited without the original author(s)?
#419 upvotes, 1 hour, no answers... How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code? Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is. Sorry OP, I got nothing positive!
All code is technical debt. We should not write it unless it serves a purpose of high enough value.
Re: What was the nicest codebase you've inherited without the original author(s)?
#5I've inherited a couple codebases at work that were pretty nice. They stood out among others because they did a good job at doing one simple thing very well. Libraries that start having a lot of feature creep, such as trying to support a bunch of different other libraries or trying to do things too cleverly to support a ton of different ways to use it, always end up being a mess.
Re: What was the nicest codebase you've inherited without the original author(s)?
#619 upvotes, 1 hour, no answers... How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code? Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is. Sorry OP, I got nothing positive!
Re: What was the nicest codebase you've inherited without the original author(s)?
#7[deleted]
Re: What was the nicest codebase you've inherited without the original author(s)?
#819 upvotes, 1 hour, no answers... How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code? Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is. Sorry OP, I got nothing positive!
Wow, that's some wisdom right there :) +1.
Whole new meaning to "best code is the one that doesn't exist".
Re: What was the nicest codebase you've inherited without the original author(s)?
#919 upvotes, 1 hour, no answers... How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code? Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is. Sorry OP, I got nothing positive!
Wow, that's some wisdom right there :) +1. Whole new meaning to "best code is the one that doesn't exist".
There's a talk by Greg Young regarding this topic called "The art of destroying software" [1]. It's a fairly interesting talk about designing your software with deletion in mind.
Re: What was the nicest codebase you've inherited without the original author(s)?
#10My current works codebase.
I've never seemed to like other peoples code. Not even my own after 1 month
But this code is very good. I would attribute it to the strong set of rules and design patterns everyone follows. All code/services are broken up into `unit` which all follow the same pattern, of how it's called, how the code is arranged etc. This means there is no ambiguity for any new starters trying to contribute to the codebase. In addition to that our linter doesn't allow you to push code if it detects any errors. There are a few other elements, involved too, but I think the most important thing is keeping a standard of where each bit of code should live, how it should be called, and ensuring everyone uses the same conventions (i.e. single quotes instead of double, all this small things add up)