In software engineering, it’s easy to criticize other teams.
Over a team lunch last week, my coworker Phil offered his thoughts on another team’s project, called Foobar:
“How hard can it be? […] Like, seriously. […] It took them a year and a half to build that?”
I’ve said things like that myself. A lot. In this case, though, I knew something about Foobar. The project really was harder than it looked.
It’s hard to appreciate how difficult a project can be. Difficulty lurks in the details. Learning details demands time we don’t want to spend.
It’s particularly hard to appreciate time spent on prototyping and experimentation, exploring paths that didn’t work out. The right strategies are obvious only in hindsight.
Some projects really may be as easy as they look. A simple exercise suggests, though, that reality is usually the opposite. Imagine describing your job at a cocktail party. I bet the description hardly does justice to the time you spend setting up and maintaining your dev environment, architecting systems, debugging unexpected failures, yak shaving.
Not to mention all the non-technical aspects that make a software project hard like poor management and confounding external factors.
Foobar had pretty much all of these things working against it. Practicing empathy for other engineering teams is hard, but important.