Coding in Anger - Adventures in Quality of Life

During a tech meeting at work, my manager started off an explanation with "It's been a while since I've coded in anger, but...". This simple sentiment really resonated with me. Often times I've made the argument for particular choices that ultimately enhanced quality of life, but I've lacked the ability to properly articulate why those choices were beneficial even if the surface value seemed to be that it would make my life easier. That simple phrase has given me a lot to think about in terms of framing the justification here.

I've heard the argument that your user doesn't care about your test suite, or how easy it was for you to write something. While I think there's merit in such an argument, the black-and-white perspective of it simply makes it untrue. There's an implication that we should consider ourselves lucky when we get to do things like test drive, pair program, use good tools, and make good architecture. It's like we as engineers are compulsively driven to want to put things in nice and neat little boxes for organization's sake. When we can't do that or something disrupts the organization, we throw a tantrum because we're simply children. While I believe there are certainly cases where this applies, it's blatantly incorrect to paint all of us under such a stroke.

The thing is we get frustrated and angry at our cools, codebase, process red tape, etc because it hinders our ability to perform. If I'm too busy jumping through the hoops of broken framework X then that means I'm not delivering awesome stuff. Instead it usually means I'm writing harder to maintain code. When something is hard, it doesn't get done. Or at least it doesn't get done as much or as well. Sure, you can build entire empires on PHP, but by that reasoning it means the next grand project akin to the Pyramids of Giza can be done without any modern trappings, right? If logs, rope, sweat, and blood were good enough for them, then it must be good enough today, right?

A software shop should fight tooth and nail to stay on top of the curb. Does that mean we have to go back and rewrite? You betcha. But if our technical debt is reduced, if the engineers are able to get closer to the features or pull out 3rd party modules to assist in development, then isn't that a big win? Avoiding rewrites is a lost cause. How many banks are glad they are still running on COBOL today? Sure it was probably great at the time, but that time has passed. Everything we use now will eventually become archaic and dated. We may as well embrace the idea that code is a living document that needs small and big adjustments both over time. Does that mean we should jump on every shiny new framework the moment it comes out without evaluation? Of course not, but this entire "suck it up and get back to typing" attitude needs to go. Your user might not care if you're using punch cards to enter your code, but they certainly are going to feel impact of such a choice.

Something to consider.