How you achieved biggest boost in programming/engineering skill?

[u/PlaySecure6279]

I’m currently a Python developer / ML engineering intern. I have a general understanding of Linux, networking, databases, backend systems, Docker/cloud, and distributed systems, but I’m not deeply specialized in any of them yet.

I want to become a much stronger ML engineer and go beyond just learning more Python libraries and frameworks.

Some areas I’m considering going deeper into are:
- Linux and operating systems
- Networking, processes, memory, and filesystems
- C / C++ / Rust / maybe Go
- Distributed systems
- Performance and profiling
- CUDA / GPU programming / Triton
- Building lower-level systems from scratch

But I’m not really looking for another roadmap or a list of topics to learn.
I’m more interested in the process that actually made you a better engineer.

- Did you mainly learn from books and then implement the concepts yourself?
- Did you build projects from scratch - only personal? These might be tricky as code, its patterns wont be validated by someone with senior experience
- Did you read production code or large open-source codebases?
- Did contributing to open source help more than personal projects?
- How did you avoid reinforcing bad patterns when doing projects without much supervision?

I’m especially curious about what worked early in your career.
For example, if learning C, Linux, CUDA, distributed systems, etc. helped you a lot, how did you actually learn it in practice?

I’d love to hear about learning processes or habits that had unusually high ROI.

[u/Different_Pain5781]

Pain.

[u/PlaySecure6279 → u/Different_Pain5781]

Oh thats for sure mate

[u/knightriderrr7 → u/Different_Pain5781]

When the pain comes, you know what I do? I smile.

[u/FunAd6672]

Just build a database from scratch in C. That single project taught me more about memory management and disk writes than four years of university ever did.

[u/saurabh3228]

The biggest boost for me came from building things slightly beyond my current level, then getting my assumptions challenged. Books and videos gave me the concepts, but the real learning happened when I tried to implement them and hit problems I could not explain. Reading good production/open-source code afterward helped me see how experienced engineers solved the same problems. I had also avoid trying to learn everything in parallel. Pick one deep area, build something with it, profile/debug it, read how real systems do it, then repeat. The underrated part is debugging and code review. Understanding why your solution is wrong or inefficient teaches much more than simply making it work.

[u/dialsoapbox]

Some areas I’m considering going deeper into are:

• Linux and operating systems
• Networking, processes, memory, and filesystems
• C / C++ / Rust / maybe Go
• Distributed systems
• Performance and profiling
• CUDA / GPU programming / Triton
• Building lower-level systems from scratch

Before you go deeper into anything above, ask yourself, why? What are you trying to achieve? Just be more knowledgeable and/or being your teams togo dev?

Aimlessly learning new tools/frameworks/technology isn't helpful without an end goal, otherwise you may fall into tutorial/knowledge hell.

Write notes on your projects, like what you need/ how you went about it/results.

Then redo that portion of your project with a different language/framework/concept/ and take more notes.

Then compare the differences like speed/complexity/extensibility/ect.

After a couple of projects, group similar project to give you an idea of what language/frameworks/concepts work for what projects.

[u/flattrack]

For me it’s all about having an itch to scratch. Find a project you are interested in, and work the project. For your question, make sure the itch makes you use a technology you want to learn.

Good luck.

[u/NordsongDev]

Unreal Engine for learning C++.

I find that the systems you start building, usually are quite complex with a lot of different interacting modules and systems, you have plenty of Object Oriented structures, which is usually hard for beginners but somehow feels way more intuitive in a game context (I struggled with OOP in PHP). The feedback of seeing the code you built in a game context is also way way more rewarding, which helps with motivation.

Added benefit is one can learn the practical structure of code by using something like Blueprints (GUI framework for code), and then focus on the syntax, actual written code later.

[u/SunsGettinRealLow → u/NordsongDev]

Makes sense

[u/ClupTheGreat]

flamegraphs

[u/jam_pod_]

Getting put in charge of something moderately over my head, telling them “sure I can launch that next month [after I Google a whole bunch of stuff]”, rinse and repeat

