A presentation I gave at the Vienna.rb Meetup in February 2014:
You probably know the feeling. You’re writing a piece of code, and just by looking at it, you know it could be better – but you don’t know how. You have that feeling that the right solution is just around the corner, if only you could reach it… but you don’t, and you have to live with whatever you’ve got. You have to live with the knowledge you were not good enough to write better code.
This happens especially if you’ve just left the beginner stage behind, and are slowly advancing through the intermediate stage. Many plateaus await you, frustrating you in your quest for progress. Some days, it seems like you’ve hit your limits, the very best you can do, and that you cannot go any further.
But there are things you can do to help yourself. I’d like to tell you about a few.
Similar to training a muscle, your skills won’t grow when you keep repeating the same things over and over. So it is important that you expose yourself to new concepts and ideas. Often, you’ll feel out of your element, and like the biggest n00b on the planet. And that’s ok. If it’s not hard, if it doesn’t suck, you probably won’t learn much from it. Become comfortable with your Discomfort Zone.
Expose yourself to new ideas. Read about something you do not yet quite understand. Listen to podcasts about topics you do not know much about. Watch screencasts about things you’ve only dreamed of.
Ask other people about books, blogs, screencasts, or podcasts they recommend. But also always ask them why they recommend them. What is right for them may not be right for you.
I like Ruby Rogues, Avdi Grimm’s Ruby Tapas, Real Talk, Vimcasts, Build an App with Cory Haines and Gary Bernhardt’s Destroy All Software. Each one of these has exposed me to new ideas, or a new way of doing things that I hadn’t know of or considered before.
But even more important, do new stuff. Just collecting information in your head is not enough, you also have to implement it. Want to learn functional programming? Go learn Haskell. Want to work in a statically typed language? Learn Scala. Always wanted to know more about the actor model? Learn Erlang.
Here’s the thing: After that initial explosion of cognitive growth, they noticed a decline in both cortical thickness, as well as the amount of glucose used during that task. However, they remained just as good at Tetris; their skill did not decrease. The brain scans showed less brain activity during the game-playing, instead of more, as in the previous days. Why the drop? Their brains got more efficient. Once their brain figured out how to play Tetris, and got really good at it, it got lazy. It didn’t need to work as hard in order to play the game well, so the cognitive energy and the glucose went somewhere else instead.
And then write programs in those languages. They don’t have to be things that will actually be put in production, but you should write non-trivial programs that do something useful (ie., anything but printing
You are functionally blind when you only have book knowledge.
Study the masters – and mastering
PeepCode’s Play by Play series shows how masters work on a given exercise, telling you about their thought process and explaining their decisions as they go along.
And, if you can, find a mentor, someone who can guide you, show you the way, and provide you with useful criticism that will let you grow.
Learn the classics
Languages and frameworks come and go, but the classics are forever.
You might call some of these things “computer science”, but many of the best programmers I know have no formal training in such. These things can be learned by anybody, many of them are learned best in a hands-on environment.
Investing your time learning things like networking, concurrency, regexes, or system programming will not go out of style in your lifetime.
Languages and frameworks are only tools, a means to an end. Understand why those tools exist, and why they work the way they do, and you will gain a deeper understanding of how things work.
Sites like Exercism.io or Code Wars present you with programming challenges in various languages that allow you to “exercise” in a very defined way. Exercism.io is especially great because its emphasis is on getting and giving feedback, forcing you to think and argue about your design decisions. This can be very enlightening even with apparently very simple exercises.
Using Katas to Improve Yourself is another possibility to train your programming abilities, while at the same time picking up a new language or framework.
The Ruby Rogues episode on coding exercises, quizzes and katas also contains useful information on that topic.
Mind your body
Go outside and get fresh air. Sleep more (about 7 hours seems to be the right amount for most people). Work out, even if it’s only 15 minutes every other day. And start meditating for 2 minutes each day. Doing these things will improve every area of your life, not just your programming.
Always remember that the biggest factor that determines your success is not intelligence, or talent. Grit, the perseverance and passion for long-term goals, and your attitude towards getting better are what determines your path ahead.
Something to meditate on:
One day a monk visited Master Wq, and inquired, “Master, how will my code be different when I have mastered Vim?”
Master Wq answered, “Before Vim: declare, define, process, print. After Vim: declare, define, process, print.”
Thanks to eclubb, Tekhne, augiedb, michael, newton10471, and markijbema of the RubyRouges Parley forum for suggestions and feedback.
Even though the post discusses mastery in the context of a business and startup founders, its lessons are easily applicable to mastery in general. ↩
A presentation I gave at the Vienna.rb Meetup in July 2013: