My management philosophy

Part 5 in a series on managing programmers

Here’s a list of some of the things about management that I expect from myself, and from people I work with and for:

Communication

I believe that 95% of all problems can be solved with better communication. Good communication is appropriately clear, comprehensive, timely, and frequent. Good communication adopts the right tone and is and channelled through the right media. Communication is often more about listening and asking than talking.

Honesty

It is the responsibility of leadership to be honest and forthright in their dealings with people inside and outside of their organization. Leaders are able to share both good and bad news in constructive ways with peers, team members, and customers. Good leaders encourage people to be honest with them.

Trust

Believe in people. Actively demonstrate confidence in their abilities. Look them in the eye and openly affirm your trust, keeping any private doubts locked away. These are things that empower. Delegate actively but always with a commitment to help, to teach, and to learn. Tell people you have their back, and then be there when they need you. We gain trust from others when we actually do what we committed to doing.

Predictability

Fear, uncertainty, doubt, and randomness are the enemies of productivity and happiness. Work to make sure expectations are clear. Strive to minimize surprises at all times. Timing is everything.

Responsibility

Stand up and take ownership of the situation. Generate solutions, not additional problems. Be willing to take the blame, and quick to admit mistakes. Do not make excuses.

Service

Embrace servant leadership. Lead with humility, and be ego-free when searching for the best ideas and solutions. Do what needs to be done, and believe that it’s never not your job. Treat people with respect independent of their status or disagreement with you.

Mastery

Expect the best from yourself and from the people you work with. Challenge yourself and others to deliver quality. Know, follow, and create new best practices. Identify root causes. Note that true mastery is intensely pragmatic, and avoids letting perfection become the enemy of good enough.

Curiosity

Always be learning. Always be improving. Always be seeking a new and different perspective. Admit what you don’t know, then go find out. Avoid stagnation, and embrace change even though it’s always hard.

Compassion

I believe there are two sides to every story, and that people generally have a reason for doing what they do. Reserve judgment as long as possible, and avoid assigning blame before you have talked to everyone involved. Deliver bad news in private whenever possible. Work to build up relationships built on mutual respect and understanding, and prefer talking with someone to talking about someone. Never say anything you wouldn’t say to their face.

Leadership

People expect leaders to act like leaders. Stand up on stage and play the role to the best of your ability (yes, everyone is always watching). It is your job to make (hard) decisions, so make the call, take the shot. Leaders understand that inspiration is better than motivation, and that people matter more than processes, systems, or things. Leaders radiate positivity and celebrate wins. Leaders are often friendly but rarely friends with those they lead. Parenting may be a useful mental model if you remember that good parents are always responsible, always making mistakes, always learning, always doubting themselves, always and deeply caring, and always willing to make sacrifices and put the needs of their family in front of their own desires.

This is definitely a work in progress, but it sums up a lot of what I think and feel are important.

Life in interrupt mode

Part 4 in a series on managing programmers

When I was first thrust into management, I would come home at the end of almost every day frustrated at how little I had accomplished. You see, like most technical managers, I still tried to keep myself involved in the task of actually writing software. I was a “working manager”, and still a developer (“75%!”). On my daily to-do list I had code to write, diagrams to draw, and databases to query.

But I felt like I “never get anything done” because, dammit, now that I was “the boss” everyone kept interrupting me. I found that even on days when I only had two or three meetings scheduled I’d still end up spending most of my day in hallway chats, impromptu one-on-ones, emergency client meetings, and responding to about ten times as many emails and phone calls as I’d had to deal with before I became a manager.

It took me a good deal longer than it should have, but I’ve since made three key realizations:

1. A manager’s job is more about people than about code.

A manager’s primary job is to make sure his or her team members are operating at optimum efficiency. That means your job, as a manager, is to remove barriers and pave paths. Your job is to work with and through other people to accomplish goals. You are no longer a do-er. Your primary contribution to the organization is no longer embodied in the code you write, but rather in your performance as the “glue” between individuals, working on stage and behind the curtains to connect people and teams. You are a leader, and your job is to inspire, motivate, mentor, guide, and help other members of the team do the actual doing. Toward this end:

2. A manager’s job is to keep their team in “flow” as much as humanly possible.

In “Flow: The Psychology of Optimal Experience“, Mihaly Csikszentmihalyi’s defines a state of flow as “the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.” (Wikipedia). Most creative professionals, including programmers, do their best work when the are able to achieve a state of flow. This is the moment when as a programmer you’ve got 18 different variables, 7 competing business requirements, and the entire architecture of the system you’re building loaded into your brain as you work through a challenging implementation. It took most of the last hour for you to get yourself to the point where you’re in flow and able to make forward progress toward a solution, and all of that can get flushed down the toilet with one single interruption. Which is why:

3. Managers endure life in interrupt mode in an attempt to prevent their team from having to step out of flow.

