[wibbily]

It bothers me that so many programmers I know, here and in real life, seem to never actually have cared about the craft of software development? Just about solving problems.

I like problem solving too. But I also like theory and craft, and in my naïveté I assumed most of us were like me. LLMs divorced craft-programming from tool-programming and now it seems like there were never any craft-programmers at all.

It feels like the group I was part of was just a mirage, a historical accident. Maybe craft-painters felt the same way about the camera.

[viraptor]

It's a false dichotomy. You can do both, depending on the project. Or even different areas in the same software. There are many things that just need writing and there's really no fancy craft in transcribing that new business rule, regardless how much you care - the difference is just who pushes the buttons for the same result.

This reminds me of the Google/Oracle Java case where one of the example "copied code" fragments was some trivial code with null guards. Anyone could write this and end up with the same code. Human/LLM/whatever doesn't matter. That fragment just needed to exist.

[embedding-shape]

Hear hear! I don't play video games for the same reasons, nor listen to music for the same reasons every time, and same with creating software.

Most of the times, I write software not to write software, but to solve a problem somewhere, often times not related to software itself. Other times I feel like the UX of some dev tool is bad, and if I just quickly fix that, I can solve my problem faster, so down the rabbit hole we go, which is a different type of experience.

Other times I'm focused on figuring out an elegant design/architecture for something that isn't problem solving, but more "neat piece of software", either a library or some other type that needs some sort of interface, be it library API or actual UI. Then I'll go into "craftmanship" mode and then most of the work actually happens away from the computer, mostly with pen and paper or whiteboards.

I still think the latter is needed for improving the former, and high-quality and easy to maintain code is more important than ever, and if you only do the former, you'll get stuck at a ceiling while only doing the latter, you'll also get stuck if there isn't an actual need (at some level, "fun" can be a need) for it.

[estimator7292]

The craft is alive and well in embedded spaces.

When I was growing up as a programmer I observed JavaScript and swore I would never, ever touch webdev. As I got older that list kept growing to include mobile, then Apple, then desktop in general.

I like my little world of C where everything must be crafted with care or it just plain doesn't work.

And it's not that there isn't any embedded slopware, but the constraints are so much tighter that you can't really get away with the same level of bad code on 1KB ram and 4KB flash that you can on a 32 core desktop CPU with practically infinite resources.

[viraptor]

> world of C where everything must be crafted with care or it just plain doesn't work.

I hope you track the progress so you're not surprised one day. The research side is way past embedded C and VHDL was of interest a year ago https://dl.acm.org/doi/10.1145/3670474.3685966 In embedded code, recent LLMs can do just fine with popular architectures. It's down to the spec and test harness whether embedded C works or not. The moat is not that big.

[estimator7292]

I'm not saying LLMs can't write embedded C.

I'm saying that the resources available are really limiting for careless slop. At least on the 8-bit end of the spectrum.

The point is that the constraints demand some amount of care. LLM's are capable of that if you hold their hand and keep them focused, but you the programmer still need to know what you're doing.

I don't think there's a moat at all. I think the size of the problem space and the resources available make it a challenge to do anything too horrendous and have it still "work".

[viraptor]

I was responding a more to the crafted part. I see the craft and care as different things that can be done mostly independently (there will be some overlap). For example writing a full spec and tests that run against an emulator and telling LLM to implement the whole project is full care, minimal (coding) craft.

[sorokod]

The spec and the test harness - that is all in a nutshell.

[square_usual]

Every now and then someone posts the "X programmers (implied good) hate AI, Y programmers (implied bad) hate AI!" and every time people come out of the woodwork to point out that, no, X programmers can also use AI to take out things they can delegate and focus on stuff that's cool. Case in point, Steve Klabnik, a programmer who nobody can say doesn't care about the craft, is working on a new language primarily with AI: https://rue-lang.dev/

[wibbily]

It can be, yeah. I use it sometimes to shim libraries or write one-off scripts. But it's made me disgustingly introspective. Why do I do anything? Where do I draw my lines?

An example. I've been writing a Lisp, and I'm using GNU Readline for text input. Later I found out that Readline can't be built for WebAssembly, and I decided to have Claude write a podunk replacement for it. I now have a bit of code in my Git, attached to my name, that I didn't write

What did I lose by doing that? My goal wasn't "to write a Readline", that's why I was using it in the first place. But my goal also wasn't "to have a working Lisp interpreter" or even like "to know how a Lisp interpreter works". It was a desire to Know More. Surely I'd have learned something useful (in some form) by doing all the minutiae myself. Or would I have learned more by doing none of it and printing out the SBCL source to read over coffee?

Sorry, I ended up rambling. I don't have any answers. I think I'm just butthurt by the "X, Y" sort of comments you mentioned and the solution is (as always) to touch grass

[viraptor]

In practice we've been doing setting the threshold of what we care about for a long time already, with firmware, operating systems, libraries, etc. You can always go one level deeper if you want more. Did you want to know how readline works? What about terminal control characters? What about pty? What about the input? The keyboard interface? HID? Device drivers? USB? Packet transmission? Serial interfaces? Electrical connections? Signal integrity?

