Happy Friday!

Last night my wife and I went to a concert and while we were walking from our car to the venue we saw a special VIP parking area guarded by a teen. The teen was sitting on a stool behind a large orange cone, and a few feet away another large cone stood to block traffic.

Then a car wanted to leave. So the teen sighed, hopped up, walked to the far cone, and moved it out of the way. After the car left, he moved the cone back, and sat. I remarked to my wife he could just move the cone closest to him a little closer to the middle then he'd only have to move that cone and not walk back and forth each time.

Yep, I'm a fun date.

Ever since the book The Phoenix Project popularized the Theory of Constraints in IT, many times people have talked about optimizations especially around bottlenecks. Folks have also mentioned that small, local optimizations aren't as useful because they don't address those bottlenecks. Either that, or implied a local optimization is self-serving and not a priority.

I love local optimizations.

Consider a team that is working hard, but like most I see, they struggle to complete a good amount of work every two weeks, and what they do complete is full of problems compounded by a slow and painful release process that adds even more distractions. Which is the better investment, addressing the faulty releases or spending time configuring and getting really good at using our IDE?

While I won't deny addressing the releases will have a big business impact, it will also likely be slow, hard to change, and complex. Making a change to how you use your IDE will be comparatively quick, requires no permission, and will have immediate benefits.

Now, this isn't a newsletter saying you should only do small local optimizations, I'm saying do both.

Often the more critical issue is a large and slow change which leaves plenty of space in-between to make many small improvements. Those small improvements can compound quickly and create a massive difference in quality, team morale, and my favorite, getting good at improving things.

I remember I was working with data scientists who needed help with some code they wrote to analyze a ton of data. The code was really slow, so they just wanted some extra help. Other devs pointed out they used a slow language, or that it ran on a slow machine. I dug into the code itself and looked at where time was lost. It turns out that a really small thing that was getting used millions of times in aggregate was taking the most time, even though each individual invocation was milliseconds. I made a few small tweaks, and suddenly, those little things took nanoseconds, and the code went from needing to run overnight to running within 2 hours.

Nobody would believe that tweaking a small thing that wasn't slow would compound to such a huge benefit, but that's what local optimizations can do. They can be quick to bring in, and you can get the benefits over and over again.

So, when you're looking for something to improve, don't overthink it, just fix something!

Sincerely,

Ryan