Become a developer in only 30 minutes a day

With Mike Acton’s unique practice routine for developers, you can greatly accelerate your learning.

Mike’s the former game engine director at Insomniac Games, now working on Unity’s Data-Oriented Technology Stack (DOTS).

His take on how to practice as a developer was a revelation for me.

While he presented it in a talk for engine developers, solving the right problems for engine developers, it’s a method you can apply even when getting started with game programming.

Learning efficiently

In any domain, there are ways to progress that are efficient and others that are not.

For instance, to get decent at drawing, you can copy thousands of manga characters over ten years.

Or you can study perspective, human anatomy, and all the fundamentals and reach farther in one or two years.

Similarly, there is a right and a wrong way to get better at game development.

You can spend long hours bingeing tutorials and courses; on its own, it doesn’t get you anywhere. Without the right practice, your progress is slow.

If you ask, “how do I get better?” people will tell you to just code, code, and code more.

“Build things. Don’t overthink it."

You can try that, and it may work a bit or not at all. If you’re lucky and pick the right projects, you’ll improve. But if you stay in your comfort zone, you won’t move.

That’s why “just code” doesn’t work; it’s too vague. Those who recommend that don’t think about what is best for you to learn.

You learn at the edge of your comfort zone

In the beginning, code feels foreign and you’re uneasy with the errors and problems that arise.

It’s completely normal.

When you feel a bit uncomfortable with something new in life, this is often a sign you’re onto something.

With code, it’s exactly the same. It’s when you embrace the things you don’t understand that you make the fastest progress.

There’s another pitfall to avoid: aiming too high or trying something too complicated and burning yourself with frustration.

As a beginner, you’ll almost always pick projects with unrealistic scope, thinking you can do it.

I’ve been there. We’ve all been there. When you don’t know better, a 3D MMORPG seems like no big deal.

How do you avoid those pitfalls? How do you learn efficiently and save time?

A solution to all that is focused practice.

Mike’s practice method

Here is the method Mike recommends, broken down and slightly adapted to a beginner’s needs.

It boils down to practicing with intention at least 30 minutes a day:

1. Choose one aspect of game programming in which you need improvement the most. It should be a weakness and ideally relevant to the projects you want to make. For example, it could be character movement or creating a user interface.
2. Decide on one specific mechanic or system you will implement, like a platform game character that can climb walls. Be as precise as possible.
3. Every day, code that mechanic or system from scratch for at least 30 minutes. Experiment and solve the problem anew every day; you don’t want to rewrite the same code lines as the previous one.

You can repeat the practice for 3 to 7 days until it’s no longer a challenge. Then, rinse and repeat with your next weakness.

The repetition strengthens your learning.

This practice is like going to the gym but for your programming skills. You repeat a targeted exercise to strengthen and grow one muscle group as efficiently as possible.

It’s been beneficial for me. With all the work, I struggle to squeeze learning projects into my agenda.

But this method has real perks:

• It challenges you just the right amount to be at the edge of your comfort zone, where the learning happens.
• The sessions are long enough for you to get better every day.
• At the same time, you can keep it short so even if you are busy, you can find the time.

Mike Acton recommends deleting your practice code right after ending the session. This removes the temptation to build upon your work and ensures you start fresh and solve problems in every session.

If you’re new to game development, I’d recommend a variation of that: keeping your project for one day.

This way, after your practice session, you can read the previous day’s code and compare it to the new result. Once you’re done reading, delete the files.

It will help you in two ways:

1. You will practice reading code, which is a core skill for any developer. The ability to read code directly will save you a tremendous amount of time learning, even early on.
2. You will instantly see and assess your improvements, which is motivating.

Why read your code after the practice? Because if you read it before, it will influence your session, and you may get stuck in a loop writing the same thing over and over.

Making the most of your practice

I recommend preparing an empty project with the assets and scenes you need to get straight to code every day.

Say you’re focusing on character movement and wall mechanics. You could premake a tiny level with walls, collisions, and an empty character scene and script. Anything that’s not relevant to your practice, you can prepare ahead of time.

Every day, you make a copy of that template project, open it in Godot, start your timer, and get coding.

Also, avoid code comments.

When getting started, a common mistake is commenting every line and reading comments instead of the code. This is a missed opportunity to hone a fundamental skill: reading and thinking in code.

It’s not that you should never use comments, but your practice will be short, and all the code will be fresh in your mind for you to read and understand it.

Every day, set a timer, and ensure that you turn off any source of distraction: put your phone and computer on airplane mode to avoid browsing the internet.

Embrace this profoundly interesting challenge where you are competing with your former self. Try to better yourself every day.

I’ve applied this method to both writing and programming to great effect.

Become a game developer, with Godot

If you found this guide useful, you’ll surely enjoy our 7-day free series to get started with game development and Godot.

Your questions

Here are the answers to the questions you sent me.

If I don’t finish making whatever system I planned in the 30-minute span, do I start from scratch again the next day?

Yes, you should start over every day. That’s where the practice happens: you’re deliberately working on something small and specific, which you can tackle in one sitting.

This idea of deliberate practice comes back in many fields. To become good at drawing hands, you’ll analyze and draw a dozen hands every day until you get it. You’re thoughtfully focusing on one weakness to get over it.

If I solved a problem yesterday, don’t I already have the solution for the next day?

No, the idea is you shouldn’t repeat what you did by heart but keep looking for ways to improve. Between two days, you can take a minute to analyze what worked well and what didn’t, then write down ideas to improve or topics to research.

In games, as so much of your code influences how the game feels, once you got the best solution you can find to a problem, you can shift focus to improving the controls and design.

Also, there are almost always many solutions to a problem, so you can try to find alternate ones.

What if I don’t know how to make the thing I want to practice? Should I start with a tutorial?

If you’re completely new to a domain, say, networking, sure, you should read a guide to get started. You can’t practice online multiplayer if you have no idea what a server is or how computers communicate over a network.

That said, in general, when it comes to practice, I would recommend working alone, offline, and try to figure it out by yourself. If you’re stuck and made no progress after your first session, try to find online resources.

If you do this, you’ll develop that essential skill of solving problems creatively, an absolute necessity to become an excellent and employable developer.

I rarely use tutorials, even when I have no idea how to solve a problem. I will read up on algorithms, data structures, and general ideas or observe and analyze another game or program, but I avoid step-by-step guides.

Many tutorials' solutions are subpar because most tutorial writers are inexperienced hobbyists or students who didn’t really dig the topic. For Godot tutorials, I mostly recommend KidsCanCode, Heartbeast, Godot Tutorials, Game Development Center for networking, and us, GDQuest.