If you ask the internet, “How do I learn to code?” you usually get the same advice. Just build something.

So you build a calculator. Or a weather app. Or a to do list.

But after you finish, you feel like this person who says, “I can’t understand and can’t do anything on my own.” You feel like you just glued together some libraries and you’re still stuck. You don’t feel like a software engineer.

I’ve been thinking about why this happens.

Back when I was an undergraduate teaching fellow at my university, I noticed a pattern in the assignments that my professors gave out. The projects that actually made students grow, the ones that turned them from confused students into capable engineers, always shared the same DNA.

They weren’t just random tasks.

They were designed with specific constraints that forced you to learn the foundations.

Now, after 13.5 years in the software industry, I’ve been able to isolate four main criteria that those professors followed when designing projects that truly built software engineers.

Let’s break them down.

1. The No Magic Criteria

The first criterion is what I call the no magic criterion.

Don’t use magical libraries to build out your coding projects.

If you just use libraries, the main skill you develop is knowing how to use different libraries and glue them together. But you don’t really understand how programming works at a foundational level.

For example, if you really want an awesome coding project, you want one that forces you to handle the bits and bytes of your data. Once you complete a project like that, you gain so much confidence around data and memory that every project after that feels easier.

I’m not saying you can’t use any libraries at all. Standard libraries are fine. But your project should not be so heavily dependent on someone else’s algorithms that the real star of your program is another developer.

You want to be the star of your own coding project.

This is one reason I often recommend learning projects in C. C doesn’t hide much from you. You are forced to build more of the logic yourself. And once you’ve felt that pain, you appreciate higher level languages like Python or Java much more because you understand what they’re doing for you behind the scenes.

2. Structure Necessity

The second criterion is structure necessity.

Your coding project should require data structures out of necessity. Not because you’re playing around with them. But because your project literally cannot work without them.

A simple to do list can often be implemented with just an array. That doesn’t force you to deeply understand more complex structures.

Instead, you want projects that push you toward things like binary trees or priority queues. When you’re forced to manually manage pointers, link nodes together, and build the structure from scratch, you develop real intuition.

That intuition carries into your first job.

When I started working professionally, I encountered all kinds of data structures in large codebases. But they didn’t intimidate me. I had already built them manually. I had already felt the pain. So when higher level languages handled those details automatically, I understood what was happening under the hood.

That foundation changes everything.

3. The Architecture Criterion

The third criterion is architecture.

Your project should be complex enough that it cannot reasonably live in a single file.

If you can cram everything into one file, the project probably isn’t stretching you enough. Real world codebases have many files. They are modular. Different parts of the system handle different responsibilities.

A solid project should force you to:

• Split logic into multiple source files
• Separate concerns clearly
• Link files together properly
• Think about how modules interact

Architecture is a skill in itself.

Writing code is one skill. Designing how that code fits together, scales, and remains understandable is another. If you practice architecture early, navigating professional codebases becomes much less overwhelming.

4. The Tangible Result Criterion

The fourth criterion is that your project must produce a tangible result.

You should be able to look at it and say, “Wow, I built that.”

There needs to be something real. Something visible. Something meaningful.

This helps motivation tremendously. If the project is fun and produces a real outcome, you’re far more likely to finish it. Bonus points if it solves a real problem in your own life.

When a project has a tangible payoff, it no longer feels like homework. It feels like engineering.

A Project That Satisfies All Four

So is there a single project that satisfies all four criteria?

Yes.

A Huffman compression engine.

This type of project forces you to:

• Perform frequency analysis on characters
• Understand ASCII and how data is represented
• Process data at the bit level
• Build a binary tree and priority queue
• Architect your program across multiple files
• Produce a real compressed file that saves space

You compress a text file into a smaller encoded file. Then you decode it and recover the original. You can even verify it using file hashes to prove the decoded file matches the original exactly.

That moment, when you compress a large file and see the smaller result, is powerful.

You built that.

And along the way, you mastered memory, data structures, architecture, and low level data processing.

That’s the kind of project that transforms you from someone who glues libraries together into someone who understands how software really works.

Build This Project With Me

If you want to go deeper and actually build this Huffman compression engine step by step, I invite you to check out my program at henrikmdev.com/sprint.

Inside the sprint, we build this exact project together over four structured weeks. You will not just copy code. You will implement the logic yourself, with guidance, structure, and feedback. We focus on frequency analysis, building the Huffman tree, encoding, and decoding, all while emphasizing architecture and clean design.

If you are serious about moving from tutorial dependency to real engineering confidence, this is where that transformation happens.

You can learn more at henrikmdev.com/sprint.

Final Thoughts

If you feel stuck, it may not be because you lack discipline.

It might be because your projects are not designed to force growth.

Choose projects with constraints. Choose projects that make you uncomfortable. Choose projects that require foundations, not just frameworks.

That is how you start thinking like a software engineer.