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!

Teaching clean code principles via de-factoring?

Here’s a new idea (to me, at least): Teach clean coding principles by starting with some very readable, very clean code. Then refactor (defactor) it into an incomprehensible, indecipherable quagmire of messy awfulness.

Why? The topic of “clean code” is a tough one to teach. Ask a random sampling of programmers and you’ll probably get a wide variety of opinions about what constitutes “clean” or readable code. Everybody has their likes, dislikes, and preferred idioms. And when we start with code that seems “bad” and try to talk about what “cleaner” code would look like we often end up talking in circles, debating what “good” code really means.

So in effort to avoid letting the perfect become the enemy of the good, I’m thinking it might make sense to try to play around a bit with de-factoring as a tool. Let’s see how it works if we start with something we might call clean, and then work to make it much worse, talking about what it is that makes it worse along the way.

Stay tuned. There’s hopefully more to follow on this topic!

How to find your Ruby gem installation path

It took me a bit too long to Google this, so I thought it was worth a note: You can find the location or path to where your Ruby gems are installed at with this command:

gem environment gemdir

Hope it’s useful!

Management by walking around

Part 3 in a series on managing programmers

The third installment in this series is about something I learned well before I got into management. In fact, it’s probably the reason why I got into management at all:

Get up out of your chair.

As geeks we’d rather just sit there. Sit in our chairs and send yet another email and hope enough folks read it. We spend a whole hour crafting a brilliant treatise on an Important Topic and assume that our written words alone are motivating enough to get people to do what we need them to do. And we hope (in vain) that people will read our words carefully, reflect deeply, and return the favor by drafting a well-written response of their own.

But when it comes to managing people email simply doesn’t work as well as we wish it did. It’s often the wrong tool entirely. You know this as well as I do. People simply don’t read your emails carefully. Or they miss it entirely. Or the message gets to them too late. Or too soon. And even when they do read your email, people can almost always manage to misinterpret the tone of your message and you end up spending even more time clarifying and apologizing and re-iterating. Et cetera.

In my experience, the only thing that does work is to do something that is entirely unnatural for most in the world of high tech: Get up out of your chair and practice some “MBWA“. MBWA stands for “management by walking around“. It means you go and walk over to somebody and actually engage in conversation. Talk to them. Talk first about the weather or their kids or whatever they’re working on at the moment. Then transition the conversation to what you need to talk about, or just drop in your request casually at the end. And sometimes, just like magic, you learn things without even having to prod. It goes like this:

Tammy sitting reading email. Manager enters, stage right.

Manager: “Hey, Tammy. What’s new?”
Tammy: “Just reading the latest missive from the client. They’re being a little less insane than usual today.”
Manager: “Nice! Always good when sanity prevails, eh?”
Tammy: “Yeah, absolutely. We can use a little bit of a break after yesterday’s server issues.”
Manager: “Wow, really? I must have missed that somehow. We had server issues yesterday?”
Tammy: “Yeah. It turns out the new audit trail feature caused our logs to fill up and we ran out of disk space.”
Manager: “Ouch! But yeah, that makes sense. You’ve got it fixed now though, right?”
Tammy: “Yep. We’re purging logs every 30 days now.”
Manager: “Good deal. Client seems happy?”
Tammy: “Sure. They seemed to like that we responded so quickly.”
Manager: “Excellent. Thanks for jumping in there!”

Manager exits, stage left. Elapsed time: 45 seconds.

3 reasons why MBWA can make you more effective

• It’s faster. Yes, it is. You might think you don’t have time to get up from your desk and actually go through the hassle of walking over, interrupting the person in the middle of their Facebooking, and actually talking about what needs to get done. But in the same 5 minutes it would have taken you to write an email you’re able to not only make the request but respond to questions immediately.
• It builds relationships. Being face-to-face with someone puts you in a position to tailor your message to the individual and respond immediately to questions in a way that is most effective for that person. Moreover, engaging people one-on-one helps build the relationship — you learn more about each other. This learning is the foundation of trust, and having trust means your conversations will end up getting faster and more effective over time, especially during a crisis or when speed is of the essence. And having more face-to-face conversations also ends up making it easier for the other person to interpret your “tone” when you only send email or IMs.
• It helps you learn and know more. As a manager you deal in information, and you’re missing out on at least 50% of the data feed if you’re not there in person. As I’ve already said, actually getting up and talking to other human beings seems counter-intuitive and at least somewhat stressful to most of us in technology. And here’s the thing: Most of our team naturally tends to avoid the face-to-face conversation as well. Yet the example above shows that it’s through the quick face-to-face interactions that we’re able to learn much, much more about what’s actually going on in our organization. Your team member may be too busy fighting a fire to send a detailed email, and maybe he’s not the type to swing by and chat either. But being there allows you to sense and prod and follow hunches, all of which end up providing you with more information, making you more effective.

So don’t just sit there in your corner office typing on the computer. As a manager your job is all about making everybody more effective by getting the right information to and from the right people at the right time. You just can’t do that with email alone. As my good friend and colleague Derek Olson likes to say: “The weeds are waist high. Sometimes you just need to stand up to see over them.”

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.