Month: September 2013

Steve Jackson: Lead with Passion

guest post[Note from Daniel: This guest post, from my friend Steve Tolman, is part of an occasional series about important career role models. I also worked with Steve Jackson, and I agree with Tolman that his energy and dedication instilled many great skills in those who worked on his teams.]

While I worked at PowerQuest, and Symantec after its acquisition of PowerQuest, I worked with a man named Steve Jackson.  He started somewhere around 1999 or 2000.  In our organization we had about seven or 8 Steves so we all went by our last names.  I was simply, “Tolman” and he was “Jackson.”

Jackson was the director and VP of all software engineering.  He was my manager and quickly became my friend.  He took his job very seriously and I learned a great deal from him.

By the time I left the team in 2008, I had learned how to run a team, how to build and release software, and how to work well with people.  One of my peers, Lane Johnson (one of the best managers I have ever known, who left the team at the same time) asked me what it was that made Jackson so dang good.  We thought about it for a while and concluded that there was not that proverbial one-thing-you-need-to-know that made him great, but more along the lines of about a bazillion qualities.  A little time brainstorming gave us a list of 45 different skills, techniques, or approaches.  Here are just a few of the highlights.

Believe in the individual

Jackson’s default mode was to trust people.  Trust them to fit into the team and trust them to do their job, but expect them to do a stand-up job for you.  Get the right people on the bus (read the book Good to Great for more info), give them an assignment, then get the heck out of their way and let them shine.  Continue reading →

What should code look like when we squint at it?

It’s the start of another school year, and my seventh-grade son is learning algebra. As I sat beside him to coach him through some homework the other night, I shared my favorite bit of wisdom about how to make math problems—even complex ones—simple and error-free:

Write the progression from known to unknown, one step at a time.

In my experience, the surest recipe for disaster is to short-circuit this rule. Collapse a few steps in your head in the name of efficiency, and you’ll forget a minus sign, or you’ll group incorrectly, or you’ll lose track of an exponent or an absolute value—and you’ll end up with a mess. You’ll have to debug your solution by slogging back through the problem from the beginning until you figure out where you went wrong.

It’s interesting—and maybe, profound—how nicely this piece of advice maps onto the design principle of progressive disclosure. The human mind is simply wired to perceive in broad outlines, and then to gradually clarify, a few details at a time.

Don’t believe me? Try a short experiment: draw this fractal.

Fractals embody the principle of progressive disclosure. Image credit: Fábio Pinheiro (Flickr).

I’ll bet that instead of laying down every pixel, like a printer, you immediately produce a simplification that captures the general shape as lines, with a lot of detail suppressed. You did this as a kid, when you drew stick figures and triangle+half-circle sailboats.

Artists sometimes squint to blur out what they don’t want to see, leaving only general patterns and colors. But coders never do, because we don’t expect code to work that way. Continue reading →