Josh Sherman
I’ve been a professional software engineer for just shy of half of my life. Along the way I’ve had the opportunity to work with a ton of different people and personalities.
A common theme with most developers is that they really like to do things their way. This tends to result in combativeness over code feedback and just a general “you’re wrong, I’m right” mentality.
I’ll save you the trouble on calling me out, I know I’ve been that guy, especially in the early days of my career. Fortunately, I’ve tried to drop the dogmatic opinions and strived to be more of a “go with the flow” type.
If a team I’m joining has collectively decided on a best practice, I assume they have already put a ton of thought and debate into the topic before they ever came to that conclusion.
Often times the things that have been agreed upon are fairly trivial and/or could be handled by a tweak to my editor configuration. I don’t always agree with stuff, but I know there are more important battles that can be fought (reads: I disagree and commit).
That’s not to say that I don’t try to shift the tides from time to time, but I do try to make sure that I understand the reasoning that went into something first.
It’s always good to approach these conversations with kids gloves on. This is especially true when the battleground is either a chat room or over email.
That said, nearly every damn time somebody new joins a team, they ask the infamous question:
Why would they do it that way?
Some times it’s sugar coated with the even more infamous line, “I’m not trying to be a dick but…”, that somehow has the magical power of absolving the next statement of all of it’s grit and aggression.
To answer this age old question, the reason that something was done a certain way is because it made sense at the time.
I know, shocking.
Rarely do people go out of their way to purposefully fuck a system over. Decisions get made, usually they are discussed ad nauseam before hand, especially if anybody has any apprehensions about the approach.
That doesn’t mean that the code is perfect or the approach is ideal. It means that at some point in history with a particular version of the team, that was the best solution.
If you were asked today why you did something a certain way 5 years ago, would you try to justify things? Would you utter the words “well at the time…”?
“Because I was young and stupid” is a catch all for so many of people’s bad decisions yet for some reason the same logic never seems to be applied to engineering teams.
That’s not to say that you shouldn’t question things either. It’s healthy to ask questions and to wrap your head around different parts of a new system.
Questioning things early will give you a sense of whether or not the team is moving their system forward or just doing things “the way they have always been”.
You can usually get a feel for this as early as the interview process.
Just don’t be a dick about it.
