Product Bootcamp Week Five: Avoiding The Weird Corner Case

You have to ask yourself how much value your effort is creating.

Product Bootcamp Week Five: Avoiding The Weird Corner Case
[Photo: Flickr user Jeremy Kendall]

As our fifth week of HappyFunCorp’s HFC Academy waned, the class slowly realized that these websites we were building…worked. But the end of our six-week course looms large. Soon we’ll have to put all these product and coding lessons to task.


I’ve said this before, but it bears repeating: If not for the instructors poking over my shoulder to correct my code, I’d have quit weeks ago. As the course wears on, I ask less for them to find my missing semicolon and much more “I want to link this to this. Where do I need to insert code to do that?” The basic instruction has moved into conceptual frameworks–plug this page into that page with this controller while this model tells these pages how they feel about each other.

The instructors take pains to emphasize how many ways we can link and style these pages. Partially this is to stretch our brains into accepting solutions as conceptual, not procedural–some solutions are lengthier while simpler solutions may take longer to figure out and code. We begin to see where adherence to Don’t Repeat Yourself programming can be ignored here and there to just get things built.

For example, one of our class project designs called for a footer to stick to the bottom of the page. HFC instructor Ricky Reusser walked us through the extensive but correct styling to perfectly replicate the spec designs…and then told us why we shouldn’t always do that. You have to ask yourself how much value your effort is creating.

“There’s absolute value to learning how to do that correctly, but there’s a lot of value to be lost dumping time into engineering solutions that are not worthwhile. I made a lot of mistakes there in the past,” Reusser says. “This is a corner case…if I engineer a corner case here, only two people will see that. So by saying “Yeah I can do that” that’s actually damaging because I’m adding a lot of code for a weird corner case and the actual payoff is…not much.”

Completing The Toolbox

The instructors have dropped our final tool in our laps: AJAX, or Asynchronous JavaScript and XML. AJAX allows you to update particular parts of a page without having to go through a full request-response cycle and reload the entire page–the asynchronous request works to ping the server to update data in the background. This is mostly useful for form data, like posting comments. It uses fewer resources, relieving stress on the server and reducing the chance that screwy server returns will leave your page in limbo. Plus, a fully refreshed page loses everything carried over from the last page, like params or URL add-ons. But more importantly, it allows the page to update data without force-refreshing the page, a major win for user-pleasing UX. AJAX streamlines your product.

“Normally, when you update a page, there’s a flash when the page reloads–and if just one element has been updated, the user will think the whole website is slow,” says HFC instructor Aaron Brocken. “Before, the page is static, but with AJAX the page is more alive. There’s a whole crazy user psychology you have to think about. People try to keep their apps from feeling “heavy.” They want it nimble, lightweight.”


Throughout the course, the instructors have hammered home the importance of responsive design. If your users change their browser window size, your page should adapt to preserve the aesthetic. Adapting to browser window size–or for mobile view–keeps your product clutter-free and, again, preserves the lightweight aesthetic.

Sometimes your assets themselves get in the way of that aesthetic. One of our projects required a directory page using an image logo that was sized smaller than adjacent images for profile photos. It came to a judgment call: We could either a) code around the image size disparity, b) ask our designer to fix the logo, or c) fix the logo size ourselves.

Choice “a” would be the elegant answer, but how much time would be spent exactly spacing out our page columns–funny spacing which may introduce problems of their own down the road? Choice “b” would be the easiest fix, offloading it to the designer, but the designer may have too much on their plate–or they’re the type that doesn’t take kindly to tiny problems that distract them from important work. Is it worth diplomatically maneuvering for this tiny fix?

Sometimes a cadet programmer just has to muscle up and go with “c”–but there are plenty of free tools out there to fix image assets. GIMP (GNU Image Manipulation Program) is an old standby, but other free solutions exist: Pixlr, for one, is an in-browser photo manipulation program that has several Photoshop-esque features.

The point isn’t that we’ve filled our toolbox. Like every step of the Learn 2 Code process, we’re being taught how to solve problems. Fidelity to solutions, not methods, will keep us flexible enough to grasp the usefulness of new tools that streamline coding so we can save energy for the big conceptual problems.

Remember: Pull Yourself Above The Code Forest

Our class is at the first stages of the coding learning curve, Reusser says: First you learn to make things, then you learn to make things well, then make things work, and finally you write elegant code, which for some becomes an end unto itself. This is a tricky pitfall when building products. It’s easy to miss the forest for the trees.


“Unless somebody’s paying attention, it’s easy to get lost writing great code. But that’s not the goal. The goal is to get the product out there,” Reusser says. “Put that in your heads right from the start.”

Ideally, this is where the project manager works their magic–figuring out tickets, find the value, and assign work accordingly. As an engineer, Reusser says, it’s your job to figure out what’s happening, because there’s not always enough oversight to keep you from getting lost. And the project manager needs to know an engineer well and adjust instructions in order for the engineer to deliver the right output.

“Some engineers will not do enough because they’ll only meet the letter of what was asked, and some will do too much. Somewhere in the middle is a happy medium,” Reusser says. “It’s not the engineer’s job to think about it, to plan and prioritize project or product management, but the engineer is the one that needs to make it happen.”

Which means us cadet coders need to get in the habit of managing our attention. Time management, Reusser admits, will always be a struggle. As an engineer, he needs to be aware of how long tasks will take for him to complete.

“It’s the last 20% of building stuff that takes 80% of your time,” Reusser says.

You, the engineer, need to communicate that to your project manager, who communicates an appropriate timeline to the client. It’s a tricky balance of team management and setting appropriate client expectations that takes learning from the 80-20 programming rule and properly respecting –that things will always take longer than you think.


“If it’s going to take half a day, you never tell the client that. You tell them it will take three days and then deliver it a day early,” Brocken says.