Comment by bradly
6 days ago
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.
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.
> 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.
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.
1 reply →
[flagged]
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.
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.
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.
2 replies →