I'm currently a Python developer and machine learning engineering intern. I have a broad but shallow understanding of Linux, networking, databases, backend systems, Docker, cloud platforms, and distributed systems. I want to become a much stronger ML engineer without limiting myself to learning more Python libraries and frameworks.
I'm considering studying areas such as operating systems, networking, memory and filesystems, C/C++/Rust/Go, distributed systems, profiling and performance, CUDA, GPU programming, Triton, and lower-level systems programming. However, I'm not looking for another list of topics or a standard roadmap. I'm more interested in the learning process that actually made people better engineers.
Did books become useful only after you implemented the ideas? Did personal projects teach you more than reading production code or contributing to open source? How did you get useful feedback and avoid reinforcing poor patterns when working without much supervision? If learning C, Linux, CUDA, or distributed systems made a major difference for you, what did that learning look like in practice?
I'm especially interested in high-value habits and methods from early in your career: projects, debugging, code reviews, mentorship, deliberate practice, or anything else that produced an unusually large improvement.
5 Answers
Choose a project based on a real problem or an itch you genuinely want to scratch, and make sure it forces you to use the technology you want to learn. A small database written in C, for example, can teach memory management, file formats, disk writes, and debugging far more vividly than reading about those subjects in isolation.
The project doesn’t need to be original or production-ready. Its value comes from making you confront the details yourself.
Before going deep into a language or technology, ask what outcome you’re pursuing. Aimless learning can turn into collecting tutorials and frameworks without gaining useful judgment. Keep notes on each project: the requirements, your design, the trade-offs, the results, and what failed. Reimplementing one component with a different language or approach can then teach you about speed, complexity, and extensibility in a concrete way.
Over time, repeated projects will show you which tools fit which kinds of problems. That targeted learning is usually more effective than following a broad checklist.
Since you already have access to experienced engineers, ask one of them to walk through a change you made. Explain your approach and the alternatives you considered, then ask about the trade-offs behind their feedback. Applying that reasoning to your next change teaches judgment rather than just giving you patterns to copy.
For solo work, use measurable problems. If inference is slow, predict the bottleneck, profile it, change one thing, and measure again. Investigate why your prediction was wrong. Tests and benchmarks can validate behavior and performance, but design feedback still benefits from another person’s perspective.
Some of the fastest growth comes from being responsible for a project that is slightly beyond your current level. You make a reasonable commitment, learn what you need as problems appear, and repeat the process. Production incidents are particularly effective teachers because they force you to understand system behavior instead of relying on surface-level knowledge.
The important part is to document what happened afterward and turn the incident into a deeper investigation rather than merely applying a quick fix.
The biggest improvement came from building things slightly beyond my current ability and then having my assumptions challenged. Books and videos helped me understand the concepts, but the real learning happened when I implemented them, got stuck, and had to explain problems I couldn’t initially account for. After that, reading good production or open-source code showed me how experienced engineers handled similar issues.
I’d avoid trying to learn every topic at once. Pick one area, build something with it, debug and profile it, compare your approach with real systems, and repeat. Debugging and code review are especially valuable because understanding why a solution is wrong or inefficient teaches more than simply getting it to work.
That distinction between validation and judgment is useful. A project can tell you whether the code works, while review helps you understand whether the design is maintainable and appropriate.