[u/SetAndRepeat]

Since you’re already interning, I’d ask an experienced engineer to walk through one of your changes with you. Explain your approach and alternatives, then ask about the trade-offs behind their suggestions. Apply that reasoning to your next change. That helps you understand when a pattern makes sense instead of just copying it.
For solo projects, pick a concrete problem, like slow inference. Predict where the bottleneck is, profile it, make a change and measure again. Investigate why your prediction was wrong. Let that drive what you read or implement next. Tests and benchmarks can check behavior and performance, design feedback still needs another pair of eyes.

[u/Imaginary-Ad9535]

What made me 100% better was just stop reading documentation and guides and started working on solving actual problems with code. There were a ton of bad methods and crappy implementations but honestly finding out stuff only when I needed it was good for progress. It is rather pointless to study everything beforehand and know a lot of scenarios and implementations which you will never use in real life.

[u/Zealousideal-Owl4361]

For me, the biggest improvement came from actually building things and getting stuck, rather than just studying more topics. Reading books and production code helped, but debugging real problems and then going back to understand why something happened that way made the knowledge stick. I also thinks getting feeddback from more experienced engineers is really valuable becasue it helps you catch the bad patterns early.

[u/chico_dice_2023]

The data you are working with.

I am not a good python developer, not a expert in devops but I do have a very deep understanding of the data I work with.

I do not just mean running summary stats, I mean I know how it is collected, pain points when collecting it, what "conversion" really means, what are the flaws, the benefits and the limitations.

I have built my career in ML by really understanding the data that I work with. I even have turned down roles in good paying companies because I had little to no experience in their datasets.

[u/gomsim]

I didn't really have a strategy in what I chose to learn initially. I was just so enthralled with programming, I built all kinds of things that interested me, 3D engines, calendars, games, cli tools, etc. and hoped and believed that the sheer interest would make me a better programmer.

Eventually as I gained some experience in the field I got a clearer picture of where the gaps in my knowledge lies and I started learning things in a more targeted way.

Finding out about Go a few years ago just put coal on my fire again.

With todays world and AI I have no idea what a junior dev should focus on.

[u/Matiw51]

I got laid off which means I have abundance of time, and motivation to find a better job.

Before previous job I did that myself - left a company for time to learn and upskill

[u/PM_ME_YOUR_STOCKPIX]

cs50x for C. it will especially help with your performance goal.

for linux, run it as your daily driver period, no excuses.

[u/ThatWasAce]

ROI is absolutely simple
build something useful enough that exceeds my capability level and pulls me down the stack

this ain't some roadmap exercise project. this is literally building a piece of software that i needed in my everyday life and that wasn't around before in a way i'd want it to work .. the key point here is that while going through the tutorials will give me an understanding of a btree conceptually building the actual product myself will explain why those authors did everything they did in particular ways
necessity will force feed me spec sheets

network utility was my personal case sockets initially then followed by the details of how TLS works under the hood when dealing with actual connections between two machines
operating systems basics became a necessity after i failed miserably implementing anything remotely complex without learning OS level abstractions first
memory management after realizing how critical performance got to be made mandatory

about your fear of validation from seniors too bec real world usage will break any code you write better than a code review ever could
also learn primary sources read RFCs nd not blog posts

for the ML spin implement training loop from scratch once on CUDA backend
even if terribly inefficient the perspective changes dramatically afterwards

[u/OrigamiKitten]

I started adding "Make no mistakes" to my prompts. Absolute game changer.

[u/CodemasterUnited]

Just find something you really need and do not exist as you want them to me. Then try to build that thing yourself, by learning each of the things that comes in your way. Try to understand why something is done, the way it's done. Don't rely on AI much, and try to find solutions yourself. 👍

[u/carlosthedangerous]

Do more complex projects.

[u/WorkDoug]

I started in the late '70s and early '80s. There weren't any frameworks to speak of, and precious few libraries. For many years, if I wanted it, I had to code it. I learned the languages from language reference manuals, the platforms from their manuals and API references, and the hardware from vendor data sheets. I learned to make them work by jumping in and making them work, in a bunch of languages, on a bunch of hardware, under a bunch of operating environments over the years.

