Live data from Hacker News

How good engineers write bad code at big companies

seangoedecke.com

131–140 of 333 posts

Re: How good engineers write bad code at big companies

#131

The claim this article makes about very short tenures at big tech is misleading. Because of headcount growth, the median tenure is naturally going to be short. Google grew headcount by 60% the year before 2013, so no wonder the median tenure was 1.1 years. A better statistic to use would be median tenure conditional on that the employee has already left.

The same process causes us to overestimate the rate at which older programmers leave the profession.

Even if there was zero attrition, programmers with 40 years of experience would still be rare. The fresh newbie developers of 1985 were a small group by today's standards.

Re: How good engineers write bad code at big companies

#132

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

I can find an experienced doctor, plumber, musician or mechanical engineer that was doing it 50 years ago.

I’m not going to find someone that was doing software 50 years ago. And if I do, their experience is completely unrelatable.

Re: How good engineers write bad code at big companies

#133

what I see alot is that the syntax and overall code architecture is text book, but its the completely wrong approach that creates extremely complicated tech debt. All the code reviews will be on the syntax, and none on the big picture of the business problem, or whether the implementation is overcomplicated. in the short run (1-2 years) there is no repercussion for this, but eventually making changes will be extremel…

[deleted]

Re: How good engineers write bad code at big companies

#134

Earlier quoted context omitted.

No, big tech engineers are highly motivated. There's lots of money, good management, and plenty of incentive. (I'm a Google engineer myself). The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results. It's generally hard for anyone without specific experience with a codebase to tell what you're doing with it. Management can't evaluate the value of maintenance wor…

The thing is shipping sloppy code is orders of magnitudes easier, because that's the default result. Any sufficiently determined hack-job can do it. On the other hand, steering a team of 5-10 engineers to deliver quality on (or before!) a deadline requires excessive amounts of coordination and skill. Now, is this trade-off "worth" the effort? I guess that's a matter of opinion, though I would argue in the long term q…

slow is smooth, smooth is fast

Re: How good engineers write bad code at big companies

#135
I don't think there's an objective assessment of good code. I've been writing code for over 20 years at this point and most times I've seen what people describe as their own good code I disagree with various decisions.

Experience CAN remove pitfalls, though developers even disagree about those sometimes.

Organization, chosen abstractions, naming etc are basically personal thinking and have differed on every team I've ever been on.

When it's been good is when it's been consistent and that's taken a strong personality the team trusted to have authority.

Re: How good engineers write bad code at big companies

#136

The short tenure is a symptom of a larger problem. The deeper problem is that very little is expected of big company software employees. Conversely those same employees tend to expect a lot in return. You can call that entitlement, poor expectation management, first world problems, and all kinds of other names. I have not worked for a FAANG, so maybe things are different there, but I don't suspect so. People are peop…

>I have not worked for a FAANG, so maybe things are different there, but I don't suspect so it is quite a bit different at FAANG. I've workded for small companies, huge companies that aren't software/FAANG, and now FAANG, and it's definitely better here. The floor is very high for talent and just an overall ability to get stuff done. Google certainly doesn't have a monopoly on genius coders, i've met brilliant folks…

> I'm also dubious of your claim that compensation doesn't attract better talent.

Maybe higher compensation does work out for FAANG, but it does not at other larger employers, at least not for software developers. I am highly dubious about this at FAANG too though. My perspective is as a former 15 year JavaScript developer and a lot of what I saw coming out of FAANG in JavaScript land just wasn’t impressive.

I do see a lot of impressive things in the world of JavaScript but it’s almost always open source from small teams or single developers.

Re: How good engineers write bad code at big companies

#137
post #125

Earlier quoted context omitted.

It's hard to write about the broader context with any expertise in a blog post written from personal experience. My own thinking is that the big competitive advantage that big tech firms have over small ones is the power to mobilize very large numbers of developers onto a project. Large projects that don't depend on a small core group of irreplaceable competent individuals are more repeatable for a business. So it ma…

Yep you just rediscovered alienation https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation

Whoa. Who's this guy? Sounds like he might have some answers to some of my questions!

Re: How good engineers write bad code at big companies

#138

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

Every time I read his article I regret it. I literally mean every time, 100% of it. Judging by the title of the article, I didn't expect his reason to be "engineers working outside their area of expertise". I've seen good engineers figure out problems outside of their expertise plenty of times, so that's not a good reason either.

I feel like this article is the equivalent 16 paragraph stating you're likely to be correct only 10% of the time when you guess a random number from 1 to 10

Re: How good engineers write bad code at big companies

#139

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

> Why does bad code bother engineers so much?

I’ll take a stab.

Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review.

“You’re a senior engineer - why did fixing this take so long?” Because of the garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity.

Yes, these are management problems. I’ve spent years managing managers and attempting to educate them on how bad code causes errors and delays. But for many reasons, it’s a Sysiphean task.

Re: How good engineers write bad code at big companies

#140

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

I can find an experienced doctor, plumber, musician or mechanical engineer that was doing it 50 years ago. I’m not going to find someone that was doing software 50 years ago. And if I do, their experience is completely unrelatable.

That's one of the many many reasons I miss my dad so much. He went straight from MIT to GenRad circa 1970. I didn't start doing software till 1998, but we had some years of overlap -- and it was profoundly gratifying to connect w/ him on engineering topics. The learning was even bidirectional tho I'm sure I got more out of our pseudo-professional interactions than he did. Sigh. I really miss him.
Post reply on HN