The advice you will get here is a true and honest take on how I believe you should start programming computers, and how you can self-educate yourself in a programming craft. I know how to do it because I went through this process by myself and I know exactly where the pain points are. I don’t talk about any specific books, as other people have done it already. I only talk about methodology and mental side of studying.

Before we start let me give you a hint for learning programming: you should find someone who will show you what programming computers is all about. At least the basic steps. The teacher who’s familiar with the writing software will be an extreme leverage, and will accelerate your learning by an order of magnitude. Remember: having a mentor like this isn’t cheating. It’s giving yourself competitive advantage.

Here we talk about situation where you don’t have a person like this in your life or if you just want to do it all by yourself. Maybe to prove yourself?

What do you want to build?

The problem I see with teaching and teachers in general is that it’s often unclear to you what the end goal is. Teachers often make the target of your study to be unknown. For self-study it’s even worse. There’s no teacher here. So you need to ask yourself: what will you do once you know programming language X? Why do you want to learn at all?

(Photo by Joseph Yates via Unsplash)

In my opinion your end goal must be building a software product. Something you can use, or something you can show to other people. Something that is “cool” to you. This should be your ultimate motivation. You learn to have enough skill and knowledge to go from zero to something working on your computer, and then possibly on your friend’s computer. Use this hint:

I want to learn programming because I want to build ……..

Until you know what to put in dots, you should think of the whole programming idea a little more. Unless you’re naturally driven to computers, learning programming will be as delightful as chewing a printer paper otherwise.

This project-target will also be your motivator in the moments of weakness, where programming will just seem boring and plain dull. Think of something before you start. It should be simple, yet interesting. Examples of things worth tackling are to-do lists, note taking programs, simple calculators, and so on.

Attitude

If you’re impatient, even now, as we converse here and you can’t wait till I “finally” get to talk about “real programming topics”, programming will be a challenge for you. If you get frustrated often by solving problems or getting discouraged because you can’t get stuff to work, do know: it’s exactly what software is about. It’s about solving problems, and most of the time when we talk about “programming” we’re struggling, because things don’t work. When things start to work, you are happy for five minutes, and then move on to other broken stuff. Think of writing software as solving a puzzle and someone finding and putting more new pieces on your table.

(Photo by David Siglin via Unsplash)

Also set your expectation low for results you’ll get in the first several weeks. Very low. It will be as simple as printing something on the screen at most. And the more enthusiastic you are about large number of little things, and achieving big goals with small steps, the more successful you’ll be. But know that building a dynamic website isn’t very much different from printing something on the screen. Don’t get discouraged. Be patient.

How much to study

Gaining a new skill is about achieving a good ratio between studying and practicing. This ratio, if gotten wrong, will prohibit you from learning and burn your excitement. If I were to show you how this distribution should look like for people in the software field, I’d present it with the following table:

Study time	Practicing	Result
10%	90%	You’re a professional software engineer
50%	50%	You’re destined to success long-term
75%	25%	You’re jump-starting yourself
90%	10%	You’re a procrastinator

The way I see this table is pretty simple: if you keep only reading but don’t do exercises and don’t get your hands dirty, you won’t learn anything. If you start a new field, you need to read a lot to do basic stuff. And the more advanced you get, the less you actually need to read, and the more that you can devote to writing software. After some years of experience you’ll mostly concentrate on new stuff: updating your skills and knowledge.

Think of your interest in programming as a fire, and a study time as a fire wood and lighter fluid. When you start the fire, you pour a lot of this liquid in, just to see any effect. You’ll then add skinny wooden strips first. When the fire is started, you’ll throw in two big wooden blocks. When the fire is fully developed, you can just add a solid wooden block every now and then. Fire will keep going on.

How to study

