Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • There’s a good list of reasons why we do this, but it leaves out the biggest one, at least for me: building stuff is fun. Reinventing stuff is fun. It’s the most natural hammer to reach for whenever I encounter a nail. Not necessarily the best, but such is life.
  • Finding a thing, using it, finding out it sucks, and then making your own version that's better and doesn't suck, is an entirely natural instinct.
  • I try to explain this on every post that complains about software reinventors. Why should people from the 60s and 70s get to have all the fun? So far my efforts have been in vain.
  • I remember in 1999 reading some tech executive (with tech education, I guess) complain, like "I'd like to make executive financial reporting, but not like this horrendous and too complicated accounting". Then he proceeded with ideas. Well, the thing is that all our terms we use are lines from summarized accounting balance sheet, from either assets side, or liabilities. And if you detach them from the rest, the list of figures won't make any sense. I learned that studying accounting in the uni.

    Also what I learned back then was that accounting was invented for the same purpose the blockchain: to make fraud in the workplace very hard.

    I remember engineers reinvent geospatial technologies, avoiding such thing as map projections, and in the end still came to them.

  • He says "engineers" but he means code monkeys. Actual engineering is all about learning from past failures
  • All while creating new ones. :)
  • This is why we do not have any real engineers at the helm of any nation, state, multi-national enterprise or anything really.

    The current world conceptions of engineers are that they're the negative ones, the naysayers.

  • That’s because most Software Engineers aren’t Engineers, they’re computer science majors. It’s a completely different discipline.
    by cush
  • That's a strawman argument, because most engineers aren't engineers. The vast majority of engineers have no consequences for their shite. Neither is certification a panacea against bad engineers.

    Watch mechanical engineers design plastic rubbish.

    Watch some electronic engineers design circuits that don't work.

    Watch some geotech engineers make up overspecified bullshit: because they're paid per hour and their work is often just a glorified tickbox (where they have no real consequences for most of their failure risk).

    Even with egregious design failures by engineers, they often get away with it for a variety of reasons. A building collapsed due to the Christchurch earthquakes - failures by different engineers with little harm to them.

  • Yep, you actually do get Electronic & Software Engineers, which has CS subjects, with an Engineering discipline.
  • He cites Brooks as proving that communication friction is quadratic in headcount. The exponent does not need to be exactly, or even nearly, 2; 1 + epsilon is already fatal. This is very closely related to Coase's ceiling.
  • >You can make lots of money by making something appear novel and undiscovered, and consequently make yourself sound smart and cutting edge. Nobody raises a round to apply a well understood discipline correctly.

    I'm curious about this. I thought investors preferred safe bets?

    On the other hand, I know that if you're too early, it can be impossible to make a business work (or even to pitch the idea in the first place).

    Related: You can't tell people anything (2004)

    https://web.archive.org/web/20091025030730/https://habitatch...

  • It's really funny, I've read this essay before a long time ago and it's really interesting playing back the many times both in realising it in retrospect and having seen it playing out before my eyes, that the last part really comes to the fore

        > One final point: I expect none of you to really get what I’m talking about here, because this principle also applies to itself. But I fully expect I’ll get the occasional email saying “Oh! so that’s what you meant.” or “Why didn’t you tell me that?” I did, but you can’t tell people anything.
    
    In my youthful naivety I thought I understood this, but now years later I can more deeply appreciate the message that you really can't tell people anything
  • Seems like this could be categorized as yet another reason why software developers are not engineers.
  • Do people seriously care about this debate? I don't even use the term software engineer. I usually just say [computer] programmer. Though depending on my mood I might say I am virtual firefighter, and believe me, there are always virtual fires that need to be put out.
  • I never understood why actual engineers(eg. Civil) have not complained more that programmers/coders stole that title.
  • I happen to be both. Engineering is a mindset, and to call yourself an engineer, people should be at least this: https://www.internationalengineeringalliance.org/accords/was...
  • Absolutely. Engineering is defined by it learning from history, it's an art build up from thousands of years of human attempts to alter the world around them. In a modern sense engineers inevitably require a certain amount of schooling, certification, and most critically of all professional and ethical standards.
  • A few years ago a software engineer asked a few Chemical/Civil/Mechanical engineers and the majority of "real" engineers seemed to think we were [1]. I'm not aware of a better study but happy to be proven wrong, since I generally refer to myself as a Software Developer

    [1] https://www.hillelwayne.com/post/are-we-really-engineers/

  • Relatedly, I fully expect the software business to fail to learn from (nearly) literally every other industry how to operate when your marginal costs are no longer zero. It drives me nuts the number of people in software who think that people in other industries are slow because they’re just not as smart as us, rather than because when it takes months to get a cast part made, it better be right the first time.
  • > It drives me nuts the number of people in software who think that people in other industries are slow because they’re just not as smart as us. . .

    Ha! I studied computer science and became a programmer because I knew I was too dumb for med. school and the other engineering paths.

  • IDK, I think it's been a bit of a (reverse?) bell curve of sorts.

    30+ years ago, You had to be a -lot- more careful about how you handled releasing software. Your stuff was in boxes on shelves, most people didn't have internet access to 'download an update' so fixing anything had a long tail support cost (i.e. paying for the media containing the fix and shipping).

    But there's a fine line. As an example, If your shop is having a vendor do brand new stuff, -compartmentalized from your other stuff-, using technologies that are actually out of support vs an in-support version is a free/zero effort update versus using the outdated stuff... Something went wrong on the management side.

  • Yes, the future of software as an institution, if there is any, is driven by the loudest voices. Those loudest voices are thus driven by selected personalities as opposed to any accomplishment or title. The people who are the highest achievers are rarely the loudest voices as they tend to be the people spending time solving real problems as opposed to the people who just talk about themselves, the forest for the trees.
  • Yet this is part correct, part wrong. Indeed every industry has some unique challenges that are not directly solvable. However, while a cast is absurdly expensive, the problem is being solved in large part by software in the FDM (3D printing) space and it's changing how things are built.

    edit: this doesn't invalidate the OP thesis, which I strongly agree with. Except that it's not just engineers, this is a more general thing across many fields.

  • It's even funnier when you realize that not too long ago a decent chunk of the software industry did have to deal with the realities of having to press CDs, print boxes and ship them to retailers in time for the holiday season. The idea that you can ship a half-baked product directly to your end users, charge for it and promise it will get better over time (but only if you manage to secure enough VC funding in the meantime) is a relatively new invention.
  • I'm a hands on engineering leader for a team of about 20 engineers and I've been spending the past 6 months trying to get my team to understand just this.

    On Friday we had a coffee hour to share how we've been working recently and they all seemed perplexed at the workflows I've been adopting. It seems natural to me as someone who's been a manager for some time now, but very alien to all those who've never gone down that path.

    That's not to say my workflows are superior, but they're extremely different to some of my teams now. In reality it's just leaning heavily on things like prds, limiting communication between agents, etc.

  • Is anyone on your team not using multi agent?
  • Can you share some details of the workflows that work for you?
  • In the few instances that I’ve been able to see a total stranger prompt a model, I learn a lot about them.

    The model output is fairly uniform because the models are fairly uniform, but the input is how I understand the prompter’s theory of mind for the LLM.

    The higher fidelity the theory of mind, the more productive the resulting conversation is. Basic things, like knowing what the model is even aware of.

    It’s okay at subjective product judgements with limited context, and so the best engineers make the most important decisions themselves, constraining the model’s solution space to something looking like success.

    Maintaining consistent progress towards a common goal with a bunch of different perspectives is the job.

  • Out of curiosity, what was the path that the engineers have been taking? The limiting communication between agents to my mind is obvious to anyone who hasn't swallowed orthodoxy Agile development completely whole. And in my experience the people who have, are rarely the devs. Context switching, between agents, people or whoever, require ramp up time to relearn context. It's always slower and more expensive, other potential upsides about long term training or developers being more replaceable notwithstanding. But no agent gets long term training, not in a 1M context window.