The Internet has brought online classes to the masses, but completion rates for MOOCs and other online courses is abysmal. I’ve discovered why: After the honeymoon phase, coding difficulty ramps up. If I wasn’t in a classroom with dedicated instructors to peek over my shoulder and offer advice, I’d probably have dropped out shortly after the coding got tough. This is my second week in HFC Academy’s coding and product bootcamp–and boy, am I earning these lessons.
There’s something phenomenal about remembering a useful element from an old project, plucking out a single segment and dropping it into a new project. With a flourish of keys, I hold my breath for the page to reload, and it works. Of course it works–this time. Every quote and semicolon settled in right where the machine logic intended. It’s a relief to have hunted through hundreds of lines of code just to see my dumb input boxes shave a few pixels for that elegant, rounded look.
“This is the turning point,” says HappyFunCorp engineer and HFC Academy instructor Ricky Reusser of our progress. “Where we were worried about front-end before, now we’re trying to make stuff that works.” Now we begin to delve into Ruby on Rails–so why not start with the man who might know Rails best?
Michael Hartl wrote the best-selling Rails Tutorial. He stopped by HFC Academy as part of its guest speaker series while he toured in anticipation of the release of Rails Tutorial’s 3rd edition. Hartl holds a PhD in theoretical physics from Caltech and has founded four companies since finishing graduate school, including the Ruby on Rails Tutorial and a startup through the famed Y Combinator incubator. Getting into Rails happened along the way–especially when he saw that there was a dearth of Rails tutorials to induct novices into the powerful web language. Hello, niche.
Hartl learned BASIC in 1983 and picked up other languages before focusing on Rails in 2005 Coding isn’t rocket science, but there’s an overhead associated with learning anything. “There’s no calculus involved in coding, but there are a lot of moving parts, and some people are overwhelmed if they don’t have a coding background,” says Hartl.
The physicist-cum-entrepreneur wanted to make his book the definitive Rails tutorial, so he released it for free. The risk worked. Everyone linked back to his tutorials and the Rails Tutorial site won its SEO battles to rise to the top of search-engine rankings–which resulted in tangible sales and business growth. And while Hartl learned Rails by reading books and taking courses, he became an expert by writing a book on the subject (his first Rails book, called RailsSpace[/url]).
“Professors do that all the time; they want to learn something, so they teach a course on it,” Hartl says.
But if you can’t plan a class or write a book exploring a subject. Hartl says to just dive in and build stuff, then hunt around Stack Overflow forums for the right segment and massage it into your project. It’s how a lot of programmers learn, by seeing how others play with code and then toying around. Monkey see, monkey figure out how the heck they made that animated drop-down menu.
You’ll notice that, despite my two weeks of intensive training, this page is no fancier. One of the most important lessons I’ve learned follows the car maintenance rule: If you don’t know exactly what it does, don’t mess with it while the vehicle’s in motion. Smarter folks than I have spent decades engineering solutions, giants whose shoulders I stand on to tinker my way into a wider world.
Over time, programmer culture has developed “best practices” to emphasize beneficial coding etiquette. Sure, the worship of cleaner code can reach an elitist zeal, but it’s grounded in pragmatism. Keep your code clean (and as short as possible) not just for readability, but because fewer moving parts mean fewer parts that can fail. Programmers notice and shame patchwork fixes for curing the symptom (not the cause) instead of addressing larger, future problems with your codebase.
Saying something has “code smell” is a coder pejorative, e.g., “that page or code segment has code smell” because it’s done inelegantly, like using negative margins instead of finding a CSS solution. Programmers label code with “smell” out of aesthetic discomfort with “hack” solutions: On the surface, the product looks as it should, but staring at the code superstructure unnerves programmers.
“Sure, it’s done. But are you really done?” says HappyFunCorp cofounder and HFC Academy instructor Will Schenk. Sure, your code works on this machine with that browser, but what happens when you look at it on an obscure Android device? Who knows how different hardware and software will change how your page operates. It’s like using high fructose corn syrup instead of agave, or more appropriately, a hundred different-sized toothpicks instead of a framework of wood and brackets. The load borne by your code will hold for now, but who knows what earthquake will come tomorrow?
Best Practice includes coding for screenreaders, programs used by the visually impaired to read aloud page content. There’s a big emphasis on coding for screenreaders in the Codecademy and HTML Dog tutorials I’ve run across, so that must mean a lot of folks put in the extra effort to code for it, right?
“Not enough” says Schenk. “Even though it would just take them five seconds more to code.”
“It’s amazing the psychological impact a clean user interface has,” says Aaron Brocken, HFC engineer and HFC Academy program director. “Nine times out of 10 when you show users a clunky UI with dynamic data and a clean UI with static data, users prefer the latter because the clunky UI ‘looks’ broken.”
Users aren’t savvy, they’re unconscious aesthetes. They don’t care how much time you’ve dumped into developing a product. They only care that it works. So clients asking you to build websites understandably desire perfection–but that can lead to tunnel-vision myopia that blinds clients to greater perspective.
It’s easy for clients to get lost in, “Ooh, I really want this to be perfect.” On a lark, Reusser built a simple bean counter program: Enter your hourly salary and it counts up–in other words, a visualization of how much time and money you’re spending making sure a feature is perfect. How much value are you actually adding?
Thus HFC finds itself asking clients over and over: What problems are you trying to solve? Are the things you’re working on right now actually solving the problems? Also, do you know your competitors?
“You’d be amazed how many people don’t know,” Brocken says. “Then they say, ‘Yeah, but mine’s different.’ How different? You keep having to answer those questions as you develop the product.”
And that means tough questioning and tough love.
“People are working on something that they’re hoping will provide them income, so we have to be honest with them,” Brocken says. “People use Facebook as a benchmark–what it was at first and what it is now? They say, ‘Well I gotta make sure my product can handle millions of users!’ You don’t have three users. Get those first, and then iterate.”
Obviously, that leads to a lot of push-and-pull between you and the client–not just by guiding each iteration toward a more useful product, but by keeping the client on the same page of priorities. Spending your time and their money productively, even if that means disagreeing with the client about what to improve now.
“So we’ll say to the client, ‘We’ve been spending lots of time on this, we can move on to XYZ but we really think sticking with the first thing is solving the problem,’ Brocken says. “There may be tension, but it’s more ‘exploratory and exciting’ tension than ‘Oh God We Need To Get This Done’.”