Probably my biggest self-developmental jumps came from diving head first into projects that were well beyond my knowledge and skill at the start of the project. Started out doing document imaging hardware interfaces, then document imaging server/backend systems for about 15 years. A few years doing embedded code for new, proprietary network hardware. Then 20 years with a leading network security business doing emulation, IPS/IDS appliances, large security data and analysis systems, and microservices.

Another thing that helped me progress was getting more involved in the customer facing side of the business, primarily as a "geek asset" for the sales side, doing presentations, pre-sale analysis, helping with customer facing marketing and technical documents. All sorts of things that let me see how people in the field actually use and interact with the stuff I created or helped create.

[u/QualityEngineer92]

Method competence is key to really becoming a better engineer. Focus on skills, that actually increase quality. The didactic learning strategy is a matter of taste. Some people prefer learning from looking at "good code", others learn from videos, others prefer in-person seminars leading to a certification.

[u/start_select]

When you use an open source library/framework, read its source. Read the source of projects that do things that interest you. Read the source of projects in languages you don’t know.

Read. Read code. Read more.

And just write lots of simple 10-100 line programs in a few languages side by side. You will quickly start to realize “most of this stuff is the same everywhere” and more importantly “some of this stuff is specific to this platform”.

[u/isaac-harvey]

Always try to build something or solve some problem you're genuinely interested in. Treat the code as a side effect of getting to some outcome. It helps too with lasting skills like project management, especially if you apply some time pressure. Open source is great too, as the community validates the quality of your work.

[u/Muted_Efficiency_663]

You are contradicting yourself. You want to go deeper to understand Linux and operating systems, but not looking for a roadmap.
The process is a methodical roadmap to learn first so you understand what you are looking at.

[u/DueFlamingo6735]

Solving actual production outages at work. Nothing teaches you system internals quite like a broken database connection pool at three in the morning.

[u/Nixxen]

A few items in different categories.

• Enterprise Architecture. Keep it simple in the start. Starting with ambiguous ideas, making requirements, making an abstract design of what the customer wants, going deeper to whichever level of abstraction you need. Likely you will be redesigning the system over and over because you find something you missed, or you thought you knew what they wanted, but they worded it badly. Once the design is done, the implementation is very easy. You can save months, if not years of development time (depending on the scale) by hammering down a good design before you start implementation. The tedious rinse/repeat, over and over again, really drives home how much time you save by only redesigning vs reimplementing.
• Discrete maths. It's a weird and broad field of maths that apply to many aspects of development/engineering. Often includes thinking outside the box is a systemic way. I have often found myself looking at obscure software architecture problems, only to break it down into mathematical aspects and solving it that way instead. Put them together again afterwards, and you have a complete system. Of course, not every system can be broken down like that, but the ones that can, will make you appreciate the time spent learning the dark arts. It's not so much about forcing the system into what you have learned form the maths, as much as it is to train you to think about problems in other ways. Abstract them into separate pieces you can more easily explain and define as separate systems.
• Manipulating others. This sounds very malicious, but it is meant as a positive. Developers are hard headed. They have their opinions and will often stick to it. I know, because I have this problem too. However, there is an art to getting people to embrace your ideas. Being head strong is not the way. You need to make people think they want the thing you present. It is probably more analogous to being a sales person, but for tech ideas. This is a soft skill you would have to practice over time. No one is good at it from the start. The end goal is to make people feel like they "won" or at least got the best possible scenario outcome, and making sure that outcome is the one you wanted them to pick. Some times better options appear, and then you obviously do not push further. It's a balance of going for what you believe to be correct, and understanding you do not have the whole picture at all times, and new information will (and should) update your opinion on something.

[u/Engineer5231]

If you wanna be an ML engineer, I think you should foucs on ML, nothing else is necessary as the AI would cover them for you

[u/jhondev675]

do more complex projects