As the engineering profession becomes more inclusive, we need replacements for terms that may conjure up prejudice or bias. Here are some suggestions for improvements:

What other terms can you think of?

• #technology
• #opinion
• #FridayDevAdvice

You may be tempted to hire a smart asshole into your team. Think long and hard before you do this. Don’t underestimate an asshole’s natural ability to ruin your team’s morale; to intimidate junior engineers; to become territorial about code and ideas; and to turn a productive hallway into a toxic environment.

Is an asshole’s genius really worth more than the loss of a good team dynamic? In twenty years I have never seen a single instance where a team wouldn’t be better off without them. Your odds are probably about the same.

Great reference: The No Asshole Rule

• #FridayDevAdvice

When recommending an architectural or strategic direction, be sure to prominently call out the major risks involved in your proposal.

You might be tempted to paper over the risks involved in your proposal, probably because you think others will be more attracted to your plan that way. If you do this, you will appear dishonest, because you are.

An honest engineer is ready to acknowledge that all proposals carry risk. Calling them out up front shows that you have nothing to hide. This—maybe somewhat paradoxically—will lead other engineers to trust you more, not less.

• #FridayDevAdvice

A really fun kind of side project is one that is barely related to your product, yet still in the realm of potential usefulness; something that makes your colleagues say “that’s might be cool, but we’ll never get funding for it”.

Not only are these side projects great fun to do (because of their inherently fun and toy-like nature), they often give you deep insights about your main product, and help widen your team’s imagination of what is possible to implement.

• #FridayDevAdvice

Don’t assume bad faith or incompetence based on someone’s technical error. This is doubly important when it’s someone from another team or department whom you don’t know too well.

Remember that there exists a “base rate” of error-making, i.e. the rate at which every engineer makes mistakes, no matter how hard they try. Once in a while, even the best engineer will make a glaring error that in hindsight was entirely preventable.

Instead of offering if-only commentary on the author in question (“If only they’d show some pride in their work!”), remind everyone that we are all fallible. Hopefully, the same courtesy will be extended to you in the future.

• #FridayDevAdvice