This is a true story, about myself. How did a rational living being gradually descend into madness?

I was sitting in my office wearing a suit, with a vague startup idea floating in my head. Then, I decided to learn programming. I had once overheard a few people bragging about how they used a language called Ruby to easily automate office work. I thought, "Ha, Ruby." I went home and Googled Ruby. Fifteen seconds later, I randomly picked a Ruby tutorial and started learning.

A week later, I attended the first hacker meetup of my life. Everyone there was discussing Scala, Clojure, and Go. I thought, they really know a lot. I turned around and borrowed three O'Reilly books, reading about 50 pages of each.

What? You're asking why I didn't finish a single book? That's because every book starts out simple and easy to understand, and then starts making assumptions—assuming you have certain knowledge, assuming you know how to use certain tools—but I didn't know any of that, okay?

A friend of mine told me I should learn Emacs, and gave me his configuration file. I spent several more hours learning basic Lisp syntax so I could set up my own config file.

Then someone walked past me, saw me using Emacs, and asked, "Why are you still using Emacs (imagine the look on their face), don't you know Vim is better?" I thought, "Ha, Vim," and so I started memorizing Vim's endless keyboard shortcuts.

Engineers often discuss the topic of which text editor is the best. Moreover, engineers treat this as a religious war—the criteria for judgment aren't based on objective standards, but on historical divisions.

Back then, I believed that the faster I could type, the faster I could program. So I abandoned the traditional keyboard layout and switched to the programmer's essential Dvorak layout (just like the one below). Objectively speaking, for programmers, this is the most efficient keyboard layout.

Looking at the keyboard layout above, can you tell me how many letter keys, number keys, and special character keys have stayed in their original positions? The answer is in the single digits.

By the time I could successfully boot Linux and type ten words per minute, I started learning Python through books and Udacity courses.

After seven months of arduous struggle, I landed my first software engineer job.

When the CTO interviewed me, I told him about all the tools I had learned and the fancy config files I was using. The CTO listened politely, nodding from time to time. After I finished boasting about my vast knowledge, he looked at me and said, "Actually, there are many ways to solve most problems, but only a tiny fraction of them are meaningful."

Four years ago, the company I was at decided to build their product with Ruby on Rails. None of the engineers had any objections to the choice of language, and to this day, much of their original code is still running. All the engineers use MacBooks, not only because MacBooks are reliable, but also because they are very similar to the Ubuntu Linux servers used in their product. The engineers here don't argue over whether Vim or Emacs is better—everyone uses RubyMine, a powerful integrated development environment with excellent default configurations. Every engineer here uses exactly the same tools, which means anyone can pick any seat and immediately start pair programming with the colleague to their left or right, without worrying about environment setup. Using identical configurations greatly facilitates collaboration between two developers.

Even though I didn't know Ruby on Rails, the company thought I was qualified for the job. Because I knew Python and Django, and had won a hackathon, the company felt that was enough to demonstrate my abilities.

The first few weeks were tough. The difficulty came not only from joining a new team, using a new language, a new framework, and a new codebase, but also because I realized the people around me were learning programming with a self-abusive attitude.

I spent months sitting alone in libraries and coffee shops, blindly installing various tools via command line, debugging Linux drivers, and solving trivial problems like mismatched brackets. I dabbled in every online course I could think of and signed up for countless MOOCs. I think I didn't actually learn anything until, in one month's performance review, I moved up to fifth place. These experiences gave me the impression that programming is a battle you can never win. I began to understand how bleak the pasts of those seemingly normal programmers really were—they had been through so much and suppressed so much for so long. I have to say, learning programming is practically an antisocial activity.

On the first weekend after quitting my previous job, I uploaded this selfie. I got up early that day and put on a decent suit. I wore the suit to remind myself: I'm a person who's about to learn programming. The Facebook caption read, "My new office—the dining table. I live a 8-to-6 life every day, only resting when I absolutely must." In life, I talked like a programmer and thought like one. By now, I've gotten used to that word.

