I’ll be starting a new job soon (!), and so I just finally got around to writing up a manager README. A manager README is a document that is intended to help introduce folks I work with to my understanding of my role as a software engineering manager, my leadership style and management philosophy, my general expectations for folks I work with, and other useful information about me (including some quirks). Check it out!

A little more than two years ago I created a presentation called “Writing Cleaner Code”. I shared this with my teams at LogRhythm and with our offshore partners at Global Logic when I had the chance (of a lifetime!) to visit their office in Noida, India.

Presentation: “Writing Cleaner Code” (Google Slides)

Basically, this is a book report, covering key concepts from Robert “Uncle Bob” Martin’s outstanding book Clean Code, along with some interpretation, explanation, and augmentation by me. This book was mind-opening for me as a programmer and as a new manager of programmers because it helped me understand how to start having conversations with other engineers about what “good code” and “bad code” actually were....

read more...

Part 6 in a series on managing programmers

It’s my experience that many technical managers aren’t – and don’t really want to be – managers. See, we generally start out as engineers or developers, and probably show some strong competence as individual contributors. Maybe we’re also one of those rare engineers who can keep their cool with customers and has a knack for explaining technical solutions to non-technical types. Then something happens – someone resigns, a team gets too big, a new project starts – and we’re thrust into the job of “leading a team”, perhaps “just in the interim”. And we try to continue doing things like we had been doing, but now we’ve got all these extra...

read more...

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...

read more...

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...

read more...

…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.

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!

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

“Be productive, be fantastically clever when necessary, speak truth to power, hit your dates, and don’t ship crap.”

@rands, 1/11/2010

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.

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...

read more...

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...

read more...

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....

read more...

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, then general intelligence, then core skills. In that order.

A little while ago I decided I needed to get my head around this whole “Ajax” thing. From Wikipedia:

Ajax, shorthand for Asynchronous JavaScript and XML, is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This is meant to increase the web page’s interactivity, speed, and usability.

Mainly it was for a couple of issues we were having at work, but I’ve long been a fan of the “magic” behind sites like Amazon, Flickr, and...

read more...