Comment by simonw
5 days ago
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.