Don’t Hire a Smart Asshole

November 8, 2018

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

Call Out Risks Up Front

October 11, 2018

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.

Good Side Projects

August 26, 2018

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.

Assume Good Faith

July 26, 2018

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.

Embrace Language Idioms

July 12, 2018

Embrace the idioms of your language and tools. Write Swifty code with Swift, ObjC-like code with ObjC, Pythonic Python, idiomatic C++. Use git like git, not like Subversion.

If you are multilingual (both human and computer languages), you’ll often find yourself reaching for an elegant concept from another language which is not found in the language you’re using. You might be tempted to implement a solution using that concept, transliterated into the language you’re working with; but that would be as silly as transliterating a Chinese phrase directly into English, and expecting your listeners to have no difficulty understanding you.

For programmers, the recipients of your communication are the future maintainers of your code. Writing in a language’s native idioms makes it easy for them to understand and update your code.