7 ms·

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 i

• alfalfasprout 11mo ago
  Interesting. Coming from big tech, it's actually pretty spot-on of an article. I think most folks at big tech have experienced this stuff too. > Why is it necessary for big tech companies to act this way? 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. These are all great questions. I have some thoughts, of course. But I'm not sure it's fair to describe OP as a burnt-out nihilist. The premise of the post is pretty reasonable actually.
  • sfpotter 11mo ago
    I don't disagree that it's an accurate portrayal of reality. And of course, as I made clear in my post, I don't know if they're actually a burnt out nihilist. My issue with the article is maybe more that the perspective and framing seem to want to lock out idealism from the conversation and encourage people to become ruthless, hard-nosed pragmatists in order to survive in this environment. Is that actually good, effective, or desirable? Again, lots of questions.
• kcexn 11mo ago
  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 makes sense to focus on making the repeatable processes more likely to succeed than simply hope that you happen to have the right team assembled for the job. Assuming that any of your engineers are above or below average hurts the ability for the business to plan.
  • Herring 11mo ago
    Yep you just rediscovered alienation https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation
    • sfpotter 11mo ago
      Whoa. Who's this guy? Sounds like he might have some answers to some of my questions!
  • master_crab 11mo ago
    True but this isn’t something big tech innovated. This is exactly how most large organizations work. For example, and specifically in the military, servicemembers are fungible and they are rotated every 2 years. The military even encourages attrition at certain ranks and points in people’s career.
  • skirge 11mo ago
    big tech firms advantage is privileged access to public money, without focus on quality or cost. Good products start small.
• master_crab 11mo ago
  You are being a bit unfair to the author, but I think I know where you are coming from in this argument. The writing comes across as “well this is the way it is and this is why it is.” That’s fine, but most of us kinda already know why it’s the way it is. Maybe, tell us something about how to adjust the culture.
• harrall 11mo ago
  I can find an experienced doctor, plumber, musician or mechanical engineer that was doing it 50 years ago. I’m not going to find someone that was doing software 50 years ago. And if I do, their experience is completely unrelatable.
  • chrisweekly 11mo ago
    That's one of the many many reasons I miss my dad so much. He went straight from MIT to GenRad circa 1970. I didn't start doing software till 1998, but we had some years of overlap -- and it was profoundly gratifying to connect w/ him on engineering topics. The learning was even bidirectional tho I'm sure I got more out of our pseudo-professional interactions than he did. Sigh. I really miss him.
  • aworks 11mo ago
    I worked on compilers and tools starting in 1981. Proprietary compiler technology has disappeared over the decades and the development tools/language/process/compute have changed considerably. But the skills and role of a compiler developer seem similar, although maybe it just means this sub-field of software has matured.
• levodelellis 11mo ago
  Every time I read his article I regret it. I literally mean every time, 100% of it. Judging by the title of the article, I didn't expect his reason to be "engineers working outside their area of expertise". I've seen good engineers figure out problems outside of their expertise plenty of times, so that's not a good reason either. I feel like this article is the equivalent 16 paragraph stating you're likely to be correct only 10% of the time when you guess a random number from 1 to 10
• jagged-chisel 11mo ago
  > 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 garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity. Yes, these are management problems. I’ve spent years managing managers and attempting to educate them on how bad code causes errors and delays. But for many reasons, it’s a Sysiphean task.
  • sfink 11mo ago
    Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. I got into this career because I like mucking about with this kind of work. Programming is sort of like building thought sculptures. Ok, maintaining them too. I spend a lot of my adult life working with these systems, so of course I care about their quality. It is unpleasant to work on a hack-filled creaking monstrosity of a codebase. My skills, such as they are, don't help as much as it feels they should, because I rely heavily on understanding a system based on how it sort of has to work given what I know about the constraints, and hacky systems constantly confound my expectations. That means I have to spend way too much time and effort learning the idiosyncrasies and unpredictable corner cases, and so have less time to make the changes I want to make. It's like a carpenter working on a house where nothing is straight, nothing is level. Or a cook given flavorless or half-rotten ingredients to use. You spend more time picking out the bad (or picking out the good and discarding the rest) than actually cooking. Any my scope is limited. Some changes are just not feasible to make, because there are too many hidden and/or unnecessary dependencies buried in the code. If you change one thing, everything falls apart. If you patch it together well enough to more or less work, you're faced with a long tail of subtle bugs that you'll be battling for a long time to come. There's no conceptual integrity. Furthermore, working with a team that accepts a never-ending accumulation of creeping technical debt is also unpleasant. You can't trust that a positive review means anything. If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough. Who cares that it means less maintenance overhead in the future if nobody's planning on sticking around, or people are depending on things being constantly broken so that they can spend their days knocking off relatively easy whack-a-mole style bugs? Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not. If they aren't, I know that the codebase is going to be littered with similar crap, and that my job is going to suck. That's what bothers me so much. This is true even if I'm the author of the bad code. Why didn't the reviewer point it out? Is it like the article said, and there's nobody competent enough to spot glaring issues? That is also a component of a job that sucks.
• zmj 11mo ago
  My feeling when I found this blog was "so I'm NOT the only one!". It's the painful truth about staff+ engineering that I've also experienced, but haven't felt safe to talk about. You're not wrong that there's something cynical or nihilistic about it. The core thesis is "do what the company wants, even if it's not what they should want". That idea may be unpalatable, but getting ground up in the corporate gears is worse.
  • jeltz 11mo ago
    Having tried both I would rather be ground up again than just accepting my fate. I rather die fighting than the alternative.
  • lalitmaganti 11mo ago
    My personal feeling is that there's a way to both agree with the underlying issues Sean writes about while being more optimistic and providing better alternatives. Something I feel I should start writing about more.
