In this installment of ‘metaphors’, coincidentally the first installment, I’d like to talk about how we talk about the work we do on-the-whole. Also, please forgive me for all of the quotation marks, but I think they help the readability. If you ask an average software engineer about their day, they’ll usually say something like “I’m making a site” or “I’m building a web app” or “I’m fixing some bugs”. All of these phrases are forms of “construction” and/or “building” metaphors that make it seem as if we’re hammering or welding something into a cohesive whole that has a state of “finished”.
One of the first things you learn when you become a software engineer is that you don’t “finish” things. And before your mind jumps to artistic metaphors like “Well, an artist never sees their work as finished”, we all know that we’re not held back out of some form of artistic integrity. Instead we’re plagued by security patches in the technology we’re leveraging, changing requirements from the product owners, people with different technology preferences coming/going from the team, the never ending waves of bugs, and the monstrous amount of technical debt that is looming behind every project. If you’re thinking, we actually don’t have a lot of bugs, then you need better QA; if you’re thinking we don’t have a lot of technical debt, then you’re not thinking about your code enough. No project is ever finished until it’s zero lines of code written down on a piece of paper, there’s always O&M, there’s always some patch.
I heard somewhere this idea of referring to our work as gardening. I’m not sure where I heard it, but it kind of stuck with me. I like the idea because it changes how we approach communicating about the work we do in the office. It’s much easier to make an argument to refactor code, why you need to perform O&M, or to explain why some things take longer than others, when you’ve never referred to your work with construction metaphors. If we start to say, “I’m laying down seeds” instead of “I’m building the initial framework”, we’ll have cause to go back and thin out the unnecessary functions and rearrange things in our “garden”. Or if we say, “I’m going to spend some time replanting these functions into a better environment” instead of “I’m going to build out these functions into another space”, we can avoid the question of “Why was it built there at all?”. And so on. I know that it’s not that simple, and it doesn’t fit every situation, but small culture shifts can have huge impacts over time. I’m going to try this one.