My colleagues almost never encounter syntax errors because their IDE handles that problem for them. And when they do run into an error message, if they can't solve it within a few minutes, they'll send an instant message to another colleague asking for help. They'll freely drop by someone's desk and start pair programming. The programmers here aren't overly egotistical, nor do they consider themselves elites. They also don't view programming as a painful endeavor. It's just constructive conversation between adult friends.

The tools used by members of a team are highly consistent. In passion projects and hackathons, developers might use newer JavaScript frameworks like Angular.js. But in a real team, members focus their energy on improving the product with existing technologies. From that perspective, they are conservative.

You'll see something similar at ThoughtBot. At ThoughtBot, everyone sticks to a small, efficient set of tools (Rails, Vim, Postgres, and Redis). Because the toolset is small, engineers can easily become experts in that domain, and because everyone uses the same toolset, interoperability between each other becomes easy.

So the real question is: if efficient teams are most productive when using a small, fixed set of tools, then perhaps it's also best for people learning programming to use a small, fixed set of tools. Those online programming courses and coding bootcamps clearly think so.

But as an individual, there are so many tools to choose from that it's truly hard to decide which way to go. I know this because I've been through it. A good programmer's skill set can be represented by a T-shape—knowing a little about many areas, but truly mastering only a few. However, over years of accumulation, the T-shape will gradually turn into an underline shape.

I've met many people learning programming who, from the very start, want to learn everything and master everything. In the end, they all fail and give up on their dream of becoming a programmer. I don't want this to happen to you too.

You Need to Focus on Fewer Things

Without further ado, here are some big mistakes that beginners tend to make:

• Switching from one language to another, jumping from one framework to the next, or fooling yourself into thinking you can master every language or framework.
• Using niche tools to build your development environment instead of choosing traditional, reliable tools.
• Learning tools like Docker and Famo.us simply because they're new and trendy, even though you haven't even mastered more fundamental technologies yet.

If I had to sum up my advice in a single word, I'd say: focus.

Let me ask you—would you use the word "focus" to describe your programming study plan? If you think your plan is focused enough, fine. You can stop reading now and go back to your plan to start learning, because I don't want to say anything that might cause you to lose focus.

If your plan isn't focused enough, you're in luck too—do what I say and you'll be able to focus, but it'll take a few minutes of your time to make a few tough decisions. Wait, don't leave!

Okay, you're still here. Here are the tough decisions you need to make.

1. Choose one type of software: it can be a web app, mobile app, game, or embedded systems. I recommend web apps because they're flexible. There are plenty of learning resources, and countless job opportunities. If your interest isn't in web apps, close this page, type "getting started in _____ development" in the Google search box, and click through the results one by one.
2. Choose one programming language: JavaScript, Ruby, or Python. Each language has its strengths, and each has a corresponding tool for building web apps (Node.js, Rails, and Django, respectively). Unless you clearly know which language you should learn, I recommend JavaScript because it's the most widely used.
3. Choose one online course. Here are some options: if you're interested in JavaScript, check out FreeCodeCamp.com or NodeSchool.io; if you're interested in Ruby, check out TheOdinProject.com or TeamTreehouse.com; if you're interested in Python, check out Udacity.com. Trust the wisdom of the instructors who designed these courses, complete the course in the suggested order, and don't skip around.
4. Buy a new or used MacBook, or install Ubuntu Linux on your current computer. As for any other tools you might need, just install whatever the online course recommends.

Once you've made these decisions, the rest of the road is simple. Just stay level-headed and don't get distracted by the new tools around you. Spend a little time on your online course every day, seven days a week—even just half an hour at a time. Trust the decisions you make today. Finally, remember: with patience, any capable person can become an outstanding coder—and that absolutely includes you.

Source: http://code.csdn.net/news/2822796