When using imperfect tooling (hint: this is always) you have at least 3 choices:
- throw it all away and write it all over again, yourself.
- begrudgingly trudge through it, loudly bemoaning the imperfections and about how “you’d do it differently”.
- accept the system for what it is. Readily work through its warts, grok its topography, and slowly become an agent for positive change.
Option 1 is easy but usually the worst: you may be getting rid of the bad parts of the codebase, but you’re also getting rid of the good parts. It’s actually even worse than that, since you’ll be creating your own brand new bugs and warts.
Option 2 is also attractive: people love to complain when situations are non-utopian (hint: this is also always). You may be getting your work done, but being loud about your disdain makes it hard for others to empathize with you (it’s hard to love the complainer), and doesn’t actually improve the state of the codebase.
1 and 2 are so appealing because it’s easy to acknowledge that all software is mutable, transient, and was written by some human or group of humans. It’s easy to want to reinvent, or to complain about its state.
What’s harder and much more wizardly is Option 3: see the tooling as a relatively permanent fixture that you can work within. There’s no sense in radically changing it: others have already put the time and work into it. It’s here to stay.
Looking at any open source project, we know the difference it makes: there’s fellow who loudly bemoans on IRC “yeah I’d totally contribute, but Perl? geez. maybe if we rewrote it in Rust” or “mocha is a way better test framework because x, y, and z”? Then there’s the fellow who isn’t engaging at all in those negative conversations and is instead making commits, filing pull requests, and actually improving things instead of griping?
I think this comes down to those who are able to maintain focus on the real problems, and those who are avoiding them. When someone views a given problem as “I want to solve X, but framework Y is annoying and has problems [Z]”, you’ve actually just created an additional constraint for yourself: “I must use the set of libraries and frameworks and methodologies that I like the best”. Now you have two problems to solve.
Maybe “imperfect tooling” is a way for our frightened minds to say “different tooling”. What if instead we learned how other communities worked? If we were open to accepting new and differing ideas? If we got our hands dirty with an unfamiliar codebase with unfamiliar ideas and unfamiliar people, and watch ourselves come out of it having learned something new?
Embrace the problems and challenges for what they are. Don’t hide behind pillars and fashion excuses behind the confines of familiarity and comfort.
