From Curiosity to Capability: How I Read to Grow as an Engineer
By Jimmy Lindsey
Feb. 11, 2026 | Categories: thoughts, senior-engineer, learningOver the last couple of years, I’ve become much more intentional about how I improve as an engineer. One of the highest-leverage tools I’ve found is reading. Learning by doing will always be essential. But reading helps you build context before you start building systems. It moves you from “I’ve never heard of this” to “I understand how this works” to “I can apply this myself.” It gives you the vocabulary, mental models, and confidence to move from curiosity to execution. That progression compounds over time.
This post is about how I use reading, and why I think it’s one of the most underrated tools for career growth.
A Bit About Documentation
The main type of reading I’m not covering here is documentation. Knowing how to read documentation effectively is an underrated skill, but it’s most valuable in the context of an active project. This post focuses on proactive reading, like articles and books, that expand your perspective before you sit down to build.
Articles vs. Books
The truth is, both articles and books are essential to your growth. If all you do is read books, you may waste a lot of time. Also, you will be less likely to explore new ideas and discover new passions. If you have a lot of time on your hands, maybe you can read every tech book that comes your way. For most of us, though, we need to be selective.
Articles are especially useful here. Since most articles can be read in 5–15 minutes, it's easier to invest that time into a subject that you either have never heard of, or one that you are not sure you care much about. In other words, since the time investment is small, you are able to dabble a bit. It is also nice to be able to read something from someone that you may disagree with. Even if they don't convince you they are right in their article, it will still give you a new perspective. You also may find holes in your own thinking that you would not have discovered otherwise.
When I first became interested in DevOps, I am not sure I knew what system design was. As such, at that stage there is no way I would've read a whole system design book. Yet, as I learned more and more about DevOps, newsletters and articles about system design kept coming up. It turns out these two fields are pretty closely linked, and having knowledge of both is very helpful.
Another topic that didn't interest me at first was communication skills. Even developers, as famously as they hide from customers and business-types, need to at least communicate with each other. As you do more research, you will realize that better communication is actually crucial for your tech career. The programmers and other tech workers with the best communication skills are the ones who are most likely to be promoted and work on interesting projects. I am not saying you shouldn't nurture your technical abilities, just don't let your people skills atrophy.
Something I like to do is find an article about management or two each week from Pointer (see below). I personally have no interest in being a manager, at least at this stage in my career, but no matter what I will always have to deal with a manager. Since that is the case, learning a bit on how they think, what their goals are and how they operate can make both of our jobs easier.
Due to their length, books are able to be more in-depth. As such, you should do a bit more research before reading them. Pick a topic that you either already know a little bit about and want to become more familiar with, or a topic that you don't know much about but that you already have a desire to learn. For example, it's not a bad idea to read a book on a programming language you are already familiar with, as that can take your skills to the next level.
You should also do a bit of research on the book itself. I have read a tech book that seemed interesting at first, but it didn't actually teach me much of anything new. The only exception is if you already have a similar book on the same topic that isn’t highly lauded. This happens to me often, since I will buy a tech book bundle from Humble every once in a while. The price in that case can't be beat, and sometimes you will find a hidden gem or a book that would've passed you by otherwise.
Applying What You Know
Of course, books and articles by themselves won't do anything for you. It is easy to just read them. As such, you need to find a way to apply at least some of what you learned.
For books, I have started to copy notes I took on the book from my Kindle, which gives me a short summary of the aspects of the book that appeal to me. If I need to refer to the book, I can refer to those notes first. Also, the act of going back after I read to refresh my memory and copy notes means that I am much more likely to keep the knowledge I gained from reading it.
For articles, I like to group them on Raindrop.io by category. If I think it is really important, or I want to read it again in the future, I give it a tag I can look up later. If it is something I want to look into right away, I will access it on my desktop so that I can work on it.
Some books and articles actually have a lab or a tutorial. If you have the time you should definitely follow along. This is a combination of learning by doing and learning by reading, and it is probably the best combination that you can find.
Articles / Newsletters
Here are some newsletters that I think are useful.
Technical Depth
- Pointer
- Pointer curates high-quality engineering and management articles. It’s my main source for discovering ideas outside my immediate focus area.
- PyCoder's Weekly
- PyCoder's Weekly is a bit like Pointer, but it focuses on articles about Python and the Python community. The project I did where I built an MCP server was directly inspired from a tutorial that I found in PyCoder's Weekly.
- Ivan on the Server Side
- Ivan on the Server Side includes updates on Iximiuz Labs, including new Docker, K8s, Linux and DevOps challenges and learning paths. For someone who is interested in DevOps, both this newsletter and the website itself are crucial.
- Linux Handbook
- Linux Handbook sends out a newsletter that includes Linux and DevOps news, tutorials, and courses.
- System Design Codex
- Each week, System Design Codex gives you a bite-sized lesson on system design.
Career and Communication
- Wes Kao's Newsletter
- The articles I like from Wes Kao's newsletter focus on being a better communicator, such as how to frame your ideas. She also writes articles about other topics, like rigorous thinking and how to set a high bar of excellence.
- The Caring Techie
- The Caring Techie focuses on communication and the people side of tech. It is an excellent place to start to improve your communication with other engineers, management or other non-technical people at your job.
Books
Here are some books I recommend:
- A Philosophy of Software Design, 2nd Edition by John Ousterhout
- Co-Intelligence: Living and Working with AI by Ethan Mollick
- Fundamentals of Software Architecture by Mark Richards and Neal Ford
- Hacking APIs by Corey Bail
Conclusion
Reading will not make you a better engineer on its own. Execution, building and struggling through real problems still matter, but reading expands what you are capable of building. It introduces you to ideas you would not have encountered otherwise, and better ways of thinking. It helps you recognize patterns faster and make stronger decisions when it counts. Over time, that accumulation of perspective compounds.
You do not need to read everything or read constantly. However, if you are intentional about what you read and deliberate about applying it, it becomes one of the highest leverage tools for growth. For me, reading has been the bridge between curiosity and capability. I expect it will continue to be one of the main ways I improve for years to come.