Note: this is the third in a six-part series covering the six-week coding and product bootcamp, HFC Academy. Read the first and second entries too.
The delicate balance of product and coding lessons at HFC Academy sits on the fulcrum of difficulty--and the Ruby On Rails language hit my barely-code-literate brain like a ton of bricks. The product lessons are great parables in the importance of communication, but mostly abstract preparation for when the programming side of the business kicks in.
It's the third week of HappyFunCorp's hybrid product and coding bootcamp, and I've hit the hard wall of language abstraction. In comparison, the first two weeks of the course learning HTML, CSS, and JavaScript tricks were gravy. Breaking visual elements rarely broke the entire page--just fix that misplaced bracket and everything will line up as you intended. Rails is far more opaque: You're toying with the strings connecting different pages and if they aren't formatted just so, your page is broken. Poof.
"Rails is just a series of horrible tricks. It's upsetting until you figure out what it wants you to do, and then you can do cool things," says Ricky Reusser, instructor at HFC Academy. 'It makes a lot of assumptions for you. Once you figure out what those tricks are, you can save yourself a lot of typing. You have to figure out where the magic is happening."
Or where the magic isn't happening, and breaking your code. Which means it's time to learn how to debug code and properly QA what's gone wrong. Sharp eyes are still important, but now it's become relentless hunting. Like hacking down brush to find the source of the fire, Reusser suggests chopping 100 lines out of your code. If your code still works, replace and chop out 90--all the way down until you zero in on the problem. This is where coding becomes a zen exercise in dogged resilience.
But never to the point of perfection. Expect perfect code and you'll never release it. In a break from the slog up the Rails learning curve, CEO and cofounder of PercolateNoah Brier briefed us on Percolate's small-team method to solve workflow madness.
Ship Small, Early, and Often
Percolate is a software engineering firm that builds suites of tools--a self-proclaimed "system of record"--for digital marketers. Up until three months ago, Percolate was a structural monolith, Brier says, but then they sliced the 50-person Product staff into five teams. It worked so well that they can't remember how it operated before, Brier says.
Each 7-8 person team is split between engineers, designers, and product managers--which means multiple disciplines have their eyes on a product as it grows. This means more eyes are acting as proxies for the user, pointing out potential problems from an early stage. Small teams are lean teams.
"One of the most scalable operations in history was the Roman army," Brier says, quoting former Engineering SVP of Twitter Chris Fry.
Percolate maintains their product teams at the vaunted two-pizza level, which means they can work on more features at once. The problem with the Waterfall workflow method, Brier says, is that you end up comparing apples to oranges: Do I want this new user feature or to refine that old one? Small teams let you compare apples to apples.
They also keep things simple. Simple doesn't happen when you merge teams for large endeavors. "As soon as you merge in, you gotta merge everyone in, who might be in 16 different places," Brier says.
But most importantly, staying small and lean fits with Percolate's mantra: Ship small, early, and often.
Small teams avoid scope creep. Percolate's small teams figure out the smallest thing they can build, built it, then refactor. Smaller projects move more quickly up the workflow pipeline and are easier to QA. Feedback comes that much quicker and products evolve more fluidly.
Brier, a former journalist and self-taught programmer, hand-coded the first iterations of Percolate back in its January 2011 beginnings. He's since handed most of the company's coding off to the regiment of software engineers he oversees as head of Product.
"I love working with engineers because they see every problem as a solvable thing," Brier says. "One of our core concepts that we took from Etsy is to always assume things are systemic problems. If somebody does something stupid, instead of blaming them, blame the system that let them do something massively stupid."
Satisfying Your Market
That's all internal, but Percolate has to make the companies buying its software understand that, too. The marketing agencies in turn have to answer to their own clients, who make numerous requests for changes.
Back in January 2011 when Brier started Percolate, the challenge was that brands saw the marketing potential of digital as more channels and more targeting options. But the production and cost model was staying linear. Brands wanted three times more stuff for three-quarters of the budget. The answer was to find efficiencies in tech--which Brier and his Percolate cofounder set out to do.
"From a product point of view, selling to someone with a budget is always easier," says HFC instructor Will Schenk. Instead, business-to-business has its own slew of challenges. "It's always a big question: What's the value of a tweet? What's the value of a Facebook share? Lots of people will consume on one channel and act on another. A lot of marketers are trying to make those connections because they don't have any sense of what's moving the needle."
Many of those efficiencies came down to homing in on what Percolate's marketing agency client base needed--not what they said they wanted.
"You're supposed to ask 'why' five times to figure out what's going on. Somebody will say we should build it because your marketers' clients asked for it--but why did those clients ask?" Briers says. "You realize people have not gone below the second layer. Instead of an idea, you should bring the actual challenge they're trying to solve."