Jon Deng

Fueling the šŸš€: How I learned to code while deployed toĀ Iraq

August 27, 2016 | 9 Minute Read

I prefer to blog on Medium for its conversation and community. Check me out!

TL; DR: While still in the Army, I went from never having programmed to getting into Hack Reactor. Here is what I learned along the way:

  • Make productivity your default
  • Donā€™t continue to do things inefficiently
  • Adopt a growth mindset when it sucks

MyĀ Story:

Coding leads to fun ANDĀ profit

9 months ago, I completed my first codeacademy course on making a webpage with HTML. I was deployed with the U.S. Army in Baghdad, and while on a run around our FOB, I met a forward deployed Palantir engineer who convinced me that it would be a fun thing to do. Now that Iā€™m back home, I applied for a spot at Hack Reactor, a full-stack Javascript bootcamp and recently found out that Iā€™m going to be part of Remote Beta Cohort 19 šŸŽ‰šŸŽ‰! Although I still have a lot of leveling up to do, I want to look back on the lessons of Iā€™ve learned so far, both technical and non-technical, and provide some value to other veterans who are in the early stages of making the jump to a career in technology. It just takes grit, enthusiasm, community, and xkcd. In this post I will review the non-technical lessons that I learned; in a future post, I will cover the specific ways I prepared for Hack Reactor.

TheĀ Lessons:

1. Make productivity yourĀ default

I read this Quora answer about the study habits of top students in Ivy League schools that argues to be successful you have to default to a place where you can be productive. Learning to code, like all challenging but enjoyable things (going to the gym, asking somebody out) is hard to start doing because its easier to be lazy. Make it harder for yourself to be lazy than to be productive. To minimize the ā€œstartup inertiaā€ of beginning a task, you need to minimize the number of steps that you need to take to start working.

For me, this meant sticking to a predictable routine everyday when in Iraq and after coming home. I would finish my 12 hour shift, workout, eat dinner from a box while browsing articles/ Face-timing my girlfriend, and then start coding. Even if I was tired, the fact that I was sitting in front of my computer made it easier to do something. Iā€™ve found that learning is a series of small wins, and even 30 minutes of plunking away at a random bug will maintain the momentum you need to keep going.

Although there are many complicated productivity systems, Iā€™ve found that the simple pomodoro method is most effective for lazy non-planners. I decide what I want to work on everyday and try to hit between 2 and 6 pomodoros (25 minute work sessions) on a workday and 10 and 20 pomodoros on the weekend. Of course, this depends on how Iā€™m feeling, but the important thing is to default to coding.*

*This doesnā€™t mean itā€™s to ok to become a complete social recluse and neglect your health. But your workouts/ hangouts/ eating food should be a nice break from your default state, which is crushing it šŸ‹šŸæ.

Takeaways: Find a place where you will be productive and default to that place when you have free time Use some sort of simple system that ensures you will make some small win everyday even if you only have 30 minutes to spare.

2. Donā€™t continue to do things inefficiently

Starting out, itā€™s easy to default to anti-patterns because you donā€™t know any better. Fixing this requires self-awareness and grit because itā€™s harder to do something new than to do the same comfortable thing over and over, even if tedious. But itā€™s super important to defeat the inefficiency monster šŸ‘¹, because you donā€™t want to develop counterproductive habits, especially early on.

When starting out, my guilty habit was copying and pasting code. The reason that I copied and pasted my old code was because I spent hours trying to implement every new concept that I learned. Once the code spit out what I expected it to, I was scared to touch it because I was worried that it would break and I wouldnā€™t be able to get it working again. Reading this worry on paper exposes how ridiculous my thinking was.

How could I expect to be an effective engineer if I wrote code that I didnā€™t understand and didnā€™t want to touch for fear of breaking?

More importantly, this lazy thinking prevented me from exploring ways to abstract my code within loops, functions, and objects to not repeat myself. Continuing to live with the inefficiency monster will prevent you from exploring new ways of doing things.

