10 ms·
I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we pe
by jaggederest 2y ago
I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field.
These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor.
It's laudable to do your work well and go home to the rest of your life, and working "extreme" hours is both a bad policy and a bad sign that the system you're operating in is brittle. Nothing that we do is so unique that another competent engineer shouldn't be able to fill in for you when you are having an off day.
The effect of consistent, careful, workmanlike effort over time trumps any number of crunch weeks and burnout episodes, to an almost absurd degree.
- ultra-boss 2y agoCouldn't agree more. I read a book (okay, I half read a book...I couldn't finish it, it was so bad) where the author (a marketer!) argued that software engineers are the most skeptical audience, and I was like, "Um, have you ever met an investigative journalist? Or people in the many many other professions that require skepticism and analytical thinking?" The sooner the software engineering field can be rid of its beliefs about the inherent brilliance of programmers, the better for everyone involved. Inlcuding software engineers!
- aleph_minus_one 2y ago> Couldn't agree more. I read a book (okay, I half read a book...I couldn't finish it, it was so bad) where the author (a marketer!) argued that software engineers are the most skeptical audience, and I was like, "Um, have you ever met an investigative journalist? Or people in the many many other professions that require skepticism and analytical thinking?" From my life experience, the claimed statement actually does have some truth in it: software engineers experience a lot more bullshit marketing than other professions that require skepticism and analytical thinking, thus they, in my experience, have indeed become more immune to exaggerated marketing claims. Also it fits my experience that software engineers are much more vocal about calling out bullshit (just consider the "bullshit bingo" game) than other professions that require skepticism and analytical thinking, thus based on the audience reactions alone, any salesman would likely indeed come to the conclusion that software engineers are the most skeptical audience.
- davidf18 2y ago[dead]
- lovich 2y ago>These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. Didn't we pass the rubicon on that in the early 2010s? I personally don't feel that its "like" finance but that its the exact same behaviors from the exact same set of people. Once tech stopped being a bunch of nerds in a basement and started being a source of wealth and power, it attracted a whole slew of intelligent and wealth seeking individuals who would have gone to wall street previously. Its not like the math skills don't have a heavy overlap already. And well, now that they're here, we see all the same power games being played with the same results
- ambicapter 2y agoI don't think it "attracted" a certain kind of people, I think the people who were already in tech just became more wealthy and powerful, and that, predictably, brought out the worst in some. The worst qualities of "tech" people can be conflated but I think have a different flavor than the worst qualities of "finance" people. It's really just the same obnoxious behavior you can spot in young tech people. Some people grow out of it, and some people earn a ton of money and so have no reason to grow out of anything (not that you can't make money AND grow out of it, but there's less outside pressure to do so).
- grandempire 2y agoIt absolutely attracted different people. The inflows are much larger and not the same. For example EE used to be prestige and CS was the backup. And that would never compare to finance or law.
- yubblegum 2y agoYes but imo this change happened no later than late 90s. I distinctly remember how suddenly it became cool to be a programmer and the 'new type' was already making changes by early '00s. And yes, the $s attracted smart people who did not embody the old hacker ethos. These are the new bloods that gifted us with surveillance tech, btw.
- strangattractor 2y agoI was once considered a 10X. I would work all night. Rewrite code simply because I found it objectionable - lots of things I'd never do now. Mostly after working those long hours I return after a long rest and spend most of my time fixing all the new and ridiculous problems I created while working tired. Things may have gotten done a little faster. Never once did it even matter - there was no material benefit to the company. Projects still got canceled - team deadlines still missed - products still had bugs - company focus changed blah blah blah. Focus is a supper power. Not getting diverted with trivial shit. Don't get distracted , avoid creating more work for yourself and others. Todays me would find yesterdays me a -10X annoyance.
- nntwozz 2y ago"Focusing is about saying no." — Steve Jobs https://www.youtube.com/watch?v=YgL8fpya8BA https://www.youtube.com/watch?v=YgL8fpya8BA
- hinkley 2y agoThere was a great article a little while back about how “yes, but” is powerful but “no, but” is almost as powerful. No we won’t do that, but we can do this. Or that is trickier than it sounds but we will think about it until it makes sense.
- awesome_dude 2y ago> Never once did it even matter - there was no material benefit to the company. I think that the idea of having people (at startups) working at a frenetic pace is because 1. The VC money is running low 2. Being first to market used to be a major determining factor on whether the product would succeed or fail
- strangattractor 2y agoMy experience is that people tend to fill the time they give themselves to do things. Give yourself 12 you take 12 hours. But humans have a limit to the focused productive work they can do. Lets say it is 4 hours. So of that 12 hr - 4 was really productive and 8 not so much. When I was at my tiredest I often spent hours trying to debug issues that literally took me minutes when I was rested. One time I worked so many hours I lost vision (temporarily) in my eye - called cotton wool spots. I was a generally healthy younger guy. Working this way has health effects. If in fact there is such a thing as 10x engineer - how long do you think you will stay 10X once your health deteriorates. Just my 2 cents.
- deleted 2y ago[deleted]
- noosphr 2y agoSoftware is different. All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly peripheral folder holding source code called all over the code base and the near impossibility of moving it in a location that makes sense for it without having to refactor the whole code base. People, including myself, have a seriously bad intuition just how much volume there is in a space which grows at least exponentially. The closest discipline to software engineering is mathematics and that has an even worse track record. There's the folklore about half of all math papers giving the wrong proof for the right conclusion. By comparison software engineering only gets catastrophic bugs less than every other time a program is run. [0] All trees are natively embedded in some hyperbolic space of whatever curvature matches the average number of children per node, and all code can be ultimately represented as a tree.
- tkahnoski 2y agoI think maybe this misses the mark. Yes software can lead to unbounded complexity unlikely many physics based engineering disciplines. However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points. What's very different is the cost to change the system to do something new and that's where this unbounded complexity blows up in our face.
- noosphr 2y ago>However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points. This is a common sense view of computation that's unfortunately wrong. The simplest counter example is the busy beaver program: with as little as 12 states we have saturated the computational capabilities of the universe, but it looks completely safe and sane for the first few states you would be testing against. You may call it pathological, and you'd be right, but the point is that you never know under which rug a function that takes more computation than the universe can supply is hiding. By comparison power electronics engineers don't have to formally prove that they didn't accidentally include a nuclear power plant in their e-scooter design.
- CrimsonRain 2y agoYet, it is trivial to find "competent engineer" in other fields and software engineering is filled with mediocre ones at best. When there's 1000 ways to do a thing, with wildly different pros and cons, and insane amount of unknowns in a field that is evolving so rapidly that it is (near) impossible for someone to keep up, being "competent" is not easy.
- WgaqPdNr7PGLGVW 2y ago> I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic The ratio of software engineers working in novel design spaces compared to plumbing style work is best guess ~1:5. The ratio in more mature fields like civil engineering is closer to ~1:500. There are lots of similarities between software engineers and the few folk in civil etc doing actual novel design work. > Nothing that we do is so unique that another competent engineer shouldn't be able to fill in for you when you are having an off day. In novel design spaces people are not fungible.
- freddie_mercury 2y ago> The ratio of software engineers working in novel design spaces compared to plumbing style work is best guess ~1:5 Google has something 25,000 developers. You think Google has 5,000 people working on novel design spaces? That number sound way, way too high. By at least an order of magnitude. And Google at least has customer facing technology compared to the thousands of companies whose developers only work is, say, integrating HR systems or deploying SAP or maintaining some legacy billing system.
- WgaqPdNr7PGLGVW 2y ago> You think Google has 5,000 people working on novel design spaces? Yes. Maintaining a bridge is in general not novel. There are clearly established best practices that have stood the test of time. Maintaining a ridiculous tangle of millions of lines of code is novel. There are no best practices on par with other engineering fields. We are at the stage of rough heuristics in most parts of software dev. One day there will be broad and consistent over time agreement on how to handle large software projects. But we aren't there yet.
- freddie_mercury 2y agoIBM's S/360 was millions of lines of code in the 1970s. Managing millions of lines of tangled code is not novel. It is older than most HN readers.
- logsr 2y ago> something unique and different about software engineering how much does the strength/weight ratio of building materials improve every year? how much does the price/quality ratio of building materials fall every year? software engineering is working with technology where compute capacity was doubling and price/performance was halving every two years for decades. this rate of change has slowed, but in a world where the price of everything else inflates, software is a rare field that works with a continually deflating capital base. the uniqueness of software development is real and based on underlying physical/economic factors that exist in very few industries. software developers are not unique. they are still human. but the profession is unique and the financial incentives are unique. consistent, careful, workmanlike effort over time wins on average, but because the incentives are large, many people will take the risk to get exceptional rewards. i approach software development like a professional athlete. i work on optimizing every aspect of my performance (physical, mental, social, technical) to be the very best i can be. anyone who applies this level of dedication in any field will be highly successful, but it requires dedication, sacrifice, and risk, which many people are not willing to accept. the world is full of exceptional software and algorithms designed by unique individuals who developed things nobody else could or would. there is a reason why mathematical discoveries are named after the people who discovered them. building software for large corporations necessarily revolves around median-level teams, because mean-reversion always happens at scale, but that is also why a great deal of technical innovation takes place outside of large corporations.
- FreebasingLLMs 2y ago[dead]
- avs733 2y ago> I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. My university has an alternative entrepreneurial focused “senior design” course open to engineers and cs students. Because of scale the CS students are now separated in a different section. All I can say is the level of toxicity that I’ve witnessed from cs students to engineering students has made this a much nicer course to work with teams. Engineering students can be ego driven now it alls sure, but the level of toxicity behavior and assumptions of superiority I’ve seen from CS students makes me glad I don’t have to deal with them anymore. The primary fault I see, and it’s buried in the abstractions comments from others is the assumption that their knowledge is all encompassing because it is so abstracted. The inability to attach it to contextual realities is taken as virtue rather than a risk factor. I always go back to the fast company article on the coding team behind the space shuttle and their culture. The difference is telling in terms of qyality and risk tradeoff. Realistically the number of engineers who will design something that could kill someone and software developers who will exist at opposite ends of the percentage scale. That reality manifests in professional culture. We’ve seen it in so many places. This threat is insightful but not in the way commenters likely think.
- throwaway2037 2y ago> well known toxic field, finance I assume here that you mean investment banks, more specifically: M&A and capital markets, where the lion's share of profits are made by few people. Post-2008, the industry has cleaned-up so much. What is toxic about finance today?
- TZubiri 2y ago[flagged]
- ltbarcly3 2y agoI think one thing that is very different about software engineering is that it's the only form of engineering I'm aware of where a very substantial fraction of the people employed to do it lack basic fundamentals like "being able to do it". Most software engineers can't write a program without google. They can't remember basic facts about the language they use every day. They don't have a sense of what makes sense and what is weird. They can't debug problems they run into without help. I know whenever someone says anything negative like this people come out of the woodwork to say the opposite, and that's fine, but I can't name a single competent programmer who doesn't say things like this in private, and I know a lot of them. Test it for yourself. The next time you need one of the mediocre people on your team to do something pay attention to how they do it. I will bet you it's something like this: Get the ticket. Spend a day or two trying anything they can think of, googling, pasting stuff into chatgpt, etc. Then they start messaging people. They tend to try to not always ask the same helper because it would get too annoying, so they rotate around the team asking for help. The helper starts by offering suggestions, but the mediocre dev can't get those suggestions working or apply them correctly. Pretty soon the helper just types a bunch of code into the chat window so they can go back to what they are trying to do. The m dev takes this code, and pastes it into their branch. It's not quite right though, it needs a little tweaking to work but they can't figure out what to do, so they message the next helper. (And sometimes it's hilarious what it is, a lot of times it's a typo and when you run the code it says exactly what line it's on, but they don't know how to run code besides pressing the button in their editor that someone else set up for them) To helper 2 it seems like they are making good progress, they are just stuck on some small thing. Happens to everyone. They tell them exactly what's wrong. And voila, this is how about 30% of the people you work with write code. People don't catch on because when you are helper #2 you assume they wrote that perfectly competent code.
- jpeloquin 2y agoI can confirm that some (30%?) mechanical and biomedical engineers follow the described problem "solving" strategy exactly. It's not just software engineers.
- nyarlathotep_ 2y agoI don't think, excluding some scenarios at well-disciplined firms that anything like "engineering" exists in programming. The processes surrounding development often strike me as haphazard, cargo-cult like behavior, and entirely subjective. Regarding people not remembering stuff--yeah that's probably true, but there's a lot a typical developer has to jump between--do people really get to "specialize" in JUST like writing Java CRUD or something anymore? Feel like there's always also troubleshooting some Docker thing, some cloud provider, some build system, some pipeline etc etc. When there's no stability and moving targets, maybe you're not incentivized to be a "specialist" on a language or whatever (this might also be painting oneself into a corner for their career) given how easy information retrieval is today? RE: the scenario Is this real? I've never been employed at any sort of fancy role but I've never encountered this kind of thing (publicly) involving me, and I generally get on well with others, so I assume I'd have seen it by now I'm sure plenty of programmers pasta from LLMs constantly now, but I've never had bizarre low-hanging "what do" inquiries. Most people have some discipline and structure when asking questions: - I'm attempting to integrate library x into the project - I've done the following and the build fails in CI with $ERROR - I've checked x, y, z - Have you encountered something similar? This indicates some level of actual understanding of how things work, or prerequisite research prior to asking. Also, where can I get a job where they hire people this minimally competent? I'm seriously burnt out and this seems like a nice change of pace. I'm totally serious with that question.
- nodoll 2y agoThere is something toxic about calling arbitrary things toxic. >The effect of consistent, careful, workmanlike effort over time trumps any number of crunch weeks and burnout episodes, to an almost absurd degree. If you have an actual life, you know, with unexpected stuff coming up from time to time, this is just not possible. Then the only way to get stuff done is go 10x during the time you have whenever you have it.
- musicale 2y ago> Then the only way to get stuff done is go 10x during the time you have whenever you have it. I believe PP is correct: the cost of "going 10x" is greater than its benefit in the long run, and often in the short run. Henry Ford lowered the Ford company work week from 48 hours to 40 hours to improve cars manufactured per labor-hour, and to give employees leisure time to drive places (increasing demand for cars). Wages were raised to compensate, further increasing loyalty to the company while enabling employees to buy more cars. For software, a 40-hour week may not be optimal, I tend to think that it may be too high rather than too low.
- majkinetor 2y agoYou are so wrong. Complex multiyear things are so unique that there is next to 0 chance to find another competent engineer as replacement. Some companies do that, and the only result is the extreme lack of quality and consequently reputation degradation. I witnessed this myself many, many times - great products turning into non-efficient and hard to use BS. Complex things posses such a big number of moving components that simply iterating over them placing them into context is impossible for anyone except the one that was deep into it for years. Its not possible to "fill in" such person, particularly if that person was lacking in some domains like proper documentation (typical case). As an example, I am leading a project that creates a government bank from 0. Just in last 2 years I wrote 1000+ pages of compressed documentation on it besides programming and management. Please replace me. My company and I are trying to do that for last 5 years.
- wiseowise 2y agoIf it’s so easy and not unique, how come engineers with supposedly 7-10 years of experience, that I work with, write absolute braindead code that breaks if you sneeze at it?
- eru 2y ago> These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. I'm not sure what you are talking about. Finance people regularly talk about risk adjusted returns, not raw returns.
- unconed 2y ago>Nothing that we do is so unique that another competent engineer shouldn't be able to fill in for you when you are having an off day. There is a big difference between filling in someone on an off day, and actually taking over their job. It's only felt over weeks and months. "Consistent, careful, workmanlike": this does not describe the kind of software built by most teams, but it does describe the work of good individuals.
- keepamovin 2y agoI always thought anyone can learn to program and gently scolded and encouraged the folks who would predictably say , “oh you do software? I could never do that. So complex.” No, I’d say, you definitely could! And not even anything to do with AI. But i take the title to indicate a bias against neurodivergence — “One of us,” repeated in a robotic monotone over and over. Hahaha ;) Perhaps i should read the article!
- Xmd5a 2y agoThis is exactly what the leads in my team not only thought but said to my face gratuitously. I'd be in my 69th hour of work on a Thursday and they would pass by my desk and say stuff like "what's important is not the time you dedicate to a task but that you complete it". The board decided to promote these people who negotiated a 4-days week; after all the team had never missed a deadline, and gradually I was given more and more tacit responsibilities without explicit status recognition. This creates a double-bind situation for both sides. While I could never be satisfied because of this lack of trust, you have to understand why they approached me with suspicion while being dependent on me. A 10x engineer (or any Nx engineer with N > 1) has to interface with the rest of the team and this necessarily implies more work. In my case, resentment grew because of the increased workload this led to for them, and my colleagues felt more impacted by this than by deadlines being not met. As for management, since deadlines were already met, they felt more compelled to listen to the negative feedback they gathered about me and develop suspicion. And yet, they had to rely on me for any impromptu problem they had. What's this article is discussing is not engineers with bouts of outstanding performance but engineers with that symbolical status. It's attacking the myth, and the attribution of that label, not a reality with measurable outcomes. The article doubts that such a measure exists, however the departure of an employee can have destabilizing effects on an organization. The delta won't exactly measure this employee's worth, but an organization can put itself in such a configuration that it will unknowingly rely on a few key individuals for its financial strategy and use the added value these people bring against its competitors, to win investors attracted by this differential in efficiency or proceed to acqui-hires. This leads the company to bind itself to commitments which pushes it near to a dangerous threshold. Once crossed, when one of the cheap keystone employees leaves, this excess of work can cascade to other keystone employees, and cause more resignations, and the company won't be able to make up for it because its finances are already engaged elsewhere.
- hinkley 2y agoI spend at least half of my best days working on making our bad days better. The thing about being intelligent is that you have the capacity to find wisdom faster. I’ve worked with too many intelligent fools, and nearly all of them quit rather than face the consequences of their own actions. I tend to stay too long, either cleaning up after my own messes or someone else’s. Maybe I watched too many westerns as a child. Who knows. But I’d rather work with someone wise who can’t reinvent bloom filters from first principles than someone who could, and thinks doing so is a good idea. There’s an ethical trap where you think you’re the only one here who can make something work, because now you’re on the hook to support it and if you have a negative opinion of your peers, how is that going to work out, do you think? Did you think? Or were you too busy wondering if you could do it to think about whether you should? I think the advice, “never be the smartest person in a room” is just about the biggest bullshit in tech. Intelligent people cannot teach you to be like them. They can’t change your brain much more than you already have, just surviving school and university. But a wise person can teach you three new things before lunch, sometimes without even trying. Don’t be the wisest person in a room, and if you must be, don’t denigrate the wisdom of beginners. Good teachers learn from their pupils.
- musicale 2y ago> The effect of consistent, careful, workmanlike effort over time trumps any number of crunch weeks and burnout episodes, to an almost absurd degree This is worth remembering for basically anyone who works on anything, or manages any kind of project.