This article is the English translation of the Japanese article titled ‘私の考える最強のプログラミング勉強法’.

---

I’d like to share what I believe is the most effective way to study programming. The title might sound a bit exaggerated. After all, what’s “ultimate” can differ depending on the person and the goal. I fully acknowledge that others may have different opinions.

Introduction

A while ago, a friend asked me for advice on how to study programming. They had bought an introductory book for beginners and were copying the sample code line by line. While it felt like they understood it at the time, whenever they tried to write something on their own, they didn’t know where to start. No matter how long they studied, it didn’t feel like a usable tool to them.

They said they were happy when sample code worked, but whenever they tried to program without the book, they got stuck. “How should I study then?” they asked. But honestly, I didn’t have a good answer either. That’s because I never really studied programming in a structured way myself. It was just a natural extension of my hobby of tinkering with computers—something I did for fun.

That conversation prompted me to reflect on how one might effectively learn programming.

Is Your Image of “Learning a Language” Actually Accurate?

One issue is that beginners often have a different image of what “learning a language” means compared to experienced programmers. When you ask a beginner what it means to “master a language,” they might say, “To have all the syntax memorized and be able to write code freely without referencing anything.”

Programmers out there—do you know every detail of your language of choice by heart? Maybe some of you do, but I certainly don’t. If I haven’t used a language in a while, I often find myself thinking, “Wait, how do I write this in this language again?” and looking it up as I go.

What’s more important, I believe, is having a strong mental model of how the language works and how its features can be used to achieve your goals. The fine details? Look them up when you need to. That’s a much easier and more relaxed approach.

If you ask me what the goal of learning programming should be, I’d say it’s “gaining the ability to imagine what you want to create and then actually make it.” In other words, a state where you understand the language’s features and can apply them appropriately based on your purpose.

Don’t Try to Memorize All the Syntax

A common mistake beginners make is starting from the beginning of an introductory book, diligently copying sample code, trying to memorize syntax—and then burning out halfway. When they hit a slightly more complex chapter, their progress slows, and they lose interest and give up.

Trying to memorize syntax without a clear purpose isn’t effective. Instead, I think it’s better to gain knowledge organically as you encounter situations where you think, “Isn’t there a more efficient way to do this?” or “Would this syntax clean things up here?” This approach makes what you learn stick more than just reading a book from cover to cover.

So, I suggest not trying to master all the syntax before creating something. Also, let go of the misconception that using lots of features makes for good programming. What matters is being able to use the right tools at the right time, and to get there, the best shortcut is reading, designing, and writing lots of code.

Get a General Grasp of the Syntax

You don’t need to know everything, but you need to know something. Skim through a beginner’s book to get a general sense of the language’s syntax. You don’t have to copy the sample code (more on that later). Just look through the basics: data types, conditionals, loops, functions, structs or classes, arrays or lists.

Take a high-level view of the book or online resources and identify where to look things up when you need to. That’s more important than memorizing everything. Look up the details as you hit real problems.

Every language has some unique “core” features. Think pointers in C, borrowing and referencing in Rust, or monads in Haskell. These take time to grasp, but the best way to learn them is simply to get used to them. Read about them, experiment, and don’t worry if you don’t fully understand them right away. Use them anyway. There was a meme once: “I don’t understand this at all, but we’re doing it by feel.” That’s honestly how it starts—and that’s fine. Once you’re more familiar with the concept, revisit it. You’ll understand it much better the second time.

Don’t Copy Code (No “Code Copying Meditation”)

One well-known study method is copying sample code, sometimes referred to in Japan as “code copying meditation.” Maybe it works for some people, but personally, I found it boring and not very effective.

You might feel satisfied from having copied a lot of code, but how much of it did you really understand? When you’re focused on copying, understanding takes a back seat. The biggest issue with this approach is that it’s passive learning. Passive learning may seem efficient, but it doesn’t stick.

Instead, I recommend taking sample code as a reference and modifying it to make something different. Sure, it might not run at first and throw all sorts of errors. But reading those error messages, comparing them with the original code, and thinking things through yourself—that’s where real learning happens.

Don’t Stop at Sample Code

Many learners start by writing simple sample programs. That’s not a bad thing—it’s an active form of learning. But sample code is often short and very simple. Even experienced developers write sample programs to test ideas, but those are just for verification—not the final product.

