Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't call yourself an artisanal programmer

purplesyringa.moe

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Don't call yourself an artisanal programmer

#51

Post by NegativeLatency »

globular-toast wrote: post #49
jlamberts wrote: post #37

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…

> Engineering is about creating something that serves a purpose, while operating within a set of constraints. A builder fits that description. Even a cook fits that description. Engineering is something else. It's hard to describe what it is, probably why it has its own word. Dictionaries probably offer a definition. > A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly.…

Highly recommend this if anyone wants to think more about what engineering is: https://mitpressbookstore.mit.edu/book/9781728280455

we built cathedrals without a detailed understanding of load calculations and material properties

Re: Don't call yourself an artisanal programmer

#52

Post by purpleflashing »

card_zero wrote: post #20
echelon wrote: post #19

Earlier quoted context omitted.

Software is ephemeral. Very little of it lasts for long. And if it does, it's legacy banking or some ossified terrible thing people are afraid to touch - not something revered. Every piece of software today will be rewritten. By 2100 much of it will be dead and gone. Like punch cards that have rotted away.

Games

I share the sentiment as a gamer but according to preservationists the majority of games have already been lost to history.

Re: Don't call yourself an artisanal programmer

#53

Post by julianlam »

bigstrat2003 wrote: post #23
jaggederest wrote: post #9

Earlier quoted context omitted.

I've gone back over most of my contributions to open source using LLMs and honestly, even though it was my best work at the time, there are big gaps that they find right away. The myth that we've been shipping perfect code for years, but you can't trust LLMs, is just subjective blindness. People can't see the issues that they can't see, definitionally. You can absolutely use the exact techniques we used to use in "th…

We definitely haven't been writing completely correct code in the past. But even so, the code LLMs write has more issues than the code humans write.

Six months ago this ceased to be the case for some (if not most), and the quality of LLM generated code has increased over time.

I'm sorry to be the bearer of bad news: human coding has not improved a lick since then.

Re: Don't call yourself an artisanal programmer

#54

Post by veqq »

qurren wrote: post #38
cortesoft wrote: post #5

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.

In food contexts when I see "artisinal" I usually just think of rich white people buying the same stuff in nicer packaging and typography for twice the price. The actual artisans don't need to advertise themselves as artisans, they just sell shit.

How constructive to make this... racial.

Re: Don't call yourself an artisanal programmer

#55

Post by barrkel »

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.

Re: Don't call yourself an artisanal programmer

#56

Post by OutOfHere »

echelon wrote: post #19
cortesoft wrote: post #5

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.

Software is ephemeral. Very little of it lasts for long. And if it does, it's legacy banking or some ossified terrible thing people are afraid to touch - not something revered. Every piece of software today will be rewritten. By 2100 much of it will be dead and gone. Like punch cards that have rotted away.

Good software runs for decades without maintenance. And by 2100, most of us will be gone.

Re: Don't call yourself an artisanal programmer

#57

Post by weitendorf »

barrkel wrote: post #55

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 unreliab…

Strong agree. I think the fundamental challenge of working in fields that increasingly become AI-enabled will be the ability to understand and direct large or intricate systems without prior knowledge/the advantage of having built the model as implemented. That’s already how it works in complex domains or large businesses.

It does require a different kind of ego/abilities than before. My (negative) framing of the whiplash effect is that it’s a reckoning of “process fetishism”/a bad kind of careerism in the tech hiring market (because for the labor market to work, candidates need to be evaluable and sortable by businesses, and many people build an identity/optimize for legibility around “best practices” or very particular “technologies” which might get them a job).

Ultimately, you need to know and learn/be responsible for stuff, and be able to help people with your labor, not be “a type of person” that isn’t effective at the task of helping. But at the same time knowing things and being able to take accountability/help people remains critical, especially because that’s what people will want to pay for even as “time spent typing it in” decreases.

Personally, I think it will be a good thing because software and “tech” will become a more strongly domain-driven/enabling medium for real-world or specialized things. IE it is the end to “software for its own sake” or “willingness to type it in and play with Jira/jenkins/frameworks” and the beginning of something that is more applicable or knowledge-building rather than “being the X for Y at Z”. Harder but more fun :)

Re: Don't call yourself an artisanal programmer

#58

Post by g-b-r »

barrkel wrote: post #55

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 unreliab…

A whole bunch of assumptions and beliefs passed off for truths.

LLMs have very little to do with engineering, unless you let a pair of dice decide how you build a house.

Cars are not built by AIs, they're built by extremely precise robots, over precise instructions.

I'd VERY much want a hand-made car over an LLM-made car, thank you.

Because I do want the precision, reliability and performance that an LLM-made car won't ever be able to guarantee.

Re: Don't call yourself an artisanal programmer

#59

Post by weitendorf »

globular-toast wrote: post #49
jlamberts wrote: post #37

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…

> Engineering is about creating something that serves a purpose, while operating within a set of constraints. A builder fits that description. Even a cook fits that description. Engineering is something else. It's hard to describe what it is, probably why it has its own word. Dictionaries probably offer a definition. > A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly.…

But when nobody will die from your decision (and to be clear I think security is extremely important, but moreso for banking/healthcare than a private wow server), then “shoddy” becomes a matter of reputation/taste vs value/marketability.

The demand curve is different because it’s low stakes, like throwing a bad party or oversalting food. And part of the problem in software to begin with is too much LARPing about scale/engineering for things that don’t need it, as well as lack of accountability or care for things that do.

You can still be an “engineer” working on a game, it’s just more about making the game fun than making it safe. Or, you create a process for making and test hundreds of experimental bridges, and refine/invest additional time in understanding and verifying the safety of the best one.

Re: Don't call yourself an artisanal programmer

#60

Post by weitendorf »

g-b-r wrote: post #58
barrkel wrote: post #55

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 unreliab…

A whole bunch of assumptions and beliefs passed off for truths. LLMs have very little to do with engineering, unless you let a pair of dice decide how you build a house. Cars are not built by AIs, they're built by extremely precise robots, over precise instructions. I'd VERY much want a hand-made car over an LLM-made car, thank you. Because I do want the precision, reliability and performance that an LLM-made car won…

Cars use AI for steering control (et al) and technology very similar to RLVR (hold the RL), eg property-based testing and formal verification, to prove the soundness of their embedded systems. Most of us in San Francisco trust Waymo with our lives more than human uber/Lyft drivers

As long as you can verify/test and take accountability for the thing you put your name on there’s no reason not to treat it as a process or search problem rather than one you assemble yourself by hand. The only problem is that it’s ironically much harder and more engineering than most “software engineers” are willing or able to do.

I spent several years working on permutation testing/experimentation and creating e2e verification of infrastructure because at scale, or when reliability/correctness are critical, you cannot rely on a single person’s mental model, or for the world to not drift around a system as it works now. That kind of system is what allows you to use LLMs or engineers who don’t know everything about it to improve or change it. It’s more science than art, which is often (but not always) what you want

Post reply on HN