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

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.

• #FridayDevAdvice

Someone smart once said: “If you don’t cannibalize yourself, someone else will.” This is often used to talk about a company’s products, but not often enough about a company’s internal engineering dynamic.

Group politics often stands in the way of choosing a rational course for the team. A powerful or popular personality who defends an existing product can become a formidable roadblock for newer, better technologies that are just emerging.

Organizations that consistently suppress superior solutions in fear of upsetting the big shots within their ranks are naturally doomed to mediocrity. They open the door for their competitors to fill the opportunity.

Leaders: make it clear to your teams that deference is not a virtue if it comes at the cost of missing an opportunity to obsolete yourself with a superior technology or product.

• #FridayDevAdvice

Incomprehensible code is unmaintainable code. Unmaintainable code is bad code.

Avoid code that violate customary idioms without having a very, very good reason for doing so.

“Cleverness” is not a good reason.

• #FridayDevAdvice