Steve Klabnik’s 9 Tips for Programming Beginners
This article is based on the Codementor Hour of Code Office Hour hosted by Steve Klabnik, who is known for being an active open source contributor and has 1900+ contributions in 2014 alone. The office hour was an open Q&A where the participants could ask Steve anything, and here are 9 important words of advice Steve has brought up while he answered beginner questions.
#1: Always Stick to One Task at a Time
Whenever I’m trying to learn how to do new stuff, or if I have a project where I’d have to figure out how to do a lot of things, I try to just pick a particular task and attack that.
Often times in programming, you’ll hold a lot of context in your head depending on what you’re working on, so it’s best to focus on one thing and try to get it done. There are a lot of ways you can tackle a single problem, so a lot of things will depend on what solution you end up choosing. For example, if you’re trying to build a CMS website that build websites where it will deploy things to each user, you could organize a site where it’s a big giant app where everyone has a specific subdomain, or you can make it so that each individual subdomain is a separate instance of your app with configuration changes. There are pros and cons to each approach, so this is where the judgment comes in and why some people say programming is an art, since you constantly have to weigh different tradeoffs.
#2: Different People Find Different Things Easy
I know people who don’t do web programming because they think operating systems programming is easier. According to their logic, they only have to write assembly code for one computer and it will do what they tell it to do. Web developers have to wrap up the markup language, programming language, and styling language before the application is sent across the network to run on a totally different computer running on a different operating system—which is very hard.
Obviously, we all have different strengths and weaknesses, so I try to shy away from telling beginners things will be impossible for them because you never know whenever you run across someone who really does have intuition for, say, CMSs. It’s possible, right? We’re all different in so many ways.
#3: Your Work Can Be Only 80% Complete
One of the things about engineering is that building a commuter vehicle and a race car are two very different things, so you can get away with things in a commuter car that you wouldn’t put in a race car, and vice versa. It’s important to decide which edge cases you want to handle, but a lot of times it’s perfectly fine to just do 80% of the work, in which the other 20% is stuff people don’t really use so it’s not that important to get those things 100% right. You can track down the last 1% of bugs in your project, but you will spend a lot of time doing that.
#4: Learn How to Google
A lot of beginners under-appreciate the degree which googling things is a part of a programmer’s job. Sometimes my job is more about knowing how to search for something than it is actually programming.
#5: Don’t Be Afraid to Ask for Help or to Help People Back
Programming is actually a really social activity. I would not be as good of a programmer as I am now if I didn’t have their help—each of my friends are good at certain areas so whenever I have a problem, I know which friend to ask. I also help them out in return when they have a problem. This is really the only way to get things done.
#6: Technology Always Changes
Therefore, the language of technology also changes. However, you’ll eventually accumulate the knowledge of all those things.
I like to think of myself as a programmer first and a language-ist second, since there will be a day when all of the programming languages we use right now won’t be used anymore. For example, if I started in the 80s, I would be using certain forms of assembly code that are all gone now for the most part. This will happen to all technologies no matter how good or bad. There will be a day when no one uses Rails anymore.
That said, there is a broad paradigm that programming languages fall into, and there’s sort of a family tree for programming languages. So, if you know a language that is similar to another one, it can be very easy to pick that language up. For example—both Python and Ruby people hate me for saying this—Python and Ruby are almost the same programming language. It’s true that, culturally, there are huge differences. However, other than that, they’re almost the exact same thing, so learning one when you know the other is very easy.
However, if you go from a dynamic, object-oriented programming language such as Pearl or Ruby, and you switch to a statically-typed programming language like Haskell, it will be a very difficult jump. This is because the languages are in totally different branches on the programming family tree. However, you’ll also learn a lot if you choose to make that leap. All in all, some languages are easy to pick up if you stay within a paradigm, and some languages are harder if you jump paradigms.
In terms of actually learning new languages, what I usually do is have a project for every programming language. It’s a text adventure game where you tell the player to go north, go east, attack goblin, etc. I try to do that when I learn programming languages, because if I have a program built in another language, I’ll know I can do it, but since I’d want to explore some things that are specific to the programming language, every program will look a little different. So, I learn by trying to write some code and reading some tutorial. It’s mostly just putting in a lot of time to learn another skill, and the more you practice, the better you will get.
#7: It’s Okay Not to Contribute to Open Source
But if you do want to contribute, the way I’ve found how to do so is work on something you’ve actually used. In order to motivate yourself, you need a stronger and more precise goal than a broad desire to contribute.
Even when shaving your goal down to just contributing to Rails will help you take a significant step towards accomplishing your goal. The more you can articulate what you want to accomplish, the more likely you are going to get it done. I’ve always had a love for documentation and that’s definitely an area where almost every project needs help with, but a lot of people find writing docs boring so even though I think that might be an avenue to get started, it’s not for everyone.
In my example, I started wanting to contribute to Rails, so what I did was I went and read through all the open issues at the time. That helped me understand what a lot of the pain points and problems were. I picked one of the issues that seemed pretty easy to fix and ended up spending a couple of days on it before I did so. Afterwards, I submitted my fix and it got accepted, which made me really excited, so I picked a second issue and it took me only 2 days to fix it. So, it’s never harder than the first time. The first couple of patches always feel like a huge, massive effort, but the more you do it, the more familiar you will get with the tools and Github, and things become easier. By default it’s always harder for new people to contribute than for existing contributors.
#8: Programmers Fail All the Time
In Test-Driven Development, you often see things like: red, red, red, green, red, red, red, green—which means most of the time, we’re failing. If all of our programs were feature complete and we didn’t have any bugs, programming wouldn’t even be a thing. Just the fact that we are programming means we either don’t have many features yet, or our software has problems.
So, in some ways, you’re always failing as a programmer. This is a weird mindset to get into, but you just have to be okay with things not being perfect and not working; it’s literally our job.
#9: Don’t Give Up
As beginners to programming, you often have no connection to what is difficult and what is easy, so you may ask me what I think of something while thinking the task to be very trivial, and I will tell you it is very difficult instead. In contrast, you may think something is very difficult and ask me what I think, and I will tell you that it’s really easy.
I think this comic from XKCD perfectly illustrates the issue:
As you can see, even though two functions may seem similar, the order of magnitude in their difficulty is way different. It can definitely be easy to bite off more than you can chew, but the cool thing about doing that is it means you’re going to learn a lot. I personally really like hard projects because of this. As long as you can be not frustrated by how long it is taking you to finish a project, the harder the project is, the more you have to learn. What’s more, it feels really good once you’ve accomplished your project.
For example, when I took over a Ruby project called Shoes, it took me six months to even figure out how to compile it. I was pretty much banging my head on the wall day after day for months, but when I finally fixed the project, it was the best feeling I ever had.
That comes in with learning, too, where things are extremely hard at the beginning and eventually they get easier because you worked at them for a long time.
With over 200 repositories on GitHub, Steve Klabnik is known for his contribution to open source projects. He is currently ranked #36 on the all-time Rails Contributors list, and has written the guide Rust for Rubyists. As of June 2014, Steve has joined Mozilla to work on the official Rust Documentation.
