The Developer Manifesto

You Are an Artisan, Not an Engineer

An engineer makes something work. You are more than that. You are an artisan. Artisans practice a craft and may, through experience and aptitude, reach the expressive levels of an artist.

Approach your work as a master craftsman.

Style matters

Just because we're building infrastructure and tools doesn't mean it can't be cool, stylish, and fun. Aesthetic matters. See The Substance of Style.

Slick and fun meet powerful and serious.

Style is expressed through design and workflow. Workflow and design dictate architecture.

Never build anything without considering the workflow of our consumers or internal team. If the workflow is flawed, the architecture is flawed.

A workflow/design iteration can, and likely will, require an infrastructure refactor.

Maniacal Focus on Elegance and Simplicity

Passion and concern for your work are demonstrated by your work. A lack of concern for cleanliness is a strong indicator that you don't care.

A product that simply "works" is a prototype. A finished product should be considered a work of art that you want people to admire.

Take multiple passes to consider ways to make your code more expressive, elegant, and clear. It should be obvious to the next person who looks at your code that you care.

Finish the Job

A product is not finished when it simply "works". A finished product should be clean, documented, and tested.

If the product is a web service, it should have, at minimum, a CLI to manage it. Sometimes a web UI is needed.

Your product is not finished if you are the only person who can use it. You must have produced the necessary tools to manage the product, the documentation to reference, and have demonstrated it to at least one other person.

Timing is Everything

If you're building something and just can't seem to get it right, maybe now isn't the right time. You learned something in the attempt, set it down for a while. Maybe in a few weeks or months, you (or someone else) will pick it up again and find that the world has changed in a way that makes it the right time to build the thing.

Throw It Away

It's not the code that is valuable. It's the understanding you've gained from building it. See James' startup school talk.

Never be afraid to throw something away and do it again. It will almost always be faster to build and much better the second (or third, or Nth) time around.

Everything is an Experiment

Anything we do – a product, a feature, a standing meeting, a workflow or collaboration tool – is subject to change. That includes discontinuing or shutting down whatever the thing is. Ending an experiment isn't a failure. We often learn the most from experiments that don't produce the results we wanted.

Question Everything

The status quo is never good enough.


Use Your Intuition

Hunches guide you to places to create new value in the product. Users don't really know what they want. Creating products people love requires treating product development as an art, not a science. But products have to solve real user problems.

Understanding the impact of product changes to an existing product is best done by studying the data. When you have a mature product and many users, you have lots of data on how they are using it. Use that data to make evidence-based decisions.

Don't just do something because a customer "needs" it. Be wise, use your intuition. Work to understand the real problem and design a solution that solves their problem in the best possible way, perhaps not the way they thought.

See: Inspired: Created Products People Love

Create Value

Value is created when we endure pain on behalf of our users. For instance, the SSL process, in general, is painful. Our customers perceive value by the ease of use. For us, that means solving painful problems for them.

Empathize with our customers. If they are feeling pain, we have an opportunity to create value.

Be cautious. Sometimes a user's pain is self-inflicted and could have been avoided.

Trust is Earned

Trust is not a right, it's a privilege.

Trust is earned by:

  • Walking the trail of tears with each other, even when we are only capable of providing emotional support.
  • Making responsible decisions, and not expecting someone else to bail you out.
  • Volunteering to help, even when the timing is not ideal.
  • Making yourself available to assist during off-hours in the event of an emergency.
  • Writing stable code and being available to fix your bugs, even sometimes after hours.

Trust is lost by:

  • Letting others bear the burden of supporting your code.
  • Not being available to assist with an emergency and not planning with someone else to cover for you.
  • Intrenching yourself and defensively arguing your position, forcing others to code around your rigidity.

Ownership, Not Consensus

Every product, feature, software component, web page, business deal, blog post, and so on should have a single owner. Many people may collaborate on it, but the owner is "the buck stops here" and makes the final call on what happens with the owned thing.

The owner can, and should, collect feedback from others, but feedback is just that – input the owner may or may not choose to incorporate into their work. If something doesn't have an owner, no one should be working on it or trying to make decisions about it. Before those things can happen, it has to be owned.

Ownership can't be given, only taken. Ownership can't be declared, only demonstrated. Ownership begins with whoever creates the thing. Later the owner may hand it off to someone else. If an item gets dropped for some reason, it's fair game for anyone else to pick up.

Apple's term for an owner is "directly responsible individual," or DRI.

Ownership may be superseded or even revoked when:

  • Any of the aforementioned principles (style, workflow, elegance, simplicity, completion) are not observed.
  • The goals of the thing or project are not in sync with the vision of the company.
  • The decisions of the thing or project do not take the scale or growth of employees into consideration.
  • The owner does not recognize the perspective of other projects that will interact with the owned thing or project.

Trust and ownership are inseparable. You cannot own a project or thing if you have not earned trust from the team.

Ignore the Competition (for the most part)

We're not a "me too" company. We innovate and trust our process. We don't make decisions to copy someone else.

At times standards and conventions are established by competitors and observed by the community at large. We cannot ignore these standards just because a competitor established them.

There are times when we need to make a strategic move to position ourselves in the market. This positioning is relative to the competition. We may incorporate features to apply leverage.

Competitors have good ideas too. Borrow them if they fit.

Strong Opinions, Weakly Held

Have a strong opinion and argue passionately for it. But when you encounter new information, be willing to change your mind.

Be blunt, honest, and truthful. Constructive criticism is the best kind. Avoid keeping quiet with your criticism about someone or something for the sake of politeness. Don't say something about someone to a third party that you wouldn't say to their face.

Be honest with yourself about your perspective. If you recognize that you are arguing for the sake of argument, withdraw from the debate.

If you recognize that you do not understand the entire perspective of those within the debate, speak up. Often times we don't understand the problem that is being discussed. If you find yourself in this situation, speak up. You cannot participate in a debate about solutions to a problem that you do not understand.

If you recognize that you are arguing for "no change" or for a solution that is easier (but not necessarily right), you should withdraw immediately.

Own Up to Failure

Did you make a mistake by posting to the blog at the wrong time? By failing to document the feature before you shipped it? By screwing up a customer's app? By not respecting someone's ownership, or hurting someone's feelings?

Own it. Admit your mistake, apologize, and feel the failure to make sure you learn from it. Then, get back to work.

Be Passionate

We are in a very fast-paced industry, and nothing will stand still for long. Even as Nanobox continues to grow, there will be a need for a startup mentality. As you continue to work for Nanobox, you should be driven by a passion for change, improvement, and making better workflows and tools for developers.

If you aren't passionate about Nanobox, it's ok, we can help you move on to a better fit. When you are, there are no limits here for what you can be, do, or how far you can go. Love what you do and be happy.

Note: This was inspired by a similar document created by Adam Wiggins. Some content has been borrowed.

This is required reading by anyone who is hired as part of the team at Nanobox. We've all read it and we do our best to adhere to its guiding principles.

Posted in Nanobox, Development, Developer Stories