As I mentioned last time, my HackR Diary was on hiatus for a bit, so the events described in this blog post occurred back in mid-November thru early-December of 2013. Weeks 8, 9, and 10 of my Hack Reactor experience covered a group project period where students formed small teams to create web apps from scratch.
I forgot to mention a few points in my description of the personal project period:
Some folks in my cohort accepted client projects rather than coming up with their own web app ideas. This meant they had to meet with clients, deal with external requirements, etc. Some had fun experiences; some had frustrating experiences. Some got paid; some volunteered. They all got to add some extra gravitas to their resumes/CVs.
Being a Senior
The cohort before mine graduated from the program just before interim week. After interim week, my cohort returned to HR HQ to find a new “junior” cohort, and there was a transition to seniorhood for us. As a senior, you have fewer/shorter lectures, less guidance, and you’re given more freedom to explore on your own. You still have a schedule to follow, but it’s far less rigid, which is fantastic. It’s funny how you feel more freedom, yet you end up working harder because of the nature of project periods at Hack Reactor.
Unfortunately, there isn’t much time to get to know the juniors when you’re a senior. We had one code review night where seniors gave juniors feedback on their classwork, but as a senior, your mind is always worried about your project, your app, your baby born of code.
By the way, I noticed that the juniors had more diversity. They had more women and more minority folks. I’m not saying my own cohort felt shitty because of the percentage of white males, and I’m not saying the new junior group reached some sort of ideal diversity (eventually, I may write a rambling blog entry about my views on diversity). I’m just noting the “slope” created by two “points of data.” The junior cohort was larger by about 5 or so people, but the increase in diversity was still noticeable. That said, I also noticed Hack Reactor felt more crowded (doh!).
Recap of Events
The first week just consisted of setting up boilerplate code and brainstorming game ideas. It took us awhile to settle on the free-for-all game mode. We originally considered implementing a game resembling zombie tag instead. My team also had to spend lots of time researching libraries, tools, smartphone abilities, and all that sort of goodness to find out what we should use to develop our project.
Fitness Challenge: Push-Up Routine
I’m sure some Hack Reactor folks (Hackers React? Hacker Reactions?) cynically roll their eyes at the staff’s efforts to promote health, but I appreciate them. For one week, there was a push-up challenge where students were encouraged to pair up and hold each other accountable for completing a set of push-ups twice a day. I paired up with a junior, and it was cool to be able to get to know someone outside of my cohort.
In the middle of the group project period, the staff told seniors about a program to extend the Hack Reactor experience. The Hacker-in-Residence program is an extra 3 months where you get paid to work part-time for the institution (develop internal tools, teach beginner-level content, interview applicants, etc) and work on more projects (i.e., extra project periods). The idea is that a select few seniors can become Hacker-in-Residence and gain valuable experience. I chose not to apply for the program because I already felt well prepared to enter the job market. Many students felt the same way, but plenty of them were attracted to the HIR program. Under half of the seniors applied, and most of them were accepted.
Therefore, about 1/3 of my cohort became HIRs. It’s important to note that Hack Reactor might not include these guys in their post-graduation employment stats. But even so, I know previous HIRs have had little to no trouble getting employed after their HIR phase ended.
New Hack Reactor Admissions
At some point during weeks 8-10, Hack Reactor launched their new website. It’s quite a bit nicer than their last version, but more interestingly, they changed their admissions process too. The new process uses their website to check very basic JS skills.
Hack Reactor likes having students/alumni contribute to their official blog, and I anwered the call for volunteers by authoring this blog post about the admissions process. Sadly, much of my experience lost relevance when the staff produced a new admissions process. I had to go through a 2-stage interview process, but now there is only a single interview. However, I think a lot of the advice I provided still makes sense.
What I Learned
Much like the personal project period, a lot was learned via trial-by-fire work during the group project period. My group tried and scrapped various features, libraries, tools, project management strategies, etc. It was so tough and so awesome at the same time.
My team knew we wanted to use geolocation, but we weren’t certain about much else. This meant that we had to research and explore many options. Eventually, we settled on a tech stack featuring quite a few different libraries/tools.
I spent a lot of time wrestling with PhoneGap, a dev tool for creating smartphone apps using tech normally reserved for web browsers. It’s a fairly popular option for informational smartphone apps, rapid prototyping, etc. However, 101 out of 62 doctors have concluded that PhoneGap can lead to headaches and irritable demeanor. I’ve written specifically about using PhoneGap for Android in a past blog post.
Don’t use jQuery animations
Engineering and Project Management
Everyone expects to learn plenty of technical stuff when building projects at Hack Reactor, but there’s a slew of non-technical wisdom discovered too. My team had a lot of discussion and debates regarding feature sets, client vs server roles, project priorities, division of labor, etc. as we worked to meet MVP (minimum viable product) milestones and deadlines.
Unlike the personal project period, the group project period involved a ton of communication. There’s a huge amount of extra planning and talking that goes into group coding. The collaboration is great for producing cool ideas and reducing scope of work for any given individual, but the group setting necessitates expressed justification for actions. When you’re on your own, you just explore and debug however you want to, and you’re often making heavy use of your working memory. When you’re in a group or even just a pair, you often have to explain before you act, which is a pretty serious exercise for your brain because it can feel like your working memory doesn’t get to operate at peak efficiency due to the extra steps of communication that fall between coming up with a small idea and implementing that idea.
Another way to put it: when you’re going solo, you get comfortable with the just try XYZ and see if it works model for programming. When you’re part of a team, you often need to explain XYZ, process any critical feedback you may receive, etc. Transitioning from solo work to group work needs a major change in mental processes. Luckily, everyone in my team is more patient and laidback than I am, so no wars broke out and no debates devolved into chaos. Good times.