John Perry Barlow is listed on Wikipedia as an “American Poet”. He was also a writer for the Grateful Dead and “cyberlibertarian political activist”, which is a big word (like “mayonnaise”) that I just learned. Barlow was a co-founder of the Electronic Frontier Foundation – Wikipedia and in his activism, worked to expand Internet access across the African continent. This guy was busy—and productive.

In his memoir, Barlow penned a list of 25 “Principles of Adult Behavior” which, although it is relatively well-known, wasn’t on my radar until very recently (which is my loss, as I have been adulting for a long time). The list was Barlow’s attempt to make sure he did not turn into an adult that could not be trusted, as most adults do. These principles were Barlow’s passionate message to himself to be a good person, and he kept them with him at all times as a reminder.

It is a wonderful idea and an inspiring list. I have it pinned on the wall above my monitor so I look at it throughout each day.

Software Development Principles to Guide Healthy Teams

At Method, we’re often asked, “What makes for good software development?” and, “How can I push the right culture for my IT/development team?” While there are specific behaviors that can identify a healthy software development team and culture, often the answers are more…squishy. It’s like answering the question “How can I be a good person?” Sure, there are ways to answer the question, but it’s more about principles, isn’t it?

Lying in bed one morning thinking about a similar question from a client, it struck me that Barlow’s “Principles of Adult Behavior” could easily be applied to custom software development.

So, this is my shot at proving that out:

1. Be patient. No matter what.

So much in software development and IT is about going faster and hitting deadlines at all costs. Races to a date so often lead to flaky software—and unhappy employees and customers, as a result. Working through uncertainty (which dominates our trade) requires patience. Being patient with the process will lead to better decisions, better work environments, and better software.

2. Don’t bad mouth: Assign responsibility, not blame. Say nothing of another you wouldn’t say directly to them.

The big IT takeaway for me here is the bit about blame. The value of blameless retrospectives and, “Fix the system, not the individual” is obvious to companies that adhere to such principles. The next time production goes down or the build breaks, work to fix the issue, not blame the person. Blame fosters fear; fear steals creativity.

3. Never assume the motives of others are, to them, less noble than yours.

Ever inherit an application and its source code and think, “Who wrote THIS garbage?” Or “Why, on God’s green Earth did they do it this way?” We all have. There are jokes about it. Remember that we are all doing the best we can with what we know today, with the constraints placed upon us.

4. Expand your sense of the possible.

This is a much less annoying way of saying, “Think outside the box.” Look for new solutions to old problems. This is what innovation really is. Question everything and experiment. When you hear, “Because that’s the way we’ve always done it,” push back. Give people the chance to learn and experiment and they’ll reward you with the (previously thought to be) impossible.

5. Don’t trouble yourself with things you truly cannot change.

To me, this means preparing for problems by focusing on what you are building. The network will fail, so prepare your software for it. Track metrics for things that matter and drive learnings. Don’t rant on Reddit about why some language/platform/library doesn’t have some feature or work a certain way. Focus on what you can control.

6. Expect no more of anyone than you can deliver yourself.

I mean, c’mon. It’s like Barlow traveled to the future and became a member of a software development effort. Treat people like people, not resources. There is data that proves overwork leads to less output. Don’t allow your team to work killer hours. Send them home—then you go home, too.

7. Tolerate ambiguity.

This is the core of Agile methodology. Uncertainty and complexity dominate most software projects, so make a process that handles them. The promise of Agile software development hinges on working from ambiguity to the concrete in small steps of inspection and adaptation. Tolerate ambiguity because it’s your starting line.

8. Laugh at yourself frequently.

The technical landscape is peppered with people that take themselves way too seriously. Don’t. If you mess up, laugh and learn. It makes you a better teammate and a happier person.

9. Concern yourself with what is right rather than who is right.

Isn’t this just another way to say “Responding to change over following a plan”? Open your mind and listen the next time someone disagrees with a tech stack or process. Debates in tech are so often fueled by personal feelings.

10. Never forget that no matter how certain, you might be wrong.

