What Makes a Good Developer Culture?

There’s a lot of talk these days about what makes a good “culture”, whether you’re an engineer, a software developer, or a chef. It’s all about finding a work environment that not only is conducive to getting stuff done, but also makes it a pleasure to get up in the morning and get there. In this article, we’re going to take a look at a few prominent developer voices that have discussed the idea of what makes a good developer culture. Is it the perks? Is it being extra “geeky”? Is it looking for collaboration where collaboration doesn’t normally happen? Or is it a combination of all these factors plus something more?

What is a “developer-driven” culture?

One of the hottest places to work for coders is Facebook, the world’s largest and most popular social networking site. This mammoth beast serves over 600 million users (and counting!) worldwide, relying on a versatile team of software engineers and developers to keep the home fires burning.  Even though Facebook has gotten a lot of flak for constantly changing the user interface and privacy settings with little to no warnings to users, their core values of always-on accessibility and a one-stop-shopping hub for all social interaction continue to flourish. This doesn’t happen in a vacuum:

“Constant evolution always marks a growth-oriented company, and Facebook definitely fits that bill. But beyond great values and innovation, perhaps part of the site’s success may be linked to the developer-driven culture that Facebook employs in creating and maintaining the code that makes the platform run in a more fluid, dynamic experience….. The Facebook example does show that developer-driven culture can work in some cases when the right variables exist. In some instances, companies may have to use trial and error to see whether the model will work in their situation. Certainly, not every company will be able to incorporate a system that grants so much power to the engineers.” – RegularGeek.com, “Developer Driven Culture”

“Power to the engineers” (or developers, as the case may be) is an interesting premise, but what does that mean, exactly? Having a really cool office filled with Dr. Who and Star Wars ephemera, free massage parlor on-site, and loads of free junk food is great, but it won’t do much to stem the tide of attrition if developers have to deal with silly office politics or worse, micro-management. What Facebook seems to get right is the encouraged proliferation of ideas, an imaginative environment that does not stifle innovation. This requires a couple things to really get right: a smart team of developers that work well with each other, and a smart management team that filters out what’s necessary and what’s not so coders can get their work done. This is a tall order, but when you’ve got a product that is as hot as Facebook, you can’t afford to do anything else.

What contributes to a strong developer culture?

At Quora, an online question and answer site, the question was asked “What makes a good engineering culture”? Obviously the answers are from an engineering perspective, but many of them can apply to developers as well. One of the answers to what makes a strong developer culture was fast iteration:

“Team-wise, fast iteration speed means having a set of strong leaders to help coordinate and drive team efforts. Key stakeholders in a decision need to decide effectively and commit to their choices. To borrow a phrase from Bill Walsh, a leader who coached the 49ers to 3 Super Bowls, strong leaders need to "commit, explode, recover," which means committing to a plan of attack, executing it, and then reacting to the results.  A team crippled with indecisiveness will just cause individual efforts to flounder.”

We’ve probably all had the unfortunate experience of being hampered by someone else on a project; it’s just the way life goes sometimes. Fast, meaningful progress for a team is something that can make the work flow more easily towards the ultimate goal of getting it done. Along with quick iteration comes the idea of automating as much as possible, building software that will help keep things simple:

"Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization. Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make."

The old adage of K.I.S.S (Keep It Simple Stupid) seems to apply here. The specific tools or processes that developers utilize in order to accomplish a sort of Zen-like simplicity in their work don’t matter so much as what they are ultimately trying to accomplish; which is basically an obstacle-free (or at least less) pathway to the end of a project.

20% time

You might have heard of Google’s “20 percent time policy”, something that is quite well known in the technology industry. This concept goes all the way back to 1948:

“In 1974, 3M scientist Art Fry came up with a clever invention. He thought if he could apply an adhesive (dreamed up by colleague Spencer Silver several years earlier) to the back of a piece of paper, he could create the perfect bookmark, one that kept place in his church hymnal. He called it the Post-It Note. Fry came up with the now iconic product (he talks to the Smithsonian about it here) during his "15 percent time," a program at 3M that allows employees to use a portion of their paid time to chase rainbows and hatch their own ideas. It might seem like a squishy employee benefit. But the time has actually produced many of the company's best-selling products and has set a precedent for some of the top technology companies of the day, like Google and Hewlett-Packard.”Lifehacker.com, “Make Your Job Feel Less Like Work With 20% Time”

Some of Google’s most interesting, well-known products were conceived in this 20 percent time, including Gmail, Google News, and Adsense. Obviously it’s working for them, and it’s easy to conclude that encouraging developers in what they are really passionate about as part of their work flow actually is pretty smart:

“For example, many people I worked closely with in software testing were serious hardware geeks, but outside of an official career change, it was very difficult for them to find anywhere to engage these interests, despite there being hundreds of like-minded geeks throughout the company. An officially sanctioned way for these people to explore these interests would have not only been enjoyable for the employees, but would have helped nurture them into people who would be be appropriate to switch into those careers….. The point is, whatever your developers are interested in, there are ways you can nurture it, even without any significant budgetary investments.” – arc90.com, “Creating a Thriving Developer Culture”

Practical suggestions

A recent presentation by Monika Piotrowicz, a Front End Developer at Jet Cooper, gave some very practical suggestions on how their firm has embraced a more inclusive developer culture, specifically, scheduling designers and developers to work collaboratively on projects rather than staggered.  

The collaboration between their design team and their developer team has reaped great results for this company. During projects, they try to work together rather than handing work back and forth at certain points; they’ve found that this approach enables more research, more prototyping, and they’re better positioned to try out new techniques.

The team also tries to collaborate beyond just the work project environment with a couple of different activities:

• Monthly Demo Days: these allow each team to show off their accomplishments and get support and feedback
• Weekly Developer Talks: All developers meet to share new techniques, talk about issues they’re facing, or anything else on their minds
• Creative Recess: Two days a month the entire company takes a break and works on their own projects, self-directed (this is modeled on Google’s 20 percent time policy as detailed above)

Piotrowicz’s presentation puts forth the belief that designers and developers should be advocating for more collaboration within companies in order to have a stronger overall team, and it definitely seems to be working for them.

Why a healthy developer culture is important

A strong developer culture is vital to good work:

“When you put a focus on culture, you’ll have guiding principles. People will know you for this. Employees will live by it. It’ll help get you through difficult times. You’ll base hiring and firing decisions on the principles. It’ll help get all employees working on the same company mission. In some sense, it’s the glue that keeps the company together.” – Kissmetrics.com, “The Four Elements That Make a Great Company Culture”

Anywhere you work – whether that is a comic book store, a bakery, or an office – is going to come with its own culture. This work culture matters. If you dread going in to work each day with more than just a case of the Mondays, then there’s a problem.

Employees that are excited to get stuff done are productive, and productivity tends to spawn more productivity. This makes companies get out in front of other companies, which helps them expand, which makes employees happy since they’re the ones reaping the benefits.

Good culture also makes it easy to find good people. Let’s face it: the office that offers developers great perks, interesting work, and a forward-thinking environment that rewards creativity is going to get more people knocking on the door of HR than the Orwellian cubicle farm that expects your life blood with little in return. Good developer culture attracts good developers, period.

There’s also a sense of camaraderie that comes from knowing that you work in a safe, creative, and encouraging place. Developers who are invested in their company’s culture and know that they are valued are more apt to stick around, work harder, and help each other:

“Culture guides discretionary behavior and it picks up where the employee handbook leaves off. Culture tells us how to respond to an unprecedented service request. It tells us whether to risk telling our bosses about our new ideas, and whether to surface or hide problems. Employees make hundreds of decisions on their own every day, and culture is our guide. Culture tells us what to do when the CEO isn’t in the room, which is of course most of the time.” – Harvard Business Review

What do you think makes or breaks a good developer culture?

It’s time for you to make your opinions known. What have you experienced personally that was good and bad in the workplace? What are some elements that need to part of a healthy developer culture? Please share your thoughts with us in the comments.