Developer joy: Reigniting passion for the art of software delivery

Software developers are the artists of the technology world, but many organizations are stifling their creativity at the expense of their company's bottom line.

Ask any developer what motivates them and you’ll hear about their passion for creating software that solves problems for users and delivers results for the business. Like commissioning an artist for a mural, ask two developers to solve the same problem and you will get two different sets of code, each crafted with the artist's impression.

This code diversity allows us to have the variety of products that drive our economy and the digital world today. At many companies, software products are the only touchpoint between a company and its customers. Yet many companies are limiting developers, not granting them the artistic freedom to do their job to the best of their abilities.

Consider this scenario:

You commission a world-renowned artist to create a statement painting that customers will see when they enter your office. You tell the artist that this piece of art should embody the spirit of your company and represent you to the world.

On their first day, you inform the artist that she will need to paint on paper (not canvas). The artist is confused but agrees and gets started.

As the artist removes her paints from their bag, you inform her that your company has a no-paint policy and that she will need to use crayons. The artist politely requests you reconsider, as this will result in a far inferior outcome to crafting the statement piece with paint.

You understand the artist's concerns, but policy is policy.

As the artist pulls out her easel to attach the paper, you interrupt her again and insist that she use your boardroom table. You spent a lot of money on the boardroom table, and it should get some use... Given the crayon discussion, the artist knows there isn't much point in debating the issue. 

While she’s unhappy about the situation, the artist does her best with the available tools.

Finally, you become concerned that the artwork might not be ready for the high-profile client visit in a few weeks. So you install cameras that count the number of crayon strokes the artist takes per minute to ensure she’s working efficiently.

Knowing we haven't created a supportive environment conducive to productivity or given the artist what she needs to be productive, what would be the point of attempting to measure her productivity? Just as the number of crayon strokes has nothing to do with the quality of the artwork in our story, counting lines of code has no bearing on software creation.

Why does developer joy matter? 

Think back to any high-performing engineer you've worked with; chances are they have gone above and beyond what was formally expected of them. Imagine the positive impact on culture and productivity if all developers on a team displayed these same behaviors.

The behaviors displayed by employees who "exceed expectations" are defined as Organizational Citizenship Behavior (OCB) and are driven by job satisfaction. It seems obvious, but a large body of academic research, including a meta-analysis by Hoffman et al., from 2007 supports the notion that happy employees with high levels of job satisfaction are more inclined to exhibit OCB.

Software teams operate in a dynamic environment where priorities rapidly change, and companies are under pressure to be first to market. To succeed, organizations need software developers who will go beyond their formal role requirements while helping teammates achieve shared goals. Organizations that can achieve high levels of developer joy will significantly outperform competitor organizations that don't.

What drives developer joy and steps to improve it

The artist in our earlier story is unlikely to have had high levels of joy or produced a high-quality outcome while being restricted to sub-optimal equipment and a do-as-you-are-told culture. These same two factors affect the joy of millions of developers around the world—they're referred to as Developer Experience (DX) and engineering culture.

Developer Experience

You can think of developer experience (DX) as how developers feel about the tools and frameworks they use to build software. How do we ensure developers have a better experience than our artist?

Many organizations establish platform engineering teams tasked with improving DX. These teams use developer experience platforms as a vehicle to reduce cognitive load, promote a healthy engineering culture, and enable teams to self-serve available capabilities.

A common challenge for platform engineering teams is to balance giving engineers the tools they want to use with standardizing a set of tools across the organization. Recognizing that no single set of tools can meet the needs of a large and diverse engineering team, a successful strategy is to use an open toolchain that allows developers to use the tools they want while bringing information back to a core collaboration platform.

The most effective way to improve DX is also the simplest: ask developers what is slowing them down, then do something about it. A developer experience survey is a great way to gain insight into what impacts developer experience across an organization. Once you understand the most common impediments, it's essential to take action. Not taking action on a known engineering impediment impacts sentiment amongst engineers more than the impediment itself, due to a perceived lack of support from engineering leadership.

DX is only one side of the equation. Engineering culture plays an equally important role in defining the levels of developer joy within an organization.

Engineering Culture

DX refers to how engineers emotionally connect with their work, while engineering culture encompasses how work is done within an organization. It’s a fusion of an engineering organization's values, practices, and norms. Leadership style, the company's mission and vision, team structures, decision-making processes, and the overall work environment heavily influence culture.

A positive engineering culture encourages OCB by fostering collaboration, promoting innovation, upholding quality standards, and embracing continuous learning. When the majority of engineers exhibit OCB, it sets off a flywheel effect, further propelling a healthy culture and elevating engineering standards. As a result, this positive engineering culture significantly contributes to achieving positive business outcomes.

If our artist had been informed of the high-profile client visit, she could have immediately determined if the date was achievable and evaluated the required trade-offs to meet it. Involving developers early and giving them a seat at the decision-making table can significantly improve engineering culture and outcomes.

Early involvement also means developers have time to experiment with potential solutions while providing realistic timeframes for delivery. This contributes to a healthy relationship between developers and the rest of the team while helping to reduce rework and technical debt.

Like artists, developers have an intrinsic love for their craft. Organizations that provide a positive developer experience and a supportive culture will drive high levels of developer joy, leading to world-class outcomes.

Developer productivity is a by-product of developer joy

The key to success for modern engineering organizations is developer joy, a product of a positive developer experience and engineering culture.

Providing developers with the tools they want to use, and consistently identifying and eliminating common impediments are great ways to enhance developer experience. Engaging developers in the initial stages of product development enables experimentation and realistic delivery timeframes, critical traits of a healthy engineering culture.

Increased developer joy leads to greater job satisfaction, a more dedicated workforce, and improved organizational outcomes.

Consider the developer experience and engineering culture within your organization. What kind of artwork are your artists likely to produce?

—

B. J. Hoffman, C. A. Blair, J. P. Maeriac and D. J. Woehr, 'Expanding the criterion domain? A quantitative review of the OCB literature', Journal of Applied Psychology 92, no. 2, 2007, pp. 555–66; and J. A. LePine, A. Erez and D. E. Johnson, 'The nature and dimensionality of organizational citizenship behavior: a critical review and meta-analysis', Journal of Applied Psychology, February 2002, pp. 52–65.

This article was sponsored by Atlassian for PlatformCon 2024