I came up with the following while reading Ben Horowitz’s book The Hard Thing About Hard Things. I highly recommend reading the book.

He has a section in the book where he talks about setting standards for his team of product managers. Here is his original document. Below is my adaptation based upon the standards I would have in place for any software developer working for me. Note, the last two are taken directly from Ben’s list.

A good software developer assumes that the Client is an expert in their field, and that she is a very intelligent person. A bad software developer assumes that the Client does not know what she is talking about because she doesn’t understand technology.

A good software developer makes expert suggestions about technology and design options. A bad software developer tells the Client she is wrong.

A good software developer communicates clearly in a way that is native to the listener. For example, if she is talking with someone on the East Coast, she will go out of her way to provide times for the Eastern time zone. A bad software developer communicates using technical terms and jargon and expects the Client to make the effort to understand her.

A good software developer creates software that is simple and powerful for the Client to use, despite the complexities in initial development and maintenance that that may entail. The software she creates will be used many times per day, and only created and maintained a handful of times. A bad software developer creates software that is easy for her to create.

A good software developer makes opinionated decisions based upon expertise, experience and knowledge of the business and client. A good software developer owns the “how” of creating great software. A bad software developer asks for a detailed specification for every decision and stops moving forward until she gets it.

A good software developer knows that sometimes you have to incur technical debt and you always have to pay it off. A bad software developer ignores technical debt, leading to shortcuts, fragile solutions and a future of putting out fires.

A good software developer asks questions. A bad software developer makes assumptions.

A good software developer builds the best possible solution for the Client. A bad software developer builds either the easiest possible solution for herself or the funnest possible solution to build.

A good software developer adopts new technology as it makes sense. A bad software developer either sticks with the same technology long after it is relevant or flits around between new technologies like a hummingbird.

Good software developers err on the side of clarity vs. explaining the obvious. Bad software developers never explain the obvious.

Good software developers define their job and their success. Bad software developers constantly want to be told what to do.