Ship, don't spin.

Whatever company you're working at, whatever job you're engaged in, if you're accountable to someone, you're going to have metrics to meet. This is particularly true—sometimes annoyingly so—in corporations. Meet the metrics, though, and you get to the next level in the game.

I made the mistake recently of allowing myself to spin my wheels on a project for a client. It wasn't mindless or useless spinning, but it left one of my deliverables open for a long time. A big portion of that spinning involved following up on requests from my colleagues—requests to change the approach or to add something here and there, which could have been challenged. I've been feeling a little more nervous about the job, so instead of challenging, my response was to concede and just do more. The problem is that doing more work—at least in the software domain—meant battling more hydra heads. Solve one problem, and another three sprout. The work grew exponentially without the feature being delivered.

While a lot of work was done and many hours spent, the deliverable had poor optics. It took too long for the feature to ship. I could justify the delays and setbacks by pointing to slow feedback cycles, vague requests from colleagues, and the learning curve in implementing certain features. But I am hesitant to put out fearful energy. Instead, I can acknowledge those factors and reflect on what I could have done better. I can own the fact that it went slow and that there were things I could have done to ensure the feature shipped sooner. Here’s what I plan to take from this frustrating experience:

1. Break features down and ship the smallest parts of them

When shipping a deliverable, I aim to deliver in component parts rather than a full feature. Why? Mostly to ensure the smoothness of a code review. The more code there is to review, the more surface area for change, the more likely merge conflicts can emerge from other work, the more feedback cycles there will be, and the more likely it is that with each change, a test failure will occur. Essentially, the larger the code delivered, the more hydras lurk. Keep the hydra count down.

This is not always reasonable for a feature and is more of an art. Usually, engineers don’t like it when unit and end-to-end tests are shipped separately from the code; the tests give them confidence that the code is working. Shipping one section or an incomplete page can often be hard to review when it’s not in context.

2. Whatever can be made a follow-up item, make it a follow-up item

Yesterday, I built a landing page for my client and put it up for code review. I got an approval and a comment asking to fix some redirect logic. That logic was out of the scope of the ticket (or at least the pull request) and was acknowledged to be an acceptable follow-up. But I got greedy. I said to myself, "I want to impress my team, show them that I’m showing up for them," and I tackled it. But it ended up being a hydra. One problem after another emerged. The changes required were much more than a few lines but involved many tests and interdependency changes. I ended up rolling back my work on this and pushing up my original work. The additional work wasn’t completely in vain, but it was a form of prioritizing spinning over shipping.

3. Get unblocked, even if it means being annoying

This one depends on the company culture. When I say be annoying, I envision messaging my fellow engineers and hopping on calls with them to rubber duck (e.g., explain the code verbally as though you would to an inanimate object, in the likely scenario that being heard will reveal faultiness in your logic or an unthought-of solution). There is a risk in unhealthy team cultures where collaborating with engineers and being vulnerable with them (e.g., "I’m stuck and don’t know how to solve this, will you help me?") can lead to poor optics. You can be marked as junior, inexperienced, or even stupid. I may be oversensitized to that risk, but I have learned (at least at this current job) that being annoying and getting something shipped is better than spinning solo and waiting.

4. Come from a place of strength

This one may be out of scope or the "which does not match" option, but I wanted to write it out regardless. I notice that when I approach a job from a place of fear, with a grasping energy, without trusting myself fully, I get poorer results. I get an unpleasant, unconducive feedback cycle from colleagues. A positive and strong energy—while not a panacea for poor technical chops or delivery—goes a long way in setting the tone in your favor. I’ve been approaching things from a place of wanting to prove and please, and I am going to stop that.

5. Set the right work boundaries and balance

One thing I have been doing poorly is setting boundaries around how and when I work. It’s been sporadic, often going late into the night. Last night, I found myself working past midnight, trying to get something shipped, grasping for more, working with that "prove yourself" energy. I paid for that today. My sleep was anxious and unpleasant; I felt the stress and dysregulation from the day. I woke up much later than I’m used to and have marked today as a recovery day. I paid a big price for minimal reward. Doing more and harder work is not always the answer—it rarely is. Worse yet, I feel resentment, frustration, and anger at myself and the job since I have been unable to tend to other priorities, particularly my artistic ones. Setting aside time for deeply focused work on the task and getting the highest leverage from those hours is a better approach—and making sure that those hours are forbidden after a certain time.

Meeting the metrics that set you apart is key for continued work and safety at a company. Metrics usually paint an impression; and if the colors used to paint are volume of pull requests, so be it.

Maybe you can relate. Are you in a role with a grasping, defensive energy? What objectives are you trying to meet? What can you do to stop spinning and start shipping?