What do you think?

Part 1 in a series on managing programmers

If I have any management secret, it’s this: Every now and then, when one of my team members asks for my opinion, I try to pause and answer with one simple question:

What do you think?

I’ve been managing programmers for over five years now. That’s a long time in internet years, and I’m to the point where I don’t think it would be too out of line for me to start sharing some of the tips, tricks, and techniques that I’ve learned about how to manage software developers and engineering types.

The first management tip I’m sharing dates back to the very first day on the job as a manager. I’d been working with my fellow web developers in a small-but-growing shop, building a couple of fairly substantial applications used by the collections and law enforcement industries. Then one day my boss took me out to lunch for my annual review and I got promoted.

On the drive back to work I realized that I was suddenly in a position where I would be managing some of the folks who’d hired me. I had deep respect for every single one of these people. All of them were wicked smart. Most had engineering or science degrees of some sort (easily trumping my history degree), and many of them had more practical experience developing web applications than I did. I’d already learned a ton from each of them during my time with the company, and I knew I still had lots left to learn.

And that’s when it hit me. Before I’d read a single book or blog post or listened to a single podcast on how to manage software developers I realized that the one thing I couldn’t lose was input and feedback from the folks on my team. In that respect nothing had changed. Being in management hadn’t magically conveyed any special abilities or secret knowledge. Just because my title had changed didn’t mean that they had nothing to teach me or that that I no longer had anything to learn from them.

So I from that moment forward I made it my practice to try to pause and ask this question at least once a day. “What do you think?”

I didn’t have all the answers at the time. And that hasn’t changed in five years. And, in fact, the key realization was that as a manager it’s actually not my job to have all the answers. My job is to work with my team to find the best answer to a given problem.

As managers of knowledge workers it helps if we start by recognizing that our teammates have probably already come up with at least one or two answers on their own. Programmers, engineers, and scientists are problem solvers by nature. It’s what they do. So I try to get behind this. In fact, I specifically try to use my role power as a manager to encourage and support this whenever possible.

Moreover, we can use this one simple question to make it clear that we’re not just merely curious or playing to their egos, but that we expect our teammates to come to us having already thought through the problem, and to have a possible solution or two in mind.

In my experience, asking “what do you think?” helps accomplish three things:

1. It empowers team members by letting them know that I will actively solicit their ideas.
2. It sets the expectation that team members should have already thought through the problem themselves.
3. It demonstrates that I care more about finding the right solution than about being the one who came up with the solution.

In five years I’ve read plenty of books and articles and blogs about management in general and managing knowledge workers in particular. But I still come back to what I learned on my first day of management. “What do you think?” is a specific, practical technique that flips the power structure on its head and helps me demand the best that my team can bring.

So every now and again stop to ask your team what they think. You and your team will be better for it.

How to find the name of the current Rake task

A few weeks ago I needed a Rake task to answer a simple question for me:

“What’s my name?”

I honestly can’t quite remember why exactly the task needed to know it’s own name, but at the time it seemed important and I spent a couple hours digging about before I found out that Rake tasks are shy by nature. Or at least when implemented the way almost every tutorial tells you to implement them:

namespace :life do

  desc "The answer to life, the universe, and everything"
  task :answer do
    puts "The answer to life, the universe, and everything is 42."
  end

end

But how do I know what the name of the current task is? Well, after making a couple of random attempts (like “puts task.name”) and digging around in the very sparse documentation on the Rake homepage, I stumbled across a bit of documentation that talked about “Tasks with Actions”:

Actions are defined by passing a block to the task method. Any Ruby code can be placed in the block. The block may reference the task object via the block parameter.

task :name => [:prereq1, :prereq2] do |t|
  # actions (may reference t)
end

Ah ha! “The block may reference the task object via the block parameter.” That’s exactly what I was looking for. Adding the block parameter allows us to reference the task object itself. And the task object itself has a good bit of useful meta information:

namespace :life do

  desc "The answer to life, the universe, and everything"
  task :answer do |t|
    puts t.name
    puts t.comment
    puts t.scope
  end

end

The task now returns the following:

life:answer
The answer to life, the universe, and everything
life

The first line of output is nifty, and answers the “What’s my name?” question with the fully scoped name of the task. Given that much it’s probably not hard to return the task name in even the most deeply namespaced Rakefile. The second line is the “comment” — actually the description of the task. And the third line gets us the scope (namespaces). There are more methods available, but check teh googles for “Rake::Task api”.

So with this meta information we can do something useful like:

namespace :life do

  desc "The answer to life, the universe, and everything"
  task :answer do |t|
    puts "#{t.comment} is 42."
  end

end

Voila. And that’s probably enough meta for one day.

Reading is fundamental

I was knocking about on LinkedIn this morning and saw they’ve added a new “Amazon Reading List” feature. So I took it for a spin and wrote up quick reviews for three of my new favorite books: Chad Fowler’s Passionate Programmer, Martin Fowler’s Refactoring, and Bob Martin’s Clean Code.

Then I thought: Why should LinkedIn have all the fun? So I’ve added a new page to my site called Reading where I’ve posted the reviews.

“What are you reading?” is one of my standard interview questions. And despite never having enough time for anything I do try to read a few new books on programming, management, and business every year.

Let’s see if I can keep this up.