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

221–230 of 333 posts

Re: How good engineers write bad code at big companies

#221

Post by Ygg2 »

godelski wrote: post #198
Ygg2 wrote: post #96

Earlier quoted context omitted.

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

Your assumption that seniors will be able to output good code in any situation is what is the issue.

As a senior I've been tasked with impossible tasks, with insane deadlines, in ""enterprise"" code bases. Sure, saying NO is an option, but being the NO guy is surefire way to getting fired. And nothing looks better on resume than repeated firings.

Re: How good engineers write bad code at big companies

#222

Post by disgruntledphd2 »

skirmish wrote: post #208
alfalfasprout wrote: post #116

Earlier quoted context omitted.

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

There are always two systems, one is deprecated and the other not feature complete.

Re: How good engineers write bad code at big companies

#223

Post by Mikhail_Edoshin »

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…

Bad code bothers engineers because it is fundamentally wrong to write bad code. It goes against the nature of things.

Re: How good engineers write bad code at big companies

#224

Post by jpc0 »

bdangubic wrote: post #179
vlovich123 wrote: post #178

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

I don't think that's entirely true. Seeking mastery does not imply being a master.

If you have only ever seen one pattern to solve a problem, trivial example of inheritance, and therefore do that to the best of your ability then you have achieved mastery to your ability. Once you see a different pattern, composition, you can then master that and master identifying when which is suitable.

Lack of mastery is just using inheritance despite seeing alternative patterns.

Naturally mastery also includes seeking alternative solutions but just because a codebase uses inferior patterns does not mean those that came before did not strive towards mastery, it's possible that they didn't know better at the time and now cannot get the time to revise the work.

There's always a juggling act in the real world.

Assume incompetence and not malice, and incompetence is not a state of being. A person without experience can be seen as incompetent but quickly become competent with training or experience, but the code they write still stems from incompetence.

Strive to see your previous self as incompetent (learn something new every day)

Re: How good engineers write bad code at big companies

#225

Post by sigotirandolas »

alephnerd wrote: post #38
hkleppe wrote: post #24

You have to realise there is a almost full complete disconnect between engineering and business value

Ime, a lot of the onus falls on Engineering and Product Management failing to make a case for why certain engineering decisions (eg. Investing in continual tech debt grooming) have business value. The point of a business is to generate revenue. The point of employees is to do work that helps generate revenue. As such, any decision needs to ensure it has a business case aligned with revenue generation. Good engineerin…

When all leadership is asking is "what is the short term business value?", it's pointless to make that case. It's much easier to measure "yet another feature" than "fix the root causes of what makes our product subpar and slows us down". Not only that, but an incompetent engineer's "tech debt grooming" may make things worse.

I think that this may eventually become better now that there isn't so much dumb money around (no ZIRP) and with AI assistants taking on some low-effort work (enabling companies to lay off incompetent engineers). But it will take many years for companies to adapt and the transition won't be pretty.

Re: How good engineers write bad code at big companies

#226

Post by chii »

pupatlas wrote: post #103
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 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…

> in this situation is to give the manager some form of metric to describe the problem

how do you have a metric to measure a future issue that got prevented by having good maintenance?

Either you cannot actually imagine nor describe the problem that was prevented, or you could just make something up which cannot be disproved nor falsifiable. So if you asked for time/resources/budget to do maintenance, you cannot then give proof that this maintenance was useful!

The only way to get a metric is to have an incident or have issues crop up, and then in the retrospective, claim that certain maintenance work could've prevented it.

Re: How good engineers write bad code at big companies

#227

Post by [deleted] »

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…

[deleted]

Re: How good engineers write bad code at big companies

#228

Post by Cthulhu_ »

In my limited experience (enterprises like energy companies is the biggest tech areas I've worked in, code order of magnitude But even then, given time and number of people, bit rot and a slow downwards spiral feels inevitable. Which is why in those industries they will often do a rewrite every 5-10 years, especially in front-end. Often a redesign / rebranding (also every 10 odd years) will be used as an excuse to rebuild software entirely.

Re: How good engineers write bad code at big companies

#229

Post by pyrale »

tjr wrote: post #30
pyrale wrote: post #27

Earlier quoted context omitted.

That is, until planes fall from the sky.

It's popular to mock aerospace engineering, but it's usually quite robust. Even if people still sometimes make bad decisions.

The goal wasn't to mock Boeing, just to point out what happens when business overrides engineering. The context is the parent post making the point that there is little business value in good engineering.

Re: How good engineers write bad code at big companies

#230

Post by sethammons »

godelski wrote: post #198
Ygg2 wrote: post #96

Earlier quoted context omitted.

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

My CTO, when told that adding scope, reducing headcount, and keeping the same timeline all while discovering new unknowns in the codebase was not possible, we were simply told to make the date and asked who's performance review will be impacted. The "no" was entirely ignored. "I don't accept that."

How do you say no in that situation? Just quit?

Post reply on HN