One of my most and least favorite part of using a computer is picking my tools. I have developed a suite of tools that work well for me. Some tools fit you like a glove. Other tools you adapt to and learn to stop hating after a while. As a computer user I have spent years using a computer and learning my tools. The result is that a large number of things other people struggle with are solved problems for me.

The limitation of tools is they cannot fix human problems. The increasing volume of email might be more easily processed by GMail’s interface than Microsoft Outlook, but it does not change the fact that it linearly takes more time to process more email. OmniFocus gives me a great place to store my personal task list, but it does not have the power to make me do my tasks. We must be cautious with imputing too much power and promise to our tools.

The other down side is we risk becoming tightly coupled to our tools. For example I have installed the zsh shell in the terminal in my Mac. It makes me a large order of magnitude more effective in using the command line interface on my computer. However when I login to a remote linux machine it is not available unless I set it up. The benefits outweigh the cost, but when you have used something that works better for you, your tolerance of other things goes down.


Yesterday, like I do most days, I went running by the Charles. However it was no ordinary day. It was cold. The temperature was chilly and the wind arctic. I forged ahead. Hit the start sequence on my Apple Watch. My feet hit the pavement in sequence. My pace was fast. It felt good.

After crossing the river to Boston, one and a half miles in, it hit me. The wind seared my face. It robbed my breathe. I looked down. I tried to regulate my rhythm. One, two, breathe in, breathe out, steady beats. The faster I went the harder the wind pushed back. I turned backwards while trying to move forwards. I could not do it. I stopped. Hitting the wall is better than hitting the ground.

When you hit a headwind, when you hit the wall, the recipe is to stop thinking about the original goal and think about recovery. In training you are not trying to win a race, you are trying to get your body to be ready for that. My body is not ready, but I know one day it will be. My heart rate drops. The headwinds are still there, but I forge ahead, slower, but more determined.

The Rescue

It happens in slow motion. Every week project leads pitch their project to the brigade members. This ritual gives everyone a chance to tell new members what is happening in their projects in their own words, and update their fellow brigade members. I listen to see what has changed. Every week I hear things change, except I notice one group is not. No worries, they’re just a little light this week. Another week passes. The slide is not updated. I hear the same pitch. I look over at the group after orientation. There is noise. Laughter. They must be doing something. I look at Slack and GitHub. There has not been a change since Columbus Day. I walk over to the project lead and we are about to have the conversation.

The first thing you learn from the conversation is the human you are talking to prayed for your arrival for the past month. They have been burning through developers faster than Trump appointees. You ask what they have been doing. They show you a Google Drive link. Concepts, brainstorming, sketches, it is all there. “This looks great,” I tell them. “So why aren’t you making it?”

“The developers have been working on the database schema for three months. We have tried building things in Django, Javascript, and then someone came by and Dockerized it all.” I look at the repo and sure enough there is a well Dockerized repo with a meticulously crafted database schema. Artisanal PostgreSQL with a sprinkle of PostGIS. “So you asked them to do this, but you got that?” I ask. “Mmm. Hmm,” replies the project lead.

“Tell me about the team,” I suggest. The project lead runs me through the roster. Every software project has a few key players. There is the project manager. I am talking to them, but I am also trying to figure out if they have managed a software project before. Have they wrapped their head around the adventure they are on? There is the designer. A good designer is worth their weight in gold. Finally they tell me about the developers. I am trying to find the missing piece.

Nine times out of ten a stagnant project is missing an important experienced person. Maybe all the developers just graduated boot camp. It might turn out the project lead has never given direction to developers before. They might have a ton of experienced technical people but no designers to focus the product and help the developers understand what to build. The conversation helps me find this missing piece.

After we wrap our heads around things the conversation ends with a plan. Does the project lead still want to keep doing this or do they want to cut their losses? If they are sticking with it then I have to stick with them. Once I know what is needed I can begin the search. I am not an expert at materializing humans, but I have met a lot of them in my life on Earth. I have Facebook, Twitter, and a sizable rolodex. Then once I find the right human I make the ask. I make sure they understand this is not a one night thing, their fellow citizens need them to serve for a few months. They can make a difference. They say yes. A few days later it is hack night. I am a little anxious. Will they show up? I see them walk through the door. I relax. The conversation has lead to human connection. The project is going to work.

The Manifesto for Agile Software Development

Last night I asked a friend about his organization’s approach to software documentation and he told me they follow the Agile Manifesto. I did not quite understand what he meant but then he reminded me to look at the beginning:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

I have come to especially appreciate the first part. My experience has taught me the tools matter very little compared to people using them.

Software Development Metaphors

  • Feature rabbit: a feature that initially appears to be one feature but after being worked on ends up having lots of other software features as a part of it. Feature rabbits breed when managers want to try and sneak extra work in their initial request, or often if a critical point was not articulated or recorded during the initial feature estimation.
  • Rabbit hole: a feature or bug fix that takes way longer than the initial estimate because it turns out implementation has greater complexity than initially understood.
  • Christmas tree: a software project that lots of stakeholders try and put their own features on. Christmas trees tend to lack product owners.
  • Tool tax: the time you pay to learn and use an additional tool in relation to your software projects. If a new tool saves you time it becomes worth it, but often each tool increases the tuition a newcomer must pay to work on your project.
  • Tuition: the one time cost you have to pay in order to work on a project because you need to learn a new technology.
Follow posts: RSS Feed
This work by Matt Zagaja is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.