Why every developer should have a creed

As a developer we rarely have time to think about the nature of our work, how we actually want to work together with our co-workers and mates and what we wanna stand for. In short - our work ethics. We are stucked between meetings, daily standups, reviews and all kind of deadlines for all kind of different projects, specifications, documentations, research, bug hunting, testing, deployments and informing ourselves about the latest tricks and trends in tech.

Nevertheless or maybe exactly for this reason, everyone of us should spare some time to deeply think about how we want to work together, how we want to treat each other and what we truly believe in. Within this challenging and sometimes stressful environment it's hard to overestimate the value of common values and principles. Working together in a way that empowers every individual to fully exploit ones potential to the benefit of everyone else is tremendously important in this fast moving industry.

Thinking about these questions, I stumbled accross the creed of the folks at Auttomattic. If you don't know them, they are the people behind WordPress.com, WooCommerce, Gravatar and many more. With currently 840 employees in 68 contries speaking 84 different languages, a common understanding of the companies values, goals and working ethics is key. Reading through their creed gave me one of these moments where you see something that was always floating in your mind, suddenly manifested in written words - clean and organized. So I contacted them asking whether they are okay with me using their creed, too. I received an answer back by one of WordPress's Happiness Engineers (cudos for their titles!) that the creed is released as Open Source - just as many of their other policies (which btw are stored in the following Git repo) - and that I'm free to use it.

To make the creed more adoptable for other developers, I tried to generalize it a bit. One thing I stripped out was a reference to Open Source eventually dominating every market it enters. Although I firmly stand behind the idea and spirit of Open Source, not every developer works for a company with Open Source products and I wanted to make the creed more useable for as many developers as possible. That's not to say that we as developers couldn't (because acutally we should) participate and contribute to the plethora of Open Source projects around there. Nevertheless, I'm still confident that my changes didn't take away the original spirit and meaning. So here we go:

Developer Creed

I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Diversity is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

I will never stop learning

The first and most important line of the creed means that you’re never finished. There is always more to learn. Your list of unread books is always going to be longer than the ones you’ve read.
The enemy of this is thinking you’re right, putting too much weight on your experience, or passing up an opportunity to understand someone’s point of view.

I won’t just work on things that are assigned to me

The full potential and creativity of any developer won’t be completely reflected in their assigned tasks or Objectives and Key Results (OKRs), or documented in the issue or task tracker used. It’s possible to survive by doing just what’s asked of you, but to truly thrive involves bringing something above and beyond to your work and making sure everything you leave your mark on is something you’re proud of.

Of course, the subtext and assumption is you’ve already done what you were assigned!

I know there’s no such thing as a status quo

We should never do something just because that’s the way it’s been done before. Decisions in the past were (hopefully) made with the best information available at the time, but if we’re always learning then our future selves will be infinitely better suited to discern and decide a course of action. (Corollaries: If you are not embarrassed by your old code, you’re not learning enough. If you’re not embarrassed when you ship your first version, you waited too long.)
Work from first principles, and make sure you understand (really understand) what came before you.

I will never pass up an opportunity to help out a colleague

It doesn’t matter who you report to or what division you’re in. Every other person in your company is your colleague. A culture where we always try to help one another is the one we all want to work in.

Taken more broadly, “colleague” is all those in the same role in the world. Can you write a blog post or give a talk that will help everyone who is exposed to it?

Part of helping someone is communicating clearly. This doesn’t mean saying “yes” to every request. The distance between saying you’ll help someone and actually helping them is a gap often created with the best intentions. But when we don’t bridge that gap, accountability suffers throughout the organization. Our desire to help might make it tempting to tell someone we’ll do something, but we should always be impeccable with our word.

I will communicate as much as possible, because it’s the oxygen of a distributed company

This is probably true in all relationships, but especially in the dynamic ones we’re in during most of the year. This is one of the areas where we differ from the late, great Douglas Adams who wrote of the Babel fish:

Meanwhile, the poor Babel fish, by effectively removing all barriers to communication between different races and cultures, has caused more and bloodier wars than anything else in the history of creation.

Repeatedly in our work, we find the opposite: poor communication (and understanding) is at the root of every disagreement, conflict, and poorly managed project. When people understand each other, difficulties melt away. (Most true conflict in a work environment is imagined.)

