I started learning to code at 11 by reprogramming the computer game Nibbles? to make it harder.
These days, I get to teach people to program at Flatiron School, but I?m personally self-taught?I?ve been teaching myself teaching myself how to code since fifth grade. Along the way, I?ve found there?s no fairy dust to sprinkle on your code that will suddenly make learning easier. Learning to code can be really difficult. And most of the time, it takes some trying, failing, adjusting, and retrying to understand how you learn, how you work?and what you even need to know.
When I first started out, I knew I would have to put in the hours to get better, but there are a few things I didn?t even know were important that I wish I had known earlier. Some of them, I was fortunate to have tried; others I kind of had to learn the hard way.
Here are ten important lessons on programming and learning that I wish I had known from the start:
1. Learning how to work with other developers is essential.
When you?re teaching yourself, it?s tempting to measure how much you know by how much you can accomplish in a certain amount of time. I wish I knew that my own personal velocity wasn?t as important as my ability to work with others. I?d think, ?I got from point A to point Z in a week. Next time, I want to cut that in half,? when I should have been thinking, ?How do I get from A to F, while someone else gets from F to M, and another person is going from M to R.? Because this is how programming actually happens in the real world.
When you?re self-taught you have to spend a lot of time working alone, but it is absolutely critical that you learn how to work with other developers. It?s not just about communicating, it is also about dividing a project up so you don?t step on each other?s toes ? so you aren?t overriding anyone or breaking anything. Even if you?re a new developer, becoming good at working on your part without breaking other peoples? parts can make a huge difference in how far you?ll go as a programmer.
2. Knowing how something works isn?t the same as knowing how to use it.
There are a lot of architectures and patterns in programming. When you start teaching yourself, you likely have one of two options: (1) you can ignore them or (2) you can use them without necessarily knowing how they work or why they exist. For example, if you never feel the pain that object orientation addresses then you can use object-oriented code with no understanding of why it?s better, or you ignore object-oriented code entirely and write everything procedurally.
I didn?t do a good job as a beginner of understanding why certain patterns and architectures existed. I either ignored a pattern because I didn?t understand it or I used it blindly before?finally?everything eventually clicked. I should have looked for that ?click? moment earlier, and spent more time learning how and why things are built as opposed to just how to use them.
This is why, at Flatiron School, we break a concept down into its parts in order to help students understand how it works. To understand how an engine works you have to start with pistons. Similarly, before we explain a Ruby wrapper around a database, we explain the database without a Ruby wrapper. You should try to go one layer deeper into the most important concepts. In cases when this isn?t as useful or efficient, you have to make really conscious decisions about how deep to go, and that does take some experience.
3. Never, ever be afraid to put yourself out there.
Always put yourself out there. Talk to the programmers you admire. Even the super famous ones can be surprisingly accessible. As I taught myself to code, I?d go to conferences and stop my favorite programmers in the hall, or I?d write a blog post I was proud of and email it to them. Most of the time, they were incredibly generous. They?d help me promote the article, and I?d get really valuable feedback.
A lot of beginners are afraid to just reach out to great programmers, but they shouldn?t be. In my experience, almost everyone I contacted was supportive. And because I reached out, programmers I really admired offered to have lunch with me and even tweeted about my blog posts. Every piece of positive, constructive feedback I received made the times I had to hear something hard, or nothing at all, absolutely worth it.
4. Try to be your heroes.
Always mimic programmers you look up to. I remember thinking, ?I want to write code like this person ? oh, they tried writing a book? I?ll try writing a book. They wrote a library? I?ll try writing a library. They have a blog? I?ll have a blog.? I would imitate the successful programmers doing what I wanted to do in every way. None of the libraries I wrote ever took off. None of the books I wrote ever took off. None of the blogs I wrote ever took off. But going through the motions taught me what it was to be a professional programmer ? and all the stuff that goes with it.
5. Read the books, even if you don?t understand them.
When I was first learning, there were probably only five Ruby books in existence, and I had read them all. I got the chance to talk about them with a programmer I admired, and, afterwards, he told me he really appreciated how much I?d read.
His compliment made me realize that if you?re going to be a part of the conversation and the community, you have to try to know what you?re talking about. Even if you don?t understand what you?re reading, just do it. You will at the very least learn about the seminal authors in your craft, and start learning a common cultural language. I?d recommend starting here:
- Learn to Program by Chris Pine is a good book for people who haven?t programmed in any language
- Programming Ruby: The Pragmatic Programmers? Guide by Chad Fowler
- Agile Development with Rails by David Heinemeier Hansson
- Weaving the Web by Tim Berners-Lee is a good source history and context for what we?re doing today
6. How your code looks absolutely counts.
You are writing code for humans. How your code reads and looks is very important. Having very good indentation, not leaving comments or broken code, correctly naming your variables, having method names that match the languages style and syntax ? these are all critical. Beginners should pay attention to what their code looks like from the start.
7. It?s better to be proficient in one thing than an expert in nothing.
Nothing will ever replace the basics. Beginners often try to keep up with technology in the same way that advanced programmers do. But all the languages are the same when you?re a beginner; it shouldn?t be a priority to use all the newest, hottest tools when you?re starting out.
If you?re really good at one language and you can use it to build amazing things, no one is going to care what language you used to make them. Beginners shouldn?t care about the languages they?re using. They should care that their chosen language matches their goals, if they?re getting expertise and depth and in it ? and, of course, if they love using it.
8. Ruby might be a good place to start.
(7) is more important here. Specific languages don?t matter as much for beginners, but at Flatiron School, we have strong preference for starting out with Ruby before covering more languages like JavaScript. Matz, the programmer who created Ruby, built the language to make other programmers happy, and in my opinion, Ruby really does value your happiness. It embraces complexity, individuality, and multiple approaches to every project.
Dutch computer scientist Edsger Dijkstra once said, ?The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities,? which means that programming languages can actually change the way we think about problems. Thinking in Ruby is not myopic or restrictive. It?s a liberating, expressive way to think, and it?s no coincidence that it is also used to build awesome things. If I had to learn again, I?d still start with Ruby.
9. Learning to program doesn?t happen all at once.
Learning how to code isn?t going to be a constant, continuous accumulation of understanding. It?s going to be an S-curve, with troughs of not really getting it punctuated by massive increases in efficiency. You just have to be diligent and get through the troughs because this is going to keep happening throughout your career. Remind yourself that if you keep going, it?s going to make sense eventually.
10. Totally fall in love with it.
A lot of programmers, including myself, will tell you that you have to fall in love with coding to really learn it. Honestly, it?s difficult to get through the tough parts without loving it. But realize this: the surest thing that has ever moved humanity forward is a leverage on technology?science put to productive use. Learning to code will allow you to change the world. How could you not want to be a part of that? If you?re sitting alone reading code and losing heart, remember the opportunities that you?re unlocking by learning to code and how fantastic this moment in time is?let that get you through it.
Finally, always remember that the journey is the most important part. It?s impossible to just know things in programming. But coming to know them is the best way to really understand them ? and to better understand yourself as a programmer.
I?m a self-taught programmer, but you don?t have to be. If you?re interested in learning more about how we teach people to program at Flatiron School, you can read about our courses here.
If you liked this article, click the ? below so other people will see this here on Medium.