If you only write sample code and stop there, you’re selling yourself short. Because you know it’s just a sample, you don’t push yourself to consider deeper issues. The gap between a sample program and a production-ready application is massive. When you try to build something useful, you start considering usability, security, performance, and more. Through that process, you also gain knowledge in systems, networking, and beyond. Building something real teaches you far more than writing countless samples ever could.

Build a Practical Tool You’d Actually Use

Then what should you build, if not sample programs? I suggest creating tools or services for yourself. Many people who love programming create things for their own use without thinking of it as “studying.” If making a command-line tool sounds abstract, how about a mobile app or a web service?

We all have smartphones these days, so building your own mobile app is a very accessible entry point. A web service is also a great place to start. What about making your own blogging platform? Or a reading tracker?

You don’t need to make something amazing right away. Just the experience of bringing your idea to life through programming can be incredibly exciting. Write down what you want to build. Don’t worry if someone else has already made something similar—just build your own version. It’s all part of the journey.

Start Small and Get It Working

The biggest trap in trying to build something practical is setting goals that are too ambitious. If you try to cram in too many features from the start, you’ll get overwhelmed.

Instead, stand on the shoulders of giants: use frameworks and libraries to build something small but functional first. Gradually add features or refine it to suit your needs. That’s the key to avoiding burnout.

Once you’re more comfortable, start incorporating design phases before coding. At first, “design before implementation” might feel vague if you don’t know what’s possible. But as you build more tools, you’ll begin to appreciate the value of planning.

Finish What You Start and Publish It (e.g., on GitHub)

Tying into the earlier point about avoiding sample code: it’s important to fully finish what you start and bring it to a point where it’s ready for the world to see.

If you want people to actually use it, you’ll need to consider usability, security, and more—all of which are much more complex than writing a basic program. When you publish something online, not only does your programming improve, but your knowledge of servers, operating systems, and infrastructure will naturally grow as well.

For example, in web development, it’s easy to feel like you’ve “mastered it” after building a sample app in a dev environment. But deploying it to production and running it? That’s a whole different ballgame. And by operating your own app, you’ll discover all kinds of things you missed or didn’t understand before.

Finishing your projects is absolutely critical.

Refactor Your Own Code

You’ve built and released a practical tool. That’s fantastic! Your programming skills are surely leaps and bounds beyond when you started. But don’t stop there. Look back at the code you wrote a few months ago. How does it look?

Chances are, you’ll find things that could be better. That’s a sign of growth.

Try rewriting parts of your code without changing functionality, based on what you now know. Maybe you’ll use language features you weren’t familiar with before. Maybe you’ll restructure your modules or folders more cleanly. Maybe you’ve found better libraries.

Seeing the flaws in your own code and refactoring it is proof that you’ve improved. Keep reviewing and refining your code.

Read Other People’s Code

Thanks to open-source projects, we now have access to tons of high-quality code. If the libraries or frameworks you use have public source code—read

them! You can learn not just syntax and design, but also commenting style and coding culture.

Since you’re already familiar with how those libraries behave, reading their source code is a great learning opportunity.

Pay attention to naming conventions, directory structure, module layout—absorb everything you can. Reading is just as important, if not more so, than writing code. Reading great code will make you a better programmer.

Write Your Own Beginner’s Guide

This might sound odd—advising beginners to write their own beginner’s guide—but I actually think it’s ideal for beginners to do this for themselves. Rewriting and organizing the syntax in your own words helps bring clarity and structure to what was previously vague knowledge.

You don’t have to publish it. Just make it for yourself.

Update your guide as your understanding deepens. You’ll see firsthand how much you’ve grown.

Summary

To summarize:

• Don’t read intro books from front to back or copy sample code blindly
• Once you grasp the basics, start building practical tools or services
• Use frameworks/libraries and start with small working projects
• Finish your projects and publish them (e.g., on GitHub)
• Refactor your own code to improve your design skills
• Read others’ code to deepen your understanding of language and architecture
• Write your own personal programming guide

Programming languages are just tools to achieve your goals. Studying them shouldn’t become the end goal (unless you’re specifically researching languages, which is another matter). Once you’ve built one complete tool or service, your programming skills will level up dramatically—and you’ll want to build more.

I hope this article helps in some way and contributes to your growth as a technologist.