Everyone is different, so you’ll have to adjust your study technique, but let me tell what works best for me. My suggestion to you is this: if you’ve just picked up programming, for every hour that you have for your study session, read a book for forty five minutes. Read slowly, with a high percentage of understanding. Books about computers and programming are very dense and packed with knowledge. It’s closer to math than it is to prose. Reading one page for several minutes is not uncommon. Moving back and forth between pages is necessary, because you’ll see constructs which are referenced in the future, or in the previous pages. Electronic books in the PDF form or on a e-book reader don’t work very well for me when I study. Paper still wins.

Paper has an extreme advantage, because you can take notes on the side, underline with a pencil, and do scratch-pad calculations. But the biggest plus of paper is that it isn’t distracting. I’m highly confident you’ll be more productive reading a paper book, since there’s no way to get an e-mail here, no notifications, no instant messaging.

So try to study completely offline, without a computer. Think of it as a “dry run” of your skill.

Now as you read, try to “compile” programs and calculations in your head. Think of what the result should be. Try to stop your eyes on calculations, and prevent from seeing the result. Derive the result based on your knowledge. Guess, if necessary. Treat these little puzzles as your personal challenges. A test to yourself which you’re taking because you want it, not because someone made you. I could quote books on learning here, but the general principle is: to engrain knowledge in you, there must be some pain, some amount of friction for your muscles and your brain. This effort is a proof you work correctly on your programming imagination, your understanding and analytical skills. Taking shortcuts, skipping exercises, not answering questions books’ authors often ask - is kidding yourself and wasting time.

The number of pages you can go in a dry-run mode, without a computer, varies on a book. For introductory material it can be ten to thirty pages. Leave yourself time to run through the exercises on the computer, but I suggest you attack the longest possible chunk of content you can tackle.

So imagine that your very first programming book is on your desk. You just read twenty pages of it. After these several pages your brain got overloaded with how things are. You’ll realize that two or three last pages you’ve read were too much, or that you were no longer able to calculate and predict expected results. That’s where you should sit in front of the computer.

(Photo by Andrew Neel via Unsplash)

Fire up the editor, your programming environment and in the book go back all the way to where you started. Glance at the page, but don’t read it. Try to recall what you’ve read from this page and start typing in code examples in your editor and running through it.

I said typing and not copy and pasting. This is intentional. It’s a well known fact that re-typing by hand is much better, because you’re actually involving your muscles into building stuff that way. This is very similar method to what copywriters use for practicing writing. To these days they study great ad writers by retyping their ads. By hand . For programming it’s exactly the same. Keep retyping programming examples with your hands. This will familiarize you with handling mistakes as well, since you’ll make typos and be faced with finding and fixing them. It’s fine - it’s also a big part of the learning process.

Crystalizing

At this point I think you see the pattern. All these things are here to stimulate your brain to recall what learn. So invent your own exercises: if the book shows a number “7” somewhere, maybe throw “11” there instead and see what happens. Play and have fun with it. These little silly steps are instrumental, in my opinion. Somehow your brain starts to be in control when you inject some of your own stuff, instead of just copy and pasting things from the book author.

The method that I show here makes you to go through the book twice: first when dry-reading, and second time, with computer, when you see things work. This is on purpose. And this is quite likely going to take less time. Reading one page and immediately retyping this page into the interpreter in my opinion is learning on the surface. I don’t believe you can really learn effectively that way.

There’ll be a point where you’ll see how things discussed in a book tie to your idea. Variables are indexes in your to-do app. Arrays are lists of tasks. Suddenly you’ll start understanding how certain pieces can be used for your idea. This is the time to start writing your software product. Start simple, maybe even trivial. And the more you learn, the more you can add to your program. Maybe after the whole book you’ll have enough skill to actually write everything what you wanted? I suspect so. This is where the mentor can be very helpful. You’d present your knowledge to him, and he’d tell you which of the new things you’ve mastered should be used in your idea. And later, once you have a prototype, you could show him what you have and get criticized.

That’s all. It’s read, write, repeat loop from now on. If you’ve tried this self-study approach, I’d like to hear from you and learn what the result was.

You may also like: “How much engineer should invest in career growth”, “Reading 101 for software engineer”, “Why you should start programming on UNIX”.