Trevor Broaddus

March 5, 2021

Potentially Problematic Problem Petting

This has been on my mind for a while, and is also a little fresh (as in I'm emotional about it). Here goes:

Don't take care of Problems like a pet, like you want it to stick around for a while and keep you company.
Get rid of them. Fast. Faster if you can.

Ok. Maybe you can't. Perhaps maybe there is some ornate reason the Problem must stick around. Maybe. In that case make a plan to get rid of it.

Context

I have been on dev-teams and worked with people who seem to try and keep the problems that plague their application code around like they belong there, like they pay rent or something, like they are cute and cuddly and only want a solid belly rub every now and then.

The conversations typically involve "hard to read" code that "behaves really weird sometimes" and "doesn't have good documentation or specs written for it". To add to that, no one endeavors to add documentation or add clarity.  Thats the real kicker, inaction.  Now, sometimes it is for very good reason that the Problem has stuck around.  Perhaps time constraints or small team-size may be at play. Other times it seems that there is something keeping developers from solving the darn Problem. In any case, if there isn't even a plan forward, it can be super unhealthy for a dev-team.

Humility

I've done it. And when I have experienced this in myself, I am typically feeling vulnerable about putting a solution out there that tries to fix the Problem. What if my solution becomes the Problem? What if I cluelessly submit code that misses what the Problem actually is? What if it isn't a Problem and I am just making it one? Heck, like this post for example. Is this really a Problem in the Software industry and on tech-teams?

Resolution

Move forward. If you're not taking action then you're taking a step back. Don't do thatDo something. Anything really. It doesn't even have to be much. Most recently, I saw an opportunity to add documentation around the important parts of a rather large Rails application (v5.2 thanks for asking). My on-boarding experience led me to want to pursue this. It wasn't a bad experience but it could have been better.

The Problem: There are large parts of this application that are super important. Let's write those down somewhere and share it with new/existing team-members.
A Solution: Schedule meetings with anyone willing to talk about the application and its important parts.
The output: Something written down.

In the End

When you have identified a Problem, write 2-3 things that you could do that day to move the needle forward towards removing the Problem. Especially if more than just you has recognized the problem. Hey! Your first step could be asking "Does anyone else experience this Problem?"

Problems aren't pets. They are weeds and they will negatively impact your application the more you let them grow.