Live data from Hacker News

Ask HN: Have you ever inherited a code base you thought was well done?

news.ycombinator.com

141–150 of 151 posts

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#141

Maybe "inherited" is a strong word, but some of the open source projects I contributed to were beautifully crafted. Django is one such example, on all fronts — docs are great, there are tests, and so on. At work, not so much, as it's mostly very rushed, badly designed software.

> as it's mostly very rushed, badly designed software What's stopping you in improving the situation? Time pressure or unwilling colleagues?

That's a great question. Now that I think of it, it's the incentive structure, for the most part. One gets recognition for half-assed implementations delivered very fast.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#142
post #87

Earlier quoted context omitted.

I might get a lot of flame for this, but I would say this is probably true of most Rails project because Rails has a lot of great standards (opinions). I am not sure why people hate Rails, I love it exactly for this reason.

I've been in the guts of about five Rails codebases that were already in production, and they've all been very bad, and the badness difficult to overcome in part because of Rails and/or Ruby (which is why I hang some of the blame on Rails itself). IME Rails codebases are a few months with a mediocre team or a few bad choices away from becoming an absolute garbage fire, and all the magic in Rails is part of why even a…

The fact that 8/10 of the top YC alum companies (as of 2019) used Rails would indicate that it isn't the massive liability you portray it to be https://spreecommerce.org/ruby-on-rails-most-popular-among-t...

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#143

There’s no such thing as a good code base. There’s only code that you deployed to production and that is working and code you wish you wrote that never got deployed and has no value.

Actually even code, which has never been deployed can have great value as an exploration and learning vehicle. Education and experience of employees is one of the most valuable resources an employer can have.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#144
post #80

Not someone else's code but I had the strange experience recently of revisiting an old project of mine (DNS server written in typescript + deno) and being intimidated by the quality of my own code . I had those familiar feelings of "I could never write code like this" or "I'd never have thought to do it like that!" or "This person must really know their shit". Turns out it was me all along and I'd just forgotten I'd…

revisiting an old project of mine (DNS server written in typescript + deno) Can it really be called old considering the very modern tech stack?

Deno initial release was 4 years ago, in tech that's ancient, right? :)

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#146
post #102

Earlier quoted context omitted.

Well said. I recently inherited a code base which was developed by some devs-for-hire while the company started building up the team to take over (including me). I met the last remaining dev-for-hire for the handover and got the impression that the company paid very very close attention to how many hours they billed and which meetings they were allowed to attend, and 0 attention to the code they produced as long as i…

> No Chesterton's fencing around That’s an interesting way to put it. I think that might be a good rule of thumb to help future maintenance: Avoid unintentionally erecting Chesterton’s fences.

The opposite of Chesterton's fence is "traffic cones" in my lexicon.

As in, "put some traffic cones around that hack" meaning make sure there is a comment or appropriate error message or something that will make it clear to posterity that this is a known temporary sketchy situation, not an accidentally load bearing wall"

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#147
post #102

Earlier quoted context omitted.

> No Chesterton's fencing around That’s an interesting way to put it. I think that might be a good rule of thumb to help future maintenance: Avoid unintentionally erecting Chesterton’s fences.

The opposite of Chesterton's fence is "traffic cones" in my lexicon. As in, "put some traffic cones around that hack" meaning make sure there is a comment or appropriate error message or something that will make it clear to posterity that this is a known temporary sketchy situation, not an accidentally load bearing wall"

See, this is the sort of behavior I would wish companies would test for when hiring engineers.

Another (in-house, salaried) contributor to the project I took over added a error message (in a very specific error handler for exactly one REST endpoint), and I quote

    raise Exception("could not load data because of error")

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#148

Earlier quoted context omitted.

The opposite of Chesterton's fence is "traffic cones" in my lexicon. As in, "put some traffic cones around that hack" meaning make sure there is a comment or appropriate error message or something that will make it clear to posterity that this is a known temporary sketchy situation, not an accidentally load bearing wall"

See, this is the sort of behavior I would wish companies would test for when hiring engineers. Another (in-house, salaried) contributor to the project I took over added a error message (in a very specific error handler for exactly one REST endpoint), and I quote raise Exception("could not load data because of error")

FWIW I got this way thanks to a stint in the sysadmin/support/operations world at the start of my career. I wonder if trying to give juniors similar experiences might help jumpstart the process of getting this kind of intuition.

When you operate software, you realize all the little things a developer can do to make the operator's life much easier or harder. I always thought this was the "true meaning of DevOps" -- thinking of how to make it easy to operate the software at dev/design time, as if it were an old school shrinkwrapped application like Windows 95... but instead it got turned into writing terraform or something haha.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#149

Earlier quoted context omitted.

See, this is the sort of behavior I would wish companies would test for when hiring engineers. Another (in-house, salaried) contributor to the project I took over added a error message (in a very specific error handler for exactly one REST endpoint), and I quote raise Exception("could not load data because of error")

FWIW I got this way thanks to a stint in the sysadmin/support/operations world at the start of my career. I wonder if trying to give juniors similar experiences might help jumpstart the process of getting this kind of intuition. When you operate software, you realize all the little things a developer can do to make the operator's life much easier or harder. I always thought this was the "true meaning of DevOps" -- th…

Well, funny thing is, that developer was also the operator.

Because if he's the only one that understands the error message, he's the only one that can fix the problem.

That's how you get credit with the suits if something breaks.

No one ever notices a stable application. A programmer fixing a problem that no one understands? That must be a very smart person indeed.

I'm being needlessly cynical at this point. This was just one person at one company. Overall, I do think that given the right incentives, what you describe can happen. But it does not someone in leadership to care. And that's a hard sell to me.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#150

Earlier quoted context omitted.

FWIW I got this way thanks to a stint in the sysadmin/support/operations world at the start of my career. I wonder if trying to give juniors similar experiences might help jumpstart the process of getting this kind of intuition. When you operate software, you realize all the little things a developer can do to make the operator's life much easier or harder. I always thought this was the "true meaning of DevOps" -- th…

Well, funny thing is, that developer was also the operator. Because if he's the only one that understands the error message, he's the only one that can fix the problem. That's how you get credit with the suits if something breaks. No one ever notices a stable application. A programmer fixing a problem that no one understands? That must be a very smart person indeed. I'm being needlessly cynical at this point. This wa…

Sigh, this is cynical but I've seen that sort of thing too and it really bums you out. When you're in an environment where this kinda crap isn't well understood it becomes frustrating, you end up feeling like you're rewarded for mediocre software engineering and punished for thinking ahead.
Post reply on HN