Oct 27, 2024

<aside> 💡

Don’t let your feelings get in the way seeing a project’s impact and time-cost.

</aside>

Ever since I started working at Bloomberg, there’s been one task that’s annoyed me on end. I’ve finally made my peace with it and I wanted to share some thoughts.

I’ve been working on a front-end feature that has a pretty manual deployment process. Whenever I pushed a change, I had to manually deploy assets spread across three repos. I think it’s best practice for code merged into main to get automatically pushed out, so this was bugging me.

I tried on separate occasions to get this to work. I looked into our CI/CD system, did a deep dive into the underlying technology, emailed people who were more familiar with the legacy library we were using, but I couldn’t figure it out.

After I read a productivity post from reddit, I realized this was a case of low-impact work with a high time-cost.

The impact is low because even though deploying the code manually to dev annoys me, it honestly takes a minute of active time— maybe five if you count the time to build the assets.

Does it take time out of day? Yeah, it does. But if I take steps to not distract myself in the four-minute build time, like scrolling social media, then it’s not that much of a detraction. In fact, a water break would be great. Even if I multiplied over the number of devs who could be impacted by this CI/CD improvement, I don’t think I could’ve saved more than three hours of active time per year.

On the other hand, the cost to effect this change was high. I had already tried to learn more / fix this, so clearly it wasn’t a trivial change that I could solve in a morning. Two things were against me: (1) it was a legacy CI/CD system that didn’t have up to date documentation, and (2) it was in a technology that I wasn’t familiar with. If I had really wanted to improve an internal tool and it was in something like React or Python, then I’d feel comfortable jumping into the code head-first. But this wasn’t. I would’ve been trying to learn both a new technology and the specific legacy flavor that my org uses.

It brings me relief to write this down. Next time I get annoyed with the deployment process, I’ll remember the rationale behind why I shouldn’t make the change.

My broader takeaway is if something takes more than an hour of free-time to do, you probably should scope it out like a ticket.

I’m not saying we should engage in bad practices. There are certainly things tasks you can do that have a high impact to time cost ratio. Documenting how to run, test, and deploy your code falls into this category.

My gut instinct now is that if there’s something you could do that would impact many developers, then it’s probably non-trivial to do. If it were, somebody would already have done it– unless you have some sort of domain expertise that makes it easier for you. If you’re working at a company where you’re delegated sufficient responsibilities, then you probably don’t have the bandwidth for a non-trivial fix either. In which case, the most appropriate course of action would be to talk to your manager to decide (1) If the time saved would make the project worth it and (2) What a POC would look like.

In fact, that happened on a team that I know. The developer saw a gap in our testing procedures, so he asked his manger for sprint cycles to develop a testing framework that his team could use– with the potential to help other teams in the org. After a successful POC, he got more buy-in and management gave him other devs to help out.

Is this less flashy than my impression of a startup, which is that they’d hack away at anything? Yes. Some might say it’s more bureaucratic.

But I think this is a good case of having organizational approval and systems. It’s there to ensure that we’re aligned on what’s important to do.

We should all strive to become great at technology. Then we can implement fixes that others thought impossible to do in a short amount of time.

When we lack that technological expertise, we have to fall back to the meta-skill of work prioritization.