You don’t tend to see vaguely patronizing, unflinchingly desperate requests like that unless you sit on some kind of goldmine. They approach us the way one might approach a mischevious toddler holding a winning lottery ticket. And, of course, anyone would expect that with wildly disproportionate supply and demand.
But, for us, this transcends just writing the code and oozes into learning about it. Like baseball teams playing the long game, companies would rather grow their own talent than shell out for high-priced free agents. And so learning about software might just prove more of a growth industry than writing it.
Look at wildly successful industry player Pluralsight. It has built a benevolent commercial empire on the simple promise of democratized learning about technical pursuits. Then you have a host of fast followers, an army of boot camp providers, and endless how-to blogs. Sometimes it seem as though a gigantic wave of pressure pushes us all toward writing a bit of code.
The Learning Tools in Your Tool Belt
Let’s say that you’re convinced. You see the money to be made, or you simply feel drawn to the profession. You want to get involved, but don’t quite know where to start. What sorts of learning can developers avail themselves of?
While I won’t call this an exhaustive list, I can offer some general categories of learning. First, consider theoretical, passive learning. You crack open some book called, “Principles of Modern Web Development” and get to reading. Second, you have classroom-style learning. An instructor leads your lessons, curates information, and engages you in Q&A. And, third, you have hands on learning. With this kind of learning, you put actual concepts into practice.
Understand that I do not consider these mutually exclusive by any means. Any serious learning plan worth its salt is going to incorporate elements of all of these (and probably other form categories that escape me at the moment). But understanding the flavors will inform the rest of this post.
Those Hard to Reach Learning Places
When it comes to retention, hands-on and interactive tend to produce better results. For this reason, comparably asynchronous providers like the aforementioned Pluralsight incorporate techniques like labs and quizzes. They elevate the game from passive consumption to application. For another example, consider homework and class projects from your youth.
Unfortunately, though, it’s harder to put your hands on some kinds of learning than others. For instance, if you want to develop a deep, ingrained understanding of the composition of Neptune’s core, you probably won’t have much luck. When practical experience proves hard to access, we proceed more indirectly.
This applies heavily to the space of professional software development. When it comes to language constructs or implementing frameworks, we can engage the three modes of learning in private settings. But when it comes to things like avoiding technical debt, maintaining software, and large-scale collaboration, that becomes harder. You can often only practice software engineering practices by doing them on the job.
The Problems with On-The-Job Learning
But acquiring practice by learning on the job presents some genuine potential problems. I won’t offer pedantry about this, favoring an example instead. Would you want your surgeon logging her first open-heart surgery on you? Freedom to make and learn from mistakes compromises a critical component of learning. Learning on the job, you don’t have this even as you need it most.
And while most of us don’t write code in environments as mission critical as open-heart surgery, we don’t operate without consequences. When we first slip up and create unmaintainable code or break a build we’re usually costing a client or an employer money — sometimes a lot of it. Our learning sets impedes important progress.
Of course, in this context, the important progress also impedes our learning. When you know that breaking the build or checking in the wrong sort of code costs money, you tend to hesitate. And, as part of that hesitation, you tend to call in other, more experienced people. You call them in to guide you, but let’s be honest — you feel a profound sense of relief when they take over and absolve you of a potentially important mistake.
You can learn this way, but not quickly. With significantly reduced hands-on component, you’re back to the teacher-student paradigm, or even the passive consumption paradigm.
In the industry, we have a paradox. The longest-ranging, hardest to learn techniques lend themselves least to the most effective kind of learning.
Getting Some Hands on Experience
At this point, let me be clear. Passive and instructor-led learning both occupy a critical seat in your overall learning path. I make courses for Pluralsight, offer lessons through other media, and go to companies to teach things to their developers. But there’s no substitute for hands on learning. You need to take the first two forms and let them drive your hands-on experience. Watch a beginner HTML course, read a beginner HTML book, sit in a beginner HTML course… and then go build a website!
That will work well for you as you learn to code. But you’ll start to struggle when you translate that to what it means to be a professional software developer/programmer/engineer. The lessons get harder when intense collaboration, long project scope, deadlines, and massive codebase size creep in. You lurch into waters where it’s easy to get hands experience only on the job, as you go.
For this reason, I encourage you to define one or more of your own capstone projects. Get heavily involved in open source or spend your spare, learning time building a progressively larger product of some kind. You can incorporate more targeted forms of learning into this overarching effort. Take that beginner HTML course and build a site. Use that JavaScrpit course to make it interactive. Take that big data course and have your site present some amazing insights. You get the idea.
As you go and as you incorporate more and more, you’ll start to learn macro-lessons as well. While building your own product, you’ll learn how ignoring code maintainability makes your life hard later. If you try to sell it, you’ll learn that obsessing myopically over details doesn’t pay the bills. On your own time, absorbing your own risk, you’ll become a pro.
When it comes to learning our craft, the single best piece of advice I can offer you is to build toward something, and to let that something drive your more tactical forms of learning.