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

How good engineers write bad code at big companies

seangoedecke.com

Post reply on HN
Print view View original

201–210 of 333 posts

Re: How good engineers write bad code at big companies

#201

Post by stuffn »

sfpotter wrote: post #93

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? Are they actually misguided for feeling like bad code is a catastrophe, or is it really the fault of the broader economic sphere we all inhabit? Is it actually maturity to reconcile ourselves to drift powerlessly as faceless and titanic forces sculpt our reality? So many possible questions.

Nihilism is a defense mechanism when everything is moving against your world view.

STEM people of all walks of life join because of the challenge, the loveliness of an elegant solution, and the “art” you create that leaves your mark. Good engineers view their code as a makers mark. This code represents me as my art and I should do my best. Unfortunately (or fortunately) this is beaten out of you by senior engineer and the shell left is a nihilist and misanthrope.

Corporate programming strips you of your creativity, your autonomy, and your drive. It’s simultaneously strict, but too loose where it should matter. It’s spastic in its execution. There is often little rhyme or reason aside from “build fast make money”. No one appreciates your contributions. You show up to meetings where sales and PMs simultaneously wrestle to take the credit you rightfully deserve. You made it 10 years, here’s another low budget pizza party while the sales team gets an all inclusive in Ibiza. You wanted to make cool, elegant, things, and instead you’re just a factory worker that had to do 7 rounds of interview for the privilege of stacking premade widgets together until retirement.

The end result as I and many engineers at and over the one decade mark have realize. Nothing matters, no one respects you, and no one truly cares. You get paid and promoted whether or not your code is elegant, or safe. You get recognized by prostrating yourself in front of leadership. So why should I give a shit if my code works or not. It passes tests and I get to eat.

The industry is pathetic and we should stop calling ourselves “engineers”. Modern corporate programming is analogous to working on a widget assembly line in the limit. Most of us simply find our joy elsewhere and have learned “hearts and minds” as the rule of corporate life.

Re: How good engineers write bad code at big companies

#202

Post by asdfman123 »

stoneforger wrote: post #192
pupatlas wrote: post #103

Earlier quoted context omitted.

> 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.

It's because the only people who can understand the code are people who write the code every day. And sometimes the devs don't even really understand it.

Occasionally you'll have a manager who manages in the day and codes at night, which is fine if not bad for his personal life. But HIS manager almost never does that. And his manager's manager? Forget it.

Re: How good engineers write bad code at big companies

#203

Post by skirge »

kcexn wrote: post #125
sfpotter wrote: post #93

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…

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…

big tech firms advantage is privileged access to public money, without focus on quality or cost. Good products start small.

Re: How good engineers write bad code at big companies

#205

Post by chanux »

ajkjk wrote: post #160
jagged-chisel wrote: post #139

Earlier quoted context omitted.

> 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 gar…

I don't think it's that. It bothers me a lot too, and not because anyone else is judging me or anything. I think it's just that it's depressing... it sucks to be doing bad work, on top of other bad work, and unable to do good work instead. It is incredibly frustrating to care about quality but be surrounded by and constrained to work on crap. Just feels like everything went horribly wrong somewhere and you're powerle…

I know how to fix this but I'm not "allowed to" can eat away at you easily. Then there are things that I know how I might fix but I wouldn't realistically be able to because it's all a lot to take on, there will almost never be enough time and hands to get it done, within the set constraints.

This is due to the way how incentives are aligned. Systems that are powering things for, say a decade at least but worked on Quarterly basis.

Why is this alive and well, then? Because it doesn't actually matter as long as money keeps rolling in. It is also possible that the losses caused by or efficiency not achieved do not show up in the accounts.

Re: How good engineers write bad code at big companies

#206

Post by chanux »

asdfman123 wrote: post #92
area51org wrote: post #72

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…

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…

Just linking this here hoping to back you up: https://www.businessinsider.com/block-cto-code-quality-suces...

Re: How good engineers write bad code at big companies

#207

Post by chanux »

doctorpangloss wrote: post #94
matt3210 wrote: post #10

It’s always a trade off between raising the bar and making a deadline. The deadline always wins since the boss doesn’t know how to read code

Deadlines are a way to manage people. They’re fine but most deadlines are not real. There are other ways to manage people, such as paying people more in bonuses for goals.

> paying people more in bonuses for goals

Then this leads to people setting tight deadlines. It's a vicious cycle.

Re: How good engineers write bad code at big companies

#208

Post by skirmish »

alfalfasprout wrote: post #116
asdfman123 wrote: post #92

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 a fairly universal one: management doesn't care about good code, it cares about results. The thing is, good code is a form of a good result. You need to solve the underlying problems (which manifest as impact) but if you used code to get there, that code if well designed is extensible, reusable, then you pay low maintenance on it and that same code can be used to solve other problems (ideal…

> It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt

No, it is just standard operating procedure: deprecate a working system and write a new system from scratch, with 50% of features not supported. This side-steps the tech debt and gives everybody artifacts for promotion. It screws all users of the system but who cares about them!

Re: How good engineers write bad code at big companies

#209

Post by knallfrosch »

Herring wrote: post #5

> Big companies know that treating engineers as fungible and moving them around destroys their ability to develop long-term expertise in a single codebase. That’s a deliberate tradeoff. They’re giving up some amount of expertise and software quality in order to gain the ability to rapidly deploy skilled engineers onto whatever the problem-of-the-month is. And also to "keep the balance of power tilted away from engine…

Software engineers themselves curse each other out if only "Bob" knows "his" code. So it's not only management.
Post reply on HN