olly - Fotolia

Tip

Larry Wall's programmer virtues and 'vices'

IT pros who are lazy, impatient and hubristic are just what CIOs need. Gartner analyst Danny Brian explains why in this SearchCIO tip.

CIOs who want to build a team that can keep up with demand as well as the quickening pace of change may want to sit down for the advice Danny Brian is doling out. The Gartner analyst recommended that CIOs encourage a mix of laziness, impatience and hubris in their employees.

The words of, ahem, wisdom aren't a Brian original. He stumbled upon them as a young system administrator when reading Programming Perl (first edition, published in 1991). In the book's introduction, Larry Wall, author and the script programming language's inventor, declared laziness, impatience and hubris to be the three great programmer virtues -- without any further explanation, Brian said.

Danny BrianDanny Brian

That is until readers flipped to the glossary section of the book, where they found tongue-in-cheek definitions of each term tucked alphabetically among the technical jargon. Laziness, impatience and hubris are often regarded as negative characteristics by most folks, but, Wall seemed to be saying, Perl programmers aren't most folks, and they don't look at the world the way most folks do. At Gartner Catalyst, Brian took it a step further: The three programmer virtues aren't just for programmers; CIOs should apply them to IT in general, especially given today's climate. Why? Because a most-folks world view doesn't cut it for IT anymore.

Programmer virtue #1: Laziness

"Laziness (noun): The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer." -- Programming Perl

Most folks see laziness as a synonym for slacker or couch potato, but Wall's definition is about efficiency. And he's not alone. Consider this quote, often incorrectly attributed to Bill Gates: "I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it."

The guy who actually said it? Frank Gilbreth Sr. in a 1920 Popular Science Monthly article. Gilbreth was studying factory workers in an attempt to identify what the most productive patterns were and what movements differentiated a productive worker from a nonproductive one. "He found he could learn the most from the lazy man," Brian said.

The lazy man figured out ways to eliminate wasteful movements, conserve energy and still get the job done. "If necessity is the mother of invention, then maybe laziness is the mother of innovation," he said. One of the ways CIOs can encourage laziness? Brian encouraged CIOs to embrace the DRY principle -- Don't Repeat Yourself. Automate what you can so that employees can devote time to the most important problems.

Here's Brian's advice on how to inject laziness into your IT department:

  • Have deep domain expertise.
  • Be able to recognize patterns of problems to avoid repetition.
  • Establish in-house test-driven development. "Writing tests first forces developers, admins and other practitioners to come up with their expectations, to express their expectations in written documentation," he said.
  • Develop processes that help employees shortcut their tasks.
  • Document everything and encourage employees to do the same. "I'm not just talking about development, in this case, I'm talking about everything," he said.
  • Find ways to balance laziness with impatience and hubris. Laziness, alone, can result in the automation of everything. Finding a balance with the other two characteristics is essential, Brian said.

Programmer virtue #2: Impatience

"Impatience (noun): The anger you feel when a computer is being lazy. It makes you write programs that don't just react to your needs, but actually anticipate them -- or at least pretend to. Hence, the second great virtue of a programmer." -- Programming Perl

Most folks see impatience as impetuousness, but Wall's definition is about having a sense of drive. Put another way: "Patience is also synonymous with inaction," Brian said. As businesses embrace agile practices where speed and continuous improvement are standards, impatience might just become an advantage for IT organizations.

And why shouldn't it? The business doesn't want to wait weeks and months for systems to be built and questions to be answered, nor should it have to. "I talk to a lot of teams who struggle with agility and, oftentimes, I think it has to do with delivery teams who don't fully appreciate the urgency of the job and the fact that things have to get done right now -- in the best possible way, of course," he said.

To encourage agility and speed, Brian pointed to automation tools as an example of how IT can unleash their impatience on the world and minimize repetitious tasks. He also suggested CIOs try out practices like extreme programming, a type of agile software development methodology; and peer programming, an agile practice where two programmers work side by side -- one as writer and the other as editor.

"Impatience leads to better tools," Brian said. "We get impatient with the tools we have, so we build a better one, and it solves the problem in a better way." That's also why impatience benefits from laziness and hubris, characteristics that can ensure the business doesn't take on too much technical debt.

Here's additional advice from Brian on how to inject impatience into your IT department:

  • Provide the freedom to evolve tools and practices. "I know governance is important, but, frankly, we have to have freedom within IT to make these choices, to test new services, to experiment with new frameworks and technologies," he said.
  • Have strong architects and advisors.
  • Empower your teams.
  • Automate as much as possible.
  • Consider cloud and software as a service as opportunities.
  • Hire for good communication skills.

Programmer virtue #3: Hubris

"Hubris (noun): Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer." -- Programming Perl

Most folks see hubris as arrogance, but Wall's definition is about taking pride in your work. Of the three programmer virtues, hubris is Brian's favorite "because it's a great word," he said.

Brian recommends CIOs take the time to recognize and compliment employee efforts -- not to the board room and not via email, but in person. "One of the major benefits that's overlooked with agile, it's intended to get practitioners and managers and sponsors talking to one another," he said. "That can only happen if you have the right communication skills."

According to Brian, hubris can embolden employees to believe they can succeed where others have failed, to experiment with new technologies without fear, to pay attention to detail and to own the results of their work.

Here's advice from Brian on how to inject hubris into your IT department:

  • Help your staff become experts. "I like to describe practitioners as mentoring architects or architects in training," he said.
  • Find people who know what good looks like, a task he acknowledged is easier said than done.
  • Train your team to recognize patterns.
  • Strive for excellence.
  • Provide your team ample training.
  • Encourage your team to participate in online communities.
  • Praise the craftsman mentality.
  • Find ways to balance hubris with laziness and impatience, which can help ensure attention to detail doesn't become obsession with detail, Brian said.

Let us know what you think of the programmer virtues story; email Nicole Laskowski, senior news writer, or find her on Twitter @TT_Nicole.

Next Steps

More from Gartner Catalyst: Listening is serious business

Mergers and acquisitions impact channel partner programs

Dig Deeper on IT applications, infrastructure and operations

Cloud Computing
Mobile Computing
Search Data Center
Sustainability
and ESG
Close