LLM code provides just another type of available abstraction where we can stop in learning, but not really something entirely new.

[xeromal]

The one engineer in my life who cared about the craft of software development also refused to have a color profile pic and also did his zooms in black and white and thought Ruby was the only good programming language.

[MisterTea]

That's like one person with terrible taste.

[xeromal]

My point lol.

I think most devs, especially ones that call it a "craft, take themselves too seriously. We're glorified construction workers that get paid a lot

[wibbily]

> We're glorified construction workers that get paid a lot

That attitude is my point. I'm a developer by trade; I have a different set of feelings and concerns about "the industry" and how new tooling will affect it. (I even use it sometimes at work.) But I'm also a computer scientist and I thought more of you all were too.

To beat my original analogy to death: I thought this was a painting forum, but it's more of a "making pictures" forum, and now that it's easier to make a picture, no one cares about paintbrushes.

[xeromal]

Yeah, I went to school for computer science but I am in no way a scientist. I'm not doing research and I'm not innovating anything that I already hasn't been built. I'm just building it for who needs it.

The space for innovation in computer science is pretty limited when it comes to constructs like how we build something considering how fully featured libraries and such are. Literally everything I've built in my career has been built better by someone else. If I am a scientist, it's the person in the lab making 10,000 flu shots a day.

I'll just say that my career in the industry as a programmer has made me very good at working on my car and I think they're more intertwined and connected then anything theoretical

[pegasus]

The brush-strokes are part of the painting (they give texture and structure for example), so a painter would care about them, if he'd care for the end product. But a painter who would instead deeply care about details of the brush incidental to the task of creating paintings, by definition got lost in the woods, or at least stopped being a painter for those moments. It makes sense to care for example about the feel and balance of a brush, because that has a direct impact on the artwork, but say, collecting embellished brushes would be him wearing not a painter's hat (beret?) but a collector's.

My point is that the end-product matters most, and getting wrapped in any other part of the process for its own sake is a failing, or at best a distraction - in both cases.

[ineedasername]

> I thought this was a painting forum, but it's more of a "making pictures" forum

It’s more like the discussions space to talk about things related to the painters of hotel art.

[tonymet]

There’s room for both types of people in any trade. Some photographers obsess over the equipment, some only care about the photos. Carpenters with tools. Musicians with instruments & gear. Every craft has people who care about the how and those who focus on the product.

I’ve always enjoyed the craft of software engineering, though even I admit the culture around it can be a bit overly contemplative .

Nevertheless, there is room for both personalities. Just hang out with likeminded people and ignore the rest.

[tikhonj]

Caring about craft in programming is more like a photographer caring about light and composition and creativity and taste than a photographer caring about equipment.

[tonymet]

In some ways yes. Many “engineers” obsess over “idioms” and other trends to the detriment of performance, correctness and usability. So this analogy is a bit too charitable.

[bitbuilder]

I'm not sure that's a valid analogy. Light, composition and creativity are all experienced directly by viewer, and essentially describe what it is that we notice and appreciate in photography (even if subconciously). The best analogy I can think of to programming is the UX/UI of the application. Given equaly competent developers, nobody is going to notice or care if your application was written in Rust or Cold Fusion.

But the original analogy is flawed too. I wouldn't consider caring about the craft of programming to be similar to obsessing over your photography equipment. GAS is about consumerism and playing with gadgets, at the end of the day.

Caring about the craft of programming is more about being an artist who takes pride in crafting something beautiful, even if they're the only ones experiencing it. I am most definitley not one of those programmers, but have always had nothing but immense respect for those that are.

[braebo]

> Just hang out with likeminded people and ignore the rest.

Or find ways to integrate with the rest, challenging one another to facilitate growth.

[tonymet]

While I appreciate your optimism, the cost of conversion is 1000x the cost of reaching & identifying the right people.

[wkjagt]

I quit my big-tech job 4 years ago and it feels like that was just in time. I don't think I would enjoy the current way. I still program a lot, but as a hobby, and still thoroughly enjoy the craft. I sometimes ask chatgpt for a function name, but mostly stay away from ai. I do realize that I'm less and less employable as a software engineer though.

[munksbeer]

> It bothers me that so many programmers I know, here and in real life, seem to never actually have cared about the craft of software development? Just about solving problems.

Why?

Intellectual curiosity is a good thing. When I first went to university, I thought I was going to be a physicist. It turns out my brain was really well wired for programming, being logical, rigorous, particular about detail, I like predictability, not a high risk taker without fully understanding and accepting the risks, etc.

But when I first started off as a programmer, I wrote physics simulations for fun (not work). I'd write little games, I wrote neural nets and fuzzy logic (gives me a chuckle), back in the 90s when the field was new. All of this was "my thing", and I barely cared about the code I wrote to achieve this. I absolutely loved it, because coding was a tool to explore my intellectual curiousity.

