Pragmatic Programming

Sajith asked me to talk about a programming topic with the good folks at 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.

Story Points Examples Template

I used Story Points for the first time at Lucideus and grew to like them as a substitute measure for effort estimation. Most teams however kind of blindly navigate this estimation by “gut feel” and “how much this effort feels like”. Having a good story points examples document for each team is a good way to make sure this calibration is done better.

I’ve made a Story Point Examples template document here. Feel free to copy, replicate and make it part of your team process 🙂

Magic Estimation as an alternative to Planning Poker

I’ve always had a beef with planning poker. Story points are definitely a huge leap over the old man hours, but when you estimate them via planning poker, I’ve noticed a bunch of things:

  1. It takes way too long! Teams spend hours refining a backlog. It’s just crazy to spend that much time in a meeting.
  2. A lot of the time, people clump around Story Point 3. [You can investigate this yourself: just plot a distribution curve of amount of stories / story point]. I think it’s because 3 is a “safe bet”. You are almost always able to justify a 3: “Oh I thought he was new to the story, and didn’t have experience in it.” or “I’m sorry, I didn’t think of that.” It promotes laziness instead of actual thought.
  3. And people think of story points as absolute sizing after a while, even if your team is good and has blessed stories to refer to.
From the article: Magic Estimation is as simple as this!

So that’s why this article on Magic Estimation resonated. It seems to solve a lot of these problems, and I love it when a team does comparative estimation.

Daily Checkins: A tool for Async Work

One of the tools that I’ve used regularly both when working in teams and managing them is regular daily checkins. It’s one of the few things I’m very particular about, and most teams I’m managing think I’m a bit mental about it before giving in, trying it out, and then more often than not, falling in love with it.

So what are Daily Checkins? I started using from my first job in Slideshare, where we used Basecamp and that had this feature built right in. It’s pretty simple to explain, but it takes everybody a few weeks to get it right. Checkins are a pair of messages you post to your team communication tool twice every day: once when you begin work (the checkin), and once when you finish your day (the checkout). For this reason, it’s also been called Checkin/Checkout by a lot of teams I’ve introduced this to.

In the early days of my daily checkins, I used to be pretty lackadaisical about what I type in: it was just prose, often directed as an answer to a question such as: “What are you going to do today?” or “What did you do today?” I soon realised however, that checkins serve two purposes:

  1. It’s a planning tool for you to establish a daily cadence of work[1].
  2. It’s a reporting tool for your managing and your team members to rally around you when you need help.
    1. Notice: I said team members, so it’s public communication, and not intended to be a replacement for a personal 1-on-1 with your team.

And if it has to serve these two purposes well, it needs to have some structure. What I’m about to describe is the structure that my teams have evolved it to, after quite a number of years of practice:


An example is worth a thousand descriptions[2], and so here’s one:

- [ ] Review all assigned PRs
- [ ] SA-834: Make reports work with SAL, finish up my PR here after reviewing comments! 
- [ ] SA-826 & SA-827: Remove attack surface applicability from model & UI, make sure that I understand all requirements from the team
- [ ] SA-663: Rename SA to SAE, SAL to SA, New SAL to SAL, start writing down a clear approach here in the Jira ticket.
- [ ] Possible Blocker: Need test cases for SA-663 to move forward

Here’s a breakdown of what you see above:

  1. Checkins are todo-lists in a way, so we use the simple text notation - [ ] for describing an open todo. (The corresponding finished task would be - [x]).
  2. Each todo ideally starts with a project identifier if you have them. Here it’s a Jira ticket ID (the SA-834 bit). In more modern communication systems, I also make these hyperlinks.
  3. After the project identifier, I write down a short phrase about what the work is about. This is distinct from what I’m going to do today to achieve progress in the work. As an example, if I’d written SA-834: finish up my PR here after reviewing comments, somebody reading it would have to look up SA-834 before understanding what it is that I’m talking about. Instead, I’m explicit and write down both what the work is about and what I want to get accomplished today: SA-834: Make reports work with SAL, finish up my PR here after reviewing comments! This is a very important distinction: Checkins have to be skimmable!
  4. Note that I also have daily routines that I write first before any of this. At most of our teams, we start our day by reviewing PRs (so that we unblock others), and that’s my first Review all assigned PRs bit.
  5. I also make it explicit when I have blockers with Possible Blocker: in them, and team members, or my manager can come in and help.

That’s it! A regular cadence of doing this every day in your communication or project management tool would mean that everybody in your team is now aware of what your daily objectives are, and if you are blocked anywhere!

Checkins however, are incomplete without Checkouts


So I used to have just checkins on most days until I realised that something was missing. When team members began checking in every day, I realised that there were holes I was missing, the narrative of work between days was somehow fragmented because while folks would write down a lot of objectives for the day, they most often wouldn’t be able to achieve all of them. They—and I, as their manager—was missing this critical piece of feedback. So Checkin/Checkouts are a pair. Here’s how a checkout for the checkin before would look like:

- [x] Review all assigned PRs → Done, merged 3, thanks all for the review! 
- [ ] SA-834: Make reports work with SAL, finish up my PR here after reviewing comments! → PR #325 raised
- [ ] SA-826 & SA-827: Remove attack surface applicability from model & UI, make sure that I understand all requirements from the team → WIP in feature/SA-826-remove-attack-surface-applicability-from-SAFE-scorin g-model
- [ ] SA-663: Rename SA to SAE, SAL to SA, New SAL to SAL, start writing down a clear approach here in the Jira ticket. → Got stuck with meetings today, tomorrow!
- [x] Finished some unexpected feature reviews that came in today from the Product team.
- [ ] Blockers: Need test cases for SA-663 to move forward → Still couldn't get this done today as X was busy, I really need some help here!
- [ ] PR: Reviewed: 2, Created: 1, Merged: 3, Pending: 1

