> That’s a deliberate tradeoff. In my experience, while this line is often repeated, in practice it’s rarely really a “deliberate” tradeoff. Rather it’s mostly accidental.
[deleted]
How good engineers write bad code at big companies
261–270 of 333 posts
Re: How good engineers write bad code at big companies
#262Earlier 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…
There is also a lot of money, there is also good management, and there are also lots of incentives. But management depends on your manager; at scale it becomes likely there are bad apples in every management tree. Incentives may not align with what you want or need, with work From Home policies getting shrunk. Even money sometimes is a point of contention.
That's just the thing though: I want to know what those other incentives are and I was never told anything else than a hand-wavy "money" blurb with zero elaboration.
I mean OK, technically the ad viewing experience in f.ex. iOS is terrible; you sit through 30 seconds, then a white button on an almost-white background appears (dark pattern, they want you to sit looking at the ad longer), then when you "dismiss" is, an AppStore pop-under shows up and you have to dismiss that as well, and ONLY THEN you get another screen where you have to wait 5-10 seconds until the blessed micro X button finally appears.
This can be made much better: the ad platform might enforce the top-left corner be always black and the X button to appear only once and be effective immediately, for example. No shenanigans with bluffing that you are now leaving the ad but haha, you have fallen into our trap! Here's our AppStore page!
But why should Apple care? The money is literally pouring in! And humans operate on fight-or-flight responses much more than what 99% of them would be willing to admit; an Apple executive can drown you in executive jargon but the naked truth would still be "We don't want to change anything that might slow down our income". Or even more bare: "Don't touch it if it works and makes money".
So yeah, that's one of the examples where the hand-wavy "money" blurb would make total sense; I get it.
But in all my career I was never told in clear certain terms -- and they must also make sense -- about why not investing just a measly two hours more on technical excellence is so extremely unwelcome. Of course they always cite velocity and customer retention and how we must make sure we don't miss a potential client but I've never seen even one little piece of evidence of customers churning because a feature was delivered on Wednesday and not Tuesday. I am sure it happens, mind you, but I could never shake the feeling that those dangers are always hugely exaggerated.
Re: How good engineers write bad code at big companies
#263Anecdote: I consulted for a large manufacturing firm building an application to track the logical design of a very complex product. They modeled the parts as objects. No problem. I was stunned to see the following pattern throughout the code base: Class of the object Instance #1 of the class Instances 2,,n of the class I politely asked why this pattern existed. The answer was "it's always been that way." I tracked do…
Seems like a pretty easy thing to clean up. I am confused by these devs who just seem to give up. Just fix it!
Re: How good engineers write bad code at big companies
#264Earlier quoted context omitted.
7 out of 4 million active SWEs sounds about right :) how many codebases have you personally seen and went "holy shit, this is masterful/flawless/..."? even just libraries as codebases is most definitely 0...? our industry is basically few solid competent people followed by an ocean of mediocrity and incompetence... always been that way and always will be the way
I don't think it's possible to write a flawless codebase. That doesn't mean SWEs don't seek mastery of their craft. Moreover, achieving mastery doesn't mean you would actually want to write an 'ideal codebase', that seems like an art project disconnected from the purpose of the craft.
“mastery of the craft” is a myth… whatever codebase you see (and I’ve seen more than I can count) you will go “wtf is this?!” over and over again. furthermore, whatever codebase someone was lucky enough to initially start with, after X amount of time you asked those same masters (if they are still around) and they will inevitably tell you “oh boy, if I can start this over, I would have…” there just is no mastery, there are just people that deeply care about what they are building and try their best not to F it up along the way but all the “craft” and “mastery” talk is just empty words people talk around fireplaces and/or at various conferences where people pitching “craft” and “mastery” and “you need [insert dev process du jour XP/agile/…]” are there to make money selling the bullshit
Re: How good engineers write bad code at big companies
#265Big companies seem to demand you do things poorly. They make some insane internal requirement, and assume that if you disagree you're showboating or being a nerd, or something else. When really, you're only disagreeing because it's clear their idea is flawed. You're sticking your neck out to help the company; it would have been easier just to go along with everyone.
Yeah, I have seen that happen many times. When some engineer tells management that fixing the issue for real is faster than fixing it ugly they are never believed even though that is a not uncommon thing.
Re: How good engineers write bad code at big companies
#266Earlier quoted context omitted.
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…
I think AI will make it worse since it will allow the incompetent engineers to do much more harm.
Re: How good engineers write bad code at big companies
#267I'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 gar…
Agree. I get accountability for code I had no control over. That's a setup.
"You’re a senior engineer - why did fixing this take so long?” This is also maddening: it's not a question arising from technical indight or a management strategy ala Drucker, ishikawa, or any other serious approach. It's a guilt trip: it's like saying why did you dress so bad at this party? It's manipulative. And nobody likes these smeer tactics.
Re: How good engineers write bad code at big companies
#268Earlier quoted context omitted.
I find this insightful. Would you recommend anything in particular to get there? Other than staying frugal and being competent at your job?
Few things that I would tell my kid of she was starting out in this industry today - never work FAANG or any bullshit company like that - look for companies that are small (up to 100 SWEs max, preferably 1/2 that) that have solid business (20+ years, profitable) - when you get hired volunteer to fix every problem everyone else is running away from (there will be plenty). you will work hard in the beginning to underst…
Excuse me but this mostly sounds like a recipe to be burned out extremely quickly, and also blamed for everything.
I think your ideas are sound but they very generously assume competent and somewhat benevolent leadership. Something I have very rarely seen.
Re: How good engineers write bad code at big companies
#269Earlier quoted context omitted.
I think you are underestimating how many product problems at big companies are actually bad technical debt. They cant release new features or evolve the offering because the systems are too complicated to change. 1 year of quick development could stunt the whole org for the next five years.
The good news if you take 2 years to ship the system "properly" then you won't have to re-factor it because the company went out of business or that product was too late to market. There is a phrase "million dollar problems". You do stuff at your startup that will take a million dollars to fix because it doesn't scale. The point is that if your startup doesn't get to that scale then it doesn't matter. If you startup…
Replies like yours gloss over nuance. I don't mind prioritizing time to market as a programmer; I am not clueless, I understand that imperfect product that pours money into my employer's coffers is infinitely better than it sinking and we all get fired out of necessity.
My problem comes from the fact that the leadership _never_ compromises and never allows us to avoid at least some crises that are extremely easy to foresee (and have happened like clockwork in 95% of the cases where I or other colleagues have predicted them).
Again, sure, let's go to market and start making sales. I completely agree. But scolding a dev for fixing a DB schema anomaly that slows down ~40% of _all_ feature requests and that it took him the grand day or two to do so, is not just myopic. It's moronic.
---
Even shorter / TL;DR version: If the balance of power was 80% leadership and 20% engineers, I'd still be completely OK with that. But wherever I go the "balance" of power is more like 99% leadership and 1% engineers (and that's only when stuff really has hit the fan; they'd take away that last one percent as well if they could).
That is the problem. There's no balance. No compromise. Just people barking orders.
Re: How good engineers write bad code at big companies
#270Earlier quoted context omitted.
I don't think it's possible to write a flawless codebase. That doesn't mean SWEs don't seek mastery of their craft. Moreover, achieving mastery doesn't mean you would actually want to write an 'ideal codebase', that seems like an art project disconnected from the purpose of the craft.
“mastery of the craft” is a myth… whatever codebase you see (and I’ve seen more than I can count) you will go “wtf is this?!” over and over again. furthermore, whatever codebase someone was lucky enough to initially start with, after X amount of time you asked those same masters (if they are still around) and they will inevitably tell you “oh boy, if I can start this over, I would have…” there just is no mastery, the…
I think you are conflating mastery with some kind of beautiful codebase that is completely obvious to everyone else. Einstein had mastery over physics and yet his ideas required a lot of studying to understand and explore.
Engineering is the intersection of science and economics. You build the thing as best you can with the knowledge you have and you often discover things you didn’t even know once you start building. Combine that with time and resource limitations, and you have to make reasonable short cuts to deliver things.
Also remember that even if there’s one master on a codebase, organizations often pair them with many non-masters to try to accelerate things. What that looks like then is a mish mash of things that don’t make sense because the master is struggling to maintain a coherent vision that other people are executing; it’s hard to develop consistency even when there’s just one person let alone a broader team.
But your benchmark is fine if one master can show another master a codebase and explain why the pieces are there and which pieces are shortcuts and what the vision is. Trying to develop that knowledge by yourself in the middle of the dev cycle is a fools errand; one of the first things I do when I come to a codebase is ask a bunch of questions to build up my understanding of the history of the codebase and why things were done a specific way.