07 Mar 2016, 06:41

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 any way (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.

PS. This list picks up where tutorials leave off. Tutorials are a great way for absolute beginners to learn, but there simply aren’t enough of them at more advanced levels to teach you what you need to be effective. Start with tutorials, but once you’ve grasped the basic concepts use the below.

#5 What You Are 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 specific “type” of coder you want to be? Answering these questions will help you understand how to split your effort. Your time is a limited resource, be conscious of how you spend it.

The best 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

This is recommended everywhere – it’s almost the classic cop out advice when people don’t know what else to say, but there’s no denying its effectiveness.

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. Updating something in a controller? Explore how the router and handlers work. Using someone else’s service? 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 actually understand how data flows through the application. The end goal should be a functioning mental model, and that’s hard to achieve by reading alone.

#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’re in some theoretical land, and 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

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

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 (at least) 10-15 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 know 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.

18 Dec 2015, 09:44

I went for a bike ride yesterday...

I’m in LA visiting my sister and sans car right now. I was planning to meet my buddy Yu Jiang for lunch and had initially planned to ride my sister’s bike the six or so miles. But as I was getting ready to actually leave the adult me stepped in and decreed it’s voice of reason: “Just uber it. It’s so much easier.” It had been a really long time since I rode a bike. The tires were flat (I’d have to pump them at a gas station), LA drivers are terrible, and well, my sister’s bike has a bunch of neon green and pink skulls on it. Once the idea of taking an uber germinated in my head, it grew rapidly as the only common sense thing to do. I had just about convinced myself to take one, when at the last second I felt compelled to try the bike. It would be a bit scarier, but it’d probably be nice, riding along the bike path from Playa del Rey to Venice.

So I set off. It was a nice day. Pleasant. At first I didn’t think too much of it. But then it began to dawn on me. How picturesque the bike path is along the beach. How calming the ocean and the palm trees and the sand and the gentle ticking of the bike chain are. How much I love riding bikes… feeling the breeze of movement cool you down in equal parts as your heart rate rises. How I had felt this feeling a thousand times in my childhood – riding around my neighborhood, on the way to summer school, and to my high school sweetheart’s house, long before I had a car. And I realized I hadn’t felt this feeling in a long, long time. When the scenery moves at a snail’s pace past you, it’s not a thing going by, but a thing that you are part of.

And it all started to break down. I love riding bikes. I love being outdoors. I love watching the wind ripple through the palm trees and the sound of the birds above me. I love the simplicity and the familiarity, the freedom. I love the aimless moments when I’m not doing anything in particular. Not endlessly thinking, planning, problem solving, yearning, searching … just being. These are the days that make life worth living. A day like this makes the thousand before it worthwhile. A day like this gives meaning to life, gives it happiness. It creates a sense of peace and tranquility that can not be bought or faked.

And it reminded me that all that I do, I do so that I can have days like this. Days where my mind is still. So much of my time is spent working towards goals and attaining things – but hard work needs to be hard work for a purpose. A job should be more than the salary it’s attached to… money should be worth more than the things it buys.

After all, you can have all those things, but unless they bring you closer to days like this, they really are pointless. They are not goals in and of themselves. Sometimes I forget that. And if I think hard about it, I don’t need much to be happy. Just a bike and a free day.