Learning to Learn as a New Coder

How do you get better as a new coder? The desire and the motivation to do so are prerequisites, but once you have these things (and even if you have a lot of them), it’s hard to know where to go. Do you spend your time reading docs or source code? Should you freelance to increase your exposure or master as many coding challenges as possible? What really makes a difference?

This is a question I struggled with for a long time. I really wanted to be better, but I didn’t exactly know how. Over time, you get better naturally (assuming you code on a regular basis), but what I’m talking about here is maximizing the return on effort.

So, without any further ado, here are 5 things that fundamentally pushed my understanding of software as a discipline, and that I continue to use on a daily basis.

5. What Are You Trying to Learn?

This is a simple one you should ask yourself on a regular basis: what’s your focus? Do you want to be a specialist or a generalist? Is there a “type” of developer you want to be? Answering these questions will help you understand how to split your effort.

Some good advice I received on the subject is that the best developers are T-Shaped. They have the breadth to understand how modern software engineering functions work together, how the code they write will be used by and impact other teams, etc., and then they have a LOT of depth in one specific area.

This is the model I subscribe to when it comes to my own learning. I love to learn about things that are tangential to my work, but I always prioritize and seek depth. The model you believe in might be different, but the takeaway here is to understand what your goals are and focus on them.

4. Read Other People’s Code

Reading code is often recommended, but rarely explained. Should you try to read the source code for Docker or some other massive open source project? No, probably not. It will be nebulous and intimidating, and unless you spend days on the endeavor (or are already quite gifted), chances are you won’t have the context to learn much beyond coding style.

But you should definitely try to read other people’s code when it relates to what you’re working on. If you’re implementing a new feature at work and are having trouble with how Go’s HTTP handler interacts with Angular, read the Go source code. You’ll learn how the tools you use actually work, discover new patterns, and learn to write code idiomatically.

Another great opportunity to read code is where your code touches other’s in a code base. Using a service someone else wrote? Read the service. What edge cases do they handle for, that you should be thinking about as well?

One last thing worth mentioning here is that reading code really means reading and playing with code. You have to get it up and running to build a mental model of how data flows through the application, which is the real end goal here.

3. Remember Your ABC’s: Always Be Coding

This one is sort of obvious, but in case it isn’t clear, this is the meat of the learning process. Everything else you do (including #2 and #1) support this. If you aren’t actually coding you’ll only go so far before what you’re trying to learn is too far ahead of the mental models you hold in your head.

There are a myriad of ways to do this. Build side projects, go to hackathons, work on open source, etc. It doesn’t really matter what, but (assuming you actually like coding) code as much as possible. In fact, code all the time. Code on anything, but just Always Be Coding.

PS. I got this one here.

2. Watch Talks

Now we’re getting up to some heavy hitters. Watching talks has been huge in my education as a coder, and it’s what propelled me from a mediocre developer to a competent one. Talks are amazing. They’re free education. They’re bite sized. And best of all, they’re self contained.

Pretty much every technology, tool, and subject matter area out there has it’s own conference and meetups. Each year the community is going to push out a number of solid talks ranging from beginner “why do we use this and how does it work” to advanced “best practices using X”. So when you want to learn something new (“Hrm, maybe I should use React on my next side project”) the first thing you should do is watch a well thought out introductory talk on the subject. I tend to prefer something from the guys who actually wrote it. You’ll get a high level but comprehensive overview in ~45 minutes.

Then, if you start to use the technology in earnest, you work your way up the talk chain of complexity. The best is when you’re stuck on something and you find a talk that addresses that problem space directly. But even if the talk has nothing to do with what you’re working on, you’ll be amazed at how much you learn about that technology (tips, tricks, pitfalls and patterns) by watching even tangential talks. Best of all, you learn what you don’t know, and that you might want to, by seeing other devs using the technology and sharing their experiences.

I could harp on this forever, but it’s really simple, watch a ton of talks. Watch 3–4 a week. You’ll learn more in an hour than in a day of googling.

Here’s the best list I’ve found, it’s a gold mine of knowledge: https://github.com/hellerve/programming-talks.

1. Follow Your Bliss

I asked my friend @caelestisca once for advice on how I should try to learn Go. She concluded her massive list of practical advice with “As far as one [thing] being the MOST important, I am going to sound so hippie here, but follow your bliss, whatever gets your happy curious, follow it…”. I think this is some of the best advice on software (and learning) I’ve received. Let’s take a minute to think about it.

If you’re naturally curious about something, it means what you’re learning is on the edge of what you already know. This is huge — since you understand the importance of the subject matter, you can logically connect it to your existing body of knowledge much easier than something that you think you should learn but don’t yet have a “feeling” for. Your mind and body are in sync, and the return on effort is huge because the speed at which you move through the material is increased significantly.

So when your curiosity gets piqued, explore it aggressively. Follow it wherever it takes you. You almost certainly will end up in a rabbit hole, but it’ll have been a wild ride and you’ll be amazed at how much you learned.

Lastly, the converse is also true: If you get stuck or are starting to lose passion — chances are you aren’t curious enough about what you’re working on. Step back, clear your mind, and follow your bliss.

Happy coding.

Originally published at kylechadha.com.