zlacker

> "For art, music, and writing? I got nothing. I’m inclined to believe the skeptics in those fields."

You've already lost me, because I view programming as an art form. I would no more use AI to generate code than I would use it to paint my canvas.

I think the rest of the article is informative. It made me want to try some things. But it's written from the perspective of a CEO thinking all his developers are just salt miners; miners go into the cave and code comes out.

I think that's actually what my hangup is. It's the old adage of programmers simply "copying and pasting from stack overflow" but taken to the extreme. It's the reduction of my art into mindless labor.

>>TheCra+(OP)
Woodworking is also an art form. But most people just need furniture, fixtures, and structures. Nobody would take seriously the idea that new construction all be done with sashimono joinery in order to preserve the art form, but somehow we're meant to take seriously the idea of hand-dovetailed CRUD apps.

>>TheCra+(OP)
That's cause there's an element of mindless labour to it. It's easier to spot that so it gets more focus.

>>tptace+u
I don't think that analogy matches very well. Most software is bespoke, the domain requirements, usage aspects, and architectural trade-offs are subtly, or often non-subtly, different each time, and take different trajectories over time. It's not like you're producing the same software 10,000 times, like a piece of furniture. And AI isn't able to produce the exact same thing reproducibly anyway. A better argument would be that AI is actually approaching the craftsmanship/artisanal capabilities.

>>layer8+i3
Most line of business apps and business logic are only bespoke and custom insofar as field names and relations and what APIs they trigger on which events.

Just because software is “bespoke” doesn’t mean it’s complicated or special.

>>sneak+u3
> Most line of business apps and business logic are only bespoke and custom insofar as field names and relations and what APIs they trigger on which events.

That's not my experience. Of course, everything is just a finite state machine operating on a memory tape.

>>TheCra+(OP)
People don't pay programmers to produce great art. No one sees that "art" and no one cares. They pay programmers to get shit done.

>>TheCra+(OP)
I'm sure salt miners needed to make peace with their toil and also focused on tools and techniques to be more productive; how to remove the salt most elegantly in nice clean blocks, minimize waste, reduce burden on their physical bodies.

But to their bosses their output was salt.

I'm sorry but unless you're working in open source for the pure love of the tech/craft, the output of software engineering is PROBLEM SOLVING.

That's why "build vs. buy" exists - sometimes it's better to buy a solution than buy one. That's why a valid solution to a problem sometimes is to convince a customer that their ask is wrong or unreasonable, and something simpler or easier would get them 99% of what they need with 1% of the effort.

That's our job.

>>drboji+T
If you find that theres an element of mindless labor to coding then you're probably doing it wrong.

>>ACCoun+F5
A functional code that is easy to maintain is art (but you have to be an experienced programmer to see it). A shoddy project isn’t, but the whole company feels the pain.

>>ACCoun+F5
Wrong.

I do pay my general contractor for the unseen quality that goes into the structure of my home. Programs should be built the same way.

>>tptace+u
> Woodworking is also an art form. But most people just need furniture, fixtures, and structures. Nobody would take seriously the idea that new construction all be done with sashimono joinery in order to preserve the art form, but somehow we're meant to take seriously the idea of hand-dovetailed CRUD apps.

How many furniture makers did you talk to forming this opinion? The metaphor does not line up with either my software of furniture experience. I work with production furniture shops that choose not to use CNCs to avoid the soul being sucked out of the work. This is not a rare stance to take and this is not "japanese joinery" woodworking. This is real work, balancing the means of production with optimal quality. There is all sorts of arguments on whether cncs or using a domino or whatever is "real" woodworking, but the idea that this choice of quality does not exist in woodworking and so we shouldn't have it in software is not my experience.

>>pydry+X8
Get a key logger and track the repeated keys you hit. Arrow keys, hjkl or w/em just the keys that take you to the place you need to be.

While your at it you can tell me about your favorite click.

>>bradly+ym
You don't need to talk to furniture makers to know that mass produced furniture has replaced cabinetmakery almost completely. Most of us are sitting on the evidence.

>>pvg+Ys
It is not about being mass produced or not–it is this reoccurring theme by people who do not spend their days writing code saying that mediocre code is good enough. It is not for me. Code decays. Mediocre code today is bade code tomorrow. Not everyone shares this pov–totally fine–but the tone of the article is tough.

>>bradly+Qv
I'm a professional software developer and I'm saying mediocre code is often good enough. Mediocre code does not in fact decay. The belief that every line of code you write on every problem definition has to be crystalline and formally rigorous is an early-career thing you get over. Fretting over literally every line of code is a way of doing your job badly. The skill is in knowing when you need really interesting (and "interesting" is the distinction here) code, and when you should just whip our your shop jig and repeat the exact same pocket hole joint you've been using for the last 10 years.

