If you grew up with traditional school, you might expect lectures, slides, and long readings before you touch any real code. That is exactly what Sam Davies thought he was signing up for when he joined the Software Engineering path at Amsterdam Tech.

Instead, he got something very different. He got projects, problems, and a clear message: “Here is the brief. Go figure it out.”

From hospitality to software engineering

Before Amsterdam Tech, Sam worked in hospitality and teaching. Coding was something a friend talked about, not something he did.

He started experimenting with FreeCodeCamp to test the waters. The more he tried, the more he realised how mentally stimulating it was. At the same time, he was living in Italy and needed a course in English that he could do while keeping a full‑time job.

A Google search led him to Amsterdam Tech, and he decided to take the leap into Software Engineering.

“I expected lectures. I got a project instead.”

When Sam started, he braced himself for a classic university setup. He imagined theory, lectures, and then maybe a small assignment.

What he got was different.

• He was given a project and told to start building.
• There was no step by step hand‑holding.
• When things broke, he had to debug and search for answers himself.

At first, that felt like being thrown in at the deep end. Over time, he realised it was the point. Every error, refactor, and failed test forced him to learn how to think, not just how to repeat.

How “figure it out” builds real problem‑solving

In a theory heavy model, it is easy to wait for the tutor to explain what went wrong. In a project based model, you are the one who has to trace the bug, read the logs, and ask better questions.

For Sam, this looked like:

• Writing code, running tests, and seeing them fail.
• Digging into error messages instead of waiting for someone to translate them.
• Refactoring the same project several times until it met proper product and style standards.

He describes the latest project review as “frustrating but incredibly useful.” Earlier in the programme, he could be a bit loose and still pass. Now the feedback is strict on consistency, structure, and professional standards. That is how the gap between “student” and “junior developer” starts to close.

Inside the BSQ project: learning to think like an engineer

One of Sam’s key projects is called BSQ (Biggest Square). On paper, it sounds simple. You get a file that represents a map, and your job is to find the largest empty square. In practice, it is a lot more demanding.

To solve it, Sam had to:

• Read and process data from a file.
• Design a dynamic algorithm that stays memory efficient and fast.
• Keep his C code clean and modular, even as the logic grew more complex.

Along the way, he became much more confident with pointers in C, which are references to memory addresses. They let you pass data around and change values efficiently, but the syntax can be confusing. Now, after this project, he feels far more in control of them.

If you asked him what changed, he would say it is not one magic trick. It is confidence. He now writes code in a more defensive, proactive way and thinks ahead about structure, not just about making it “work once.”

Why this feels different from traditional university

Sam still respects theory. But he has learned that theory without practice is fragile. In his words, every big refactor on this project taught him more than six months of lighter work.

This “do something, check, improve, repeat” cycle is close to a lean or agile approach:

• You ship a first version, even if it is rough.
• You compare it to clear product specifications.
• You improve it until it meets real standards, not just passes a basic test.

You do not wait for a perfect first try. You accept that your first version might be something you “hate” later, and you keep going anyway.

How Amsterdam Tech is designed for this kind of learning

Amsterdam Tech is built around the idea that tech careers are about doing, not just knowing. That is why the curriculum is:

• Flexible and online, so people like Sam can work a full‑time job in Italy and still follow a structured programme.
• Project based, so every module ends with something real, not just notes.
• Focused on clear standards, so feedback pushes you toward professional quality, not just completion.
• Supportive but not spoon‑feeding, so you always have guidance, but you are still the main problem solver in your own journey.

This “figure it out” model can feel steep at first, but it produces the kind of resilience and thinking that tech teams rely on every day.

What you can take from Sam’s journey

If you are used to traditional education, Sam’s story might feel both scary and exciting. That is normal.

You can start with a few simple shifts:

• Expect to be uncomfortable at first. A steep learning curve does not mean you are failing. It means you are growing.
• Treat every error as a teacher. Instead of feeling ashamed of bugs, get curious about them.
• Look for programmes that ask you to build real things and stick with them, not just watch or read.

When you are ready, you do not have to choose between theory and practice. Explore our programmes, see how project based learning in Software Engineering, Data Science, or AI could fit you, and treat your next project as the first step toward thinking and building like an engineer, on your terms.