Join the discussion

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

  • Hacker News
  • I find more pleasure and satisfaction by programming at a higher altitude, at the system level. This zooming out gives you a better feel for building an effective scaffold and you can iterate on ideas faster.
  • The vocabulary point matters: calling careful work artisanal turns reliability into a personal taste when it is often the core engineering requirement.
  • I agree with the title, but perhaps for different reasons.

    Somewhere (maybe the 1960s?) the idea crept in that programming is some kind of production process, and the "engineering" happens upstream. Elsewhere, the line between engineering design and manufacturing is the transition of a set of documents to those with the skills to turn what those documents specify into real products in a reliable, repeatable manner. That repeatability is one of the hallmarks of manufacturing. For software, all the processes reliable enough to qualify are downstream of typing `make` and striking return, ending in the binaries and the computational processes that those paying the bills desire. It's our build and deployment tools that do the construction, which means that our source code is the final, detailed design.

  • Isn't there a difference between making things that code does and the code itself? Ive seen truly beautiful software with terrible to follow but effective code and I've seen beautiful code that while technically amazing didn't do anything of substance. Software is like woodworking, it includes all levels of care and product outcomes.
  • I prefer the term "classically trained programmer." :-)
  • A good chunk of engineering is putting together reliable systems from unreliable parts.

    You build in safeguards, redundancy, defense in depth, recovery systems. You build models of the system and prove characteristics about it.

    Software is fundamentally automation. LLMs enable automating the construction of software itself. They're much faster and cheaper than people, and they're more unreliable. (People are unreliable too!)

    The immediate challenge of these times is figuring out how to reliably construct reliable software in the large, over the longer term, reliably. This is an engineering challenge, and the only way we'll get to the other side of it is by trying to do it. Things will be rough, there will be a Cambrian explosion of techniques, most approaches will fail, and many more won't survive as models improve on quality and capability. But we'll figure it out.

    Making things by hand, as in the time before agentic coding, can be engineering too, but it is not the core challenge of these times, and it will soon be a hobby, or possibly a kind of luxury good. You will no more want hand-written software than you'll want a hand-made car. It will not have the precision, performance or reliability of machine-made software.

  • Engineering is about creating something that serves a purpose, while operating within a set of constraints. Part of that is realizing that "100% correct/reliable in all circumstances" is an unrealistic goal, since implementation time and cost is one of those constraints.

    A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly. For example, if you're working on safety critical or very foundational systems like OSes, medical tech, etc you should bias very heavily in favor of robustness. If you're not, this can easily be an act of overengineering. The engineer's job is to find the right spot along the cost-correctness curve for the thing they are building.

    This has always been true, and LLMs just change certain parts of the equation. For example, code writing is far less of a bottleneck than before, so "we can just try with a throwaway impl and see if this works" is suddenly economically viable. It also turns out that many things, in practice, don't need to be as correct as some of us may have believed.

    We can still enjoy making quality things, but doing so is often an act of artisanship rather than engineering.

  • Weirdly, I thought the terms would be reversed… I think of a craftsman as someone who values quality over quantity, and makes everything beautiful and long lasting, while an engineer is more about productivity and tolerances and efficiency. A craftsman makes better quality but doesn’t scale the way an engineer and the factory process does, although mass produced goods sacrifice quality for quantity.

Explore Birbla archives

Don't call yourself an artisanal programmer · Birbla