Overdoing It

A buddy confided in me that his house was always messy. He couldn’t keep it clean.

“That’s it. This weekend I’m going to deep-clean everything. I’ll scrub from the top to the tile!” He told me.

He came over the next week. While he was hanging up his jacket, I asked him how the deep-clean went.

“There was so much to do. It was stressing me out. I didn’t do anything. Man, how do you keep your place so spotless?”

goir/Shutterstock.com

I pointed to a muddy spot on the floor next to my shoes. It had been there since his last visit.

“Ok. I wouldn’t eat off your floor, but it’s nothing like my place.”

I shrugged. “I just clean sometimes.”

He looked at me.

“Really. I try to clean one thing every weekend. Kitchen sink. Bathtub. Whatever. Sometimes I don’t get around to it. During the week I do the dishes and sweep.”

He made a face.

“Ok, here’s the deal. You’re overdoing it. A top-to-tile deep clean is so much work! Just do one or two things sometimes. If you get around to it often enough, it adds up.”

He nodded. “Yeah, I guess I made it bigger than I needed to.” Scheduling too much cleaning had increased the static friction of the work so much that he couldn’t get started.

If you focus on doing enough instead of doing everything, projects that seem hard often become easy. They naturally break down into pieces you can do one by one. You’ll turn around one day and realize all the pieces you care about are done.

You might also want to check out these articles:

What Code Review Can’t Do

When developers complete a feature, they (hopefully) submit it to their colleagues for review. GitHub does this with pull requests. Azure Repos have their own flavor. GitLab uses merge requests. There are many tools.

Code review increases the quality of contributions. It enables the team to have your back. Reviewers might catch mistakes you missed or share ideas you didn’t think of.

But, reviewers can’t guarantee code was written as well as they could have written it if they’d written it themselves. It doesn’t substitute for seniority.

That’s easy to see if we scale up to an extreme example. Five interns plus one senior reviewer doesn’t add up to six seniors. They actually add up to zero seniors because the one you have will be so busy with reviews and helping that they won’t get any work done.

Development is dynamic and creative. You stare into an ocean of tooling and a blank screen and invent a way to implement a feature. There are always many approaches. Some work well. Some don’t. Some seem like they will and then don’t. Sometimes you get halfway through your second approach before you finally realize what you should have done. It takes time and a lot of willingness to rework your own work. Reviewers aren’t spending that time and doing those reworks. They’re looking from a distance at something they didn’t write. They can’t catch everything.

A skilled reviewer can raise the quality of the code they review by 10%-15%. That’s huge value! But it’s also only a little bit of the total. Most of the value still comes from the skills of the developer doing the initial implementation.

You might also want to check out these articles:

Overcoming Static Friction

Static friction makes objects resist movement. It keeps them where they are.

Work can have its own version of static friction. I resist starting it. I have to push myself to sit down and log in and start typing. If I don’t push hard enough to overcome that initial cost, I can try a hundred times and never make progress. The energy I spend on all those attempts is wasted.

GBJSTOCK/Shutterstock.com

If I’m struggling to overcome a task with a lot of static friction, there are some tricks I try. As an example, let’s say I don’t want to go grocery shopping.

  • Look for an easy prerequisite. The drawers in my fridge are covered in bits of last week’s broccoli. I need to clean those out before I put in new vegetables. Where’s the sponge? Halfway through scrubbing the second drawer, I’m not trying to get started. I’m already working.
  • Look for a gap in my knowledge and start by learning something instead of taking action. I know I need more calcium. I mostly eat vegetables. I don’t know what vegetables contain calcium. Can I find a reputable article on vegetable calcium content? Great, found one. Pick ones to add to my shopping list. I turn around and I’m in the grocery store trying to find the kale.
  • Schedule it for later. Static friction varies from day to day. It’s actually my energy and willpower that vary day to day, but I perceive it as a change in the difficulty of starting. I’ll check the fridge to make sure I have enough food for today and schedule shopping for tomorrow. Crucially, I schedule it. I don’t just skip it. I add a task to my calendar or stick a note on the counter. I don’t want it to disappear. I just need a break.

These get me past a surprising amount of high-friction work. Try them out! Let me know how it goes.

Adam

You might also want to check out these articles:

A Checklist for Submitting Pull Requests

Reviewing code is hard, especially because reviewers tend to inherit some responsibility for problems the code causes later. That can lead to churn while they try to develop confidence that new submissions are ready to merge.

I submit a lot of code for review, so I’ve been through a lot of that churn. Over the years I’ve found a few things that help make it easier for my reviewers to develop confidence in my submissions, so I decided to write a checklist. ✔️

The code I write lives in diverse repos governed by diverse requirements. A lot of the items in my checklist are there to help make sure I don’t mix up the issues I’m working on or the requirements of the repos I’m working in.

