I agree with everything he has to say but there's an important caveat missing: In his example, the code he starts with is trivial to understand. I can read thro

I agree with everything he has to say but there's an important caveat missing: In his example, the code he starts with is trivial to understand. I can read through it linearly. I can see how the variables are used to achieve the layout. The functions draw_title() and draw_big_text_button() have obvious meanings, partly because I can see x and y coords being passed in. Comparatively, the code he ends up with is hard to understand. If I was new to the code, I'd be wondering what layout.window_title(title) does. I'd have to lookup the definitions of Panel_Layout data structure and window_title() function. Instead of reading linearly, I now have a tree traversal to do. That is harder. However, he's not wrong. The changes he made allow more things to be added to the UI panel without the code becoming an incomprehensible mess. Let's call the original code the linear one. I think the reason his refactoring is good is because the linear function would otherwise have passed a threshold where it was too complex to fit into the working memory of the programmer. The tree traversal exercise he is forcing the next programmer to do serves a purpose. Each function and data structure he introduced is small enough to fit in the programmer's working memory. After looking up those definitions, their (simple) behaviour should be able to be parked in the programmer's medium term memory. Once that investment is made, use of working memory is reduced, freeing up the possibility of adding more stuff to the UI panel function without it passing the threshold. There's a trade-off. In some ways he made the code worse. But it was necessary. We should always be asking ourselves if the abstractions we are introducing are necessary. Understanding the constraints of programmer's brains is vital to being able to make that judgement.