New programmers face countless decisions that all seem equivalent in magnitude. Once you’re beyond the time-sucking abyss that is: “What should I learn first?” There are a host of follow up choices that can make your progress fleeting. It’s natural to conduct your due diligence, and I urge anyone who’s interested in code to pepper Google with the following: “What language should I learn?” “What languages are ideal for (insert interest here)?”, “What should I learn to get a job?”
“What language should I learn?” “What languages are ideal for (insert interest here)?”, “What should I learn to get a job?” Anyone who dismisses these as illegitimate questions is over-simplifying.
Anyone who dismisses these as illegitimate questions is over-simplifying. Yes, these questions are too broad to yield anything groundbreaking on Quora or Medium, but they’re where most of us start, and that’s okay. Next you want to start thinking about how to structure your programming journey like a productivity hub, a la unicorn tech startup.
Below is my advice on how to avoid common time-consuming pitfalls and stay on the dynamic path.
start thinking about how to structure your programming journey like a productivity hub, a la unicorn tech startup
1. Setting Unrealistic Learning Goals
If you’re an ambitious learner, you want to learn everything under the sun: mobile, fullstack, machine learning, VR, etc. It’s clear from my experience that learning to code does not lend itself to cramming like you would an exam — mostly because if you’ve never programmed before it’s difficult to gauge your understanding and retention, especially early on. Thus, it’s in your best interest to quell your desire to bulldoze your way through material unguided.
Don’t set up aggressive timelines that don’t account for the hours you’ll spend debugging — you’re setting yourself up for certain failure. A rule of thumb to keep in mind is that it will always take longer than you think, and in the event it doesn’t, there’s room for improvement (disclaimer: finishing early does not happen often). Instead, take your time, identify the areas causing confusion, and invest in the journey, where all the learning happens.
A rule of thumb to keep in mind is that it will always take longer than you think, and in the event it doesn’t, there’s room for improvement (disclaimer: finishing early does not happen often).
Don’t assume you can “power through it,” while paving over the opportunities to cherish small victories and progress at the rate that makes sense for you.
2. Time Management
At this point you’ve brought your first complex project to life, half-finished, buggy, and uncooperative when you want to show your friends. Fear not, this too is common practice for your first-born. These can quickly go from celebratory symbol of your new coding alter ego to demon spawn haunting your computer, whispering back all those features you said you build when you conceived the idea. This point borrows from number 1 — carefully assess your skill set before engaging in a project that doesn’t improve you as a programmer. For example, in one of my very first projects, I tried to build a simple web app that used a concert database to display local events in your area. Simple enough, I thought.
[Your projects] can quickly go from celebratory symbol of your new coding alter ego to demon spawn haunting your computer, whispering back all those features you said you build when you conceived the idea
Quickly I realized that I not only did I not know how to parse the API, I didn’t even what kind of dataset I was requesting, nor how to get it to show up on the screen. Weeks went by where I would make an inch of progress and what felt like a foot backward when accounting for the time I spent working on it. I was neither learning, nor doing, wasting precious time convincing myself to stick with a fruitless pursuit of completing a project that didn’t showcase all the things I did know.
This is not to suggest that you shouldn’t develop projects that will force you to learn new skills, indeed the opposite is true, but this should serve as a cautionary tale that just because you’ve gotten yourself into a beast of a project, it doesn’t mean you can’t take a break to refine your skills. Don’t hold yourself hostage to a time-vacuum.
I was neither learning, nor doing, wasting precious time convincing myself to stick with a fruitless pursuit of completing a project that didn’t showcase all the things I did know
3. Coding Around the Real Problems
In a similar vein, my previous tip is not an excuse to not build anything challenging. You’re only as good as your depth of knowledge across your field of expertise. Therefore, chose this field carefully and be conscious of how it affects your growth as a developer. In my previous example, when I wasn’t experiencing night terrors, I found myself working on “B” problems: bugs/features that were not central to the functionality of the application, mostly the aesthetics of the nav bar and the images on the home page. The “A” problems, you know, actually rendering the API I was using, would consistently slip down my priority list.
You’re only as good as your depth of knowledge across your field of expertise. Therefore, chose this field carefully and be conscious of how it affects your growth as a developer.
Objectively, it doesn’t matter how nice my app looks if it doesn’t work, no one buys a BMW without an engine. It’s easy to rationalize that at least I was productive since I was “cleaning up the UI” while taking a break from my other programming troubles. Let me say, when a “break” becomes 3 weeks, it no longer occupies space on your priorities; it’s been long forgotten, even from the backburner. Take charge and tackle your most pressing problems. Address the UI when necessary, like the day someone that isn’t your friend wants to use your application.
If you’re interested in learning more about what we’re building at Fullstack360 — check us out at fullstack360.com
#DontForgetoCode