I don't want to step on the cabinetry discussion, just, I think it's important to call out this idea that there's a universal quality/intricacy/interestingness threshold for all production software. That was a common fallacy long before LLMs (you used to see a lot of it in Rails culture with people ceaselessly grooming unit test suites and designing ever-more-seamless mocking systems). Part of growing in this profession is getting a sense for when extra exertion is needed, and when it's wasted.

>>bradly+Qv
Right but just like most people were looking for a cheap shirt, pot or chair, most people are looking for 'cheaper way to make computers do what I want'. These changes didn't happen because people hated art or failed to inquire with weavers, potters and joiners.

>>tptace+3w
> Mediocre code does not in fact decay.

That's okay. I think all code does. Some much faster than others. I could be wrong, but I think I'm sticking to this opinion (for now at least)

> The belief that every line of code you write on every problem definition has to be crystalline and formally rigorous is an early-career thing you get over. Fretting over literally every line of code is a way of doing your job badly.

I agree. I do not think this is a debated topic. That being said, I don't see writing quality software to be a waste of time the same I don't see a quality weld. It needs to be relible to what the stakeholders have defined as adaquate.

> The skill is in knowing when you need really interesting (and "interesting" is the distinction here) code, and when you should just whip our your shop jig and repeat the exact same pocket hole joint you've been using for the last 10 years.

Ahh alright so this is where is gets interesting! I think you are close, but not "whip out". As a woodworking you need to be able to make that jig! The is real knowledge/wealth.

I'm still under the belief great devs will use the tools at their disposal as they see fit to write high quality software. Poor devs will write poor quality software with the tools at their disposal. I don't think any of this changes with AI.

I think where I struggle is even as someone who use AI to help write code everyday and would have a hard time going back, these articles do not sit with me.

>>pvg+hw
But woodworkers still woodwork just fine with mass production. Just there are mass produced things. And there are not. So then there can be mass-produced code and there can not be. The article feel all or none and I do not think that translate to woodworking or software.

>>bradly+rz
I don't think the article says that. People still write games for the NES in assembly but that's effectively unrelated to current software development practice.

>>bradly+1z
Sure, you need to be able to make the jig. But what does that have to do with anything? Once you do, you have it. Is your point that LLMs are problematic for less-skilled programmers, who need the rote tasks to build up fluency? That's probably true! It doesn't change anything for skilled programmers, though.

>>pvg+mA
Again, this comparison that professional woodworking is anything like NES game building is just so far from my experience. Cabinet makers (and to a less extent furniture makers) are numerous and very successful.

Mass production doesn't have to eliminate the alternative to exist. The same way fast-food and cheap groceries are not a threat to quality restaurants.

>>tptace+GX
> Is your point that LLMs are problematic for less-skilled programmers, who need the rote tasks to build up fluency?

Yes, I think less-skilled programmers are being bombarded with messages that in the future of coding being less-skilled is adequate. What I've seen in today's layoff culture is not something that gives me hope for tomorrows junior developers.

I think there is huge and vast gap between: "mediocre software is good enough" and "as a highly skilled dev I understand when I need to be clever or not". The latter has been true for ages and the former is the feeling AI pushers are pushing.

I think the term "mediocre" represents both poor quality code and boring code and I think this word is chosen because of this ambiguity. I am absolutely onboard with boring code and I'm definitely not okay with mediocre code if it is not reliable, maintainable, and/or readable per the stakeholders.

> It doesn't change anything for skilled programmers, though.

Exactly! Its just another tool. A great one, sure, but we were great devs before AI and we will be great devs after.

These are hard conversations to be have via message boards for sure. Thanks for the time. Would love to grab coffee or a drink and talk more.

>>drboji+Fs
Ok. My favorite letter is apparently E.

Does that mean ive never written anything creative before?

>>bradly+3x1
This 'only one can exist' is something you brought in, though. Neither the article nor I am saying that.

>>pydry+jE1
No but it means your missing my point. Do you click those keys for their own sake, or are you doing it for some other reason?

Personally I don't code because I love the letter E. I'd prefer if they all appeared on the screen without me doing any typing at all. It's a means to an end.

What one person enjoy might be toil to another.

>>deanCo+28
Sure, for a large portion of our industry, the goal is to hoover up as much user data as cheaply as possible. Being responsible with that data isn't part of that "PROBLEM SOLVING."

>>tptace+u
I'm not sure why you're equivocating "all code" with "CRUD apps". If that were the case I'd be with you. But it isn't. Glue code between APIs is indeed pointless garbage that can be automated, but that's not what I, nor many other engineers, are writing day-to-day.

>>drboji+ik2
Im not doing it for its own sake but it's also a tiny fraction of the effort of coding. I spend thr vast majority of my effort thinking, very little on typing.