Dev Rules to Live By

A bit of a departure for the blog this week. First, we're trying the article feature on LinkedIn. Second, instead of talking about the wine business, we’re going to talk about the software business. We need to start with throwing some credit to Elizabeth Schneider from Wine for Normal People. When we started down this wine focused path, her podcast was our first tutor. Just as she endeavors to bring the wine world to normal people, we endeavor to bring tech to normal people. 

These rules come from Les Makepeace and Yuanming Chen (founders of MyWineList.co). Chen is the CTO and the best developer in the world, seriously. I’m (Les) the product nerd. I’m thankful every day to work with world class developers.

These are meant to be aspirational, not doctrinal. Nobody is perfect, no software project is perfect. This is what we strive for, and what we think software teams should strive for, especially when the end users are “normal people”.

#1. Make it easy for them: If you can make the user experience easier, then do so. Wasting the users time is a good way to lose users.

#2. Focus on code quality: When writing a piece of code, be diligent with code qualities, even if it is something that’s often invisible to end users. The belief is that “quality pays”.

#3. If a user is having trouble using, it's our fault, not theirs: Users don't have our tech expertise. If they did, they wouldn't be buying our software. If a user is having troubles, there are precisely 2 appropriate responses. 1 See rule #1. 2. Aggressively and quickly help them through the issue, and feed the problem back into the dev path to look for ways to avoid in the future.

#4. Fix early: Always try to fix a bug at the earliest possible moment. It will also lead to happier customers. In addition, if a problem is addressed at a later time, the developer might need to spend way more time later to refresh one’s memory on the bug.

#5. Functional is more important than Pretty: We can always go back and make it prettier. Missing or broken functionality will drive users away faster than lack of prettiness. We do eventually need to improve prettiness.

#6. Empower the team: Invest time on empowering other stakeholders to do administrative tasks or any repetitive tasks. Don’t waste the time of talented developers on things that can be handled upstream. Do the dev required to enable this.

#7. Users are overwhelmingly “Normal People”: Two points here. First, they're people, and deserve our respect and consideration. Second, they generally aren't conversant in dev environments, languages, APIs, or "the stack". It's unreasonable for us to expect them to be.

#8. Use the right tools for the job: There is a tendency, for anyone, to gravitate to the tools they already know how to use. Don’t fall for it. Pick the best environment, language(s), stack, for the task. The team will be better served learning some new tech in the beginning than fighting the wrong architecture for the life of the project.

Please add yours! We can all stand to learn how to serve our "normal" customers better.