Live data from Hacker News

Mistakes engineers make in large established codebases

seangoedecke.com

381–384 of 384 posts

Re: Mistakes engineers make in large established codebases

#381

Earlier quoted context omitted.

I tried my best to offer a pragmatic recommendation for dealing with those sorts of people. I'd love to know what you would recommend instead?

IME it's politics, so you need to find someone that the sticky person fears/respects, and get them onboard. The only other way I have succeeded is to appeal to the sticky person's ego, make them think that it's their idea. Note: I have also had to deal with Sticky person: Do it this way Me: But X Sticky Person: No, do it the way I have decreed [...] Three hours later (literally) Sticky Person: Do it X way

You are most likely giving the only real answer. However I just say its better to not care. Look how much energy and mental strife you are going through to line someone else's pockets against their will. That only is not even including the actual work just the unnecessary work around the work. Its not worth it. If the tech is this dysfunctional then so is the rest of the organization, you breaking your back to fix one support structure is just masochism.

Re: Mistakes engineers make in large established codebases

#382

Sometimes the right approach is to keep the consistency. Other times, that approach is either impossible or catastrophic. IMO software development is so diverse and complex that universal truths are very very rare. But to us programmers, anything that promises to simplify the neverending complexity is very tempting. We want to believe! So we're often the equivalent of Mike Tyson reading a book by Tiger Woods as we lo…

The same is true for stock picking.

Re: Mistakes engineers make in large established codebases

#383

Earlier quoted context omitted.

IME it's politics, so you need to find someone that the sticky person fears/respects, and get them onboard. The only other way I have succeeded is to appeal to the sticky person's ego, make them think that it's their idea. Note: I have also had to deal with Sticky person: Do it this way Me: But X Sticky Person: No, do it the way I have decreed [...] Three hours later (literally) Sticky Person: Do it X way

You are most likely giving the only real answer. However I just say its better to not care. Look how much energy and mental strife you are going through to line someone else's pockets against their will. That only is not even including the actual work just the unnecessary work around the work. Its not worth it. If the tech is this dysfunctional then so is the rest of the organization, you breaking your back to fix on…

Heh, unfortunately it's been this way in almost every company I have been in.

I don't think that I have ever been in a company where I haven't had to deal with it - and it's taken me a while to work it out, I've had physical threats and (just this Christmas gone) been punched in the stomach at a work Christmas event by someone upset that I'm able to point out these other ways of doing things.

People are very scared of losing what little power they think that they have.

Re: Mistakes engineers make in large established codebases

#384
post #236

Earlier quoted context omitted.

In my current job I did a PR in the first week of joining. It was reviewed after exactly 2 years. I had to rewrite the whole PR because of the affected lines had changed. Of course I did not remember at all what is was about. Some PRs are faster but some are slower as well.

Maybe you meant getting a PR merged. Then 3 days seems possible depending on the approach. At my current company, the team is small so approval process is quite fast and not too fussy.

Why would I write "reviewed" when I mean "merged"? I meant reviewed.
Post reply on HN