I really agree with Sean Goedecke’s piece on how to read code (opens in new tab). He describes following a particular path through a program, seeing which functions call each other and how the data moves, then going back into the detail once he understands the shape of it.
It’s a big reason why I still think design engineers need to understand coding fundamentals, especially with how much code we can now generate with AI.
When you’re working on an interface, you’re making decisions about behaviour all the time. Take a search field. Someone types, a request goes out, results come back. Then they type something else whilst the first request is still running. If the older response arrives last and replaces the newer results, the interface is now showing the wrong thing.
To understand why, you need to follow that interaction through the code: what triggers the request, where the result is stored, and what decides whether it should still appear. Knowing about functions, state, and asynchronous work gives you somewhere to start. You can connect the behaviour you’re seeing to the thing that causes it, and judge whether a proposed fix actually deals with it.
Sean also makes a point I think matters here: AI can produce code that works whilst making decisions you wouldn’t have made. It can add complexity to solve something you didn’t need solved. Reading the code gives you a chance to notice that and decide whether the tradeoff makes sense for your product.
For me, that understanding is part of being able to care for the thing you’re building. You’ll want to change it, or someone will use it in a way you hadn’t considered, and you need enough knowledge to work out what should happen next. I still see learning those fundamentals as a really worthwhile part of becoming a design engineer.
If you’d like to learn the fundamentals a DE should know, my course is here (opens in new tab).