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

311–320 of 333 posts

Re: How good engineers write bad code at big companies

#311

Post by zanellato19 »

Herring wrote: post #294
zanellato19 wrote: post #61

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.

> this is a deliberate choice to make labor less powerful... To be fair, though, I don't trust modern labor either if they can't figure out how to NOT vote for a rapist pedophile real-estate billionaire. Twice. Including a pandemic and a coup. What a mess we find ourselves in.

I think labor is worried about a bunch of practical things that the Democrats didn't know how to communicate and Trump did.

Did he mislead them? Yes but honestly, so did a lot of Democrats.

All that to say, yes, but Capital has a lot more resources available to mess with people's head.

Re: How good engineers write bad code at big companies

#312

Post by Herring »

zanellato19 wrote: post #311
Herring wrote: post #294

Earlier quoted context omitted.

> this is a deliberate choice to make labor less powerful... To be fair, though, I don't trust modern labor either if they can't figure out how to NOT vote for a rapist pedophile real-estate billionaire. Twice. Including a pandemic and a coup. What a mess we find ourselves in.

I think labor is worried about a bunch of practical things that the Democrats didn't know how to communicate and Trump did. Did he mislead them? Yes but honestly, so did a lot of Democrats. All that to say, yes, but Capital has a lot more resources available to mess with people's head.

Idk man, I'm pretty sure there's more going on than that. Look at this study for example https://link.springer.com/article/10.1007/s11109-024-10000-8

Normal people would become more liberal.

Or look at how badly teachers are treated https://www.census.gov/library/visualizations/interactive/te...

Or look at the way Americans punished Democrats really hard after Obamacare https://www.quorum.us/data-driven-insights/under-obama-democ... Democrats won't make that mistake again of listening to Bernie any time soon.

Or look at how bad the coronavirus response was, for such a rich country.

Something's deeply wrong with American political culture, like from watching too much Game of Thrones or something. It’s not just being misled, it’s ingrained.

I think for many Cruelty Power. Like how guns make them feel powerful. I wasn't born here originally so I don't really get it (thank god). It won't end well.

Re: How good engineers write bad code at big companies

#313

Post by Kinrany »

stoneforger wrote: post #193
Kinrany wrote: post #184

Earlier quoted context omitted.

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

I don't think we disagree? Bad code makes it harder to make changes, that's why it's bad.

Re: How good engineers write bad code at big companies

#314

Post by Ygg2 »

godelski wrote: post #293
Ygg2 wrote: post #290

Earlier quoted context omitted.

I get the feeling you didn't work in a dysfunctional company. Here is some anecdata. I came onto a team, that had team lead, product owner fight tooth and nail to not use boolean special flags for some case. Instead the Product Lead went to CTO and overruled them. A product lead that ain't a programmer told programmer's to shove it, and do how he wants it. This flag along with many, many such cases has been caused pr…

Actually I worked for a failed startup where everyone left because they disliked management. In that startup I was the lowest paid engineer and the only non "staff" level one who had a contract bringing in money to the company. My last employee review with the company was terrible even though they admitted in the meeting that I had achieved all the goals and gone above and beyond what they had requested I do to get a…

> This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences.

Not really. I'm reaching my conclusion after several experiences in various domains (fintech, ad tech, logistics software, and government-adjacent firms). Each company is terrible in its own little way. The reasons aren't always the same, but they can vary from colleagues to bizarre pipelines, to management to CEOs.

I have communicated this to management, to PO, to scrum masters, to a point. I don't want to get fired of course.

And I can see the outlines of what caused these issues and why management is doing what it is, but that's again tied to a larger economy at play.

> You're not stuck where you are, so stop acting like that.

Again, you're assuming you understand my condition.

It's a different pickle. I'm waiting for an external thing to happen (it has been continuously delayed for nearly 12 months) to be able to change jobs. Not that it's easy in the current market.

Re: How good engineers write bad code at big companies

#315

Post by pdimitar »

jeltz wrote: post #11
lapcat wrote: post #4

> They are almost certainly working to a deadline, or to a series of overlapping deadlines for different projects. I think this is crucial. Even old hands working on their area of expertise can be compromised by deadlines.

Yeah, I in my experience this is the root of most bad code. People rushing. And it is not even necessarily faster to rush, since often working slow and methodical wins the race. I don't get why we as managers and engineers have just accepted rushing and taking shortcuts as the default. Especially at the big tech companies this constant rush makes zero sense, they have tons of engineers they use very inefficiently.

What is there to get? Bull-headed egomaniacs on a power trip are the norm in most of the world -- on the executive positions, middle managers included.

Reasoning with unreasonable people is not impossible but drains too much time and energy... and you don't know if they will not come back to you next week and hit you with "You know what, I actually think that your idea is not as good. Let's get back to mine and...".