This isn’t a guide on writing good code. You can spend a lifetime on that topic. This is a quick checklist I use to avoid common mistakes.

This is written for Pull Requests submitted in git repos hosted on GitHub, but most of its steps are portable to other platforms (e.g. Perforce). It assumes common project features, like a contributing guide. Adjust as needed.

The Checklist

Immediately before submitting:

  1. Reread the issue.
  2. Merge the latest changes from the target branch (e.g. master).
  3. Reread the diff line by line.
  4. Rerun all tests. If the project doesn’t have automated tests, you can still:
    • Run static analysis tools on every file you changed.
    • Manually exercise new functionality.
    • Manually exercise existing functionality to make sure it hasn’t changed.
  5. Check if any documentation needs to be updated to reflect your changes.
  6. Check the rendering of any markup files (e.g. README.md) in the GitHub UI.
    • There are remarkable differences in how markup files render on different platforms, so it’s important to check them in the UI where they’ll live.
  7. Reread the project’s contributing guide.
  8. Write a description that:
    1. Links to the issue it addresses.
    2. Gives a plain English summary of the change.
    3. Explains decisions you had to make. Like:
      • Why you didn’t clean up that one piece of messy code.
      • How you chose the libraries you used.
      • Why you expanded an existing module instead of writing a new one.
      • How you chose the directory and file names you did.
      • Why you put your changes in this repo, instead of that other one.
    4. Lists all the tests you ran. Include relevant output or screenshots from manual tests.

There’s no perfect way to submit code for review. That’s why we still need humans to do it. The creativity and diligence of the engineer doing the work are more important than this checklist. Still, I’ve found that these reminders help me get code through review more easily.

Adam

You might also want to check out these related articles:

How To Work From Home

Hello!

With the expansion of the recent coronavirus, major companies like Microsoft have started asking their teams to work from home to limit exposure. I find remote work is often the most productive, but the transition can be messy. I’ve been doing it for years, and I’ve learned some lessons I thought I’d share.

✔️ Lesson #1: keep the ticket tracker up to date

One of the hardest parts of managing a remote team is keeping confidence that you know what’s going on. Good managers keep a keen ear on their team, but when their team goes remote their ears aren’t enough. The best way to help them is to make the ticket tracker (like Jira or Trello) the source of truth for the team’s work. My rule is this:

If the boss needs to know the status of your work, all they should need to do is refresh the ticket board.

🗣 Lesson #2: use chat software for discussions but don’t use it to communicate requirements

It’s easy to take everything to your chat app as soon as you leave your shared office space, but I find that leads to dropped tasks. If it has to get done, it should be a ticket in the ticket tracker or at least an email that copies the Project Manager and Manager of the project. A ping in a chat channel isn’t enough. It’s too easy to scroll past something critical. My rule is this:

If something gets missed and it was only posted in chat, the miss belongs to the person who posted.

👥 Lesson #3: replace check-in meetings (like Scrum stand-ups) with a tool

If there’s noise in your home workspace, like a roommate coming home or a kid leaving for school, a pair of headphones is enough to mask it and help you focus. On a call, that background noise disrupts everything. Regular check-in meetings exaggerate competition for your workspace, but they’re also repetitive so they’re easy to replace with a text-based system. I’ve used Status Hero for this. It sends reminders, teammates can tag each other if they need help, and it tracks blockers. It instantly reduces the call schedule. It’s a quick win when you’re trying to bootstrap a newly-remote team.

📫 Lesson #4: use Inbox Zero

Unanswered emails are one of the biggest frustrations I face as a remote worker. Things get missed and chat channels get polluted with “hey did you see that email…” messages. I try not to create the same frustration for others.

Everybody gets a lot of email. Checking it is hard, even for diligent workers. Inbox Zero teaches you to process email instead of checking it. If you’re on a thread with an action item, create a ticket and archive the message. If someone sends you a link, bookmark it and archive the message. Instead of letting messages build up into a database of everything, process them into wherever they go and then get rid of them. Then unanswered messages don’t get lost in the pile.

Enjoy skipping your commute!

Adam

Need more than just this article? We’re available to consult.

You might also want to check out these related articles:

Grooming Large Backlogs

This morning, a buddy was wrangling a Trello board. It was packed with tasks and it was getting hard to plan work. Not long later, I got an email:

What’s your recommendation for a Very Large Backlog?

I see a lot of Very Large Backlogs in DevOps. Everybody is moving to the cloud. Everybody is automating. Everybody is paying down technical debt. There’s a lot to do and a lot of it shows up in the backlog. My buddy doesn’t work in DevOps, but VLBs are common in my world and I have a few recommendations that’ll help in any field.