Another principle that is foundational to Agile methods. I like to say that the surer I am, the more likely I am wrong. Certainty fosters blindspots and bias. Being wrong is OK, as it fosters learning.

11. Give up blood sports.

OK, this one is a bit abstract, so I am going to say it means to use your technical knowledge and powers for good. Don’t be a hacker. Don’t be evil. Also, don’t get caught in comment wars on social media, which are just digital blood sports that make no one happy. They are dark places that will suck your very soul.

12. Remember that your life belongs to others as well. Don’t risk it frivolously.

Software development and IT are team endeavors. You are part of a team that is building part of a company. Don’t risk your team or company for shiny newness. Pay attention to security bulletins and CVEs. Patch your software.

13. Never lie to anyone for any reason. (Lies of omission are sometimes exempt.)

Fail fast. Don’t hide cracks in the software or process or idea. Don’t tell the business that things are on track when you know that are not. Look at your project with a child’s eye. In this case, a lie of omission is a technical detail that the business won’t understand, not the negotiation of an estimate (you cannot negotiate an estimate).

14. Learn the needs of those around you and respect them.

The business is not “stupid” or “clueless.” IT is not a cost center. You are a team empowering your company to live in a digital landscape. The business has needs—learn them and work toward them, as they are what will feed your livelihood.

15. Avoid the pursuit of happiness. Seek to define your mission and pursue that.

The #1 motivator for employees is growth. Growth comes from impact. Impact comes from moving toward a mission. A mission is a leg on the way to a vision. Define your vision and accept the missions to get there. Your team needs to know their impact. Show it to them.

16. Reduce your use of the first personal pronoun.

The team will get there as “we,’ “us,” and “y’all.” Not as “I,” “me,” and “you.” You are not a “ninja” or “10x” nor is anyone else on your team. Don’t celebrate “hero work.”

17. Praise at least as often as you disparage.

Remember how we’re all doing the best we can? Celebrate each other’s victories. (“You fixed that test/improved performance, etc? GREAT WORK!”) Praise is a gift to both the giver and the receiver. It will build the trust that cements the success of your team.

18. Admit your errors freely and quickly.

Fail fast and in the open. Make your process highlight the bottlenecks (i.e., limit WIP). Encourage team members to present errors and failures and talk about how to fix them. This is the quickest way to improve.

19. Become less suspicious of joy.

Take part in the happiness of your cohorts. Use open source. Welcome new ideas. As something of a tangent, remember what Teddy Roosevelt said: “Comparison is the thief of joy.”

20. Understand humility.

You are not the best at what you do. You are not the worst. You are in a community that will both teach you and learn from you. It will also exist without you. Be humble.

21. Remember that love forgives everything.

Don’t dwell on mistakes, either yours or those of others. Love your job. On the right team, your mistakes will fuel team learning.

22. Foster dignity.

No mansplaining or scoffing at “bad” code or laughing at n00bs. Share knowledge, build bridges, lean on each other. Respect, foster, and fight for diversity.

23. Live memorably.

From the software development context, I like to apply this to giving back to the larger community. Attend conferences, make presentations, contribute to open source.

24. Love yourself.

Exercise and eat well. Get away from the computer, the phone, and the job. No, really. Get out of here.

25. Endure.

Knowledge work ebbs and flows. Some weeks are all new learnings, cool languages, and completed stories. Other weeks are unforeseen changes, unrealistic deadlines, and fixing COBOL. Take the good with the bad.

Looking at one or two of these a day sometimes keeps me humble, stops me from dying on hills, and reminds me that success in this job takes patience and respect. I realize some of my explanations smack of platitudes, but I also think we aren’t yet mature enough as an industry to hear these things enough.

I think these principles are a fine outline of the sinews of healthy software culture. At Method, we strive to keep our teams healthy, challenged, and happy and principles like these help that focus. I emphasize the word strive in the last sentence. These are principles worthy of pursuit. They are also extremely difficult to achieve, especially in a legacy IT environment. If you are asking yourself how to get started or how to move the needle, we can help. Method has years of experience working with companies of all sizes to help them deliver in the spirit of these principles. We can help you create a culture that works toward them with strategic actions that have tangible results.