When I started teaching, I thought my job was to know the material. Know it cold. Know it forward and backward. Be ready for every question. What I learned instead is that knowing something and explaining something are two very different skills. That realization followed me back into software development. In the classroom, I could solve a problem in my head in seconds. But when I tried to explain it the same way I solved it – jumping steps, skipping assumptions, compressing logic – I would lose half the room. The students weren’t confused because the material was impossible. They were confused because I had teleported from A to D…
-
-
I used to think that if my JavaScript ran without errors, I had done my job. If the feature shipped, the console stayed quiet, and the tests passed, I’d mentally roll for loot and move on. Victory secured. XP gained. On to the next quest. But somewhere between shipping features and revisiting old projects, I started noticing something uncomfortable: working code is not the same thing as readable code. And readable code is the difference between a clean campaign journal and a pile of crumpled notes written during combat. One of the first times this hit me was with a small function that filtered active users and displayed their names…
