Needs work:

A pattern I’ve noticed is I can get very busy and get very little done. This happens when I’m stressed, which has been most of the time for several years. This is a virtuous cycle, meaning stress creates more stress because the gap between expectations and reality is growing. A systemic way to address this is to realign expectations to reality.

Runaway System

The system of anxiety-driven development is common. A frazzled developer sits down to work. They have a task that isn’t going well. Either the problem isn’t well understood or the developer isn’t competent with the technology or the software is mysterious to them.

The developer’s response is a learned behavior. At some point, the frazzled developer breaks down. Maybe they chat with people online, open social media, turn on some music, or take a walk. Things aren’t working, the work is difficult, and something gives at some point. Because this break takes time and because the break was unscheduled, it seems unnecessary to the developer. The developer is avoiding work for at least a few minutes in order to hold it together.

Either the break calms the developer down or, in the case of runaway stress, the break heightens the emergency. When the developer is young, adrenaline will kick in and they find themselves productive again. When the developer takes caffeine or other drugs, they can use stimulants or depressants to get into a flow again.

To make up for the erratic behavior, the developer will work later or get up earlier or make excuses or blow it off. Sometimes the developer concludes they are not that smart, or not as smart as they used to be. The next day, the developer sits at their desk frazzled again.

What I’m describing is a cycle that breaks the developer down. The system adds pressure as delivery dates are postponed or unaddressed problems grow more threatening. Sometimes a developer will pop and leave the team. Sometimes the developer moves to management to get away from the pressure. Sometimes the developer gives up and expects less and less of themself.

Problems

This problem is not the developer’s fault. The only part of the whole problem that the developer controls directly and confidently involves their study of the software they’re buildig and the tools they’re using. That’s it. Every other problem involves things outside the developer’s direct control. The best a developer can do is raise an issue and see if they can fix the system around them, but this is often controlled by non-developers who need to understand what is happening and slve the problem.

The problems I often see include:

  • The developer is inexperienced with a technology.
  • The developer doesn’t know the software they are building well.
  • Expectations are inconsistent with reality.
  • Tasks are not maintained at a workable size.
  • The reason for tasks and priorities are not clear.
  • People are not empowered to leave good things out of a system.
  • The developer is expected to have infinite will power and concentration.
  • Changes and interruptions are mandated outside-in without accounting for the damage they cause.

Many of these are described in our scenario.

An Integrated System

John Cutler shares his worldview on software development. He breaks down problems into rough orders of magnitude: 1-3 hour tasks are delivered every 1-3 days. This work is reviewed every 1-3 weeks and demonstrated to be useful. Every 1-3 months a group of deliveries are meant make a meaningful improvement in the software system. Every 1-3 quarters whoe systems are delivered so that every 1-3 years a business model can be implemented.

At every stage of this work there is a hypothesis or bet:

  • If the North Star metric for a company improves, its business value improves.
  • If a major component or input to the company is implemented or improved, measurable differences occur.
  • If we take advantage of opportunities, we begin to see things change.

Below this, designers and developers engineer a system that creates deliverable efforts every 1-3 weeks. At a business level, someone could explain an opportunity to grow and the builders in the meeting will have a chance to understand the opportunity and challenge whether it’s a tractable goal. If the opportunity would take 1-3 years to implement, then it’s got to be scaled down. The ideal situation means there will be a follow up meeting in a few weeks to demonstrate how the opportunity was seized and another meeting a month later to see whether the opportunity paid out as expeected. People can decide when there’s a problem where there were problems with the idea or the exeuction on that idea. They can adjust and make small things better.

When organized this way, it’s easier to answer why we are doing something. It’s easier to discuss why a priority changed. It’s easier to introduce changes at the right times, after things are working and before new challenges are accepted. An integrated system makes it easy to explain why things are the way they are and whether problems have to be addressed now or later. A lot doesn’t go perfectly in life, and allowing for human frailty in work makes the team stronger than the individual, the group smarter than any of its parts.

For the developers and designers, the goal is to demonstrate something every 1-3 weeks. They can then break down that work into chunks they can review every 1-3 days together and tasks they can deliver every 1-3 hours.

What this means is a developer, once organized, can build confidence and insight every 1-3 hours, or 2-6 times a day. Maybe there were interruptions. Maybe their will gave out amidst the stress of the work. But there was good news too. Important things were delivered anyway. It’s a net win.

Instead of heaping stress and anxiety on a person until drugs and adrenaline no longer rescue the developer, they are given an arena where they can perform well. They can go to work without heroic efforts.

How to Integrate Efforts

The approach I’ve taken with John’s ideas is I wrote down some work I’m doing on a mind map. Here is what I hope to achieve, this is why I’m doing it, this is the time constraint for this effort this time.

Once I see this tree, after about an hour’s effort, I can see that some of my expectations have been wrong. I’ve wanted to finish 1-3 month efforts in 1-3 days. Why is that? I’ve been nervous. I don’t like the pace of delivery. I’m hoping something will give and in my anxiety I can’t see that I’m creating a bigger gap between expectations and reality.

Now, is it possible to deliver a 1-3 month effort in 1-3 days? Absolutely. There are several ways to do that. Without any wisdom or deference to my health, there are probably drugs that will put me in a flow and I can manically deliver something big in a short amount of time. I’ve never delivered great work when drinking large amounts of caffeine, but that’s an optin. A better option is to reduce the complexity of what I’m doing. Say I want to get a survey system together, I skip backend tools and just read a JSON file. Or, instead of making the system pretty, I can make it functional. Or, instead of handling every use case, I pick one out of ten.

There’s always an option to remove good ideas from a delivery. but it’s scary to not do something good. I can only do something like that when I am calm and confident. Oh, I see that I’m going to break my promise if I keep doing things this way, what gives? Am I going to tell people my 1-3 week delivery needs to be a 1-3 month delivery and I deliver a signifant portion of it? Do I maintain the 1-3 week delivery and remove some features? Or do I just pretend a problem isn’t a problem and hope it goes away?

Analogy

Driving a boat is different than driving a car and riding a skateboard is something else entirely. Because a boat can’t change direction quickly and it doesn’t have brakes, the captain watches the horizon and anticipates problems. Because a car can usually manuever quickly, a driver often only maintains a safe distance and keeps track of things going on around them directly. With a skateboard, every pebble, every movement, every other thing matters and can cause a broken arm.

Captains in software look at business results, market responses, competitors, and the one goal of the organization. Drivers in software maintain speed and distance, keeping the pace and safety. Skateboarders in software do the fun trucks but have the most personally at risk, so they’ve got to control their environment with as little disruption as possible. Give them a skate park and leave your Suburban out of their way.

With this analogy, the skateboarders need to be doing tricks. If they’re not, what’s wrong? Is the pressure too high? Is the system out of integrity? Can more sense and explanation be offered? Do they believe in what they’re building? This sound manipulative, but as long as they enjoy the work and they’re respected for the work and they have a voice about what work gets done and how, it tends to work out. Respect goes a long way. So does trust.

Adice to Self

At the end of the day, what did I deliver? Do I have more confidence in anything I worked on? Did I submit code for review?

At the end of the week, can I see a pattern that’s working? Am I trusted to make important decisions? Is this working out for me and the organization? Do I have the information I need to make these decisions?

Am I on track to succeed? Where are expectations different from reality? How much of this was created by the anxiety cycle? What is it going to take to address any problems with any of this?

This may be an imperfect frame of reference, but the more software I write, the more I appreciate constraints. I’d rather build good software that makes business sense than write pristine systems that have no practical use to anyone. I’d rather develop my abilities and contributions in productive directions.