Don't say "can't"

One of the phrases I regret using the most in my early career is “We can’t do that, because…”, at least with respect to making certain technologies work.

Working at a smaller-sized company, I was often tasked with coming up with a “quick and dirty” solution to get things back into a working state. I began to notice that quick and dirty solutions lived up to their name: They were quick(ish) and they were DIRTY. After seeing many of these haphazard fixes fall apart, I began to dread to being assigned a task of the flavor “get it working”. The easiest solution was to simply impress upon management that the type of task they were asking for wasn’t possible. By that, I meant that it wasn’t possible to “get it working” in a tiny amount of time, because the end product would never truly be “working”.

However, the read from management on this news was---for some unknown reason---never to try and tease apart my mental distress at being asked to perform my work duties. Instead, the conversation went something like this (with some details left out for brevity and discretion):

• Manager: Our internal dashboard website sets static config variables at startup; how do we change these variables on-the-fly?
• Me: We can’t. That’s the way the startup was written.
• Manager: We could restart the website each time the configuration changes, I suppose.
• Me: I guess that would work. That does seem like a hassle though. But, if we wanted to change the variables on the fly, we would need to re-code a large portion of the website.
• Manager: So, it would derail our development to implement a full solution?
• Me: Yes, but it would probably be best in the long run…

Best (or worst) practices aside, my approach to these types of conversations was almost the inverse of a productive conversation. My approach was to:

1. Confirm that the problem “couldn’t” be solved
2. Acknowledge (and dwell on) the proposed “hacky” solution
3. Provide no golden path to a working solution
4. Begrudgingly accept the “hacky” solution as if I didn’t just help solidify it

The above is a great set of steps to make yourself and your manager miserable. These steps start with the word “can’t”. Indicating that a task is impossible is a good way to invite a whole host of workarounds and bad priorities. If your manager is asking whether “we can do X”, oftentimes what they really mean is “what is your solution for problem Y, which X would solve?“. When you say “We can’t do X”, you are relaying the false premise that the only way to solve Y is with a subpar practice. After all, if X was the straightforward way, and X is impossible, where is there to go?

That final question is the key to eliminating the word “can’t” from your vocabulary. If problem Y actually can’t be feasibly solved (e.g. if there are hardcoded values on site startup that need to change), stop dwelling on problem Y and think of a solution that would make problem Y go away. If you really can’t see a solution, instead of “there is no way to change the hardcoded variables without a site rewrite”, simply ask for a bit of time to scope out the problem. When you have an answer in hand that addresses the problem in a principled way, present that answer as a solution to Y, even if it is actually a solution to the cause of Y. If this solution is too costly, don’t make the cost the initial pitch. Negotiate down to a moderate solution, instead of negotiating up from a “first sketch” dirty solution.

In essence, stop playing the devil’s advocate for bad solutions. If your company and manager value working technology (and they almost certainly do) they will prefer a cleaner solution over a dirty one. Give management a justification for taking the better path. You are doing everyone involved a disservice by focusing on the increased workload required for doing things right. If working software is the goal, then you shouldn’t come out of the gate trying to compare how much effort will be needed for a working clean solution and a working “hacky” solution.

This may sound like generic or obvious advice. Maybe it is. It took me a couple of years to realize I was falling into this trap, and another year or so to correct my behavior. I will also say that company culture plays into this a lot. If the quick and dirty solution wins out over and over, there is less incentive to fight for the correct solution. In that environment, it can seem like management will want to hear about how much time the correct solution will take, because time is tight. Don’t assume this. In retrospect, my experience in a smaller, faster-paced company was dictated largely by assuming that because there were hacky solutions in place, my cleaner solutions (that required more effort) were unwelcome. I rejected the right solution before fighting for it. Moving forward, I try to treat management like they want what I want: Clean, working technology. In pursuit of that goal, the question is “What can I do”?

Now, sometimes the clean solutions really do get shot down. In those situations, sometimes just solving the problem on your own time is a worthwhile pursuit. This obviously depends on the size of the problem and the surrounding architecture. Don’t give up work-life balance for a cleaner solution. But, don’t compromise if you don’t need to. Unless you really can’t solve a problem due to real limitations, focus on what you can do. That way, when you say (either to yourself or your manager) that you can’t solve Y, you know you mean it.