• vlovich123 11mo ago
  > 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. It could be maturity to resign to powerless forces or it could be the inability to obtain that mastery or the willingness to let go of that mastery. I would think it’s more mature to fight the good fight, but at some point you just get old and tired I imagine. And it’s interesting to posit the author is nihilistic when this “uncontrollable forces” itself is a nihilistic take imho.
  • bdangubic 11mo ago
    there’s like 7 of these mastery-seekers worldwide
    • vlovich123 11mo ago
      Hard disagree. I’ve met at least 7 in the course of my career alone.
      • bdangubic 11mo ago
        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
        • neko-kai 11mo ago
          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.
• MaxfordAndSons 11mo ago
  > Why is it necessary for big tech companies to act this way? This question gets directly at the cause of the author's nihilism: the necessity is borne from the endless pursuit of positive quarterly growth, the "binding fiduciary duty to shareholders". Which is a lie, there is no such legally binding fiduciary duty. So the aforementioned necessity is also a lie. Companies could operate on a longer time horizon, let engineers write better code, make better products, maybe even consider societal good in their strategic planning, and still turn a healthy profit. But the cost of perhaps taking a few degrees off their YoY trend line is unacceptable to the insatiable greed of their controlling shareholders.
  • stoneforger 11mo ago
    Fuck Jack Welch
• kuahyeow 11mo ago
  I think you are ascribing too much into this. If he does not believe anything then there will be nothing to write about. It looks like he does not believe in _your_ ideals - that does not make it nihilism though.
• majormajor 11mo ago
  I think the engineer jumping between giant companies for three years or less every time rarely works on particularly key things. Big tech companies do a LOT of stuff, and most of it is crap that isn't moving the needle. This post describes teams that are constantly changing priorities (chasing trends?) and IME that's not true of the really core, central functions at companies. But very true of the "support/enabling" or "what else can we do?!" side functions. For instance, Github Actions being a meh product is called out in the article - that's a classic "check the box" feature that's good enough for a lot of people (let's not forget that Jenkins was no picnic before it) but is never gonna massively increase GH's bottom line. Those sorts of projects are easy places for politics to fester since they are easy to ignore for the most influential-and usually strongest-parts of leadership. On the other hand, if you're on a core, mission-critical team and other people's code is turning into your bad performance review, you need to figure out if the problem is (a) bad/toxic manager or (b) a failure to keep your management chain informed at what the root issues are and how you can improve it.
• Mikhail_Edoshin 11mo ago
  Bad code bothers engineers because it is fundamentally wrong to write bad code. It goes against the nature of things.
• stuffn 11mo ago
  > 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.
• matwood 11mo ago
  I think one of the issues is that engineers define bad code on a different set of dimensions than the business, and even amongst each other. Early in my career I was definitely guilty of this, that if the code didn’t fit my definition of perfect code, it must be bad. I’ve met great programmers (I don’t consider myself in this group) in my career who put even more strict criteria on something to be considered ‘not bad’. Then I worked at small companies, big companies, was an owner at one, and my definition of bad code narrowed. While my criteria are still subjective, if the code meets the business goals and a baseline of quality I consider it fine. Because outside of some absolute genius programmers like Carmack, few of us will look at someone else’s code and not think of any type of improvement.
  • omnicognate 11mo ago
    I've come to quite a specific definition of "bad code", at least the main form of bad code that infests corporate environments. It's overly complicated code, but people disagree on what that means too, and I have a concrete definition of that now. Bad, over-complicated code is code that requires you to form an unnecessarily detailed mental model of it in order to answer a particular question you may have about it. People rarely read code in its entirety, like a novel. There is almost always a specific question they want to answer. It might be "how will it behave in this use case?", "how will this change affect its behaviour?" or "what change should I make it to achieve this new behaviour?". Alternatively, it might be something more high level, but still specific, like "how does this fit together?" (i.e. there's a desire to understand the overall organisational principles of the code, rather than a specific detail). Bad code typically: * Requires you to read and understand large volumes of what should be irrelevant code in order to answer your question, often across multiple codebases. * Requires you to do difficult detective work in order to identify what code needs to be read and understood to answer the question with confidence. * Only provides an answer to your question with caveats/assumptions about human behaviour, such as "well unless someone has done X somewhere, but I doubt anyone would do that and would have to read the entire codebase to be sure". Of course, this doesn't yield some number as to how "complicated the code is" and it depends on the question you're asking. A codebase might be quite good on some questions and bad on others. It can be a very useful exercise to think about what questions people are likely to seek answers for from a given codebase. When you think about things this way, you come to realise a lot of supposedly good practices actually pessimise code in this sense, often for the sake of "reusability" of things that will never be reused. Dependency injection containers are a bête noire of mine for this reason. There's nothing wrong with dependency injection itself (giving things their dependencies rather than having them create them), but DI containers tend to end up being dependency obfuscators, and the worst ones import a huge amount of quirky, often poorly-documented behaviour into your system. They are probably the single biggest cause of having to spend an entire afternoon trawling through code, often including that of the blasted container itself (and runtime config!), to answer what should be a very simple and quick question about a corporate codebase.
• deleted 11mo ago
  [deleted]