Escaping the Coding Desert of Despair — 1,258 Hours
After being pent up in my room, at 5:25 am I realized what needed to be done. I needed to take the leap.
I missed my work holiday party with the flu and was still up due to a cold induced insomnia and because of the decision at hand.
Pent up in my room, since a friend-of-a-friend (Josh), from my college startup incubator was crashing for the week in the living room, I was deliberating whether to take the gamble.
The choices were this:
- Take unpaid leave from work living off of my savings for 3 months, seeing how much I could teach myself developing Android Apps, spending half my time going through the Udacity Android Nanodegree program, and the other half working for free on a project for a couple of technical teams within my company.
- Accepting a quasi-technical role in the Ad-Tech space which in itself was great and a much safer path, however would not result in becoming a developer.
Thinking about Josh, now friend crashing on my sofa, I was forced to reflect on why I wanted to move out to Silicon Valley 3 years ago. I knew I had to build things when I started taking design classes in high school. I started spending my time in other classes sketching designs for a universal iPod exercise holder and weekends creating the renderings.
Fast-forward to senior year of college I had a professionally crafted prototype for an iPhone5 exercise holster, but knew I did not want to spend the following years focusing solely on smartphone accessories. My passion is in creating, and by being in an ecosystem where people are working on cool shit would help develop my own ability to create.
Thus, the move from Maryland to California, where I could be immersed in a center of people working on a myriad of ideas.
While up early that morning I stumbled across a TED Talk by YouTube creator, Casey Neistat, which was exactly what I needed to hear listening to him describe the leap to his first creative job, providing him living runway of income for 3 weeks.
Looking back now, the opportunity that was leaving a day job for something that was much closer to where I wanted to be. What a gigantic step that was for me. At the time I was 24 and didn’t understand all of the nuances of that decision of what that opportunity could of presented, but I grabbed it and I ran with it.
One year ago I went with the gamble taking unpaid leave, going all in, and now I am an Android Developer. Whether I realized it or not at the time, below are the lessons that got me through the toughest phase of learning how to code, the coding desert of despair.
What is the Coding Desert of Despair?
When I began my journey to learn how to code in 2014, a mentor shared a starkly honest article, Why Learning to Code is So Damn Hard by Erik Trautman. The article de-constructs the path of learning how to code into 5 stages and provides tactical advice on how to get through each stage. I highly recommend his article if you want to get serious about learning how to code. Erik coins the toughest phase as the coding desert of despair.
Desert of despair — You push forward regardless of confusion and lack of perspective on how to get to the end goal. As you come across new concepts you enthusiastically research them. Sometimes quickly comprehending a new concept, but many times getting stuck for days making it feel like no progress has been made overall and perhaps you’re just not cut out for this. The hardest part of this phase is that there is no definitive end in site.
The 5 Stages of Learning to Code
- Hand-holding honeymoon — You write a couple If / Else statements, everything is easy and exciting. You can’t understand why everyone isn’t programming.
- Cliff of confusion — Quickly you are overwhelmed as things ramp-up. You get a peek into how much you don’t know what you don’t know. When you get stuck you don’t have the where with all to troubleshoot and you can’t fathom how long it will take you to become barely competent.
- Desert of despair — (defined above)
- Upswing of awesome — You are able to select a new concept, study the documentation, stumble through the roadblocks with prolonged debugging, but ultimately implement the final result. Your work is not a finished product, but you’ve learned how to learn. Despite the encouraging progress, there is a sense of the imposter syndrome. As the successful fiction writer Neil Gaiman describes, “The first problem of any kind of even limited success is the unshakeable conviction that you are getting away with something, and at any moment now they will discover you.”
- Job Ready — You have the ability to produce a finished quality product and understand not only how to get features to work, but you’re aware of why best practices are the most effective approach.
Unlike with the majority of skills, habits, or hobbies where you can gain 80% of the core benefits out of 20% of time or effort, with becoming proficient in coding grinding out the additional 80% teaches you how to problem solve which is crucial to gaining a core competency because any issue ignored will reappear.
My Maxims of Learning to Code
Warning: results may vary.
Question The Options Provided
“If you don’t choose the life you want to live, chances are, someone else is going to choose it for you. And the results are probably not going to be pretty.”
— James Altucher, entrepreneur, author and podcaster
I started learning Java late in 2014, and began spending 10 hours a week during nights and weekends increasing that to 18 hours per week while working more than a full-time digital marketing role.
By the beginning of June 2015 I was writing my first lines of Android code, yet by the end of the summer I felt stagnant in the coding desert of despair as I had been working on a major project for the Android Nanodegree and not yet finished.
Options laid themselves out before me once more…
- Continue grinding away at 18 hours per week
- Quit my job and work all week
- Keep my job, but test out working full-time at coding to see how much I can accomplish as well as if I’d enjoy coding at least double the amount of time per-week.
In order to do Option 3, I used 2 weeks of paid vacation saved up over my 2 years at the job and had a hackation. During the hackation I was able to submit 2 projects as well as create a side project for myself at work with mentorship from an engineer in Singapore.
Many times I was nudged towards becoming a Product Manager in my career when I expressed interest in becoming more technical. Being a PM can be a great role — however, I had to remind myself and others that was not the goal for me.
By questioning the options provided in terms my schedule and future roles, I was able to create an unique opportunity to test out coding full-time and to solidify what the end goal is.
For most, using vacations in order to take on even more vigorous work is not an option. Fair enough. The point is to question your own schedule and optimize for what is important to you.
An easy way to tell what is important to you is how you spend your free time.
Surround Yourself With Others With Similar Goals
I heard Joshua Waitzkin, a chess prodigy and martial arts competitor describe the Plus|Minus|Equals principle to learning on Tim Ferriss’ podcast.
The principle simply suggests that when learning any new skill one should surround them self with those who are better than, equal to, and not as experienced in that skill. You’ll learn and be inspired from those who are better, work together with those who are equal, and solidify your skills mentoring those not as good as you.
In order to expand my network of people to learn from outside my group of friends I started spending time at a local co-working space HackerDojo, creating side project opportunities at work, and reaching out to the course managers of my Android Nanodegree to create a local meet-up of students sponsored at their headquarters. It started as a test-run with a developer or two sticking around to answers questions, and then expanded into a larger more organized program.
If You’re Not Willing To Do It For Free, Don’t Do It At All
Learning to code is brutal. If you’re doing it solely for the amount of money you heard you can make, it will be difficult to make it through the phases where you question if you’re good enough. Approaching 1 year of consistently coding, I was confident I wanted to do this full-time, but did not have the skills ready to apply for full-time roles.
After reading through the fine print of company policies, there was a loop-hole: I could take 3 months unpaid leave with the support of my manager and director. I took the opportunity during my leave to work on my course projects half of the time, and the other half work for free, helping to build an internal app that would to help various teams test tools. I was content working without pay because I was receiving real work experience and feedback from experienced developers.
This is an extremely rare opportunity, and one I am grateful for. The principle still applies even without being able to take extended time off and without being part of a company that allows people to work cross-functionality. You’ll have to spend lots of time building the craft for free before seeing a monetary return regardless. Also, if there are not side project opportunities via work, there are plenty of open-source projects available.
Accept Hard Advice
The director who had initially helped me join his small team consulting mobile apps was aware of my technical aspirations and took interest in my path.
Before he left, we had a 1:1 lunch and he asked, “What area of tech I wanted to develop in?” I pitched him ideas for things I wanted to build, types of consumer apps I wanted to work for, and rattled off a list of teams internally asking which ones would provide the best chance of growing programming skills.
He responded…
If your true goal is having the skills to build apps you need to get hands on experience, which those teams will not provide. Also, you can’t handpick the types of apps you’ll work for. You need to build your skills and work for anyone that will give you a chance.
This was hard advice because I had to renegotiate with myself since I imagined transitioning onto a ancillary team and having a smooth transition into more technical work, and then somehow magically turning into a full-time developer. Accepting that I needed to take the full leap to a technical role, as well as not pigeonholing the types of apps to work on allowed me to brainstorm how to create my own project. Then, I interviewed teams and identified a common need that turned into my side project.
Don’t Harp on Past Mistakes, Analyze Them And Move Forward
After dabbling with JavaScript in college attempting to build a fully responsive website from scratch for a product I created and doing a side project in Python in my marketing role working on an Ad-Tech solution without much passion, I would give coding one more shot. If things did not click with Java in order to build Android apps then I would be done coding forever.
I have failed twice before, so why would this be any different. What I realized is that my past failures were not because I was not good at X language, but that I was going about learning wrong.
Failures → Fixes
- Absorption of content: Reading through documentation and guides I had understood the concepts at a cursory level at the time of consumption, however the concepts did not sink in deeper. For Java and Android I combated this by organizing the information into easily accessible and searchable components with examples, going as far as creating short-links to remember using bit.ly. For my intro Java course I created bit.ly/guide-introjava, and bit.ly/and-resources when I began writing Android code. It slows down the consumption of information, but solidifies and makes information shareable with others.
- Training/projects: My training/projects were not a reflection of real-world working environments. I did Code Academy with JavaScript my Junior year of college because I wanted to make a portfolio to display a product I was building. Code Academy’s exercises of fill in the blank coding and building a basic game was not the proper fundamentals by itself, but regardless I jumped directly into a massive project, without smaller ones leading up to it, then wondered why I wasn’t any good. Also, I purposefully ignored resources such as bootstrap.io so that my end project would be more authentic. Turns out, I never finished. After I learned Java, rather than jumping into something over my head and building an app from scratch, I researched Android courses that would give me practical skills. I was lucky that Google had just announced the Udacity Android Nanodegree which they helped create. I knew it was good because Google used to offer their own internal training “ABC” (Android Bootcamp) to developers, which had been replaced by the Nanodegree. The set of courses take students through concepts building on each other and with guidelines for apps to build at the end of each section.
- Focus: I was learning JavaScript while rapid prototyping 3D models, fabricating parts, and overseeing construction for my iPhone 5 exercise holster so I had at best 20% focus on learning JavaScript. Focus the majority of your energy on developing one thing at a time if it is brand new. I devoted the majority of my free-time during this period on learning Java and Android.
- Measuring Progress: I remember my first Director at Google telling our team over lunch that although it may seem our day-to-day impact is small, when you take a step back, looking at all of the interactions with advertisers over the course of a year, the impact is substantial for Google. From the day-to-day it felt like I was talking to a handful of local business, but somehow that equated to 1 million dollars of marketing uplift spend per year. Whenever I become discouraged at the lack of progress I am making I like to do an exercise where I reflect on where I was with this goal exactly 1 year ago. If I’ve put in consistent effort I find when looking in the birds eye view, I tend to be exponentially more so better off than where I was a year before. In digital marketing, we had to keep track of every metric of engagement and spend in dashboards/tools upon which we were judged on by management. Despite, despising most aspects of this, I leveraged the quarterly tracking idea in order to make sure I spent X amount of time each week keeping my own simple dashboard of a coding log. When I began my full-time role as an Android developer I had completed 1,258 hours of coding, escaping the desert of despair.
I still have a lot of work and learning to do, but now I realize, the Desert of Coding Despair is less of an endless expanse, and more so a steep, but if managed properly, conquerable mountain.
Don’t underestimate your experience self teaching.
— Hiroshi Lockheimer, Self-Taught Programmer, Head of Android at Google
I’m Adam Hurwitz — recommend and check out the rest of my writing if you enjoyed the above | Thanks!