Here’s a breakdown:

  1. As you can see, Checkouts are exactly like Checkins except they have additional information. For one, they check off completed tasks with a - [x].
  2. Then, they suffix information about task progress. For e.g. PR #325 raised is a clear indication that I’ve made some progress with this task. This can also be negative progress however, like this one: Got stuck with meetings today, tomorrow! I generally separate out the checkout information with the separator, but you can use anything really. I’ve seen my team members using a more indented bullet point, or even other formatting. The only rule is that is should be easy in Checkouts to make out your progress (or lack of it).
  3. I make my blocker explicit as in my Checkin, this seems to have gotten worse today, and is a clear call for help: Still couldn't get this done today as X was busy, I really need some help here!
  4. And it’s also possible to have more items in your Checkout (but never less) than your Checkin: [x] Finished some unexpected feature reviews that came in today from the Product team.


It’s a bit of a finicky tool to explain, but team members soon make it their own. One of my delights in managing teams over the last few years has been reading their detailed checkouts. A lot of folks become good writers, entertaining me (& others in the team) with their witty checkouts. We celebrate success together, and share frustrations. Sometimes a small aside in a checkout (we really should do something about this!) becomes a trigger that brings the whole team together to build better tools.

I would love it if you’d try it out and tell me about your experiences! 🙂

[1] As a planning it’s wonderful as it lets you break down work to the smallest unit of the day. Most teams work in sprints, but that’s often too big a unit to really plan around, especially for a young developer. With guidance (& feedback from the team, your performance and from your manager) with daily checkins, you can become really good at sprint deliverables. However: the biggest win of daily checkins is not personal planning, it’s the feedback cycle you get from the tool. There’s a great video that explains this in more detail.

[2] This is why I’ve always hated man pages. I mean wtf. You write a dozen pages of prose but nobody can make sense of how to use your tool? tldr is a far better man than man. (giggle)

Managing Engineers: Assorted Tips

This is the last in a series of articles about engineering management, the first one was about valuing people, the second about business value, and the third about coding in the trenches, and earning the respect of the team. This last article is a set of assorted tips about managing people, and building a great team and running it sustainably.

Hire for and Value Performance

Building a great team starts from step 1: hiring the best folks. Hire for and value performance, not “hours on the desk”, “desire to learn” or loyalty. Performance and commitment, professional behaviour and the ability to deliver value are what should matter for you. This is not to say you have to be an automaton and willy-nilly fire or hire based just on this metric, but at the end of the day, performance and delivery should drive these decisions. Use compassionate candor to communicate, and make sure that your hires align to your company values. A good hire should either be a hell yeah, or a no.

Autonomy, Mastery, and Purpose

Daniel Pink’s Drive should be required reading for anybody who wants to manage people, but a few people mistake autonomy for letting engineers do anything that they want. Cultivating good drive is about setting clear boundaries, and very clear expectations, and teaching people that the why of what they do is as important as the how:

  • Make sure that your engineers understand the why (business context) and the what (the specifics of the requirement) for a story really clearly. Why are we doing this? What is the customer need? And what is it exactly that we’re doing? If necessary, spend time with them to collaboratively shape some of the details.
  • Make sure that the success criteria for story delivery are extremely clear. What is the process through which an engineer gets a story to done? Maybe it’s PR reviews, maybe it includes some automation tests. Make sure that this is not a surprise to a new engineer.
  • For beginning engineers, make sure that they understand how to solve the problem. Most new folks are stuck trying to figure out the how: teach them that learning how to get themselves unstuck is also an important lesson in autonomy.
  • Then, leave the rest to the engineer. The trick here is to get involved when they need help, and to give folks a lot of space when they don’t.

I also think Drive is a rediscovery of a universal truth about what motivates people, and there are deeper understandings of this concept out there. Ikigai for e.g. is at once both simpler, and more comprehensive.

Valuable Books

This last section is about books I’ve read that has shaped my thinking around engineering management. The best way to read these books, especially if you are a new engineering manager is to not read them cover to cover. Skim through them, find a section that is interesting, and dig deep. And if you are struggling with a difficult scenario at work, come back to these books and see if you can learn more lessons.

  1. Julie Zhuo’s Making of a Manager is probably the most wisdom/page of an engineering management book I’ve read. It’s probably the best book for a new engineering manager, and one that I’ve recommended many times over the last year.
  2. Camille Fournier’s The Manager’s Path is also common-sense advice, but it’s a bit more geared to somebody who’s been on the engineering-management path for a few years.
  3. Basecamp’s Shape Up is an opinionated way to plan and manage your work. It’s not something you can implement by yourself unless you have top-management support, but the lessons it teaches are still valuable. All of Basecamp’s books are good reading, and offer a view of an alternative way of working that just might suck you in 🙂
  4. I’ve already mentioned Daniel Pink’s Drive, but there’s no harm in a further plug.
  5. The Goal is a book that has long been required reading for all MBAs. The Pheonix Project is its equivalent for engineering management: how an agile philosophy and simple truths around keeping work-in-progress low and ensuring slack can turn around a business. It’s a bit of an utopian read, and it’s definitely a caricature, but it’s a great intro to agile and how it can deliver value.

So that’s it! Took a month to write these series of articles! If you found it useful, I would really appreciate a comment or a tweet. Thanks for following along!