How to get an “A+” on your performance review

My advice on how to get an awesome grade at your next performance review is to simply follow Rands’ advice:

@rands, 1/11/2010: “Be productive, be fantastically clever when necessary, speak truth to power, hit your dates, and don’t ship crap.”

By the way, if you’re a programmer or a manager of programmers and you’re not reading everything that Michael Lopp, a.k.a. Rands in Repose has to say, you’re missing out big time.

Make the call

Part 2 in a series on managing programmers

The second lesson I learned after being thrust into management was this:

Make the call.

Management didn’t confer any secret knowledge or special skills. Nothing about me had really changed from one day to the next. Except that all of a suddenly folks around me expected me to make the tough decisions.

Suddenly people would approach me with an issue. I’d listen and try to figure out what the problem was, and maybe think up a solution or two. Then I’d try to ask them what they thought about it. Hey, you’re smart. We’re paying you to know this stuff. So what do you think?

And more often than not they’d respond with something like: “Well, um, I’m not sure. That’s why I’m asking you.”

So here’s the crazy thing about being in leadership:

People expect you to lead.

I’m lucky. I get to work with wicked smart folks. So I expect them to have thought things through. And I’m usually no where near the most qualified person to make this decision. But there you have it. When the going gets tough your team members will expect you to make the call. That’s right, you’re “The Decider“, for better or for worse.

And this is a Good Thing. Making the call is, after all, why you’re there. Yes, it’s your job to make tough decisions in the face of uncertainty and lack of information and time pressure. What’s more: If you want to keep on making “the big bucks” and retain that fancy manager title then those spur-of-the-moment decisions will need end up being right more often that they’re wrong.

No pressure.

At the end of the day, being asked to make the call with insufficient information day in and day out is one of the major reasons why I see plenty of smart geeks quickly leave management roles or try to avoid them at all costs. It’s not really in our nature, because most of us technical types are information-driven. We’re type “C” in the DISC model, as the cats over at Manager Tools like to remind us. Our default mode is “ready, aim, aim, aim, aim…”. So making decisions quickly without enough information makes us really nervous.

Moreover, problems are often political. Yep, that’s part of the job too. Often the best technical answer to the problem is pretty clear to see, but implementing it means somebody’s feelings are going to get hurt. That’s why your team is coming to you. And while taking responsibility for something that might get somebody fired seems like a tough gig, it’s really the most important and best thing you can do. Really.

So if you’re a geek who’s suddenly found him or herself in a leadership role, and now everyone’s looking to you to make the decision, how do you do it?

Tips on how to make tough decisions

• Accept responsibility for the decision. This is really important because it’s where you get a chance to exercise your role power and political power in a really positive way. By accepting that it’s your job to make this tough call, you’re helping to take the pressure off of your team member. It’s very often this pressure to make the right decision that’s brought your team member to you in the first place. And removing some of this pressure will help free them up to focus on solutions and not consequences.
• Ask for recommendations again. It goes like this: “Hey, thanks for coming to me with this issue. It’s definitely a problem, but I’m sure we’ll figure something out. So tell me… if time/money/politics weren’t an issue, what would you recommend we do?”. So first take the pressure off them and then try to get them to re-engage. Remember, they’re usually the one with the most knowledge. And it’s always good to take another quick look around before jumping.
• Go get consensus. If you need to get up out of your chair and ask other folks what they think about a given problem, do it! Not getting up out of your chair is probably the number one mistake technical managers make. So stand up. Call a hallway meeting. If Kevin’s brought you a problem that Jake might have insight into, then drag Kevin over to chat with Jake. And make sure you get to a point where folks agree. Consensus is important because you need this to help make the decision stand.
• Don’t delay. Avoid the temptation of avoid putting off a decision indefinitely. Commit to a date and time. “I’ll let you know what I think by COB.” Or: “Let me check with Bob and get back to you within the hour.” It’s very natural for us to want to wait, but remember that your teammate brought this issue to you because it was important. While you sit and ponder your team is very probably at a standstill.
• Link decisions to principles and goals. When you end up at an answer to the question or a solution to the problem, it’s a good idea to try and frame it in terms of a general principle instead of a specific solution. Choose a direction (“North”) instead of trying to specify a specific path (“42 paces to your left”). Leave yourself and your team some flexibility by letting the folks who are going to have to do the work handle the details of a specific implementation. It sounds like this: “Well, I hear you on how we’re running out of time on this project, but since we’ve all agreed that we need to do as much testing as possible even on legacy code, I’d say let’s identify the 3 most critical features and write tests for those, for starters. Do-able?”. Focusing on principles means you’re focusing on what’s reasonable based on a larger context and previously established norms.
• Decide on plans not rules. “We must have 100% test coverage” is an empty decision without a corresponding plan for how you’ll achieve the new goal. Recognize that a decision is nothing without a plan for acting on it. While it is useful to make a general principle the foundation of your decision, it’s important to end with a plan for how the decision is going to be implemented. Here’s how that sounds: “Yes, we I agree we need to attack some of the underlying problems with the architecture. So why don’t you begin by make a list of sections of the code that already have good test coverage? Then we’ll know where we can start with the least chance of breaking things.” At the end of the day plans are more flexible, more comprehensible, and more likely to succeed in the real world than arbitrary rules.

