Pragmatic Programming

Sajith asked me to talk about a programming topic with the good folks at Shopper.com recently, and I picked something near and dear to my heart: how to engineer with pragmatism at heart, how to navigate the challenges between business folks who want really fast turnaround time, and your engineering soul that wants good, maintainable craftsman-worthy code.

This wasn’t my finest presentation, but I liked the discussion that came up in between Sajith & me, and there were several things I’d improve if I were to give this talk again (this requires that you have either watched the video or at least skimmed through the slides above):

  1. I wish I had called this Pragmatic Engineering instead because a) there is very little programming in these slides, and b) people will think this is from the book, when it’s clearly not.
  2. Sajith brought up a good point in between that pragmatism is only possible because you lean on the shoulders of giants who wrote code before you (i.e. open source code). And that work priority is independent of these decisions: you plan & prioritise based on what makes sense to your organisation. I somehow should make this clearer in the slides and the talk that “big rocks” doesn’t necessarily imply a work priority.
  3. I think the ending is very weak. I didn’t directly address what measures are possible for a pragmatic organisation. Here’s an attempt:
    1. Since the primary thumb-rule emphasises change, let’s measure speed of change or velocity. This is a leading measure, and a corresponding lagging one could be customer features delivered / quarter.
    2. A corresponding negative measure related to velocity could be defect counts, and defect escape rates, these can be measured from leading to lagging, as in DERs caught by PR reviews, your staging or QA environment, your beta and the worst of em all: in production.
    3. If there’s one thing that impacts the velocity of the team it’s good test coverage. So both code and feature coverage[1] measures, and test resiliency metrics like false negatives should be measured and constantly improved. These are all leading measures.
    4. Measuring the warts in your code (e.g. FIXME/TODO lines, or “known issues”) is also a good leading measure. This should trend down.
    5. And finally, measure Cycle Time, but segmented by business use cases. The intent here is that all non-“Big Rock” items should have low Cycle Time. If not: maybe you don’t have the right processes or pragmatic software selection there yet. As an example: if a marketing page typo fix takes your company a week to execute (perhaps because it has to be prioritised in a sprint backlog), then might have a problem.

I’m willing and excited to do more such talks! If you’d like me to speak to a small group, do send me a message!


[1]: Feature coverage was a term we invented at Lucideus to measure how many important features were covered by integration tests. Unit test coverage is easy to measure, integration tests aren’t, and only if you measure something can you consistently improve. The eventual definition ended up being something along the lines of “The % of test cases with priority Critical or High that were automated.” We reported these metrics segmented by feature.

A Few Thoughts on Managing Engineers

What follows is some really common-sense advice on how to manage engineers. [A lot of it should apply to managing creative people in general, but I don’t really have any experience managing non-engineers].

And because I’ve been thinking about it for a while now, there’s quite a lot to talk about, so it’s in 4 parts. This is Part 1.

Your #1 responsibility is your people.

Make sure that they are happy and productive.

I think if you only take one thing away from this writeup, it should be this: engineering (programming, designing systems, UX, system architecture) is a creative profession, and requires time, dedication, and nurturing to do it right. Your job as a manager is to make sure that your people are on a clear maker’s schedule [2], with as little interruption as possible.

How do you make this happen? Here are two things that I’ve found works well:

  1. Keep meetings to a minimum. Promote asynchronous work. The cost of an interruption, and switching attention from one task to an urgent another is probably minimal (& expected) when you are a manager. But if it happens too many times to your creative engineering team, it is a recipe for disaster. So your job is twofold:
    1. Make a team that can function with minimal meetings. Consider replacing stand-ups with daily checkins. When you do have meetings, have them over a shared document so that decisions are recorded instantly, and everybody has visibility into how a conversation is moving & structured, and what the next steps are.
    2. Step in & protect your team when some VP absolutely wants a team member’s attention for something critical.
  2. Have regular twice a month 1-on-1s with your team members. [Of at least 20 minutes, and not more than 40 minutes long.] Valuing your team also means really listening to them. This means scheduling regular checkins with your team members where your only job is to listen to understand. This is probably one of the most important things you’ll do as an engineering manager, and it’s crucial that you do not skip this cadence step:
    1. You’ll find that the best ideas come from your team. They are the ones who are on the ground every day, facing and solving technical challenges.
    2. You have to create a safe space for them to open up and talk to you about their problems. The best way I’ve found to do this it to make sure they know the conversation is confidential and wouldn’t affect performance evaluations, and that it’s their meeting: they set the agenda, and your job is to listen.
    3. At times you’ll find that some folks really have nothing to talk about. Maybe it’s a dull week, or maybe they have had a really good month, and have no concerns. Fill in the blanks at that point by giving unsolicited, structured, actionable feedback. Talk to them about how they want their career to proceed. Talk to them about your experiences when you were at similar roles, and how you think they can improve in their role.

Well that’s it for this instalment! Next week, I’ll write about being committed to Value Delivery, your #2 responsibility.