Comment by danShumway
5 days ago
You've said this a couple of times, but I don't understand what you're trying to say.
Yes, I can do frustrating things, I know how to review and vet code. I also know how to write boilerplate code. I also know how to research new tasks in areas where I have no familiarity that are poorly documented. I know how to do a lot of complicated, difficult things - all of which are part of being a professional developer.
The question is whether I want to use a tool that makes most of my job the difficult part.
The only way this makes sense is if you are somehow reaching a point where "doing the harder thing" is not the harder thing for you anymore - where reviewing code is easier for you than writing it. And maybe your argument is that you can get to that point with practice, or that LLM code is generally easier to review than other types of code, or that the problems it's tackling are so difficult that in those cases writing the code is harder than reading it.
But it's not that they're both true. "You should be able to do the harder thing" is not really an answer to "why are you selling me a tool that replaces an easy thing with a hard thing?"
There are many difficult things that I can do as a professional software developer. I can mentor junior developers. I can do detailed product design work with stakeholders and translate technical limitations into language that they understand. I can negotiate software deadlines with product owners. I can write interfaces for undocumented software and deal with undocumented bugs in 3rd-party code. I can step through minified code in production settings to debug problems. These are all difficult things that, as a professional developer, I am capable and willing to do, and often need to do. And yes, of course, I can review pull requests. I am not, however, generally in the business of adopting tools that force me to do that stuff more often than is necessary to get good results. I don't adopt tools that make my life harder, and I honestly think that's a big part of being a professional.
To be very blunt about it: "Buck up, you should be able to handle this" is not a sales pitch. I can also write with my non-dominant hand, but I'm not going to start taking notes that way. There's no intrinsic prize for making your life harder, the only way what you're saying makes sense is if it's not harder for you to read code than to write it.
I've kind of lost track of where we disagree here, to be honest.
Maybe we need to drop "easier" and "harder" and talk about speed.
I can write software faster with LLMs, without sacrificing quality - in fact I can get higher quality software because doing things "better" doesn't mean they take longer.
I derive enjoyment from building good stuff. If I can do it faster I can build more of it, which increases my enjoyment.
I wrote about this a couple of years ago: "AI-enhanced development makes me more ambitious with my projects": https://simonwillison.net/2023/Mar/27/ai-enhanced-developmen...
That's still true today, only more so because the models are significantly more competent than they were in March 2023!
I think it's great if reviewing code for you is faster than writing it.
I don't think reviewing code well is something most developers can do faster than they can write it. I think that's what Joel is getting at when he says that understanding code is harder than writing it. Harder in the sense of, it takes more effort and takes longer and you are more likely to make errors.
And that might not be true for you. But it is true for a huge number of professional developers.
And it is certainly not the case that understanding and reviewing code is both:
- more time consuming and more difficult than writing it and
- that it's faster to move your entire development strategy to one where you review existing code.
Those are incompatible claims. Pick one.
----
I wouldn't normally quibble about something like this, but it does kind of rub me the wrong way when I hear AI developers talk down about this (and I'm sure it's not your intention to talk down). In your post, you write:
> Figuring out how to patch fetch() like that is non-trivial—where I’m using the software engineer’s definition of “non-trivial” as meaning “I don’t know how to do that off the top of my head”. I’d have to do some thinking and research! I’m already tempted to drop this idea and work on something else.
If I responded to that by writing, "well, doing quick thinking and research is part of the job of being a professional developer and is a learned skill that you could get better at, so what's your problem" - I think you would very rightly say that's not a reasonable response.
So I think that "well, you're a professional, you should be faster at reviewing code" is similarly dismissive to a real conflict inherent in these tools that you are ignoring, and is the kind of dismissive response that I don't normally see from you. Especially phrasing it as, "they're both true".. I don't understand what that even means.
They're not both true, you're telling me right now that it's not both true - you are telling me that it is faster for you to digest code than it is for you to write it. So what is this "both are true" bullcrap?
I'm not Simon, but I think reviewing code is both faster than writing code and more difficult than writing code.
Lots of difficult things don't take very much time: shooting a bullseye, lifting something heavy, winning a round of geoguessr, playing the guitar solo from Peg. We don't call these things difficult because they take a lot of time in the moment, but because they take a lot of time to master.
I think reading code is like that too. When I think about the best code readers/reviewers I've worked with, they are (1) also among the best and fastest code writers I know, and (2) still much faster at reviewing code than they are at writing it.