How you deal with this depends on the tasks in your backlog. There’s no magic method. But, I have seen several recurring patterns in big backlogs. I’ve also found some ways to deal with them:

  • Tons of small, lower-priority tasks. I’ll often bump these up in priority just to get them out of the backlog. One of my mantras is, “You have to do a sufficient amount of the little stuff every week to keep the business running.” If I’ve got a bunch of cards for “rotate password on [service]” and “set up new account for [person]” and “email instructions for [task] to [coworker]”, I’ll just sit down for three hours and smash through them. It’s better to spend time doing the work than to spend time tracking it.
  • Tasks that are vague or not actionable until far into the future. These are good candidates to convert to a bulleted list in a markdown file. I keep a workspace directory with a notes.md file where I track these. It’s a workspace for me to think about stuff and experiment. Like, “Consider switching from Google Apps to Office 365”. It’s something I want to remember to think about later but it’s not really an actionable task that needs to be scheduled.
  • Planning tasks. I try not to put these in the backlog. Things like, “write a plan for how I’m going to write the code/copy/proposal for [task].” There are a lot of sneaky variations on this pattern, so I go through my backlogs and read each task carefully to look for it. I usually just delete them. If a task fits in one sprint, I consider my approach when I start the task. Orienting myself and planning my implementation is part of the development process, not something I do separately. Any task that’s so large I can’t plan it in-line isn’t a task. It’s a project and it needs a whole other process.
  • Tasks that just never seem to get prioritized. Backlogs often bloat with tasks that’ll never be high-value enough to prioritize. Like, “define code style standards for all mah code.” Or, “figure out how to install that JIRA plugin we talked about in standup that one time.” There’s only so much magic you can do to tame a large backlog. Too much work is too much work. One of the best things you can do is sort by value and drop tasks from the bottom. Put a note in the card and close it (don’t delete it, you want it to show up in searches so nobody adds it again). If the backlog is too big to complete, your options are to hire workers or cancel work. Hiring workers is slow and expensive. Canceling low-value work is fast and cheap. (You can also look for ways to work more efficiently but those are usually gains of just a few percent and won’t overcome a large backlog.)

There is a lot more to backlog management than fixing these patterns, but these can help a lot in shrinking your backlog down to something manageable.

Happy grooming!

Need more than just this article? We’re available to consult.

You might also want to check out these related articles:

A Book from 2017: Stretch Goals and Prescriptions

Happy New Year!

Today’s post is a little outside my usual DevOps geekery, but it’s been an influencer on my work and my career choices this year so I wanted to share it.

For the record, I have zero connections to 3M.

In my teens, I noticed that whenever I bought something with the 3M logo it was noticeably better than the other brands. I didn’t know what 3M was, but this pattern kept repeating and I started to always choose them. Years later, deep inside a career in technology, I was still choosing 3M. I started to ask myself how they did it. Why were all their products better than everyone else’s?

I didn’t know anyone at 3M, so I found a book. The 3M Way to Innovation: Balancing People and Profit.

the3mwaytoinnovation.jpg

Balance? At work? And still better than everyone else? Bring it on.

The book approaches 3M through their innovations. They built hugely successful product lines in everything from sandpaper to projectors, and it turns out other companies have long looked to them as the top standard for the innovation that drives such diverse success. As I worked through the book, one thing really stuck with me: 3M’s definition of Stretch Goals.

I’ve seen a lot of managers ask their teams what can be accomplished in the next unit of time (sprint, quarter, etc.). Often, the team replies with a list that’s shorter than the manager would like. The manager then over-assigns the team by adding items as “stretch goals”. If the team works hard enough and accomplishes enough, they’ll have time to stretch themselves to meet these goals. The outcome I usually see is pressure for teams to work longer hours (with no extra pay) so they can deliver more product (at no extra cost to the company).

This book described 3M’s stretch goals very differently, which I’ll summarize in my own words because it’s characterized throughout the book and there’s no single quote that I think captures it. 3M sets these goals to stretch an aspect of the business that’s needed for it to remain a top competitor, and they’re deliberately ambitious. For example, one that 3M actually used: 30% of annual sales should come from products introduced in the last four years. Goals like these drive innovation because they’re too big to meet with the company’s current practices.

The key difference is that 3M isn’t trying to stretch the capacity of individuals. They’re not trying to increase Scrum points by pushing everyone to work late. They’re setting targets for the company that are impossible to meet unless the teams find new ways to work. They’re driving change by looking for things that can only be done with new approaches; things that can’t be done just by working longer hours. And after they set these goals, they send deeply committed managers out into the trenches to help their teams find and implement these changes. Most of the book is about what happens in those trenches. I highly recommend it.

