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:
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 successfu
l 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 everyday routine 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 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 space
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.
The two lessons from this section are:
- While learning, you can’t be scared of “breaking your code”. Debugging your implementation is the only way to fully understand a concept
- Don’t default to inefficient ways of doing things. Look on stackoverflow or npm to see if somebody has found a better way*
\* I realize there might be some debate about this point, given the left-pad thing, but my opinion is that programming is always going to be an abstraction based on some previous programmer’s work. While it’s a good practice to be mindful of your dependencies, you can’t not use other people’s work.) *\
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:
- Make learning to program a priority
- 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 R̶a̶n̶g̶e̶r̶ ̶S̶c̶h̶o̶o̶l̶ 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.
- Adopt a growth mindset; every obstacle you face is a tool for your learning
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?!
I’m planning on writing a post soon 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 love if you followed me and contributed to the convo. We’re all in this together!
Additionally 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 additional 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.
- This is just a flat out inspiring story.
