The Three Skills (Plus One) You Should Be Learning As A Developer
The Three Skills (Plus One) You Should Be Learning As A Developer
Being a career changer and a bootcamp grad, people often reach out to me with questions about my experience. Many times it’s people who are considering if they should get into tech, or perhaps they already decided they want to get into tech and want to know if the bootcamp route is right for them, while others already know they want to do a coding bootcamp and are trying to decide which bootcamp is right for them.
In all of those cases, I always try to help out; I’ve been helped by many people along my journey, and it’s the least I could do to pay it forward.
One question I get asked often by new and potential coders is which languages/frameworks should a new coder learn first and whether bootcamp X is better because it teaches technology Y.
My usual answer is that the specific language/framework a bootcamp teaches shouldn’t matter, that’s not the question you should be asking.
What should matter is that the bootcamp/course gives its students the tools they need to continue learning on their own. Worded a little differently; in a good bootcamp, you don’t learn a language, you learn how to learn.
Recently I got into this discussion with a friend of mine, and they asked me to clarify what it is that I meant by “learning to learn”; what are the actual skills needed to learn how to learn and how can someone new to programming learn those skills?
That started a whole discussion; I had never bothered to quantify what are the skills that help developers learn new technologies.
After some thought, I managed to narrow it down to three skills: learning how to read/understand error messages, learning how to Google things, and learning how to read/understand documentation. From my experience as a developer, I can say that I spend 90% of my workday doing one of those three things.
Each of these skills can be a blog post on its own,* but for now, I’ll summarize them as follows:
*In fact, I’m in the process of writing it up as a talk I can give at conferences or meetups, and if you are organizing one geared at people new to code and would like me to present, feel free to get in touch.
1. Reading error messages
This was one of the first lessons I had to learn when learning to code, and, in my opinion, what separates developers from the rest of society.
Not a helpful error message
Back in my “civilian life” error messages were scary, they were opaque, they felt like the computer was screaming at me in a foreign language and blaming me for something which it probably thought was my fault.
When I started learning how to code I naturally ran into many error messages, and that felt very discouraging; I felt like I must be doing something wrong.
Eventually it “clicked” for me that error messages are far from my enemies. When I encounter an error message as a developer, it’s the computer’s way of letting me know what’s wrong with my code; it’s how it provides clues on how to fix things.
As a developer, you will be working exclusively with broken code (if the code was working then who needs you?) reading and analyzing error messages is how you will go about fixing it.
A good bootcamp will encourage you to play around with the code, break things, and will celebrate error messages instead of showing you how to fix them.
2. How to Google stuff
As a developer, you will spend the majority of the time doing things you don’t know by heart. Google (or DuckDuckGo, Bing, etc.) will be your best friend.
Honestly, if you made it this far you’re doing pretty well.
For beginners, it can be hard to know what to Google for, especially in the beginning when you aren’t even sure what it is you’re trying to do, never mind verbalize it in a way that a search engine can understand.
Learning how to structure your query for best results is an art that comes with experience, but some rules will help you get started:
- Include the language you are using: if you are learning Ruby and have an array you want to sort, searching for “how to sort an array” will probably not be very helpful; when I just did it the first page of results contained only answers about how to do it in Java, Visual Basic, and JavaScript. Always start your query with the name of the language you are searching for (in our example, “ruby sort an array” will give you plenty of results that a Ruby programmer would actually find useful).
- Use well-defined keywords: this comes more with experience, but knowing which keywords represent the actual information you need will save you time filtering through unhelpful results. As a general rule, don’t include words that aren’t necessary; crafting the shortest query that contains all the keywords relevant to your search will help make sure that you get only the results you want.
- Know which results are more likely to be helpful: Again, this comes with experience, but some results are more likely to be useful than others. You will develop a taste for this with time, but in general, more recent results are less likely to be out of date, and an answer on Stack Overflow with a hundred upvotes is more likely to be helpful than a blog-post from a no-name author (which isn’t to say there aren’t great blog-posts by relatively unknown authors).
3. How to read technical documentation
Languages/frameworks have many features and functions, and unless you use a particular function on a semi-regular basis, it is unlikely that you will have the syntax memorized.
The documentation for most languages is usually the most comprehensive and concise reference for language features, saving you the trouble of memorizing hundreds of obscure language features.
For example, Ruby has about 20 different ways to iterate over an array. If you are trying to learn Ruby, you might think that you have to memorize all 20, but if your goal is to learn how to learn then all you have to remember is that you can find all of the ways of iterating over an array in the documentation on Ruby’s Enumerable module.
The problem for beginners is that the documentation can look dense and intimidating; the conciseness means that the page can look like a scary wall of jargon and technical terms and scary symbols, but with practice, you can learn the patterns and learn how to find the information you need. With time you will find that the official docs will become your go-to reference for simple syntax.
Plus one
Now you are probably wondering about the “plus one” in the title, that is one skill that is not exactly about self-learning, but it’s an essential skill to have if you want to be an effective learner.
The last skill is knowing when to step back and ask for help.
None of us ever did it on our own, the “self-taught developer” is a myth.
Surrounding yourself with a network of mentors and fellow learners, and knowing when/how to leverage it will save you time best spent actually learning new things. It will mean that you don’t have to spend hours banging your head against the keyboard over a simple typo that a second fresh pair of eyes would have caught in a minute (though we’ve all been there :)
In conclusion
In conclusion, learning to code is a big decision. Many factors are involved in what makes a good bootcamp or course. I hope that reading this post will give you an idea of which skills are important to focus on and which are just a passing fad.
Good luck!
Comments