Welcome To Product Development Boot Camp

Co.Labs sits in on HFC Academy, a bootcamp for building websites and apps.

Welcome To Product Development Boot Camp
[Photo: Flickr user Dev Bootcamp]

Bootcamps have sprung up all over offering to train anybody to code in just a few short months. But there’s a big difference between learning to write software and building an actual product–which is something people often confuse. After profiling the Brooklyn-based dev shop HappyFunCorp just before the inaugural class of its HFC Academy, a bootcamp teaching how to build websites and apps, they invited me to take the course and report back.


Over the next six weeks, I’ll explore whether HFC Academy lives up to its promise. This first entry will cover the basic course outlines and what kind of person it’s designed to teach.


HFC Academy covers six weeks of 9 a.m. to 5 p.m. daily instruction. Students can expect to learn everything they need to build websites and apps on their own, specifically studying HTML, CSS, JavaScript, JQuery, Ruby, and RubyOnRails, among others. In addition to the tutelage of Will Schenk, cofounder of HappyFunCorp and one of the Academy’s two full-time teachers, instruction includes discussions from HFC employees and industry professionals. That’s the basic stuff–240 hours of guided learning.

Like many coding bootcamps, HFC Academy is designed with the complete neophyte in mind. Aside from middle-school HTML class, I have zero coding experience. Fellow coding illiterates, fear not: This course moves at your pace. As such, there’s a bit of assigned pre-work to get your coding feet wet before the course starts–HTML and JavaScript basics from HTMLDog and, yes, the introductory tracks for CSS, JavaScript, and Ruby on CodeCademy.

But HFC Academy distinguishes itself from the bootcamp crowd with its focus on creating products. As HappyFunCorp cofounder Ben Schippers told me back in July, they’re training students like they’d train new employees–to have a product-minded skillset, not just a toolbox of coding languages with little idea how to apply them.


Which means the course isn’t for folks wanting to immediately delve into the heavy-lifting, granular languages like C or into back-end or database management. It’s for folks who want to get a job building the sites you’ve got open in your other tabs and apps just beneath your phone’s lock screen–the things you see and use every day.


The first class of HFC Academy is held in a plush (and mercifully air-conditioned) conference room in HFC’s DUMBO office in Brooklyn. The walk through Brooklyn’s darling startup-trendy neighborhood seems like the first lesson: Here are folks with jobs in all manner of trendy startups. Odds are good that half of them are on a first-name basis with HFC Academy’s instructors, Schenk and engineer Aaron Brocken.

That conversational style flows into the wee conference room, where my fellow First Class guinea pigs and I are greeted with a little slideshow and a lot of TLC as we set up our “local environments.” Woe to the Windows user (me) who walks into a front-end coding and product course! Turns out that Ruby (our chosen language workhorse) was forked long ago down a Mac and Linux path, while the rogue Windows users gnaw on the occasional port and helpful command line patch. I didn’t find those bones the developer community threw my way–my instructors hunted down the Windows patches without knowing beforehand. Lesson two: Programmer problem-solving requires stretching the brain and, as the cliche goes, thinking different.

One point before I go further: HFC cofounders Schenk and Schippers were careful about who they chose for the first HFC Academy. Obviously, it behooved Schenk and Schippers to select ambitious candidates who applied on the HFC Academy site–those who would profit best from the short, intense bootcamp. But their selection doesn’t resemble the tech scene’s WASPy dominance: Half the class is female and half the class is nonwhite. I won’t speak again of my classmates out of respect for their privacy, but this intention to diversify the tech scene is powerful and important. Deliberate choices here and now will open up tech to critical new voices that will break the paradigm of white male Silicon Valley’s dominance of the scene.


Our first task: Learn HTML. HTML is an imperative language, which means there’s a lot of behind-the-scenes unpacking of the simple commands you type. In that sense, it’s probably the easiest language to learn–and some erudite programmers may debate the semantics of calling it a “language.” But it’s the basic version of every site you see and the introduction to the essential programmer quality of anal-retentive grammar. It’s arduous (and heartbreaking) to hunt for that one misplaced quote breaking your page.

The biggest revelation comes when the neophyte links their crude HTML to a CSS stylesheet for the first time. Like routing electricity and plumbing into a building for the first time, the home transforms, and new features beg to be plugged in. Of course, those wires can get plenty tangled when you keep layering them. Lesson three: Keep your code clean and those page-breaking mistakes are easier to find.

Then you discover that CSS (along with JavaScript and other stylesheets) can automate appearance and functionality, saving hundreds of lines of HTML code. This is the primal lesson, the thing that fuels programming debates high and low: Elegant code is best. Elegant code is efficient. Think elegantly and your problems decrease; slap code on to patch each individual problem and your code becomes a labyrinthine beast. It’s not just harder for you to catch–it’s harder for anyone coming after you.

It’s as I stop styling code for each graf and start styling for the whole page and nesting code only where necessary that my perspective starts to slide out. I see the interconnectedness of stylesheets and pages across my crude practice site like tin can lines across a neighborhood. And as my perspective expands, so does my vision, and I see the carpet of my HFC classroom has been carefully tiled into a giant Space Invader.



Let’s cut right to the showcase material–the product-focused instruction embedded in the course. In the first week, we students received our first two long-term projects. Both were designed by Milos Roganovic, seasoned product designer at HFC. An experienced programmer in his own right, Roganovic built our sample projects to resemble products they make for clients every day. Why work on anything but what you’d be expected to build in the real world?

The first project, a “Fitocracy meets Github” named “Gitocracy,” is a humorous jab at the startup trend to mash services together into a VC-friendly pitch line–e.g., “It’s [Facebook/Twitter/Tumblr] meets [Yelp/Amazon/Tinder].”

Boom. From the second day of class, I’ve been building products–and learning from the programmers and designers who do this every day. The words “best practice” float around the classroom, but so do “what the client REALLY means is…” and even “never let the engineers talk to the clients.”

Laughs aside, the lesson is clear: What’s best or easiest for a software engineer is rarely best for the client. Engineers spend so many hours enmeshed in codebase guts that they often get tunnel vision–and become very attached to their code. If a client looks at mockups and doesn’t like a feature, a wave of their hand can wipe away weeks of programming.


Thus the importance of the Project Manager–the gap-bridger, the intention-translater, the motivation machine. While the PM’s duties rarely involve rolling up sleeves for sustained codework, coding fluency is critical to managing deadlines and maintaining project perspective. Especially when the client changes their mind.

A client may say, “I want a simple search…like Google.” The engineer hears “simple” and thinks “Oh sure, I’ll just put in a keyword search. Easy!” and he’s done in a couple hours. But the PM knows what the client actually means–a search that is simple for users–and how to break to their engineers gently that the client changed the layout design…for the 6th time.