Adapted from my Chinese answer on Zhihu to “Jeff Dean says that as AI agents write code, taste is becoming a scarce skill. What does ‘taste’ mean to you?”, originally published on August 8, 2026.
When we talk about good taste in code, we can do more than trade abstract principles. There is a famous, concrete example from Linus Torvalds’s 2016 TED interview, at around 14:10. He dislikes giving talks, so he had the organizers make it an interview instead. The perks of being Linus.
The example is simple: an introductory data structures exercise, removing a node that is known to be in a linked list.
The textbook solution
A linked-list node is just a struct containing a value for the data and a pointer to the next node. The pointer head holds the address of the first node.
struct list_entry {
int value;
struct list_entry *next;
};
typedef struct list_entry list_entry;
The interviewer contrasts two ways to write the removal function. Here is the textbook approach, using a head pointer:
list_entry *remove_list_entry(list_entry *head, list_entry *entry)
{
list_entry *prev = NULL;
list_entry *walk = head;
// Walk the list until we reach the node to remove.
while (walk != entry) {
prev = walk; // Keep track of the previous node.
walk = walk->next;
}
if (!prev) // The first node: update head itself.
head = entry->next;
else // Otherwise, update the previous node's next pointer.
prev->next = entry->next;
return head;
}
This is the standard textbook answer. To remove a node, first find it, then make the preceding node point to the following one. If we are removing the first node, we update head itself. The node is no longer part of the list. We are not freeing its memory here, just unlinking it.
Both implementations return the resulting head pointer, so the caller writes:
head = remove_list_entry(head, entry);
But Linus does not consider this good taste, because it introduces a special case: is the target the first node? That takes an if to handle. The nodes are all on equal footing, yet a node becomes a special case simply because it happens to come first.
Perhaps such a small demo does not convince you. “It’s just one more if. What’s the big deal?”
In a large, real-world system, though, this kind of structure reflects a real design flaw: the abstraction creates a special case where none needs to exist. In physics, the analogy would be a theory that cannot properly account for the experimental data and needs patching. In astronomy, it would be Ptolemy’s geocentric model explaining the Earth and Sun perfectly, only to need epicycles piled onto deferents to explain the planets’ retrograde motion.
One more level of indirection
The version Linus considers good taste uses one more level of pointer indirection to make the special case disappear.
list_entry *remove_list_entry(list_entry *head, list_entry *entry)
{
// Think about why we can take this address here. ;)
list_entry **indirect = &head;
// Walk the pointers leading to the nodes.
// Reminder: -> has higher precedence than & and *.
while (*indirect != entry)
indirect = &(*indirect)->next;
// Then just unlink it.
*indirect = entry->next;
return head;
}
The clever move is changing the iterator from list_entry *walk, which points directly to each node, to list_entry **indirect, which points to the place where that node’s address is stored.
Every node has a pointer leading to it. For the first node, that pointer is head; for every other node, it is the preceding node’s next field. Once we operate on that incoming pointer, the distinction disappears.
Taking &head works because head is a local pointer variable. At the start, indirect points to that variable; as we walk the list, it points to the next fields inside the nodes. The final assignment, *indirect = entry->next, updates whichever pointer leads to the target. Returning head lets the caller keep the new starting point if the first node was removed.
Relativity replaces Newtonian mechanics. Heliocentrism replaces geocentrism.
No extra node required
A dummy head is another way to eliminate the special case: give even the first data node a predecessor, and every removal can update a next field. The pointer-to-pointer version achieves that uniformity without adding an extra node.
Simple. Efficient. Natural. If you are used to C, this feels like the perfect abstraction for a linked list.
You might still think: sure, another level of indirection gives us a perfect abstraction, but the original version with an if for the first node was easier to understand. It’s only one special case. Is the taste really that bad?
Then I suggest you look back at the code your AI agent has written. How many if statements are there to handle special cases?
Any problem in computer science can be solved with another level of indirection.
I once wrote an AI inference engine in C, building it from the ground up, starting with linked lists, hash tables, and graphs. I used Linus’s technique there too: LightNet. You can see it in the linked-list removal code.
Both illustrations come from Marc Kirchner’s Linked lists, pointer tricks and good taste.
Illustration license
MIT License
Copyright (c) 2020 Marc Kirchner
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.