Live data from Hacker News

How good engineers write bad code at big companies

seangoedecke.com

191–200 of 333 posts

Re: How good engineers write bad code at big companies

#191

Earlier quoted context omitted.

> Why does bad code bother engineers so much? Others have said some true things but the core is missed. It bothers engineers who care about mastery. It’s the same for architects who see design flaws in buildings that were done by those who don’t care about mastery. Or a filmmaker who watches a movie with lots of flaws. Caring about obtaining mastery means having the capability of seeing the flaws and resolving them.…

there’s like 7 of these mastery-seekers worldwide

Hard disagree. I’ve met at least 7 in the course of my career alone.

Re: How good engineers write bad code at big companies

#192

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 problem I observe is the universal one: management doesn't care about good code, it cares about results. It's generally too hard for ANYONE to tell what's going on in a codebase unless you're experienced with it. Management can't evaluate the value of maintenance work, so it doesn't value it. I think this is a very telling statement, but perhaps not in the way you intended. I would agree that management only ca…

Why is the manager unable to understand? Maybe he should be able to in order to manage.

Re: How good engineers write bad code at big companies

#193

Earlier quoted context omitted.

It's interesting that you talk that there's a lot of good management, followed by a list of things I'd call bad management: Forget about good vs bad code, of course that's unimportant. But insufficient maintenance that causes lower velocity on the next set of changes matters. Good engineering will tell you when the issue isn't just about code that is ugly, but code that slows changes down so much you'd be better off…

> code that slows changes down so much you'd be better off improving it Note that the minimum amount of time necessary for a change is ~zero. A few minutes in practice because CI checks need to run, but that's it.

Is this facetious? Have you worked in anything remotely bad or complicated across teams?

Re: How good engineers write bad code at big companies

#194

Earlier quoted context omitted.

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

Thank you!

Re: How good engineers write bad code at big companies

#195
post #176

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…

>Management can't evaluate the value of maintenance work, so it doesn't value it at all. So it's the McNamara fallacy?

Was McNamara really thinking that's how you win a war and people just went along with it or was it just another excuse in a long line of excuses to keep the gravy train going?

Re: How good engineers write bad code at big companies

#196
post #156

Earlier quoted context omitted.

if I learned anything in my (too) long career is that one should do everything possible to ensure that whoever pays you needs you more than you need the money they are paying you. it is not easy to get there right away but if you make this core thing in your career it is achievable and your career will be happy and prosperous

Doesn't that just mean you are underpaid?

It means that we are okay with being exploited and that's almost universal except for the sociopath class

Re: How good engineers write bad code at big companies

#197

Maybe it's things like 4-year tenure, or shorter tenure, or something else. But I think it's a matter of motivation, Bob. > The thing is, Bob, it's not that I'm lazy, it's that I just don't care. It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? ... my only real motivation is not to be hassled. That, and the fear…

Motivation doesn't necessarily help.

I used to be an extremely motivated engineer. I cared about the code that I wrote, the other people on my team, making sure things were documented and understandable. I tried to write good code where I could, and detailed PRs and issue writeups where I couldn't.

Despite that, I was always paranoid I wasn't doing enough, because it always felt like there was someone else that was shipping more code than I was. Some of this was almost certainly social comparison bias and impostor syndrome-like feelings at work; but I also had a string of managers that pointed out all the work I was doing, and how I was helping the team as a whole.

Eventually, the company got acquired by exactly the sort of company this article is about, my manager got a new director from outside the company, and my manager had to go on extended medical leave after a cancer diagnosis, leaving the director with ~7 new reports. I started hearing about how the number of PRs I was opening weren't as numerous as some other people's, and the code didn't look "hard" enough to their glance. Never mind if the easy code was hard to come to, or if talking through it after the fact they agreed with my assessment, or if I had performed a detailed investigation and writeup, or if my peers left reviews or public plaudits about work I had done. Those weren't PRs, which is ultimately were what they wanted, since that was the metric they could easily see, and justify to their boss.

I did _try_ to do better by their metric, though I never had a definition of what "better" would actually be. Funnily enough, that person was fired a few months after I was.

Also kind of funny to me is that, if I weren't motivated and didn't care, none of this would've affected me all that much.

Re: How good engineers write bad code at big companies

#198
post #96

Earlier quoted context omitted.

> A good senior engineer is for the most part able to not write bad code from day one This seems unlikely. Self contained, I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior. But what is good code is in context of the codebase. It takes time to get the context of a reasonably sized codebase and no one is doing that in a single day or single week, even the wizards. I don't agr…

> I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior. You say that until you are tasked with doing impossible - three lines, all perpendicular, five green, two anti-green, seven in ten or more dimensions, any color; while customer only uses purple lines. Last guy that worked on it committed seppuku. Rest of team is in mental ward. Your only team member is guy that programmed…

Words aren't absolute. No reasonable interpretation of my comment suggests I'm saying you should do the impossible.

If someone asks you to do the impossible you have to say no. Better yet, you should figure out what they actually do want. They can't get the impossible, that's not on the table.

The worst thing an engineer can do is not learn how to say no.

I'll even say, if you don't know how to say no then you're not qualified to be a senior

Re: How good engineers write bad code at big companies

#199

Earlier quoted context omitted.

Yeah, this is a deliberate choice to make labor less powerful. Capital is willing to be less efficient for that. He does touch upon this by saying that Capital wants every worker to be replaceable.

if I learned anything in my (too) long career is that one should do everything possible to ensure that whoever pays you needs you more than you need the money they are paying you. it is not easy to get there right away but if you make this core thing in your career it is achievable and your career will be happy and prosperous

I find this insightful. Would you recommend anything in particular to get there? Other than staying frugal and being competent at your job?

Re: How good engineers write bad code at big companies

#200

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…

100% this. Stuff like database schemas gets comitted in the first sprint and never gets refactored, which completely locks you in to long term design decisions, then every subsequent PR will get held up for days in arguments around meaningless "code quality" arguments which ultimately affect nothing

100% this. The architecture is what slows things down (or speeds them up), the code quality, variable naming, all that bs just does nothing.
Post reply on HN