There’s one other thing from the book I want to highlight: the process of innovation doesn’t simplify into management practices you can choose off a menu. There’s more magic to it than that. It takes skilled leaders and a delicate combination of freedom and pressure to build a company where the best engineers can do their best work, and trying to reduce that to a prescription doesn’t work. Here’s a quote from Dick Lidstad, one of the 3M leaders interviewed for the book, talking about staff from other companies who come to 3M looking to learn some of the innovation practices so they can implement them in their own teams:

They want to take away one or two things that will help them to innovate. … We say that maintaining a climate in which innovation flourishes may be the single biggest factor overall. As the conversation winds down, it becomes clear that what they want is something that is easily transferable. They want specific practices or policies, and get frustrated because they’d like to go away with a clear prescription.

I heard truth in that quote. Despite being a believer in the value of tools like Scrum, which are supposed to foster creativity and innovation, I’ve spent a lot of my career held back by the overhead of process that’s good in principle but applied with too little care to be effective. Ever spent an entire day in Scrum ceremonies? There’s more value in the experience of 3M’s teams overall than there is in any list of process.

This book was written in 2000, but not only has 3M stock continued to perform well, I found many parallels in the stories this author tells and my own experience in the modern tech world. It’s heavy with references and first-hand interviews, and I think it’s a valuable read for anyone in tech today.

If you read it, let me know what you think!

Adam

Need more than just this article? We’re available to consult.

You might also want to check out these related articles:

Hygiene Checklist for Paid Subscriptions

One day I get a text from the illimitable Kai Davis. He’s had a Bad Moment.

Adam. I have terrible OpSec.

A former user had deleted a bunch of files. Luckily, he was able to recover.

Teach me how to OpSec.

No worries buddy. I got you.

Kai is a power user, and in today’s Internet that means he subscribes to two dozen hosted services. How do you manage two dozen services and keep any kind of sanity? I do it with checklists (⬅️ read this book).

Before I show them to you, we need to cover one of the Big Important Things from Mr. Gawande’s book. Kai already knows how to manage his services. He just needs to make sure he hasn’t forgotten something important like disabling access for former users.

I wrote Kai two checklists. One to use monthly to make sure nothing gets missed and one to use when setting up new services to reduce the monthly work. I assume he has a master spreadsheet listing all his services. Kai’s Bad Moment categorizes as OpSec, but I didn’t limit these lists to that category.

Hopefully, these help you as well.

The Monthly Checklist

  • Can I cancel this service?
  • Should I delete users?
  • Should I change shared passwords?
  • Should I un-share anything?
  • Should I force-disconnect any devices?
  • Is the domain name about to expire?
  • Is the credit card about to expire?
  • Am I paying for more than I use?
  • Should I cancel auto-renewal?
  • Are there any messages from the provider in my account?
  • Is the last backup bigger than the one before it?

The Setup Checklist

  • Add row to master spreadsheet.
  • Save URL, account ID, username, password, email address, and secret questions in 1password.
  • Sign up for paperless everything.
  • Enter phone number and mailing address into account profile.
  • Review privacy settings.
  • Enable MFA.
  • Send hardcopy of MFA backup codes offsite.
  • Setup recurring billing.
  • Set alarm to manually check the first auto-bill.
  • Set alarm to revisit billing choices.
  • Set schedule for backups.
  • Check that backups contain the really important data.
  • Create a user for my assistant.
  • Confirm my assistant has logged in.

Some Notes

Monthly

  • Can I cancel this service? I always ask “can I”, not “should I”. There’s always a reason to keep it, but I want a reason to nuke it.
  • Am I paying for more than I use? I look at current usage, not predicted usage. The number is often not actionable, but it’s a good lens.

Setup

  • Save URL, account ID, username, password, email address, and secret questions in 1password. The URL matters because 1password will use it to give you warnings about known vulnerabilities that you need to change your password to remediate. The email address and username may seem redundant, but having both has saved me a bunch of times. Same with secret questions.
  • Enter phone number and mailing address into account profile. These make recovery and support calls easier.
  • Review privacy settings. Remember, Kai already knows how to manage his services. He knows how to pick good privacy settings. But privacy settings are often hidden and it’s easy to forget them when signing up.
  • Enable MFA. I know it sucks, but the security landscape gets worse every day. Use this for anything expensive or private.
  • Send hardcopy of MFA backup codes offsite. I have watched people spend months on account recovery when their phones die and they lose their Google Auth.
  • Set alarm to manually check the first auto-bill. This saves me all the time. All. The. Time.
  • Set alarm to revisit billing choices. This has saved me thousands of dollars.
  • Set schedule for backups. Even if it’s an alarm to do a manual backup once a month.

Stay safe!

Adam

Need more than just this article? We’re available to consult.

You might also want to check out these related articles: