Rendered at 05:39:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
cortesoft 2 hours ago [-]
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.
jolmg 47 minutes ago [-]
It's interesting how the words can be ambiguous like that. If I think of the distinction in the context of e.g. clothes, there's likely more engineering in fast fashion and more crafting in bespoke clothing. With food, more engineering in the food items you'd find at a gas station and more crafting at a restaurant.
>> “artisanal” coders who value the experience of coding over the final product
I don't see "artisanal" as that. It may be more that they value the details rather than the experience of coding. They value the details of the final product. Details that most people will not care about. The details that are present in bespoke clothing but missing in fast fashion, the details that are present in a good restaurant's food but missing from a gas station food item.
8note 31 minutes ago [-]
id consider that a craftsman tends to build without constraints. an enginner meets the constraints with a defined safety factor.
an engineer uses tools that represent the current state of the science, while a craftsman uses tools passed down as archaic art that require meticulous skill to use rather than repeatable math
g-b-r 4 minutes ago [-]
[dead]
echelon 26 minutes ago [-]
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.
coldbrewed 6 minutes ago [-]
Your bank's mainframe would like to know your location.
card_zero 24 minutes ago [-]
Games
Tanjreeve 1 minutes ago [-]
I'm reasonably sure/hopeful all of these discussions will be as important as people's discussions about whether using vim makes you a real programmer or not.
"Does it work" is what matters. We already know that "do this make no mistakes" works on some things. And then some things that are very "wide" e g "integrations for lots of different things" you basically write a new layer of software on top of the software in specs and .md and that yields a software project that you can mostly just add features by asking for them. But there's still deep narrow projects where creating that context is way more work than just implementing it. And then you have some projects where you can mix approaches and use the "metasoftware" for all the cicd and boring bits but not the core. I'd argue all of the above it's kind of meaningless to try to distinguish it as even if it's fully handrolled an llms still there as a search engine and task runner.
spawrks 2 hours ago [-]
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.
Prydown 3 hours ago [-]
The vocabulary point matters: calling careful work artisanal turns reliability into a personal taste when it is often the core engineering requirement.
dwattttt 29 minutes ago [-]
But can they compete with my shade grown software? It does result in a 40% markup, but there's no putting a price on being raised in a loving environment, is there.
andsoitis 3 hours ago [-]
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.
g-b-r 1 minutes ago [-]
You mean by vibecoding? Don't call that programming, for God's sake
throwy98888 1 hours ago [-]
Couldn't take an article seriously that started with the author claiming that code he writes by hand is "100% correct"
Bruh
jaggederest 1 hours ago [-]
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 "the old days" to produce reliable code with LLMs generating most of it. The issue is, it's really not a lot less conceptual and intellectual effort than in "the old days", at root. You speed up the programming part, but the rest is still a hard slog, so nobody is out here doing really thorough testing in ways we used to dream of.
conradludgate 27 minutes ago [-]
Likewise, I've found many bugs using LLMs in the small software libraries I hand wrote and considered complete and correct - even though it was my sole focus at the time and I thought I had perfected it
matheusmoreira 8 minutes ago [-]
Same. Frontier LLM code review proved to be a very humbling experience for me.
bigstrat2003 10 minutes ago [-]
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.
jaggederest 1 minutes ago [-]
Do you have any analytic basis to make that assertion? I haven't found that to be true, it'd be more accurate in my experience to say that LLM code has different issues than the code humans write.
conradludgate 28 minutes ago [-]
she*
carabiner 34 minutes ago [-]
Way ahead of ya.
acedTrex 51 minutes ago [-]
Fully agree with this, careful work is foundationally engineering. Slopping and not reviewing work is not.
conradludgate 21 minutes ago [-]
Yes, these are the only two options. That is definitely true.
It's of course impossible to have any nuance or middle ground here where you use LLMs to assist while you still focus on the engineering design decisions and the quality.
kittikitti 1 hours ago [-]
I would call myself an artisanal programmer. Software Engineers are some of the least likable people I've ever met and being associated with them is cringe. Questions like, "Why are you using Notepad++ instead of using VSCode with 100+ plugins?" in a very condescending manner gets old very quickly. They need the title of Engineer because deep down they are very insecure.
On the plus side, they're usually promoted very quickly to management and never code again.
dosisking 5 minutes ago [-]
Sounds similar to Rust programmers
throwy98888 42 minutes ago [-]
Exactly, when the real question is "why are you using notepad++ instead of emacs, you philistine?"
greygoo222 18 minutes ago [-]
"I’ve seen it before, though: it’s very much part of the fascist playbook."
>> “artisanal” coders who value the experience of coding over the final product
I don't see "artisanal" as that. It may be more that they value the details rather than the experience of coding. They value the details of the final product. Details that most people will not care about. The details that are present in bespoke clothing but missing in fast fashion, the details that are present in a good restaurant's food but missing from a gas station food item.
an engineer uses tools that represent the current state of the science, while a craftsman uses tools passed down as archaic art that require meticulous skill to use rather than repeatable math
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.
"Does it work" is what matters. We already know that "do this make no mistakes" works on some things. And then some things that are very "wide" e g "integrations for lots of different things" you basically write a new layer of software on top of the software in specs and .md and that yields a software project that you can mostly just add features by asking for them. But there's still deep narrow projects where creating that context is way more work than just implementing it. And then you have some projects where you can mix approaches and use the "metasoftware" for all the cicd and boring bits but not the core. I'd argue all of the above it's kind of meaningless to try to distinguish it as even if it's fully handrolled an llms still there as a search engine and task runner.
Bruh
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 "the old days" to produce reliable code with LLMs generating most of it. The issue is, it's really not a lot less conceptual and intellectual effort than in "the old days", at root. You speed up the programming part, but the rest is still a hard slog, so nobody is out here doing really thorough testing in ways we used to dream of.
It's of course impossible to have any nuance or middle ground here where you use LLMs to assist while you still focus on the engineering design decisions and the quality.
On the plus side, they're usually promoted very quickly to management and never code again.
Holy reach