Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mistakes engineers make in large established codebases

seangoedecke.com

Post reply on HN
Print view View original

111–120 of 384 posts

Re: Mistakes engineers make in large established codebases

#111

Post by staunton »

HideousKojima wrote: post #83
peterldowns wrote: post #34

I agree that consistency is important — but what about when the existing codebase is already inconsistent? Even worse, what if the existing codebase is both inconsistent and the "right way to do things" is undocumented? That's much closer to what I've experienced when joining companies with lots of existing code. In this scenario, I've found that the only productive way forward is to do the best job you can, in your…

My approach is what I call defensive programming, with a different meaning than the usual usage of the term. I assume that my coworkers are idiots that aren't going to read my documentation, so I make all public classes and methods etc. as idiot-proof as possible to use. Hasn't saved me from every issue caused by my teammates never reading my docs or asking me questions, but it's definitely prevented several.

> assume that my coworkers are idiots

I know (most?) people don't mean it literally when writing something like this but I still wonder why such self-evident ideas as "make things easy to use correctly and hard to use incorrectly" are framed in terms of "idiots who don't rtfm".

The best documentation is what wasn't written because it (actually!) wasn't needed. On the other hand, even if people aren't "idiots", they still make mistakes and take time to figure out (perhaps by reading tfm) how to do things and complete their tasks, all of which has a cost. Making this easier is a clear benefit.

Re: Mistakes engineers make in large established codebases

#112

Post by eru »

Supermancho wrote: post #101
dasil003 wrote: post #98

Earlier quoted context omitted.

Yeah 100%. Honestly style / technique / language consistency are implementation details, it helps with engineer fungibility and ramp up, but it also works against engineers applying local judgement. This is something to briefly consider when starting new services/features, but definitely not something to optimize for in an existing system. On the other hand, data and logic consistency can be really important, but you…

A common experience (mostly in the Pacific North West) I have had is to implement a feature in a straightforward manner that works with minimal code, for some backlog issue. Then I'm told the PR will be looked at. A couple days later I am told this is not the way to do X. You must do it Y? Why Y? Because of historical battles won and lost why, not because of a specific characteristic. My PR doesn't work with Y and it…

I feel your pain. But I guess you need to work harder on detecting these kinds of work places upfront, instead of joining them one after another?

Re: Mistakes engineers make in large established codebases

#114

Post by jimbokun »

citizenpaul wrote: post #106
digging wrote: post #67

Earlier quoted context omitted.

> If it's actually better, others will start following your lead. Not really my experience in teams that create inconsistent, undocumented codebases... but you might get 1 or 2 converts.

>Not really my experience in teams that create inconsistent, undocumented codebases... but you might get 1 or 2 converts. This has also been my experience. Usually there is a "Top" sticky/unhelpful/reticent person. They are not really a director or exec but they often act like it and seem immune from any repercussions from the actual higher ups. This person tends to attract "followers" that know they will keep their…

Well HN was created as a forum for discussing start up best practices, which is all about disrupting big companies weighed down by internal politics.

Re: Mistakes engineers make in large established codebases

#115

Post by darepublic »

peterldowns wrote: post #34

I agree that consistency is important — but what about when the existing codebase is already inconsistent? Even worse, what if the existing codebase is both inconsistent and the "right way to do things" is undocumented? That's much closer to what I've experienced when joining companies with lots of existing code. In this scenario, I've found that the only productive way forward is to do the best job you can, in your…

My last experience with this, in the section of code I had to navigate for my first ticket at startup X we had some code that was querying the same tables multiple times unnecessarily. We were also using a highly bespoke (imo) code library with a relatively small following on github but this library permeated the entire codebase and dictated the way things had to be done. I tried to just make my changes by touching the code as little as possible, but avoiding the most outstanding inefficiencies. I thought of my changes as a small oasis of sanity in a desert of madness. In that first PR the seniors tore me a new one. It turned out there was a v2 of "the right way of doing things" that I had to learn about and then write my code to conform to. v2 had it's own issues, though was perhaps not as bad as v1. Later on when I became more influential I was able to successfully advocate to management to change many things to my liking, including axing the beloved exotic library that distinguished our codebase. But the old guard remained highly resistant to changing the way our code was written, and switched their stance from 'this is great' to, 'it sucks but its too much effort not to keep with it'. I am left feeling that it was all not worth it, not just the struggle but whether the product was appreciably effected one way or another. Just another crappy war story of my blighted career.

Re: Mistakes engineers make in large established codebases

#116

Post by __MatrixMan__ »

hnthrow90348765 wrote: post #50

To be fair, the previous engineers got paid to write the legacy mess and were employed for a long time if there's a lot of it. Where is the incentive to go the extra mile here? Do you eventually put up with enough legacy mess, pay your dues, then graduate to the clean and modern code bases? Because I don't see a compelling reason you should accept a job or stay in a code base that's a legacy mess and take on this ext…

Would you be willing to put that take on your LinkedIn profile? If not... well that's why.

Re: Mistakes engineers make in large established codebases

#117

Post by jimbokun »

citizenpaul wrote: post #109
peterldowns wrote: post #44

Earlier quoted context omitted.

And it's fine, right? Honestly I think people need to realize that part of being a good engineer is being able to deal with inconsistency. Maybe submodule A and submodule B do network requests slightly differently but if both ways are reasonable, working, and making the company money, it's probably not worth delaying product improvements in order to make things "more consistent." On the other hand if no one in your c…

>and it's fine, right? The hard part of being an engineer is realizing that sometimes even when something is horribly wrong people may not actually want it fixed. I've seen systems where actual monetary loss was happening but no one wanted it brought to light because "who gets blamed"

That’s always a strong signal to start polishing your resume. Layoffs are probably just around the corner.

Re: Mistakes engineers make in large established codebases

#119

Post by dirtbag__dad »

darepublic wrote: post #115
peterldowns wrote: post #34

I agree that consistency is important — but what about when the existing codebase is already inconsistent? Even worse, what if the existing codebase is both inconsistent and the "right way to do things" is undocumented? That's much closer to what I've experienced when joining companies with lots of existing code. In this scenario, I've found that the only productive way forward is to do the best job you can, in your…

My last experience with this, in the section of code I had to navigate for my first ticket at startup X we had some code that was querying the same tables multiple times unnecessarily. We were also using a highly bespoke (imo) code library with a relatively small following on github but this library permeated the entire codebase and dictated the way things had to be done. I tried to just make my changes by touching t…

This resonates hard. In particular, managing the old guard’s emotions is a defeating process. It is almost always easier to jump into a project and critique it than it is to start from scratch. New perspectives and better ideas should be welcome, but instead they can be shut down because folks take things personally.

My (rather unfortunate) conclusion is that when I encounter this behavior I move to another team to avoid it. If that’s not possible it’s honestly worth looking for another job.

Re: Mistakes engineers make in large established codebases

#120

Post by jimbokun »

pablobaz wrote: post #62

In my experience with very large codebases, a common problem is devs trying to improve random things. This is well intentioned. But in a large old codebase finding things to improve is trivial - there are thousands of them. Finding and judging which things to improve that will actually have a real positive impact is the real skill. The terminal case of this is developers who in the midst of another task try improve o…

Which can lead to trying to rewrite Netscape Navigator from scratch and killing the company:

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Post reply on HN