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.
