Do What You Can

As a software engineer, your job is to convert business ideas into code. Business ideas that drive revenue up. These ideas often come from teams that study market trends and customer behavior. Business dictates what you work on, meaning you don’t have much control over what you work on.

Market trends are constantly changing. To keep up with that corporations have to shift priorities to stay profitable so they don’t end up like BlackBerry or Blockbuster. Due to these rapid shifts, what you work on again isn’t in your control. The project you’ve made a lot of progress on has been axed. The feature you just deployed no longer targets customers that don't capture the market anymore. It needs to be reworked.

The point is, you don’t control most of the work that comes your way. What you want to work on won’t always align with the needs of the business. And for a business, its needs are the top priority.

So, how do you work on the things you want to work on? How do you work on things that interest you? All while you make progress on the important stuff. The stuff that makes the money.

Narrow your scope. Find what you can control. Then do what you can.

Documentation for the services you maintain is a good area you can always focus on. I’ve never heard anyone say “we have enough good documentation.” There’s almost never enough documentation because it was most often an afterthought rather than a requirement. That’s an area you can work on.

Manual tasks that you perform to remediate some customer issues. Maybe it’s restarting a batch job, calling a REST API again to process data again, or sending a missed event on Kafka. You can write a CLI application in whatever language/framework you want for this. You not only improve developer productivity but you got to work on something you wanted to, with the tools you wanted to.

Another thing I have never heard is “our test suite is robust and tests everything we want.” Some tests are more fragile than glass. Change one line and thirty tests break. Maybe you only coded the happy path for your end-to-end tests due to time constraints. Perhaps, you don’t have integration tests (why?). This is a fine opportunity to experiment with test frameworks while improving the quality of your code base. No one ever complained about having too many good tests.

You have to actively seek out these things. They’re not obvious. If they were they would have been better. So find those small unnoticed inconveniences and do what you can.

Thanks for reading the article. If you enjoyed this and would like to receive similar articles, please consider subscribing. It's free, and I won't ever spam your inbox. Share on Twitter.