Surviving the 3 Fallacies of Learning to Code – InApps 2022

In a couple weeks I will be celebrating an anniversary meaningful mainly to myself: the one year mark since completing front-end web development boot camp.

I graduated from a program that made a lot of starry-eyed promises about employability upon graduation, and indeed there were opportunities. This particular boot camp came with a “career concierge” assigned to helping us write resumes, practice interviewing, and find job leads.

Unfortunately, the kind of jobs on offer to us newly minted boot camp completers all seemed to involve formatting HTML/CSS newsletters for corporate marketing departments. Um, yeah, no thanks. Any potential junior front end dev position that looked actually, well, not shitty? We were drastically unqualified.

Thus it became very clear very fast that I would need to keep on learning All The Things (And Especially JavaScript) if I did want a bona fide dev job some day. Which I damn well did. And still, do. It also became evident that the robust “You Can Learn to Code!!!!” industry that has sprung up to capitalize on the global shortage of qualified software engineers and developers is built upon the following collective set of lies: (1) anyone can learn computer programming; (2) it’s quick and easy; and (3) there is an actual, discernible path leading through the skill levels from n00b to ninja.

No, they can’t, no it’s not, and no there sure AF is not. But I have come to realize that, while this is a hard road, it’s not an impossible one. Stick to it, focus and work hard, and eventually, you’ll have a portfolio of work to show what you can do, and be skilled and knowledgeable enough to not look like an idiot during job interviews when the code challenges go up on the whiteboard.

One year in, I’ve got so much of this nailed: first, it turns out that I appear to be reasonably good at programming, and I actually like it. So I survived Learn to Code Fallacy Number One, which probably skims off the vast majority of people pretty quickly.

This kind of abstract knowledge gathering is not progress, though it can feel deceptively so.

Fallacy Number Two takes care of the next strata, those who actually have a shot at really learning programming but fall away over time as the learning curve gets steeper and resources become fewer. I made it past, at least thus far, because I am nothing if not stubborn, and have no Plan B. Quitting is not an option. I work my ass off at this stuff, so my portfolio of Stuff I Built has been slowly coalescing into something not utterly embarrassing. And my JavaScript mentor has been throwing the same code challenges at me that he encounters during job interviews — and I’ve been able to solve them sans Google. (OK, most of them).

There is one fall-down area that is still really holding me back, though, and that is the focus thing. I work incredibly hard at this — studying, reading, learning, building, going to coding meetups. I mean, I’m even starting to teach some of this stuff at the same institution where one year ago I was a student. Yet I feel incredibly frustrated with my progress, which still feels glacial.

Which takes us to Learn to Code Fallacy Number Three: how to finally reach coder competency. My focus is a problem because I am trying to learn too many things, all at once, and it’s very very difficult to prioritize. I have known this for awhile, but it doesn’t make it any easier to stop. There is an enormous amount I need to learn to get to where I want to go, professionally, and so much of it is awesome and interesting. Lacking any linear learning plan I fall down intriguing rabbit holes all the time.

Like last week I was writing a recursive function, and then made the mistake of wondering, “Wow, how does this actually work?” Hours of reading and console code-puzzling later, I still can’t completely say how recursion works (my current hypothesis is “By magic!”). And the project I was actually, officially supposed to be working on did not benefit in the least from my side trip into recursion land.

So, yeah, focus appears to be my weak spot.When things get difficult or just plain tedious in a project, it’s all too easy for me to skitter off and work on something else. Which is easily justified because there is just so damn much to BE learning, and to the point where everything seems imperative to learn. However, this kind of abstract knowledge gathering is not progress, though it can feel deceptively so. And seductively so, too. When coding gets hard, or boring, it’s imperative to maintain focus, push through anyway and not just go trying out the next cool-looking thing.

But, when learning to code on your own, nobody’s there to say, “Dude,  step away from the rabbit hole.” With no witnesses, there is no one to call it out when you wander in circles or let a self-imposed deadline slide. The operative word here is accountability — having outside help to stay on track, hitting project benchmarks instead of losing an afternoon geeking out on abstract syntax trees. Fascinating? Yes. Useful? No.

Only, all too many times I forget to ask that simple question before diving down that rabbit hole. Losing focus means losing momentum. And it seems like I am far from the only code n00b struggling with this issue. Various online code-learning sites attempt to address the drift in all kinds of ways, from assigning one-on-one mentors (for the really expensive ones) to deadlines and goal enforcement and private Slack channels (still paying, but less) to throwing it back on you to build your own local community of people near you who are also taking a shot at the Free Fallacious Code Learnin’ Academy curriculum. Most of whom end up dropping out pretty quick.

So, lacking money but needing accountability, I’ve signed up for Chingu Cohorts in the hope that connecting with a group of other coders more or less at the same point on the web dev learning curve will help with the finding focus thing. We can point out rabbit holes and hold each other accountable for goals. Shoot, having to clearly state a goal in the first place, and set a deadline, and then have people asking me whether I’ve followed through — that is a seriously malnourished area of my self-study regimen.

I don’t know much about how Chingu works yet. It’s a pretty opaque setup, actually, until you’re actually in it. There is a detailed questionnaire about your work habits and learning status — how much you know, how many hours a week you are currently able to devote to coding self-study — so you can be sorted into the best-fitting cohort. A cohort lasts five weeks, at which time you can sign up for a new one. They ask for a commitment, that you won’t drop out and let your study mates down. At this point, all I really know is that I’ve been admitted to the mid-July cohort (fist pump!) and that I’ll be able to choose a study track — pair programming, a group project, or a dedicated study group. (There are multiple study tracks catering to Kyle Simpson YDKJS acolytes vs P1XT pilgrims vs Free Code Camp fellows).

Watch this space, friends. For now, I got to go shake some asynchronous tree architectures. I mean work on a project.

Follow Code n00b on her path to being a Code Ninja here.

Feature image by Samuel Zeller via Unsplash.