Of course, it’s not as easy as I make it sound. But at the end of the day it’s what your team needs you to do. So make the call. It’s what you’re for as a manager.

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.

How to filter Subversion logs by date and author

I keep forgetting this snippet, and then spend hours re-discovering/re-inventing it. So for the record: Here’s a bit of magic to let you filter your Subversion (SVN) logs by date and author:

svn log -vr {20091014}:"HEAD" | sed -n "/nealenssle/,/-----$/ p"

I use it in a bash shell script function that I’ve got in my .bash_profile script like so:

function svnlog {
    svn log -vr {$1}:"HEAD" | sed -n "/$2/,/-----$/ p"
}

And then call it like so:

svnlog 20091014 nealenssle

Happy spelunking!

Developer Day in Boulder

Yesterday Jake and I enjoyed attending Developer Day at the TechStars facility in downtown Boulder.

Highlights included meeting Chad Fowler, author of one of my new favorite books The Passionate Programmer. It turns out Chad and I are, literally, neighbors. His house in Longmont is just a few blocks away from my own.

Another interesting moment was hearing Bruce Eckel, author of Thinking in Java, express his belief that “Java is likely going to become a legacy language.” Also a bit surprising to me (though I’m sure it’s old news) was his deep love of Python — a language free from the design constraints of backward compatibility that have plagued C++ and Java. Yet another reason that Python’s next on my list of “languages to learn”.

Hiring 101

Foraker just posted my new blog article: “Hiring 101“. The key point:

At Foraker, we recognize that our best chance at success involves getting the right people on our bus. So we’re almost always looking for people who live and breathe the web, who are passionate about getting just a little bit better every single day, who enjoy the challenge of working closely with a team of like-minded individuals, and who are eager to produce exceptional websites and web applications for our clients.

What we look for: Passion + team fit + core skills + general intelligence. In that order.

Why Rails?

Foraker just posted my new blog article: “Why Rails?“. The key point:

Rails lets us focus on solving business problems. At the end of the day, our customers care more about results than about any particular technology. Using Rails as a common language for our team means we can spend more time wrestling with our customers’ business problems, and less time wrestling with the technology itself. Rails lets us get started quickly, work efficiently, and respond flexibly, helping us to focus on the real challenges of designing and implementing functional, usable, and reliable web applications for our customers.

How to create Rails scaffolds and database tables dynamically

The idea I’m exploring here is whether or not we can build a CMS (content management system) in Ruby on Rails that can dynamically build a CMS. In other words, can we write Rails code that writes Rails code.

It seems we can. This is pretty awesome, and somewhat frightening, because it apparently works. Here’s a method in, say, a “utils_controller.rb”:

def generate_scaffold
    @results = `script/generate scaffold
    Things name:string value:string`
end

Note the use of backticks around the shell commands to generate a scaffold. If you run that method in your browser, it actually generates the controller, model, migration, etc.

Then do this:

def migrate
    @results = `rake db:migrate`
end

Yep. Now you just migrated the database and have new “things” table.

Eureka?

Obviously some issues here (like… OMGWTF! Run away! Do not try this at home!). But I’m a little bit excited…