I’m watching the New York Yankees play the Kansas City Royals on a pleasant summer afternoon. Giancarlo Stanton hits a high foul ball that drifts to the right of first base. Kansas City’s Hunter Dozier is tracking it, battling the sun and wind to try to catch it for a quick out. He winds a little left, a little right, and eventually lunges forward only to have it drop just out of reach. An excited Yankees fan, in the stands just behind the protective netting, leaps to her feet. She points and (reading her lips) shouts, “you suck!”
It wasn’t until into my adult life that this behavior came to strike me as odd. At any given time, there are about 750 people playing Major League Baseball. These are the best baseball players on the planet, the top 0.0004% of human beings to play the game, and we casually proclaim that they “suck”.
MLB umpires have a strike zone accuracy (called balls and strikes) of between 88% and 97%. That’s quite the success rate when you consider that they have less than 0.5 seconds to determine whether or not a baseball has broken a 3 square foot plane. No small feat and yet, we’re quick to (virtually) berate them when they miss a call.
With perspective, this behavior looks ridiculous but we all get excited. Caught in the moment, we’re emotional and reactionary.
You see similar behavior in an immature engineer. “Who wrote this?!” “This code sucks!” “This needs to be re-written.” It’s no different than the fan’s “you suck” because, like a player battling the elements or an umpire with a split-second to make a decision, the developers that came before you had their own factors and time constraints to reckon with.
The culture of this profession places a substantial emphasis on ability, which tends to feed egos. Whether of outsized or undersized self-esteem, developers face the (perceived) pressure of demonstrating that ability. That delta in our self-esteem can manifest as a form of aggression that is detrimental to both ourselves and our teams.
It’s essential to maintain perspective. The circumstances that lead us to make choices are many and varied. In most cases, we’re doing the best that we can with what we have in the time that we have to do it. Software evolves, it grows and contracts, with these choices. Inevitably, that process can be messy at times. The developers that came before you faced constraints that are likely unknown to us now.
It’s unlikely that the who in “who wrote this?!” is in the top 0.0004% of software developers in the world. It’s also unlikely that the choices you see implemented were the result of gross incompetence. By maintaining the perspective that an implementation is the product of choices within constraints, we relieve a lot of the frustration that we might otherwise feel.
Image: Baseball / CC BY-NC-ND 2.0 Peter Miller