Four Agreements

Don Miguel Ruiz wrote a great book called The Four Agreements. He summaries them at Toltec Spirit:

  1. Be Impeccable with your Word

    Speak with integrity. Say only what you mean. Avoid using the Word to speak against yourself or to gossip about others. Use the power of your Word in the direction of truth and love.

  2. Don’t Take Anything Personally

    Nothing others do is because of you. What others say and do is a projection of their own reality, their own dream. When you are immune to the opinions and actions of others, you won’t be the victim of needless suffering.

  3. Don’t Make Assumptions

    Find the courage to ask questions and to express what you really want. Communicate with others as clearly as you can to avoid misunderstandings, sadness, and drama. With just this one agreement, you can completely transform your life.

  4. Always Do Your Best

    Your best is going to change from moment to moment; it will be different when you are healthy as opposed to sick. Under any circumstance, simply do your best, and you will avoid self-judgment, self-abuse, and regret.

We withhold judgement on whether the agreements are comprehensive, but we disagree with nothing in any of them. They are particularly important in the long-distance relationship that is distributed work; distance and the fact that we primarily communicate via text means there is so much opportunity to misunderstand, misinterpret, and hurt feelings.
These are highly related to Postel’s Law.

Postel’s Law

In January of 1980 Jon Postel wrote:

TCP implementations should follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others.

This has been generalized and called the robustness principle.

It was written in the context of a very specific technical implementation, but oh my goodness does it apply to all other parts of life.

In a distributed organization it is especially easy to misinterpret, misread, or misunderstand what a colleague says. Most of our communication is via text, and you don’t have the luxury of hearing someone’s tone of voice, seeing their face, or maybe even having met them in person before.

Even when we’re on video chat, many companies span over multiple countries so the incredibly diverse set of circumstances we grew up in, live in, and speak as our first language means that it’s easy to take what someone said the wrong way.

We should never try to communicate poorly, and brilliant jerks aren’t worth it, but we should always strive to practice radical empathy for others’ words — we can’t control what was said, but we are in complete control of our reaction to it. Hopefully the empathy we show toward another will someday be repaid when we speak shortly (for whatever reason) and someone guides us back to communicating in an empathetic way.

I am more motivated by impact than money

Money is totally fine, and it’s completely necessary in our current socioeconomic system for everything we want to accomplish as a company — and for many things individually. A good attitude is summed up in this Walt Disney quote:

We don’t make movies to make money, we make money to make more movies.

Making money is okay — in fact, it’s one of the freedoms enabled by the GPL, and no one should feel embarrassed about discussing compensation with HR. But we work for more than just a paycheck.

I am in a marathon, not a sprint

But it’s still a race.

Given time, there is no problem that’s insurmountable

The key here is “given time.” Much of the work that we do is hard. It’s easier to put everyone in the same database. It’s easier to put everyone on the same domain, and you look much better on comScore rather than being dark matter. Our product eventually dominates every market it enters, but sometimes “eventually” can take a while.

We have to be comfortable swimming upstream, with most of the world considering us wrong for long periods of time. This is uncomfortable. Sometimes it means we’ll be ostracized. More often people, or the market will consider us parochial, unambitious, or just plain stupid. They’ll be right unless our success proves differently.

Diversity and Inclusion

Grüezi! We work in international companies with employees who come from a wide variety of backgrounds. We believe that the more perspectives we embrace, the better we are at engaging our global community of users and developers. We want to build our company as an environment where people love their work and show respect and empathy to those with whom we interact. Diversity typically includes, but is not limited to, differences in race, gender, sexual orientation, gender identity or expression, political and religious affiliation, socioeconomic background, cultural background, geographic location, physical disabilities and abilities, relationship status, veteran status, and age. To work on diversity means that we welcome these differences, and strive to increase the visibility of traditionally underrepresented groups. We see inclusion as the ongoing, conscious effort to celebrate difference and welcome people of differing backgrounds and life experiences, whether they’re current or prospective employees, partners, or users of our software.

Final thoughts

For me personally, this creed really helps me to better position myself, reflect on the values important to me and ultimately guide me to a better life - because, let's face it: Work is a big part of our life and as developers, we actually never stop coding, do we?

What do you think? Would such a creed benefit you and your organization? Is there something you would add or change?

Show Comments