flickr.com/photos/kenfagerdotcom

Use technologies the rest of your team is motivated to use

For great justice

Nathan Herald
Jul 28, 2013 · 3 min read

This is an exposition of point 3 from Be a good programmer.

Most of my time is spent either reading or editing someone else’s work. Very seldom does one get to start from scratch when building something for the web – and even then we use frameworks and libraries we didn’t write. It’s very important that the code you choose to include in your projects is compatible with your colleague’s interests and motivations.

You may want to write a new app in go, but no one else does. Then don’t do it. Write a personal app in go or write the app in go, but don’t show them and rewrite it in whatever. It’s important to leave a legacy of making things easier. Someone in the future will curse your name during a git blame if you’re not careful. It might even be you.

Most of the developers I work with use ruby, rails, mysql or postgres, redis, memcached, git, etc all the time. Now, I’m pretty fortunate, because those are all awesome things to use. However, I learned this lesson more than once working at Livingsocial: don’t go against the grain unless it’s worth the friction. (It might be worth it, but make for certain.)

When I was planning out a new set of apis for their iOS app I had planned to use sinatra and redis. At the time, no team had needed a large redis install, so there wasn’t a master-slave readily available. The ops guy told me no. He said we hire rails people and we use mysql. I was pretty miffed at the time, I felt like I was being kept from doing my best work by being limited.

Sinatra and rails are both ruby, how different could they be? How hard could it be to install and maintain an HA redis setup?

It turns out the answers are: quite different and very hard.

When building a core service or library that will be used and modified by any number of people, it’s usually best to be a little boring about it. Sure, go ahead and prototype something in closure. But when it comes time to run something in production that serves millions of users, boring trumps clever almost every time. When you are away and no one else even knows how to run the tests in the app – well, that’s when they curse your name.

I’m not advocating that we never push things forward or try out new things. Instead, rally the troops and get everyone involved. If everyone on the team is excited to learn something new, then it won’t matter if you are there or not – anyone can jump in and take care of business. You will learn something new way faster if your colleagues are learning it too. They will discover things you didn’t, you can argue about best practices, and bounce things around so they end up the best they can be.

I. M. H. O.

The Editorial Page

    Nathan Herald

    Written by

    I work on products and drink coffee.

    I. M. H. O.

    The Editorial Page

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade