reminds me of a lesson taught by a chef early in my career. For one, he came on to the team not introduced as the new chef, just another cook. It wasn’t until a week later was that announced. It wasn’t a trial, it was what he requested.
One night over a beer and a heated chess match, I asked him why did he do that. The primary reason was he wanted to see how people worked naturally, not “being on their best behavior.” The other reason was the one that has always stuck with me.
He said often chefs come in and want to change everything. Often that’s why they were hired, a failing restaurant, be it critical failing, finacial, or usually, both. But he said knowing why something is done a way is often the key to knowing what to fix.
That has stuck with me in every aspect of my professional life. It’s easy to say something is broken, or being done wrong, but unless you understand how it got to that point, you aren’t wholly solving the problem. Understanding the underlying issues that created the undesired result prevents you from repeating the failure.
So next time you read some code, or start a new job and see someone doing it wrong, don’t jump to conclusions. Rather, if you truly want to fix it, follow it to its source and know why first.