I could say the exact opposite, that I feel a bit sad that people care more about the characters they type on a screen than the concepts they explore.

As I morphed into a professional software engineer, I grew to understand the importance of high quality code and engineering (I mean architecture decisions). I have had a long, successful career by refining my craft. I care about the quality I produce for my future self and others, and the success of the product as a result of this quality.

But at the heart, I am still just an intellectually curious person, and one day I may stop working professionally and at that point, I think I'll love using AI to write code and help me explore concepts. I very much look forward to it in fact.

[wiether]

I used to be intrigued by _software craftsmanship_, but I mainly saw people using it to practice heavy gatekeeping. Be it on the job, in code reviews, in job interviews...

Furthermore, given how they behave in a cult-like way, it feels like they are straight-up delusional.

People working as consultants for big retail chains, talking all day long about "the craft". Nobody cares. They sell trash. They don't put marble in their store. They don't want fancy software. Furthermore, if, by trying to force "the craft" to their peers, all they do is making the life of others miserable... Just stop. Please.

Now my approach is as follow:

if stakeholders are only interested in two things (how-much it cost, when it's ready), which is 99% of the case at $JOB, then make something that does the job and that won't make you hate yourself if you have to maintain it in a year

if I'm the stakeholder, like creating internal tooling that nobody asked for but that will solve issues, then yes, I do things as good as I want them to be

same for working on FOSS on my personal time

[port11]

The one issue that stands out is that, by optimising for cost and time now, you might build unmaintainable messes for later. Therefore, later the cost and time goes up.

EDIT: child commenter is right, my bad.

[munksbeer]

In the post they already addressed that

"and that won't make you hate yourself if you have to maintain it in a year"

[nurettin]

I've had a two hour long discussion with a super llm about a somewhat complex event loop processing task. It could not manage. I even restarted the session a couple of times. Then I did it manually and showed it a working version using a simple state machine. "That's brilliant!" (no, it wasn't brilliant)

I am really worried for the next generation of programmers fully dependent on llms.

[port11]

This is a classical, charming take on software developers, but we don't judge most professions that way.

“It bothers me that so many cashiers don't care about the craft of service and payment point connection.”

“It bothers me that so many butchers don't care about the craft of choosing meat cuts and selling meat tailored to the customer.”

We expect of developers craft, passion, after-work commitment, life-long learning, and so on, and so on. Many other professions are free of or lighter on such expectations.

I agree that it's alienating to see sloppy, automated code crop up simply because people want to get paid. Code used to be this cool domain… But I'm not shocked, since our society evolved towards commoditising absolutely everything.

Even thoughtful messages to loved ones are now available through LLM-hallucinated apps. We're done here, pack up your expectation of humanity staying, ahm, human? Disheartening.

[Viliam1234]

The customers these days are willing to pay for programs full of bugs that require enormous amounts of resources, so the craft no longer generates profits.

[m463]

Personally I think of custom houses vs tract homes as an analogy.

People won't care that much if their daily life software is developed by artisan developers, offshore coders or ai. They will just need to get things done and won't be able to tell who wrote the code.

That said, I still think there will be a spec, and that spec will mostly be written by humans.

[ivanjermakov]

> Just about solving problems

Or just about making money :(

[fnoef]

The craft has, unfortunately, died by a a bunch of tech companies who promised you the craft, but in really were all about making money ASAP, disregarding the craft.

Nowadays, the craft can be practiced at your home, by yourself.

[bigyabai]

After a certain point, I think "craft" becomes a meaningless and self-flattering scapegoat, similar to how people use "taste" or "courage" as an excuse to make boneheaded decisions. Most software customers aren't buying software because it's tasteful or impressively crafted, but because it fills a gap in their workflow. People who obsess over polish often end up missing the forest for the trees.

Plus, code-based meritocracy flat-out doesn't exist outside the FOSS circle. Many of the people you know are clocking-in at a job using a tech stack from 2004, they aren't paid to recognize good craftsmanship. They show up, close some tickets, play Xbox during on-call and collect their paycheck on Friday.

The people who care might be self-selecting for their own failure. It's hard to make money in tech if your passion for craft is your strongest attribute.

[oehpr]

I need to say as someone who also really really cares about the craft. About doing things right. LLMs have been a massive boon to me, because they're the only entity in this world that seems willing to work with me to get things right.

If something is working but it is ugly, sketchy, or I feel there may be a more apt abstraction or generalization of the problem, every other human being on the planet has persistently turned that situation into an exhausting argument. If the code works, it works, right? And all this shit I talk about is pointless because it works. And I have to fruitlessly construct an argument that would appeal to someone who cares nothing other than a complete ticket.

LLMs are at least not needlessly combative and incurious as to think that every approach but the first one we try is a pointless waste of time.

[codyklimdev]

I like programming as a craft, but the kinds of coding I do for fun and the kinds of coding I do for profit look very, very different. So, for my work programming I use AI a lot more than I do in my own time.

After all, my work (for the moment) is just about pushing features to keep the PMs happy ¯\_(ツ)_/¯