I have danced this dance. As much as it pains my younger idealistic self to say this, you'll know how well you'll work with somebody after the end of the first week. All the signs are there, we just choose to ignore them because you can't bail during your first month after all.

Re: How good engineers write bad code at big companies

#316

Post by pdimitar »

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…

Well maybe you get hit with the gray arrows because you first make a sweeping generalization and then say "I have no sympathy for you". Food for thought?

I have communicated the business value in addressing tech debt, as in I have pointed out how many critical customer features got delayed by it and we churn customers we really can't afford to.

Still got overruled. The tech lead stepped in and threw his weight around with zero explanation to the CTO or the CEO. Who needs to hear what the engineers on the ground have to say, right? They cannot communicate!

Man, tearing down strawmen is easy. You should do better and see nuance. A lot of engineers communicate very well and are still ignored.

Re: How good engineers write bad code at big companies

#317

Post by pdimitar »

cadamsdotcom wrote: post #148

There’s a cost-benefit component missing from the analysis. “Bad” code is probably “good enough for now” code that was written some time ago on a bet that doing it better would never be needed as it wouldn’t need to change. Also, “good” code is costly especially if taking longer to build the thing causes the company to miss its market.

Bad code is not written on a bet. It's written because either competent engineers crunch, or because they are incompetent.

Good code could be costly, yes, but often is not. In fact it's very often economically sound to periodically address tech debt i.e. not allow it to accumulate because it seems to increase exponentially until one day a critical customer-acquisition-stakes feature cannot be shipped on time due to it. Only then do the executives wake up and even then 80% of the time they just blame the engineers and move on. They are never at fault, the angels.

Finally, many companies are already on the market and are relatively OK economically. Let's be honest: most deadlines are entirely artificial and are just power moves by management; they are not mandated by critical business needs.

Re: How good engineers write bad code at big companies

#318

Post by Ygg2 »

godelski wrote: post #271
Ygg2 wrote: post #221

Earlier quoted context omitted.

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.

Again, you need to reasonably interpret what I'm saying. Picking out an edge case and acting as if it is some mic drop is disingenuous. We can't communicate if you hyper fixate on one tree when our discussion is about the forest. Language isn't precise enough to do that without getting extremely verbose. So either I can write a novel in response (I'm not going to) to explain what I said above or you can work with me…

> We can't communicate if you hyper fixate on one tree when our discussion is about the forest.

All I'm saying is you can't expect perfect code in impure systems.

> You are not a mindless automata directed by your manager.

I never said I was, but I also can't turn a ship on a dime. I'm asked to perform a task; I'm going to perform to the best of my abilities, but in impure systems the best you can do is patch the leaking part with code and do some basic refactoring. Any moment spent trying to simplify and fix the software will be rightfully considered a waste.

Because a feature sold is better than performance gained (unless it's utterly abysmal).

> The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.

Again, in impure systems half the puzzle pieces have left, some other parts of other puzzles have been mixed, and it's the clock is running.

The more you focus on cleaning code, the more you are falling behind feature wise. Up until a point that you can present to managers "Shit is very bad, we need to refactor."

Re: How good engineers write bad code at big companies

#319

Post by n4r9 »

lloydatkinson wrote: post #7
n4r9 wrote: post #2

The referenced article Pure and Impure Engineering was discussed a few months back here: https://news.ycombinator.com/item?id=45165753

I find these drive-by-attacks on CQRS to be particularly frustrating. Some people know CQRS or CQS are fairly straightforward ideas that can be nice to use and give you some benefits. Some people believe CQRS is some kind of elitist architecture authoritarianism bogeyman in the same category as the microservice pushback.

I searched for "CQRS" in both the HN thread that I linked and the article that that linked, and the only mention I could find was this:

> Companies burned hundreds of thousands of engineer-hours migrating from monoliths to microservices, or from HTTP service calls to event-sourced architecture, or from event-sourced architecture to full CQRS, and so on.

Is that what you're talking about? imo this hardly counts as an attack on CQRS itself. The issue is rather with enterprise companies forcing the migration of large codebases based mostly on hype.

Re: How good engineers write bad code at big companies

#320

Post by pavel_lishin »

bad_haircut72 wrote: post #49
mikert89 wrote: post #37

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

I moved teams a few years ago, and the very first thing I did was push hard to re-structure the schema they (sorry, pals) slapped together without much thought. It took some fair amount of arguing, and maybe a PR that I had reviewed by only a single person and pushed through because it's easier to ask for forgiveness, but we got there in the end.

Luckily, we were able to do this before the code started hitting production traffic; it would have been significantly more difficult to fix once we started getting real data into the system.

Post reply on HN