Guest Posts

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 →

Code Isn’t Art

Programmers, tell your inner artist to shut up.

One of the defining aspects of the Ruby programming language is that it is very flexible. It takes a very UNIX-like approach of having a few simple and well-defined functions that allow you to build rather complex systems. Unfortunately, it also ends up encouraging programmers to start thinking of their code as art, and then they start writing “clever” code. There’s nothing necessarily wrong with finding an unconventional solution to a coding problem, but that often falls apart when you have to involve another human in reading your “art”.

Let’s use an example from SQL of a “clever” solution. Take a look at the following query:

SELECT cl.Language, c.Name AS “Country Name” FROM CountryLanguage AS cl INNER JOIN Country AS c ON cl.CountryCode=c.Code SORT BY c.Code

How long did it take you to read that query? Probably a good minute or two because you had to expand out all of the aliases to figure out what it’s doing. Compare that to the unaliased version below:

SELECT CountryLanguage.Language, Country.Name AS “Country Name” FROM Country Language INNER JOIN Country on CountryLanguage.CountryCode=Country.Code SORT BY Country.Code

As you can see, it isn’t a “clever” query, but it sure is a lot more readable to a third party.

A lot of programmers will probably come back with “so what? I can read my own code and it gives me the result I want.” The fatal flaw here is that code is written not for machines, but for people. (Odds are good you’re also not going to be the only person that sees that code.) If we were writing for machines, you’d be using pure binary. All programming languages are made to give humans a way to express this in terms that are much more easily understood. Heck, SQL had an explicit design goal to be easily understood by accountants that needed to work with a database. The human element is crucial.

This is especially frustrating for those of us in support roles. I have a long history with SQL, some PHP experience, and I’ve done some dabbling with Ruby on Rails, but that’s atypical. Most support people don’t have any programming experience. What if they’re in a situation where they need to decipher the scripts that support a product or, heaven forbid, peruse the source code to try and find the cause of a particular error? They can probably figure out verbose code from having dealt with pseudo-code examples but will run straight into a brick wall if a programmer decided to be “clever”. Now the engineering team has to be drawn into something that could have potentially been resolved by support.

The question you have to ask yourself is if the ego boost from “clever” code is worth the increased work created when others don’t understand your “art”. I’m going to bet that your team members, members of supporting teams, and any management you report to won’t look favorably upon it.

Jesse Harris has been a geek since cutting his teeth on the Commodore 64 in pre-school. He currently works in support at RSA, the security division of EMC, and has been doing support, systems administration, and web development for 13 years.