It’s difficult for an executive to criticize a budget when most line items are for mysterious high technology activities. It’s easier to tackle the more understandable portions, like postage, janitorial services, and consulting.
Jerry Weinberg
We want to help. We want to do stuff. We look for matches between what needs done and what we know how to do, and then we do it.
But does that always help?
Today in his newsletter, Marcus Blankenship told the story of the three bricklayers. What are you doing? “Laying bricks.” “Making a wall.” “Building a cathedral.”
We want to do something. We want to lay some bricks. As programmers, we want to write some tests, make a class, throw out an API.
After we break down a feature implementation into tasks, it is tempting to get started on the parts we know how to do. Knock those out, advance that progress bar. Make the wall taller.
Those are the least helpful parts to start with! In software development, our job is making decisions. What we need most is knowledge.
The pieces of the task most amorphous, kinda vague, the ones our brains want to slide past with hand-waves — those are the tasks that will give us more than apparent progress.
Integrate with that new service. Get authorization working. Pick the database and get familiar with it.
Digging into the uncertain tasks gives us information. We will learn how the API needs to be different than we thought. The data we didn’t know we needed, the unhappy-paths we didn’t know we needed to pave.
Lay the bricks slowly. Consider, what is going to hold this wall up? and what will this wall hold up?
In the opening quote, an executive tries to manage costs. They are drawn to the little nitpicky items that look approachable. But the easy ones are already pretty good! The giant Megatechnology items with big dollars next to them, these provoke handwaves. What might the executive gain by digging in and learning more about these? Maybe not cost-cutting, but definitely better decision making.
To help with the cathedral: be okay with uncertainty, sit in the unknown. Feel confused, be uncomfortable. Observe things that don’t yet make sense.
It’s tempting to start with what you most know how to do. Start instead with what you least know how to do.
Code (especially unreleased code) is a fast material to change, far faster than bricks. The hard part is deciding what to change it to. Aim for understanding, and progress will come to you.