How i studied smarter, not longer, to get ahead in software
Busy but not learning? Replace passive tutorials with hands-on builds, deliberate practice, and real deployments that prove skill.
I finished uni better than average without longer hours. Two years in person, two remote because of the pandemic. I learned fastest when I controlled my schedule during those last two years. Remote let me rewatch hard parts, skip easy parts, take a break, and come back sharper.
Here is the gap I saw: Most students and many junior engineers drown in tutorials and pretty notes. They only ship localhost demos to show professors because it’s mandatory, not real code on things that are useful. They copy from Stack Overflow (from ChatGPT now) without understanding trade-offs. That keeps them busy, but they don’t learn.
If you want to move faster than your peers, you need a simple system. This post is about how a student becomes a productive engineer whom managers trust.
In this post, you’ll learn
How to replace passive tutorials with fast variations you can ship.
How to use mental models to reason about trade-offs before coding.
How to practice on purpose with short loops and debugging drills.
How to grow one project through levels until it runs in the wild.
Learn by doing, not watching
It’s simple, if I wanted to play NBA, I’d have to both play a lot of basketball and learn from the best. With coding, it’s the same.
Watch a small tutorial, then build a different app with the same principles. Do not copy the repo, do not copy line by line. Change the domain, the data, or the constraints. If the tutorial is a TODO app, build a wishlist.
You’ll learn faster with your hands than with your eyes.
Design your own friction. Add someone feature you do not know yet. Without checking how to implement a certain UI component or a login, think about how you could do it.
Stay on the edge of your knowledge. I can’t write here “the perfect project to learn” because that depends on you: Your current level, your interests.
Minimize notes, maximize code. Write about concepts, mental models, snippets, and short explanations... When I was a student, I uploaded solved exercises and theory summaries. It costs time that should have gone into coding. Today, you can google or ask AI anytime, so let code be your source of truth.
Build a lightweight feedback loop. Chat from time to time with two or three people. Show a working slice and one bug you cannot solve. Ask for some suggestions. Talk about programming with people: News, a trick you found, or a mistake you made.
Immerse your inputs. Swap a few hours of entertainment for programming media. Follow one Twitch stream or YouTube series where someone reads and refactors code live. In my fourth year I started watching programming content. The same way that learning English or Spanish accelerates when you read and listen things in that language, your engineering fluency grows when you consume content about that.
2) Understand why, not just what
Don’t stop when you know what something does. Ask yourself why it was invented. How does it solve it under the hood? What trade-offs does it introduce?
Build mental models for abstract concepts. For example, a computer’s memory is a grid, like a chessboard, where variables occupy cells. Redraw ideas without syntax. People say great thinkers use simple images to reason. For example, there are many models of the atoms in different years. They were just representations of complex concepts we don’t understand well.
Read good code regularly. Pick a tiny library or a tool you use and that’s open source. Look for regular coding, not only complex things. Look at the naming, control flow, error handling, and how files are split. And follow that open source repo to see the PRs people raise, which ones get approved, etc.
Use AI as an private tutor, not like copying in an exam. Paste a function and ask for a line-by-line walk-through. Ask for alternatives and about the trade-offs. Reason about those concepts before implementing them. This is the same skill we used with Stack Overflow. It was never the best to just copy-paste, it was about understanding the problem and the alternatives to fix it before committing the time to fix them..
I saw the benefit of remote study here too. I could watch an explanation at 2x when it was clear, and replay the hard part three times. Always match the load to your brain, as everyone is different. Productive engineers use that control to their advantage.
3) Deliberate practice
The point is to find the sweet spot between things being too easy and boring and feeling overwhelmed.
Create a ladder of difficulty:
Follow a guide slowly and note decisions.
Rebuild from memory.
Third pass, add new constraints like caching or rate limiting.
Close your eyes after having worked and rebuild the idea. The best way to get concepts to stick in your brain is to do this kind of active recall.
Focus on one concept per session. Keep the theme small so you can finish. If you recall, you didn’t learn the variables, the functions, the loops, and the design principles in the same class when you were a student. You were going concept by concept, most of them on different days.
Get obsessed with debugging. Do not ask AI to fix things blindly. check the input, state, and the call stack. All abstractions leak at some point, so go one layer deeper than you usually need. That’s the law of leaky abstractions.
Run experiments. Do not accept that X is faster than Y because someone said so. Write both and measure. AI makes building a small proof of concept fast, but you still need to decide what you want.
Share your small wins. Share the bug you traced and the diagram you drew. When I shared solved exercises and summaries while I was a student at university, people found errors and asked questions I didn’t have an answer for. After all, I was no expert. I was just learning those concepts at that time. But that feedback and questions meant I had many small exams through conversations before the real exam.
4) Ship a real project, not only random POCs
Pick a domain you care about and you know about. Fitness, finance, study tracking, or a tiny game. Sticking to one domain keeps you motivated and reuses context. You learn faster when you know the concepts of the real world, like exercises and nutrients for a fitness app, so you just have to focus on learning the programming concepts.
Level up the same project. Start with a console script that takes clean input and prints clear output. Move to a CRUD web app with tests. Add auth, caching, background jobs, and pagination. Finish with observability, logs, metrics, and traces. Add a frontend. Each level forces you to learn new concepts..
Do not stop at the POC. Deploy a real instance. I would have learned faster if I had a tiny cloud budget as a student to learn how to use real-world tools. The world runs on deployed code, not on localhost. Invite friends to use it and to give feedback. Invite your programming friends to open issues and PRs to your repo.
Iterate and refactor after shipping. Don’t stop at “it works”. You will not write beautiful code on the first try. Take ideas from books and apply them to your messy repo until it feels clear.
Commit everything to GitHub from day one. You get a visible trail of growth. Hiring managers and interviewers like evidence besides a good interview. Productive engineers leave evidence.
Success leaves clues
That’s why I recommend picking a real project to learn. You don’t want to refactor a small project that was already evaluated by your professor and that you’ll never use. Build something you and some people around you can actually use.
Conclusion
When you build stuff and keep iterating over it, you move from “it runs” to “it is reliable and understandable”. You create visible proof of growth and have real users who try to break it.. That is how productive engineers stand out in front of strangers.
If you’ve read this far, don’t close the article now. Pick something you care about, define one utility you would use, and set a tiny cloud budget.
And subscribe to the newsletter so you can tell me how things went after reading this article.
This is an article inside our system’s transition from phase 2 to phase 3: earn career capital. I’m building this system for paid subscribers. Thanks for your continued support!
🗞️ Other articles people like
👏 Weekly applause
Here are some articles I read during this last week:
The 3 Mindset Shifts That Separate Mid-Level and Senior Engineers by
. Outcomes over output, and focus on being a team multiplier instead of only individual outcomes.Never forget how to delegate. This is the easiest framework for engineers. by
. Having clear the problem, goal, solution, and risks to meet the other engineer exactly where they are so they can own it and grow.My Mistakes and Advice Leading Engineering Teams by
. To ahve more scope, we can’t add work indefinitely. It means delegating real work, coaching, and monitoring progress.Everything You Need to Know to Understand How LLMs Like ChatGPT Actually Work by
. This is a great, practical breakdown of LLM fundamentals: While most of us will build apps that use LLMs through an API, it’s useful to understand what makes a stable AI systems.- . Knowing these will help you when evaluating a tradeoff, like latency vs. throughput.
P.S. This may interest you:
Are you in doubt whether the paid version of the newsletter is for you? Discover the benefits here
Could you take one minute to answer a quick, anonymous survey to make me improve this newsletter? Take the survey here
Are you a brand looking to advertise to engaged engineers and leaders? Book your slot now
Give a like ❤️ to this post if you found it useful, and share it with a friend to get referral rewards
Thanks for writing this, it clarifies a lot. Your points on active learning and building useful projets are crucial. Too many students get lost in passive consumption. Emphasizing mental models for trade-offs is key for true understanding, especially in complex fields like AI development.