How do you know when youā€™re being sabotaged by the inefficiency monster? You will find yourself doing something tedious that involves zero thinking such as:

  • Manually aligning all the lines in your code with tabs and spaces
  • Adding and deleting console.log statements to your code to debug
  • Trying to match opening brackets to closing brackets
  • Looking around in Finder for a specific file or directory
  • Trying to select the right DOM elements with jQuery (šŸ˜œ)

Instead of prolonging your suffering, make the investment in learning a better way to do it. If you are doing something tedious and painful, chances are some previous programmer probably found a way to abstract the pain away and posted it on the internet.

Takeaways: 1. While learning, you canā€™t be scared of ā€œbreaking your codeā€. Debugging your implementation is the only way to fully understand a concept 2. Donā€™t default to inefficient ways of doing things. Look on stackoverflow or npm to see if somebody has found a better way

3 Adopt growth mindset when itĀ sucks

Being in the military is a full time job. Having a family is a full time job. Volunteering in your community (can be) a full time job. Everyone has commitments that will get in the way of hacking all day. If youā€™re learning to program on top of a full time job, by definition you have to study on nights and weekends.

Here is something I had to learn the hard way:

Nobody at your job cares that you stayed up all night coding. You still have a responsibility as a professional to deliver regardless of your side projects.

If you want to give yourself the gift of a new skill and a job in a field that youā€™re passionate about, you have to accept youā€™re going to be tired a lot, and will spend hours looking at your computer both at work and after work when your friends are camping or going out or grilling. In order to learn to program effectively, it has to be a priority in your life.

This is a difficult lesson that I continue to learn everyday. I spent and still spend a lot of my time thinking that I suck at everythingā€Šā€”ā€ŠI have imposter syndrome. On bad days I feel like this:

ā€œWhen I write, I feel like an armless, legless man with a crayon in his mouth.ā€ā€Šā€”ā€ŠKurt Vonnegut

The only way Iā€™ve found to overcome physical and emotional discomfort and self-doubt is to just do it. Everything sucks a lot less after you start moving forward. Doing things youā€™re not good at repetitively to get good at them (in other words learning) is inherently masochistic, but also super rewarding.

What has helped motivate me in the long term is the endorphin rush that comes when you code finally works and the understanding that bugs are tools for me to deepen my understanding of programming concepts. If you are having a hard time understanding or implementing a concept, itā€™s probably because you havenā€™t yet put in enough time yet. Donā€™t worry, if you keep at it, youā€™ll get it.

Takeaways:

  1. Make learning to program a priority
  2. Adopt a growth mindset; every obstacle you face is a tool for your learning
  3. Accept that you will undergo discomfort and be challenged. When I was preparing for Army Ranger School, I found these simple instructions useful and applicable to programming:

If you want to succeed at Ranger School programming, make your mind up to succeed before you get there. Make sure you have your personal affairs in order. But most importantly, prepare yourself mentally before hand [sic] and DONā€™T QUIT.

Conclusion:

I realize I still have a long way to go before I feel ready to program at a professional level. Hack Reactor is supposed to be a very challenging and all-consuming course. Which means that I have many more lessons to learn and write about. Exciting, right?!

If youā€™re interested in Hack Reactor specifically I wrote a post about the specifics of how I prepared for the Hack Reactor admissions process.

If youā€™re a veteran/ military/ military family and interested in becoming a software developer, Iā€™d suggest getting involved with Operation Code, a veteran-founded and led nonprofit that is the fasted way for military, veterans, and family to get coding. Additionally, Iā€™ve listed some additionally resources that I found helpful below.

Resources:

Operation Code: I got the chance to meet the founder, David Molina, at a GitHub conference in LA. It still blows me away that he was able to bootstrap an organization that can help you get unstuck, learn a new programming language and contribute to open source software in no time for free. The good stuff all happens when you join the Slack Channel.

Climbing the Wrong Hill: This was one of the blog posts that inspired me to commit to learning to code. Artur, a Hack Reactor alum, was a really big help as I prepared for the Hack Reactor technical interview, even going so far as to meet me in a coffee shop in SF to do a mock interview and hack around with the underscorejs library. Thanks Artur!

FreeCodeCamp: If I didnā€™t need to find a job immediately, this is how I would learn to develop software. A place to become a software engineer for free. Either way a good way to learn the fundamentals and join a community.