Learning to code, whether done independently or with the help of someone, can be a heck of a journey. Much has been written about the early bouts of confusion, impostor syndrome and debugging purgatory that often turn the outwardly ambitious into the seemingly masochistic. No doubt, the above phenomena are quite real and to varying degrees, they can represent useful and edifying phases in the growth of a developer. Certainly, being “stuck”, making mistakes, rooting out answers and good old-fashioned hard work have their place, but often in learning to program, we allow ourselves to wallow too long, simply accepting extended “frustration” or repeating bad habits longer than we should.
Particularly, I’d like to highlight some of the habits I’ve now internalized, which, if I had acquired earlier, would no doubt have saved me loads of time and gray hairs.
1. Look It Up. Everytime.
My suggested habit for reconciling the desire to move forward, with the nagging feeling that we should be digging deeper as we go, is to Look It Up, right from the start. Now, when I say look it up, I don’t mean you necessarily launch yourself into full exploration of the new term, but rather you engage in a quick triage.
From there, you can decide if it’s:
1) Something simple and relevant that you can fully digest in a few minutes. If so, do it. It may not be essential to your current task, but over time it’ll help you build a much broader and stronger foundation.
2) Something important, but not imminently essential and too complex to get into now. If this is the case, try to “get” the one-sentence definition and jot it down on a running list to revisit in depth when your schedule allows.
Or, 3) Something that just isn’t relevant in the short or mid-term. In this case, you can simply return to the original task.
By instituting the above habit, you’ll find that you can both stay on task and learn more as you go, all while getting a better understanding of the ever-growing programming landscape.
People fear asking what they perceive to be stupid questions, or more precisely, newbie questions. This fear is understandably exacerbated in a space like programming where the “helpful” answers we find in places like stack overflow are often needlessly complicated and/or chastise the asker for their admitted lack of understanding.
My solution to this is two-fold. First: as you learn, jot down the best people and resources to ask and keep that list handy. Sometimes Google or Stack Overflow will lead you in the right direction, but often blogger specific or the person sitting next to you is most appropriate.
Second: Get. Over. It. Any “embarrassment” you might feel in asking a silly question early on will be dwarfed by the embarrassment you’ll feel when you realize you’ve been doing something wrong for years, simply for fear of asking.
3. Clean Code, Right from the Star
We personally were amazed to find that writing clean code was as much a practice in keeping my syntax tidy (little things like proper indenting/spacing) as it was much broader guiding principles like “having methods just do one thing”. The irony of some of these rules is that they are both conceptually very simple and have powerful and far-reaching implications in learning to code.
Not everyone agrees on what clean code is, but in general it is something any novice programmer can spend a short amount of dedicated time learning and then putting into practice immediately. Moreover, it doesn’t run the risk of becoming a time-suck or leading to greater confusion, like so many other digressions can. In terms of bang for your buck, clean coding practices are about as good as it gets.
4. Use Version Control
Whether you choose Git, Subversion or TFS Version Control, you should use something, even early on. Version control systems aren’t difficult to use, but using them correctly and getting into the second-level functionalities can take some time. Having good practices in this area is simply fundamental to modern-day programming and essential to working on a professional team. You don’t want to be honing your Git skills on the spot when you land your first Jr. Developer role, so if you aren’t familiar with version control already, it’s time to dive in. Despite the power of these tools, don’t fear getting your feet wet; it will quickly become an eye-opening and time-saving pursuit.
5. Raid the Bathtub and Grab Your Rubber Ducky
We had been programming for several years before we learned what Rubber Duck Debugging was. Though it is certainly useful for debugging, it is equally useful for solidifying new concepts and sketching out plans for your code or information architecture. While many new developers will stumble upon this method for making sense out of chaos, we often fail to use the tool as often as we should. In a job where getting stuck for hours is a matter of course, we should be much quicker to reach for the tool which we know can often get us unstuck within minutes.
6. Work in Parallel
Programming can be a very focused task, it is part of the reason while it is such a great flow activity and conversely, why you can spend so long spinning your wheels, often when you know what you are trying probably won’t work.
After years of daily coding, we know now that in terms of long-term productivity, it’s always good to have at least two meaningful tasks to work on at any time. When you are stuck on one, it’s very often emotionally helpful to simply switch tasks and know that you are still going to get something useful done. Alternatively, if you needed to ask a question, you can guiltlessly move forward on your parallel task while you wait for a response.
7. Circle Back to What You Know
If there ever was a constantly evolving field, software development is it. As such, you can expect that much of what you should learn will change over time. Your understanding of debugging may have been sufficient for a small project, but when you begin tackling a larger legacy project, it’s probably worth explicitly revisiting. Your facility with your IDE or SDK may be high for a novice, but as you become more advanced, the more powerful features – perhaps those added in recent updates – are worth seeking out. Similarly, the conception you have for of a fundamental idea like Object Orientation or Polymorphism might be appropriate for a novice, but now that you are more advanced, could benefit from an upgrade. Simply put, it’s worth “re-reading-up” on some of those terms, jargon, concepts and acronyms that you may have had to look up when you first got in the game. Much like we can always benefit from refactoring code, we can also benefit from refactoring and refreshing the tools and principles which drive our work.