I read a lot. Not always books. Often documentation, datasheets, changelogs and long-form articles. This issue is about the things that actually changed how I think, with a short note on why each one mattered.
These are not the books everyone puts on a list because they are famous. They are the ones that shifted something in how I approach problems.
On electronics and hardware.
The Art of Electronics by Horowitz and Hill is not a textbook. It is a companion. It explains what is happening in a circuit and why, not just what the formula produces. The chapter on op-amps rewrote how I thought about my audio amplifier project. The sections on noise, filtering and grounding are things I return to whenever I am designing something analogue. I go back to it when I am confused, not when I want to confirm something I already know. That is the mark of a genuinely useful reference.
Practical Electronics for Inventors by Scherz and Monk is more accessible than Horowitz and broader in scope. Useful for the moments when you need context before you need precision. Good coverage of power supplies, motors, sensors and digital interfaces. I used it when specifying components for the Phaemos hardware layer.
On software and systems thinking.
The Pragmatic Programmer by Hunt and Thomas contains career advice but the deeper value is the mental models: DRY, orthogonality and programming by design rather than by coincidence. Reading it early changed what I noticed when reading other people's code and when reviewing my own. The broken windows concept is one I think about whenever I am tempted to leave something messy because it is not the main task right now.
A Philosophy of Software Design by John Ousterhout is short, direct and opinionated. The core argument is that complexity is the enemy and depth is the goal: modules should do a lot and expose little. I think about this when designing API endpoints, firmware state machine interfaces and database schemas. Deep modules reduce cognitive load on everyone who uses them. Shallow ones push complexity outward where it multiplies.
On learning.
A Mind for Numbers by Barbara Oakley describes the focused versus diffuse thinking model in a way that is genuinely actionable. Focused thinking is deliberate and directed. Diffuse thinking happens when you step back and let the mind wander. Both are required for understanding to consolidate. This changed how I structure study sessions and how I treat breaks. Taking a break when stuck is not laziness. It is part of the process.
Make It Stick by Brown, Roediger and McDaniel was uncomfortable to read because it made clear that most of what I thought counted as studying did not. Re-reading notes feels productive and produces almost no durable retention. Retrieval practice, spaced repetition and interleaving are the methods that actually build knowledge you can use under pressure. I changed how I revise for exams and how I plan projects where I am learning while building.
Resources I return to regularly.
The ATmega644P datasheet. Not a book, but the most useful document I have read in the past year. Every answer about the microcontroller is in there. Learning to navigate a datasheet is a transferable skill. The index, the register summary tables and the timing diagrams are where the real information lives.
Phil's Lab on YouTube covers PCB design, embedded systems and STM32 content with clear explanations and real projects. No padding. I watched his KiCad and STM32 series before starting the Phaemos hardware layer.
embedded.fm is a podcast of conversations with working embedded engineers. Useful for understanding how the industry actually thinks rather than how academia presents it. The episode archive is long and the quality is consistent. Find it at embedded.fm.
A note on the classics.
Structure and Interpretation of Computer Programs is important. Clean Code is widely cited. I have read both. Neither changed how I think as concretely as the books above.
The best resource is the one that meets you where you are and gives you something you can apply to what you are building right now. That changes as you develop.
Next issue: what a British Airways maintenance simulation taught me about engineering rigour.
Zac
