Think for Yourself (Flashback Edition)

TL;DR: the advice is the same as it ever was

I recently posted some advice that evolved from a tip I contributed to a Modern Software Engineering newsletter. It concerned avoiding atrophy of either your skills or your codebase when working with LLM-generated code. The guidance followed four main questions, with a couple of corollaries:

1. Does it work?
2. Do you understand the generated code? Could you explain it if asked?
3. What’s different between the generated code and what you might otherwise have done? Are the differences something you can learn from or something you should reject?
4. Can you think of at least one way to improve the generated code?

I posted the blog at the beginning of the week I spoke at NewCrafts in Paris. On the train, while working on slides for my talk, it occurred to me that it might make sense to reinforce why focusing on knowledge, skills and awareness in code and tests — the subject of my talk — continues to make sense when much of the current conversation around software development is focused on GenAI. I ended up including the above four questions.

As I was presenting it struck me that, in a world of copy–and–paste-driven development (a.k.a. Stack–Overflow-driven development) and overwhelming legacy, these have always been the questions to ask if we wish to be the driver of changes in our development (both personal and software) rather than be passengers in a process. The wording changes are minor:

1. Does it work?
2. Do you understand the existing code? Could you explain it if asked?
3. What’s different between the existing code and what you might otherwise have done? Are the differences something you can learn from or something you should reject?
4. Can you think of at least one way to improve the existing code?

These are good questions to ask of yourself or in any review. In other words, the quality of what you are building is not independent of you, of what you know or of how you go about your work. That will inform how you employ any tool or technique.

This echoes a point Chris Simon made in his NewCrafts keynote: AI adoption in software teams acts as an amplifier not a compensator. That observation cuts both ways:

1. If you have a strong testing habit, you’ll catch misunderstandings, miscommunications, hallucinations and other defects quickly. If you don’t, these can pile up faster than any productivity gains you may have been hoping for.
2. If you understand what you are building and why, you know what you are changing and how and why you want to change it. If you don’t, you’re stumbling around relying on luck. Remember that luck comes in both good and bad varieties. Either way, it’s not the basis for a sustainable workflow.
3. Software development is knowledge work. Critical thinking and engagement is how we can build knowledge within ourselves and embody that knowledge in the code — a codebase is a knowledgebase. Learn from code that improves on what you would otherwise write; know how to judge and reject code that is worse.
4. The oft overlooked subtitle of Martin Fowler’s classic Refactoring book is Improving the Design of Existing Code. If we are to imagine improvement, it helps to know what ‘good’ looks like and to understand the diff between that and the status quo. Knowledge and informed judgement come from learning and exposure, which are matters of practice and engagement.

x.com/KevlinHenney/status/1397190695518093322

After decades of IDE-supported refactoring, the reason much code mess is a scaled-up by-product of trivially fixable issues — questions of naming, logic, control flow, composition, decomposition, etc. — is not because of a lack of tooling.

This is a matter of taste — what does good look like? — and empowerment — is it OK to change something for the better? If we focus on tools without training our sensibility, we should be unsurprised when our tool use is insensible.