You no longer get to spend as much time in quiet solitude, working for hours crafting a nearly-perfect solution on a single problem. Rather, you are supposed to be there to run interference and, yes, to run errands for your team. Your new role expects you to be able to juggle multiple balls, multiple projects, and multiple priorities. Which requires, at most times, multiple personalities. In one moment you’re the wise mentor, working with a junior developer to clean up some code or get a test to pass; the next moment you’re the project manager politician fighting to balance a half dozen emergency requests across only three developers or write three dozen user stories before noon; and minutes after that you’re playing the gadfly, prompting your fellow developers to reconsider potentially problematic architecture decisions. And all of this talking and walking and meeting is in selfless service to the goal of trying to keep the rest of your team in flow.

This life in interrupt mode is very hard to take, and is very likely one of the main reasons why many new technical managers bail out of the job. But it also makes for very interesting and exhausting days. Because after you get home and get the kids off to bed you still have your fair share of code to write, diagrams to draw, and databases to query…

How to quickly disable the HTML 5 cache manifest using Rails

I’m playing around a bit with the HTML 5 cache (here’s a good introduction to AppCache) for a web application I’m working on. Part of the fun is how to expire the cache when testing. In Google Chrome one can simply browse to:

chrome://appcache-internals/

But I wanted an even quicker way to see what happens when browsing to a page that has not been cached in the AppCache. And one quick way to do that is to load the page without a valid cache manifest. Like so:

<!DOCTYPE html>
<%- manifest = params[:manifest] == 'false' ? '' : '/cache.appcache' -%>
<html lang="en" manifest="<%= manifest %>">
...

So whenever I pass “?manifest=false” in the URL, it passes an empty string to the “manifest” parameter instead of the actual file name, and so therefore doesn’t load the cache manifest. It’s important to point out that this does not blow away the cache manifest file (that could be arranged, however, no?). The manifest file is there, undisturbed, until we call the page again without the “manifest=false” parameter.

Note that this would work with almost any server-side scripting language (e.g. PHP, ColdFusion, etc.). And yes, it’s a hack, but wrestling with the AppCache is enough of a challenge that I thought this trick might be worth sharing.

Rocky Mountain Ruby Conf 2011

The Foraker Labs team had a great time at this year’s Rocky Mountain Ruby Conference (#rockymtnruby). It was fantastic to see a full house at the Boulder Theatre for the two days of the conference, and we enjoyed hanging out with old friends from within the Boulder Ruby community, as well as getting a chance to meet a whole host of visitors from near and far.

Here’s a brief overview of some of our favorite talks.

How to sort query results using a SELECT clause in the ORDER BY

The other day I needed to order a SQL query using by a value derived from a sub-query. Turns out it’s pretty straightforward:

SELECT *
FROM posts
ORDER BY (SELECT last_name FROM comments WHERE post_id = posts.id) DESC;

The ORDER BY clause will use whatever’s returned from the subquery to order things.

How to pick a random element from an Array

Here’s a nifty little patch to Ruby’s Array class to provide a method for picking an element at random:

class Array
  def random_pick
    self.sort_by { rand }.first
  end
end

So then you can do things like this:

def what_is_your_favorite_color?
  colors = [ 'red', 'blue', 'green', 'yellow', 'purple', 'pink', 'black' ]
  colors.random_pick
end

Please don’t ask my why I’m doing this. The answer has something to do with test data.

How to be successful as a web developer

…in 5 easy steps:

1. Stop complaining about the client.

2. Stop complaining about the project.

3. Stop complaining about the team.

4. Stop complaining about the technology.

5. Start solving problems.

How to detect if a Rake task is being run with --trace

So occasionally I want to output a debugging message for a Rake task. That’s easy enough. But what if I only want to output that message if the Rake task is being run with the --trace option? It turns out the answer is to check the Rake.application.options.trace flag in your task to determine if the --trace argument has been passed in, like so:

desc "The answer to life, the universe, and everything"
task :answer do |t|
  puts "42"
  if Rake.application.options.trace
    puts "Task '#{t.name}' is in --trace mode"
  end
end

Note that you can also set Rake.application.options.trace = true in your Rake task if you always want to see the stack trace information.

How to become a better programmer in 90 days

Foraker Labs just posted this (unofficial) YouTube video of the lightning talk I had a chance to give at the Mountain.rb Ruby conference last week in downtown Boulder, Colorado:

How to Become a Better Programmer in 90 Days

In this brief talk I present highlights from three books on my required reading list that (I believe) will help make you a better programmer:

• The Passionate Programmer by Chad Fowler
• Clean Code by Robert C. Martin
• Refactoring by Martin Fowler

Thanks to Derek Olson for taping and editing, and thanks again to Marty Haught for organizing the conference!

Mountain.rb 2010 recap

I had a great time along with some of the rest of the Foraker crew at Mountain.rb, Boulder’s own Ruby conference.

Check out my recap of Mountain.rb, posted in two parts on the Foraker blog.