The best way to predict the future is to engineer it.

This was something that immediately drew me to Hack Reactor. If you’re here, your probably doing some kind of research into coding bootcamps or trying to find a first hand account of the experience at Hack Reactor. Congrats my guy, you found it. As of this writing I have completed the second day of the Software Engineering Immersive at Hack Reactor/Galvanize San Francisco. But, before I can talk about that experience, I gotta tell you it was a journey to get here.

So, if HR is something you’re interested in just know that there is quite a bit of legwork before you begin your first day. I imagine you know this, seeing as how the low acceptance rate and conversion of graduates into industry jobs are the main selling points. I chose HR because everywhere I read said it was the best. And I want to be the best.

I won’t bore you with that stuff today. It would ruin the fun for you.

Instead I’ll tell you about one of my experiences so far from day one and two. I’ll be keeping things vague in respect to the curriculum and content of HR and please note that these views or opinions are mine and mine alone.

Pair Programming wasn’t something I encountered on my journey to this point. It was always something I knew I’d have to tackle at some point. Even just doing the small coding projects I was doing in my spare time leading up to the immersive program seemed to move at a excruciatingly slow pace. I’d broken so many things so many times in the name of progress and found myself backtracking more often than making that progress.

The struggles of learning code alone are either followed by ‘A-ha’ moments or more staring at computer screens that seem to laugh in your face. The serotonin that I get from those ‘A-ha’ moments give me life. That’s enough for me to get through the struggling.

Pair programming is a different beast.

There’s different approaches to the workflow and thought process that need to be addressed before the work can begin. What is the division of labor, what is the expectation for each of us, what is the overall game plan and our respective parts within that game plan? What do we do when something doesn’t work, how do we test if something is working?

These are simple questions that we gloss over when working alone. They’re present but as a supporting actor in the stage production of getting our code to run. These simple questions can be difficult to answer when you actually need to conjure the words to answer them.

Luckily, I had a partner who was very receptive to my ideas and had very good ideas of her own. Due to our skill levels being pretty evenly matched we were able to have some fun while coding as the challenges were similar to things we had encountered in the past.

All the anxiety I had about the actual prospect of pair programming seemed to be a nonissue in my initial experience. How that might change I can’t say, but the difference between coding alone and coding with one other person has been quite a large jump as is.

There’s so much information on the internet. Enough to create endless amounts of courses to teach people how to code. So if you’re looking for some kind of confirmation on whether you should choose HR or study on your own, or whatever you want to do… Only you can make that decision. But you should know, no one truly codes alone.

I do stuff and things. A student at Hack Reactor SF.