devopsy.kinsta.cloud

Tag: burnout

The End of Alert Fatigue: How AI-Powered Observability is Transforming SRE Teams in 2026
Your SRE team is drowning. Not in downtime or failed deployments — in notifications. According to research from PagerDuty, most incident responders receive over 10 alerts per shift, the vast majority of which require no immediate action. Across a typical enterprise, that volume can exceed 2,000 alerts per week, with only 3% genuinely warranting attention.

The rest? Noise. Expensive, demoralizing, burnout-inducing noise.

Alert fatigue isn’t a new problem, but in 2026, it’s reaching a breaking point. The Catchpoint SRE Report 2025 found that nearly 70% of SREs say on-call stress has impacted burnout and attrition on their teams. With unplanned downtime costing organizations an average of $5,600 per minute, the cost of getting this wrong is enormous — both for the business and for the people doing the work.

The good news: AI-powered observability is finally making a real dent. In this post, we’ll break down why alert fatigue has gotten worse, what AIOps platforms are doing differently and how teams are cutting alert volumes by up to 95% while reducing mean time to resolution (MTTR) by 40–58%.

Why Alert Fatigue has Gotten Worse, not Better

You’d think that with more monitoring tools, we’d have less noise. Instead, we have more.

The average enterprise now runs dozens of observability and monitoring tools across applications, infrastructure and networks. Each tool generates its own stream of alerts, often with overlapping signals and no shared context. A single incident might trigger 50 or more alerts across Prometheus, Grafana, application performance monitoring (APM) tools, log aggregators and cloud provider dashboards — all independently, all at once.

This isn’t just an inconvenience. It actively degrades reliability. When engineers see 500–1,200 alerts per day, they start tuning out. According to INOC’s 2026 Event Correlation Guide, a service provider with 700 devices can see over 35,000 events per week. During maintenance windows, volumes spike 300–400% further. In that environment, the critical alert — the one that actually matters — is buried.

The operational burden compounds over time. The Catchpoint SRE Report 2025 found that the median time spent on operations activities had risen to 30% in 2025, up from 25% in 2024. That’s time not spent on reliability engineering, automation or building better systems. It’s reactive firefighting instead of proactive engineering.

The human cost is even steeper. 67% of SREs surveyed in the same report said they don’t have enough time for technical training. Teams are running to stand still — and burning out doing it.

What Traditional Alerting Gets Wrong

Traditional monitoring tools operate on a threshold model: If metric X exceeds value Y, fire an alert. It’s simple, auditable and hopelessly inadequate for distributed cloud-native systems.

Here’s the core problem: Modern infrastructure is dynamic. Kubernetes clusters autoscale. Microservices communicate asynchronously. Traffic patterns shift by the hour. Static thresholds set for yesterday’s workload create cascading false positives on today’s. Teams spend hours chasing alerts that turned out to be expected behavior from an auto-scaling event or a batch job.

Even rule-based correlation engines struggle. They can group alerts by label or service name, but they can’t reason about causality. They don’t know that the database connection pool alert is a symptom of the upstream API rate-limiting issue — they just report both separately to the same on-call engineer at 3 a.m.

The result: Alert noise grows, trust in alerting systems erodes and engineers start ignoring notifications. The very system designed to catch real problems starts hiding them.

How AI-Powered Observability Changes the Model

AIOps — AI for IT operations — takes a fundamentally different approach. Instead of setting static thresholds, it learns the normal behavior of your systems continuously and flags deviations that actually matter. Instead of reporting individual events, it correlates signals across metrics, logs and traces to surface root causes, not symptoms.

The market is moving fast to catch up with this need. The AIOps market reached $11.16 billion in 2025, at a CAGR of 25.3%, with some analysts projecting $32.56 billion by 2029. Enterprises are voting with their budgets: Adoption of AI-powered monitoring jumped from 42% to 54% between 2024 and 2025 alone.

The results teams see are significant:
- 95% Reduction in Alert Volume: Organizations implementing AIOps routinely see daily alerts drop from over 5,000 to roughly 100 actionable items — and often fewer. Teams that were handling over 800 alerts per day are down to 20–50.
- 40–58% MTTR Reduction: A global technology services provider cut MTTR by 58% in the first 30 days after implementing event correlation. Broader enterprise case studies show a consistent ~40% reduction across implementations.
- 15% Increase in Revenue-Generating app Availability: A Forrester-commissioned study found that combining observability with AIOps increases the availability of revenue-critical applications by 15%, in addition to the MTTR improvements.
One major retailer reduced incident resolution time from hours to under 15 minutes using AIOps. That’s not an incremental improvement — it’s a fundamentally different operational posture.

The Three Pillars of Effective AI-Powered Observability

Not all AIOps implementations deliver these results. The ones that do tend to share three characteristics.

1. Unified Telemetry Across Metrics, Logs and Traces

AI is only as good as the data it sees. If your metrics live in Prometheus, your logs in a separate stack and your traces in yet another tool, no AI layer can reason across them effectively. The starting point for meaningful AI-powered observability is a unified data plane.

This is why the shift toward unified observability platforms is accelerating. When all telemetry flows into a single system — whether you’re using Grafana, Loki, Jaeger or other open-source components — AI can work across the signal landscape simultaneously, identifying multi-dimensional correlations that humans simply can’t track manually.

Platforms such as StackGen’s ObserveNow and Grafana are built on this principle, unifying metrics, logs and traces from across the stack into a single pane of glass. Rather than replacing the open-source tools teams already use, the goal is to integrate with them — giving AI a complete picture without forcing a rip-and-replace of existing investments.

2. Root Cause Analysis, not Just Symptom Surfacing

The difference between useful AI and noise-amplifying AI comes down to causality. A system that groups 50 alerts into 10 groups hasn’t solved alert fatigue — it has just reorganized it. What teams need is a system that looks at those 50 alerts and says: “There’s one root cause. Here it is. Here’s the confidence level.”

Automated root cause analysis (RCA) is now a core capability of mature AIOps platforms. By learning dependency maps — which services call which, which infrastructure components underpin which applications — AI can trace an incident from symptom back to source in seconds. The on-call engineer sees the root cause and recommended action, not a wall of cascading symptoms.

Aiden AI Copilot for SRE, part of the StackGen platform, does exactly this: Correlating signals across the stack, identifying the underlying failure and surfacing it with context so teams can act immediately rather than investigating for hours.

3. Automated Remediation for Known Failure Patterns

The final frontier is closing the loop entirely: Not just detecting and diagnosing incidents faster but automatically resolving known failure patterns before an engineer needs to get involved.

This is where SRE teams are seeing the most dramatic quality-of-life improvements. Runbook automation — where AI executes pre-approved remediation steps for common failure patterns — means that memory pressure on a Kubernetes node, a database connection pool exhaustion or a stuck deployment pipeline can be resolved automatically, with full audit logs, without waking anyone up.

This isn’t removing humans from the loop. It’s removing humans from the loop for problems that don’t require human judgment. Engineers still own complex, novel incidents. But the 80% of incidents that follow predictable patterns? Those can be handled by automation while engineers sleep.

devopsy.kinsta.cloud highlighted this shift directly: “Many SRE teams already rely on automated incident-response playbooks, where scripts or AI-driven workflows resolve common failures instantly, rather than waking a human at 3 a.m.”

What This Means for SRE Teams Right Now

The shift to AI-powered observability isn’t just a technical upgrade. It’s a structural change in how reliability engineering works.

Teams move from reactive to proactive. When AI handles the noise and resolves known issues automatically, SREs get time back. That time goes into reliability engineering: Improving SLOs, building more resilient architectures and reducing the blast radius of failures before they happen.

On-call becomes sustainable. The data is clear: Burnout correlates directly with alert volume and false positives. Organizations that cut alert noise by over 90% consistently report improvements in on-call satisfaction and reductions in attrition. This isn’t just a morale improvement — retention of experienced SREs is a direct reliability investment.

Incident response becomes a learning loop. AI systems improve with every incident. Each time the system identifies a root cause, validates a remediation action or learns a new failure pattern, it gets better at handling the next one. Unlike traditional threshold-based monitoring, which stays static until someone manually updates a rule, AI-powered systems compound their value over time.

The observability stack becomes an asset, not a burden. Right now, many teams treat their observability infrastructure as necessary overhead — it costs money, someone has to maintain it and its primary output is noise. With AI embedded in the stack, observability becomes a competitive advantage: Faster resolution, higher availability and better developer experience.

Getting Started: What to Prioritize

If you’re ready to move beyond threshold-based alerting, here’s where experienced teams tend to start:

Start with data unification. Before AI can help, it needs complete visibility. Consolidate your telemetry into a unified observability layer. If you’re running fragmented tools, connecting them via a platform that integrates across your existing open-source stack (rather than replacing it) is the fastest path to AI readiness.

Instrument the relationships, not just the metrics. Service dependency maps and topology data are what make automated RCA possible. Invest in distributed tracing and service mesh instrumentation early — it multiplies the value of everything built on top.

Start automating runbooks for high-frequency, low-complexity incidents. Identify the 5 or 10 incidents your on-call team resolves most often. These are your automation candidates. Document the steps, build the playbooks and let AI execute them when the pattern matches. Measure the reduction in on-call interruptions over 30 days.

Measure what matters. Track alert-to-incident ratio (how many alerts translate to real incidents), MTTR by incident type and on-call interruptions per week. These are the leading indicators that tell you whether your AIOps investment is working.

Frequently Asked Questions

1. What is alert fatigue in SRE?

Alert fatigue occurs when SREs and DevOps engineers receive so many monitoring notifications — many of them are false positives or of low priority — that they become desensitized and begin missing critical alerts. Research shows that typical enterprise teams receive 500–1,200 alerts per day, with only a small fraction requiring immediate action.

2. How does AIOps reduce alert fatigue?

AIOps platforms use machine learning to learn normal system behavior, correlate signals across metrics, logs and traces and suppress non-actionable alerts automatically. Teams implementing AIOps commonly see alert volumes drop by 90–95%, from thousands of daily alerts to fewer than 100 actionable items.

3. How much can AI-powered observability reduce MTTR?

Case studies show MTTR reductions of 40–58% with AIOps. A Forrester-commissioned study found that combining AI observability with automated correlation can cut MTTR by up to 50% and increase revenue-generating app availability by 15%.

4. Does AI-powered incident management replace SREs?

No. AI handles known failure patterns and high-volume noise so that SREs can focus on novel, complex incidents and proactive reliability engineering. Most teams implementing AIOps report that SRE job quality improves significantly — less reactive toil, more strategic work.

5. What tools support AI-powered observability?

The ecosystem includes open-source tools such as Prometheus, Grafana, Loki and Jaeger as data sources, AI platforms that layer on top for correlation and RCA and copilot products such as Aiden AI for SRE that automate detection, diagnosis and remediation. StackGen’s ObserveNow integrates across the open-source stack and feeds into Aiden AI for end-to-end automated incident management.

Conclusion: The Alerting Tipping Point is Here

Alert fatigue has been eroding SRE effectiveness and engineer well-being for years. However, 2026 is shaping up to be the year the industry actually closes the gap — not through better threshold tuning or smarter dashboards, but through AI that understands your systems as deeply as your best engineers do.

The numbers are compelling: 95% noise reduction, 40–58% faster resolution and 15% higher availability for revenue-critical systems. However, the real value is what those numbers enable: SREs who are less burned out, more focused on reliability engineering and able to stay in the profession long enough to build the institutional knowledge that makes systems truly resilient.

If your team is still managing alert fatigue with silence windows and PagerDuty escalation policies, it’s time to look at what AI-powered observability makes possible.
May 28, 2026
Survey Surfaces High DevOps Burnout Rates Despite AI Advances

A survey of 604 software developers and engineering professionals finds that while 61% work for organizations that are employing artificial intelligence (AI) to build software to some degree nearly two-thirds (65%) still experience burnout. In fact, after maintaining a high-performing team (47%), burnout (41%) is the second most often challenge, survey respondents cited.

Conducted by Kickstand Research on behalf of Jellyfish, a provider of a platform for managing software engineering teams, the survey finds that among organizations that have adopted AI, a full 94% said it positively influenced their team’s productivity, with 81% reporting AI increases the quality of code.

A total of 84% also said AI frees up time to focus on high-value activities, the survey finds.

However, the survey makes it clear there is a disconnect between the managers (48%) and developers/engineers who participated. More than three-quarters of executives (76%) believe their team has embraced AI, while only 52% of the rank-and-file respondents agreed.

Of the non-AI users, 48% said their team had not adopted the technology due to security concerns, followed by just over a third (34%) citing a lack of expertise. Just under a quarter (24%) said budget constraints had prevented them from using AI. Notably, 19% of executives who work for organizations that have not embraced AI view it as a gimmick.

Jellyfish CEO Andrew Lau said that while there is a lot of hyperbole being thrown around when it comes to AI, software engineering teams should lean into it. AI agents and copilots are bringing inevitable change to software engineering that will change and impact the role of software engineering, he added.

AI Models Will Become More Commonplace

Long term, there’s no doubt AI will enable software engineering teams to be more productive as additional advances are made, said Lau. For example, AI models trained for specific domains such as software engineering will become more commonplace, he noted. Many managers and businesspeople in the short term, however, are overestimating the impact AI can in the short term have on software development, he added.

In fact, 43% of the developers and engineers surveyed said feel that leadership at their company is out of the loop regarding the challenges software engineering teams face. Just under a third (31%) said their team lacks sufficient visibility into project status and well over a third (37%) said efficiency, predictability and productivity have all decreased on their team in the past year.

Overall, more than two-thirds said their engineering organization received a budget increase last year, with 57% of engineering leaders noting the size of their engineering team has increased over the past 12 months. More than half (56%) of all respondents expect the headcount in their department to increase over the next 12 months.

However, more than a third (34%) of developers/engineers do not feel the potential for advancement in their current role, with just under a third (32%) considering a career change. Nevertheless, 80% of all respondents said the work they do is rewarding.

Thanks to the rise of AI more software will probably be developed in the next few years than all of the past decade. The challenge now becomes how to manage a volume of code that is about to exponentially increase beyond what was once thought to be ever imaginable.

July 15, 2024
Six Ways the Software Development Platform can Reduce Developer Burnout

The frantic pace of digitization in the industrial internet of things (IoT) creates steep learning curves for embedded software engineers. Building, integrating and updating industrial software applications without compromising safety, security and performance can feel like working under pressure on constantly shifting sands. It can be demotivating and challenging for even the most experienced professional, impacting innovation and creativity; and burnout is a very present issue estimated to affect four in five software developers.

Even the term “developer friction,” which means difficulties in the software creation process, gives a sense of vexation from endless hurdles. Time is a constant pressure on anyone who wants to stay ahead of the curve to keep software relevant to end-users who want to advance with the benefits of the latest technologies. Any part of the software development process that hinders creating and integrating code adds cost, delays and complexity.

Reduce Barriers, Reduce Burnout

Reducing barriers without compromising on the quality and complexity of projects can be achieved by choosing a software development platform that supports even the most complex embedded applications’ performance, safety and security needs. Here are six ways that the right platform contributes to reducing developer friction.

1) Never Compromise on Throughput Performance
Throughput performance is the heartbeat of software applications, so don’t compromise on the capability criteria of a preferred software development platform.

Empowering mission-critical applications to thrive in any environment requires high overall OS throughput and near-linear scalability with increased cores. Compromise only kicks the can down the road, and settling for less will mean issues with system capability, speed, and reliability from this point on. Ultimately, this brings sub-optimal results and increases stress and pressure on the team.

2) Plan to Go Big (Not Go Home)
The best practice software design should always be built for growth. However, scalability can easily be hindered by the limitations of the software development platform, be it curbing expansion or compromising safety and security for progress.

Better development starts with a platform that accommodates seamless scalability as a foundation for future innovations and opportunities. Your future self will thank you for it!

3) Know When Compromise is Not Okay
Time and precision-sensitive applications, where reliability is necessary, not optional — such as surgical and production robotics — add extra pressure for software designers. Hard real-time systems built on a microkernel platform that divides core functionality across separate spaces provide a more stable environment, with absolute reliability and no scope for latency or jitter. In contrast, if you build on a monolithic microkernel, however good the software may be, if the system goes down it all goes down.

While Linux is a popular OS, it is built on a monolithic core, which makes it difficult to set real-time, complex software-driven systems up for success. In robotics and industrial automation, for example, choosing a microkernel OS releases some pressure and supports software designers in advancing real-time solutions with confidence, predictability and control.

4) State-Of-The-Art Tooling
Time pressure is a major contributor to stress and burnout for software developers and teams. Removing needles from the haystack is tiresome work, and dated toolkits can mean more rework and delays. Choosing the right developer tools can accelerate time to market, identify and resolve bugs, optimize development workflows and enhance the overall integrated development environment (IDE). Therefore, take time to investigate and find state-of-the-art tooling designed to help modern developers push the boundaries of innovation.

5) Design for the Future, Today
Feeling anxious about tomorrow’s challenges? Architecting a system with the future in mind means being confident that you have a solid foundation for safety and security now, and ensuring systems remain relevant and robust in the long term.

With today’s pace of change, if you plan to adapt your software for future needs, you will already be doing it tomorrow. And the next day. And the next! The better alternative is to design with future needs, safety, security and innovation built in today and a platform with the stability to carry innovation into the future. Collaboration in the cloud can help share workloads, make use of the best skills (wherever in the world they may be), and increase efficiencies to alleviate pressure.

6) Skills Development is an Industry Responsibility
The best platform technology is designed to evolve and educate, helping the software developer community to keep pace with the world around it, and offering seamless support regardless of complexity.

Explore the education and support provided by your choice of software development platform provider as a gauge of its commitment to the industry. And choose to work with those that invest in progressing industry talent, research and education, as well as minimizing integration hurdles and empowering innovation, every step of the way.

The tech industry is prone to burnout due to high-pressure environments. As demand for precision software to power robotics, vehicles, industrial and medical environments is set to grow, expect pressure and pace to rise also, exacerbating the high workloads and inefficient processes that are already major contributors of stress and burnout.

Choosing the right software development platform gives a firm foundation for getting it right the first time. That means developing with the future in mind and setting up for success, reducing stress and pressure of the work.

June 19, 2024
Evolution of Toil Identification and Mitigation – A Classic SRE Challenge

Ingo Averdunk, leading architecture and solutions for cloud service management and site reliability engineering for IBM Cloud, contributed to this article.

Christine White, architect at IBM Consulting, also contributed to this article.

When many people think of operations, they often associate it with manual, labor-intensive work. This is because operations traditionally encompass a wide range of activities that involve managing and executing tasks related to producing, distributing and maintaining goods and services. Information technology (IT) is not different: Manual work has traditionally been a significant component of various tasks and processes. Examples are server maintenance, software installation, troubleshooting and network configuration, which historically required manual intervention and human expertise. Much of the work is inherently repetitive by nature, time-consuming and prone to errors. We call this work “toil”, the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value and that scales linearly as a service grows.

Toil

This toil has always been there. And toil leads to burnout, increased errors and reduced scalability. Only how we have addressed it has changed. While toil remains, toil mitigation has evolved.

In the beginning, toil was addressed through labor arbitrage. Between 2000 and 2010, we leveraged labor arbitrage to reduce the cost of manual work by outsourcing and out-tasking activities to near-shore and later off-shore countries. When there is a problem, the person who can solve it steps up. Then, to manage it better, we started to do workload or work item management. You have systems, like prioritized backlogs, and we started putting a structure on how we solve these problems. But still, it was all resource-based; everything was resource-intensive. And that is why the engineers became more of the subject matter experts (SME). Being a subject matter expert took time, and being critical to operations became exhausting. And the repetitive manual activities required took time and effort they didn’t have.

As issues became repetitive, we started thinking about scripting. We evolved from a complete labor arbitrage mentality to writing spot scripts. Engineers began to use scripts to solve a small part of the most oppressive problem.

Tools started to be developed to enable and automate some of the work. Organizations purchased tools, and education of the tools commenced. It became important to be an SME in your area and an SME of the tools in your area. However, the tools were specific to certain functions and features that they provided, and the software development life cycle (SDLC) had a lot of nuances that many of the tools did not capture. So even when the tools helped, it created this mass of white spaces that could not be integrated easily. Tools were very format-specific and didn’t have the flexibility end to end integration. Newer problems emerged as formats were different, speeds were different, and other differences manifested. Even as this initial approach was an improvement over the labor arbitrage mentality and reduced the amount of manual effort required, it often resulted in complex and brittle systems that were difficult to maintain and debug.

Automation

From 2015 to 2020, automation became more prevalent. On one side, the cost levers of labor arbitrage were reduced, and due to low skill, quality suffered. Thanks to technological advancements, automation in various flavors became a viable alternative: Runbook automation, robotic process automation, etc.

Aligning tool isolation with SDLC nuances required an end-to-end automation philosophy. We need to do automation across the board. Toil elimination was a goal of end-to-end automation, and that obsession led to SRE thinking and the principle of capping operational load. An SRE spends only 50% of his time on operational activities, and the other 50% on “engineering” (improvements): Identification and elimination of problem areas, improving and integrating tooling, etc. And thus, the genesis of the next wave of reliability engineering principles began.

Parallel to this, adopting DevOps and Agile practices as well as cloud computing enabled IT teams to define and manage infrastructure and application configurations through code, allowing for automated provisioning and scaling. Applications are designed for reliability and instrumented for observability, providing insights into the production use. Traditional organizational barriers are broken down and teams cooperate across the entire SDLC with a shared goal that balances velocity and quality.

The new focus on leveraging cloud-native technologies and practices to build scalable, flexible and resilient systems allowed SRE teams to adopt cloud-native technologies such as Kubernetes, containers and serverless computing to build systems that are designed to be highly available, fault-tolerant and easy to maintain.

Toil mitigation and the SDLC lifecycle have evolved from reactive handling of problems to a proactive approach to operations, where alerting is maturing, and other sophisticated instrumentation is implemented. A proactive approach underlined the importance of observability and monitoring. SRE teams are using observability tools such as Prometheus, Grafana and New Relic to monitor their systems in real-time. The ability to identify potential issues before they become incidents emerges.

AI Infusion

The next step is being more prescriptive and predictive. That calls for a good bit of AI infusion. We have historical knowledge management systems that will tell us what went wrong, how it went wrong, how it got resolved and how long it took. We can augment that knowledge base with publicly available and curated knowledge.

Starting in 2020, AI and machine learning are being used in IT for tasks such as anomaly detection, predictive maintenance, risk assessment and automated incident response, reducing the manual effort required for monitoring and maintaining systems.

AI systems can learn from all this and not only predict issues, but when issues happen, they also auto-resolve. An extension of AI, Generative AI, will disrupt this event more. Prediction of a problem will also lead to the generation of executable runbooks and playbooks, which are agnostic to specific types of automation or automation tools. New challenges such as data quality, model training and explainability have arisen simultaneously and human intervention is still required until we can reach a certain comfort level. There will need to be a manual effort to look at Generative AI proposed solutions, approve them and prove the solutions in lower-level environments, before applying them into production environments.

In the next 18 – 36 months, we will see that morph into risk-taking, where Generative AI will become digital operations. If we look at an Ops team or a SRE team, there are different personas, and we firmly believe that those personas will be assisted by an AI bot. These bots will participate in daily standups, and they will learn. They will participate in issue-resolution processes, and they will learn. They will start participating in retrospectives, and they will learn. This “AI persona” will become a digital worker in a highly integrated digital team. The manual tasks that once were solved through AI are now becoming complex decision-making processes. We are entering the 4th wave of automation improvements using Generative AI.

Be Prepared

Just as the invention of fire, tires, the printing press, the telephone and the lightbulb, what we do with this advancement will greatly shape our future. We must be prepared. And the best way to be prepared is to upskill our practitioners with newer technology skills like AI. The upskilling needs to include all the core and peripheral benefits and concerns to help them manage and improve upon the current day. We need to clarify roles amongst practitioners so there is not an “I’m being replaced by a bot” mentality, and most importantly being open-minded about the possibilities, building on those possibilities and embracing risk rather than fighting it!

November 2, 2023
Are you Being ‘Nice’ to Your Developers? Think Again

As a developer, you’ve learned your craft. From your fingers comes the magic that builds the applications that run the world. You can literally create something from nothing! And not just software programs. You can create value that means revenue for your company. You’re a revenue machine — no, you’re a god, creating anything that’s needed! That is, you could be if you could spend all of your time writing that magical code. But this dream is not so simple. If you’re like most developers, you’re spending way too much time on other things, such as:
● Meetings
● Dealing with interruptions
● Security hassles
● Operations
● Debugging
● Fighting with infrastructure
● Burnout

Every minute you’re dealing with any of those, you’re not making magic. Because you’re human, that is going to make you unhappy.

If you really are a developer and not just imagining you are, you already know all of this. Now let’s turn our attention to those of you who are responsible for developers. Because it’s your job to make them happy.

Yes, it is, if you want them to keep working productively for you and add value. Luckily, it’s within your reach to do so. It will benefit you, add value to the organization and, most importantly of all, the employees themselves.

Simply put: If you want to get value from your developers, you have to be nice to them. If you expect them to pour themselves into you and into the company, you must first prioritize them and invest in them. Success can only be realized and achieved by a happy balance of developers who are motivated to create.

Do you know who feels more motivated than anyone else? Who will always go above and beyond?

Those who are appreciated.

So let’s get started.

Increased Productivity and Value

The most obvious issue is productivity. The reality is that software development can be an arduous mental task, and when developers are unhappy, it will inevitably affect their productivity—especially when they spend mental cycles on things that are not directly related to the task at hand.

Even if they’re not spending work time searching for another job (or quiet quitting), they’re probably thinking about what could be different and mentally grumbling about it every time something comes up that irritates them.

By treating developers well and eliminating those annoyances as much as possible, you prevent that problem and get 100% of their attention.

And there are other productivity benefits, as well. When developers trust their company and their co-workers, it fosters greater collaboration between those developers and business stakeholders. It also engenders greater creativity, which can lead to innovation and value above and beyond what you are expecting them to deliver.

Retention

The most obvious issue when it comes to developer happiness is, of course, retention. After all, if you’re not nice to your developers, you should expect them to leave for other jobs. If the Great Resignation taught us anything, it’s that it is human nature to move along if dissatisfied.

That may not seem like a big deal to you, but think about the implications if your developers are leaving in droves. Never mind the turnover costs, what about the inevitable delays as you bring new developers up to speed? Hiring and training are arduous, time-consuming endeavors. And if turnover is bad enough, you may never be able to actually complete anything because nobody ever gets a chance to build up a good head of steam.

Compare this to a company with a dedicated team of happy developers who are motivated to grow and innovate for themselves, their team and your organization.

Which organization do you think is going to come out on top? Yes—the organization with the happier team of developers is probably going to have a competitive advantage—and a big one!

When developers are happy, they are likely to be loyal to your company. That loyalty means they stay long enough to become experts in what you do, making them more likely to create the kinds of innovations that move the company forward for added value.

But most of all, can you really afford to have your best employees leave and take all of the knowledge they’ve gained with them, potentially to a competitor? Probably not.

Maintaining a Good Reputation

All of this adds up to reputation; get a bad reputation in the developer world and it is going to be hard for you to attract top talent. In a world where technology changes so fast, it’s already difficult to find developers who have stayed with one technology long enough to become experts. You need to take advantage of every tool you can to make it easier. Your reputation can be one of them—if you treat your developers right.

But there’s another reason to protect your reputation among developers: It could easily bleed over to your reputation among your customers. If you’re a big company, word of your treatment of developers may spread. If you’re not so big, and you have enough developer turnover, some of your former employees may work for prospective customers or know someone who does.

Today, customers are trying to be socially responsible by buying from companies that ‘do the right thing.’

Without much effort, you can be one of those companies by trying to foster developer happiness. Ultimately, it’s not that difficult.

How to be Nice to Your Developers

Fostering developer happiness doesn’t have to be a hugely expensive proposition. It’s not always about huge paychecks (though they do help smooth out some rough edges). Some things you can do to be nice to your developers include the following.

1. Provide what they need: Developers should be able to spend as much of their time as possible actually coding; make sure they have the tools that they need so that they’re not having to improvise or struggle with creating infrastructure. For example, engaging a ZeroOps partner can take some of this off their plates.

2. Eliminate distractions: Even in ideal situations, it can take as long as 20 minutes for a developer to get back into their train of thought every time they’re interrupted. Try to provide an environment with as few distractions as possible.

3. Foster a training-centric culture: Developers need to feel as though you have their best interests at heart, and one way to do that is to help them learn new skills. And there are multiple benefits for you: For one, it’s much easier to train your existing people in an in-demand technology (such as Kubernetes) than it is to hire someone who already has those skills. For another, training your entire team in these new technologies can unlock creative ways of solving problems.

4. Help developers understand how their work relates to the customer: While it can be tempting to expect developers to simply do what you ask them to, when they understand why they’re doing it, they’re much more likely to feel invested in the work.

5. Listen to ideas: Your developers are at the heart of what you’re trying to do. It’s very possible that they have a new way of doing something or an idea for something that could help your company. Even if you don’t end up going forward with the idea, your developers need to know that you respect them enough to listen.

6. Respect work-life balance: Developers have a reputation for working long hours and many even take pride in it. But it’s not always the most efficient way to get things done. A tired developer works more slowly and makes more mistakes. Be flexible and make sure that you’re not overloading your people with more than they can reasonably accomplish. If your developers have to work 70, 80 or 100 hours a week to meet deadlines, you either need to hire more people (if you can find them) or find a way to partner with other organizations to take things off their plate. (See number one).

All of these things make for a positive work environment that enables your developers to work their magic for you, day in and day out, making something from nothing and moving you forward the way nobody else can.

April 6, 2023
How To Keep Engineers Happy and Reduce Burnout

Software development can be a mentally taxing profession. It requires intense mental focus, often under heavy workloads, with unclear job expectations and a lack of control. And with recent labor shortages due to layoffs and resignations, teams may also be understaffed, making matters more complicated. These issues can compound and lead to prolonged excessive stress—that’s when burnout hits.

In fact, one report found that 82% of developers surveyed indicated that they had experienced burnout in the last six to eight months. Some top causes of burnout include increased workload, a poor work culture and personal reasons. But whatever the cause, for 73% of these developers, burnout is negatively impacting their productivity or personal life. So, what can leaders do about it?

I recently talked with Randall Degges, head of developer relations at developer security company Snyk, to learn how to address ever-present burnout issues in software development teams at scale. Snyk, which provides popular automated vulnerability detection tools, recently closed a staggering $196.5 million series G funding at a $7.4 billion valuation. With that kind of momentum, they must be doing something right. According to Degges, there are a handful of tactics to consider to prevent burnout, like ensuring developers are heard, not assigning tasks without context and making improvements to the DevOps workflow.

Understanding Burnout

Burnout is an ever-present issue, explained Degges. It’s common within any high-stress job where you’re on the hook for constantly delivering new features to support the business. Specifically, in software development, burnout can quickly arise when developers don’t feel they have a voice. Or worse, when they’re tirelessly producing software they know won’t ever see the light of day.

A paper entitled Burnout in software engineering: A systematic mapping study took an interesting systematic approach and analyzed decades of research into burnout in software engineering. It found the following qualitative work-related factors to be most correlated with burnout. (Interestingly, the paper suggested machine learning might soon help produce more quantitative indicators of burnout.)

Causal-relationship of burnout, taken from ‘Burnout in software engineering: A systematic mapping study.’ (Deciphering this diagram gives me burnout!)

7 Ways to Fight Burnout

Since we know burnout is a pervasive problem, how can engineering leaders minimize the issue? Below, we’ll outline some specific strategies to consider and how they might help.

1. Give Developers a Voice

First, Degges encouraged leaders to ensure developers have a say in what they’re building. He recalled working within a large enterprise, sitting in a cubicle and having absolutely no say in the features his team was working on. This often included code they all knew would never make it into production.

Slaving away on irrelevant work is never motivating. Instead, a good internal culture provides a comfortable atmosphere where developers can raise issues early on, said Degges, hopefully before leadership puts targets destined to fail on the roadmap.

2. Provide More Context

On that note, when decisions are made, don’t throw orders over the wall in a vacuum. Instead, Degges recommended providing more context into what you’re all creating. Giving visibility into the reason behind decisions will align everyone on project roadmaps and create a shared purpose. This helps foster a culture of empathy and listening to others, said Degges. (David Shackelford affectionally calls this attitude HugOps.)

3. Optimize Communication Patterns

Optimizing communication patterns for your working environment is also vital to encourage a healthy culture, said Degges. For example, this could equate to optimizing for the physical reality of distributed teams—no one should have to clock into daily standup at 4:00 a.m. If you are working under timezone constraints, Degges recommended adopting more asynchronous communication.

For instance, his team relies heavily on Slack and provides dedicated channels for sharing ideas. They’ve also incorporated automation to summarize verbose Slack communications with a recap of conversations. In general, removing unnecessary meetings and optimizing communication patterns could greatly reduce the baggage an engineer might carry in their day-to-day work.

4. Practice Internal Developer Relations

As they say, practice what you preach. Many tech-driven companies have adopted a developer relations (DevRel) division to build a community with external developer consumers. But are you practicing DevRel internally? According to Degges, DevRel teams should act as a bridge between external and internal teams.

“Our goal is to not only to think and empathize with customers but also to encourage internal people to be authentic community members themselves,” said Degges. This can equate to empowering internal employees with resources like mentoring, blog writing or speaking opportunities, he said.

Additionally, other groups are emerging to help increase internal developer satisfaction. For example, platform engineering and developer productivity engineering (DPE) are being applied by many organizations to improve developer experience around internal tools and processes. Naturally, this will require working closely with internal developers to source feedback and make quality improvements.

5. Automate Away Security-Related Toil

Another method to upkeep engineering morale is through automating away toil. And security vulnerability discovery is one area full of painstaking manual tasks. Half of applications have high-risk vulnerabilities, and new exploits in open source libraries are being discovered almost daily.

As more software supply chain risks emerge, it’s challenging to keep up with the pace of vulnerability discovery and necessary software patching. Therefore, implementing real-time automated vulnerability detection, said Degges, can help remove many manual processes and free up energy to devote to other areas.

6. Hire Based on the Work, Not the Interview

Before developers even get the job, they can be put through high-stress on-the-spot tests during the interview process. Experiences here can set the tone for the entire engagement with the company. But activities like white-boarding algorithms are pretty disconnected from day-to-day work, said Degges. In his opinion, engineers should instead be hired based on the quality of their past performances and the work they’ve produced. This could be artifacts like their personal blog or contributions to open source projects.

7. Apply Artificial Intelligence (AI)

Lastly, what’s a tech blog post in 2023 without a mention of AI? Generative AI like ChatGPT has rocked the programming world and is being integrated into more development environments and engineering workflows. The future of AI looks very bright and is poised to help developers produce more with less time and resources.

Of course, automated code generation will require sanity checks, but these tools can certainly help many ancillary functions. For example, Degges’ team is using ChatGPT to spin up content outlines and automate keyword research, helping support their educational content production.

Soothing the Burnout

Even with new tools emerging and a newfound emphasis on developer experience, burnout is still prevalent. A full 58% of developers and security professionals said they are currently experiencing burnout, according to a 2022 Cobalt study. This is, perhaps, due to the rapid release cadences of today’s software delivery.

“In the past, it took months or years for new software updates to roll out. Now, developers only have a matter of weeks,” wrote Bill Mann, CEO of Styra, on Forbes. “Suffice it to say the stakes are high for today’s software teams.”

Burnout is psychologically taxing and can negatively affect employee happiness and retention. Therefore, it’s an excellent idea for engineering leaders to take it seriously and consider what positive cultural changes they can make.

April 6, 2023
Best of 2022: The Great DevOps Burnout

As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

DevOps needs a mindset shift to save the overworked engineering collective. There’s a considerable discussion right now about the Great Resignation. But if you work in software engineering, you’re probably even more familiar with the Great Burnout.

Everything in the software development realm has sped up over the last few years. Engineers perform at a rapid-fire pace, with perfect accuracy, all day, every day. The demand for new, updated or better apps never slows down. But your DevOps team can only perform so fast.

DevOps is Overworked and Burned Out. No, Really.

A full 83% of software developers feel burnout from their work, while 81% reported an increase in burnout due to the pandemic. The most significant factors contributing to those feelings of burnout include high workload, inefficient processes and poorly-defined project goals and targets.

Overworking, overloading and burning out developers is a recipe for disaster; that’s resulted in job hopping and low productivity. Organizations need to shift their mindset about how we develop apps and nurture developers to make the future of software development sustainable.

The Burden of Uneven Engineering Demands on Your Bottom Line

Software delivery is only as sustainable as the level of workforce happiness. Today, the supply and demand for engineers is entirely lopsided and the chasm between the two continues to widen.

The highest number of SaaS companies worldwide exist in the United States. The vast majority (73%) of all U.S. businesses are planning to switch to SaaS in the near future; the demand to hire great engineers and find balance will continue to escalate for years.

Additionally, software developer employment is projected to grow 21% by 2028, faster than the average 5% projected growth rate for all occupations.

For engineers, this growth is excellent news. But for leadership, the uneven demand for engineers means it’s more important than ever to consider the pain points of your DevOps team and offer solutions to common issues, like overwork.

Infrastructure Needs to Change to Dampen DevOps Burnout

Throwing more money and more people at an already overworked engineering culture will not make the SDLC more sustainable nor help you hit business objectives.

If we take a page out of the “five whys” and dive into the root cause of universal DevOps burnout, there is a common thread in all software engineering approaches. DevOps, Agile, Six Sigma, Lean, Scrum, you name it–these are tried-and-true methodologies that fail if only the symptoms of our infrastructure issues are addressed. We need to reconsider our current tooling choices if we are to appropriately leverage these frameworks for sustainable development.

Organizations can deflect further engineering burnout and rebound by focusing on saving developers time and reducing toil: The labor engineers devote to repetitive, dull or manual tasks.

It’s necessary to advance infrastructure with automation and embrace next-gen tools that focus on developer experience to halt further DevOps burnout.

Let’s Try Something Different: Automate the API

There needs to be a mindset shift to save DevOps from demise. You can do this by taking a bottom-up approach and introducing more intelligent automation into your software development infrastructure.

Automation saves developers from mundane or low-value tasks and instead focuses their time and talents on planning, creating and delivering high-quality apps. By improving the quality of DevOps functions, engineers feel more valued and have more pride in their role in the company.

Automating tasks doesn’t just help the current DevOps team. Embracing automation frees up your existing workforce, requiring lower hiring demand while retaining confidence that their DevOps team is operating at peak efficiency. This approach tackles the root of the problem—too much work, not enough developers—and allows organizations to retain developers long-term by making their work lives more, well, livable!

Let technology do the mundane, so developers can apply their specialized expertise where it matters. Hire less but do more. Automate workflows so that developers can do their real work: Write code. Sidestep the employment demand issue and protect developers.

Of course, this approach doesn’t come without drawbacks. Even a near-perfect product can introduce failures if it requires too much customization by highly specialized developers. Then, costs begin to skyrocket because of the manual labor required for API development for customization and database management.

When done effectively, continuous development is a shining example of improving the infrastructure of DevOps and impacting burnout with automation. Continuous integration and continuous deployment (CI/CD) allow for faster feedback from your customer base, letting you turn around adjustments of features, add or remove things that actually fit and solve problems for your customers faster.

3 Next-Gen Development Tools to Save Your Team From Continued Toil

Tackle developer overload by incorporating the next-gen development tools designed to improve the developer experience. Make the workday more manageable, not more complex, with three emerging categories of development tools to fix DevOps burnout.

1. Automated Code Suggestions
Context-aware code completion tools suggest code to developers during the coding process. Automated code suggestions save developers precious time (and labor) thanks to fewer keystrokes and are designed to increase the speed of the entire coding process.
2. Instant API
With only a few lines of code, instant API connects your data to your app, helping to turn every developer into a backend dev. Whether you need to power a web app or a mobile app, hosting your API and databases in the cloud on one platform allows teams to configure, test and manage APIs without the all-too-familiar manual burden on developers.
3. Neural Networks
A branch of machine learning, artificial neural networks are computational models that extract meaning from complex or messy data to detect trends and patterns. Neural networks, while not perfect, can suggest improvements to coders as they write.

We are doing our engineering workforce a grave disservice by ignoring the Great Burnout and not addressing the shift needed to course-correct DevOps from the ground up. Without the necessary infrastructure automation advancements and adoption of developer-focused tools, teams will continue to battle against velocity demands and churn. It’s time to embrace a new mindset and usher in a new era of DevOps productivity and developer satisfaction.

January 2, 2023
A Developer’s Guide to Building Healthy Teams
To build a great software product, teamwork must extend across developers, managers and executives. Everyone needs to understand each role’s value–you can’t have an effective team without a good coach and vice versa. It takes a culture built on empathy, trust and shared responsibility with the right amount of ambition and personal connection to make the dream work.

It isn’t easy to achieve this balance, but here are some tips to help your team become healthier and more effective.

Watch out for Knowledge Silos

When too much unique knowledge is stored in one person’s brain, your ability to get things done depends on their capacity, which can jeopardize the team and the entire organization. Some silos can be good, but only when everyone on the team knows what’s in each one and how to access the information.

Knowledge silos can take several forms:
- Technical skills, like being the only one on the team to know Go or Python.
- Ancillary knowledge in some field, like a background in statistics.
- Historical knowledge, like a developer who has been there from the beginning and knows the whole codebase.
- Institutional knowledge, like understanding larger business and project strategy and the history of the company.
There are some great hacks for overcoming knowledge silos. Simple awareness of who is good at what–or what background everyone has–is a great place to start. Leaders can then think creatively about team collaboration like pair programming or assigning pull requests based on each individual’s knowledge. Pushing each developer to assess their own silos can help set the team up for better knowledge sharing during impromptu sessions or scheduled meetings. Prioritizing documentation is a good way to ensure developers share what they know. Additionally, using brown bags and demos can help your developers hone their teaching skills. These strategies are a great way of investing in your team’s future velocity.

Focus on the Individuals That Make up the Team

Fast Company published a great article about the different personality types that make up a great team:
- The brain pushes others to take action in pursuit of a goal.
- The voice gets the big picture and motivates the team.
- The sharp eye focuses on details to get things done the right way.
- The heart promotes community, consensus and collaboration.
Thinking about these four very different traits and identifying who plays each role on your team can help you build a harmonious group—while ensuring the strengths of each individual are emphasized and appreciated.

Foster Empathy and Build Trust

Having empathy for your team often means finding a balance between the desire to win or hit certain goals and understanding the different needs of each teammate. As a manager, you should push yourself to ask thoughtful questions that put you in your developers’ shoes.

Empathy builds trust. So does:
- Supporting developers at their unique levels.
- Nurturing a culture of healthy sprints and personal well-being.
- Using data–and not just a gut feeling–as a starting point for improvement
- Clearing roadblocks to productivity so that teams don’t feel overloaded.
- Granting autonomy to individual contributors.
- Consistently accomplishing goals as a team.
- Being transparent with challenges the team is facing.
- Sharing data across the organization.
Things that tend to erode trust include:
- Stack-ranking developers based on lines of code.
- Rallying around ambitious deadlines at the expense of burnout.
- Using data to demean your team members.
- Enforcing a productivity quota.
- Managing with a top-down perspective.
- Limiting data to leadership.
These tips help teams avoid burnout, which is a surefire way to wreck a team. The World Health Organization (WHO) defines burnout as “a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed.” So this isn’t just an individual’s personal problem–burnout is a sign that something is wrong within your organization.

Understanding knowledge silos, emphasizing individual strengths, cultivating empathy and building trust are the foundations of a strong developer team. Once you have those covered, you’ll be on your way to healthier, more effective teams.
December 21, 2022
Avoiding Developer Burnout With Clean Code Best Practices

Employee burnout is common in the tech industry, especially for developers. In fact, 83% of software developers feel burnt out from their work and of those, nearly half of them feel overworked. Often, this is because the processes currently in place at their companies are not effective and too much time is spent doing mundane work.

Resolving coding errors is a necessary part of software development, but this isn’t always an easy chore. Given the complexity of code today, developers do tend to spend a large percentage of their bandwidth on maintenance issues, refactoring, debugging or just modifying code that they never wrote in the first place. That said, 44% of developers stated that fixing software defects and problems is their biggest frustration.

Every developer wants to create good code, but repetitively dealing with issues that aren’t part of the code they write steals away time from doing interesting work. More than a third of developers claim that they would prefer spending more time with their families, participating in more physical activity and even getting a full night’s sleep than spending the majority of their time fixing code. Developers also stated that they could use the time at work to focus on new features and capabilities.

By implementing clean code best practices across the organization, development teams can create an environment that prioritizes new and interesting projects while organically addressing errors. Clean code practices help keep developers engaged and interested.

What is Clean Code?

Every organization relies heavily on software and the source code that powers it to run successfully. Companies are aware that the source, or DNA, of their software is what counts as its most important asset. The behavior and functionality are both governed by the source code and if it’s not kept in good condition, the source code can turn from an asset into a liability.

Clean code refers to a codebase that has reached a flawless and problem-free state. It is code that is maintainable, reliable, secure, readable and embodies other such attributes of code. While developers write clean code for their new projects from the beginning, they simultaneously address existing issues through set quality standards. The overall workload of security and development teams also is greatly reduced when clean coding practices are considered and integrated into the development workflow.

With this method, fewer issues reach the final stage of inspections. It also avoids pricey post-production rework or drawn-out feedback processes. The outcome is a simplified and effective method for managing the state of your code.

How Clean Code Helps Developers

By giving your developers access to the power of clean code practices, organizations can make sure that their development teams are working on projects that are impactful and exciting rather than dealing with mundane repetitive work. This means that they have more time to research, put new ideas into action, and also be part of new initiatives that have a direct impact on their organization’s success.

When using the clean-as-you-code approach, you create a precedent that, moving forward, new code that is added or updated won’t result in new problems. As new updates are made to old code, the overall quality of that code progressively improves. This is a much more manageable process and a huge step toward improving the overall quality of code.

Additionally, the clean-as-you-code approach empowers developers to take charge of the quality of the code they deliver. The feedback loop to detect and fix issues is naturally shortened with the proper tooling they can use in their current DevOps workflow. And contextualized education helps them quickly understand the root cause and get guidance to fix them. When their everyday routines automatically incorporate this technique, the possibility of recurring or exposed weaknesses is greatly reduced. In the long run, this helps save development time and effort, making development so much more enjoyable.

There are many things that are a necesssary part of a developer’s everyday responsibilities. Making it simple and efficient is a win-win for everyone. No matter the state of your codebase, the maturity of your development team, or the size of your organization, clean code best practices are easy to embrace and will make your developers happier and more satisfied at work.

November 18, 2022
Understanding the Importance of Developer Experience

If you’re creating a developer tool, you’re bound to run into this dilemma—you know the inner workings of it really well, but others don’t. And without solid documentation and samples to follow, it can be challenging for another person to get started. Friction with the tools we use can contribute to burnout, inhibit creativity and slow down innovation.

Developer experience (DX) is becoming integral for any software company to consider. I recently met with Christine Spang, CTO and co-founder of Nylas, to consider the benefits of investing in developer experience. Below, we’ll take a look at what exactly DX is and consider some best practices for implementing it.

What is Developer Experience?

Developer experience (DX) is similar to user experience but for developer-facing tools. DX considers the developer’s journey while developing with a certain framework, language or platform. “Developer experience is the amount of friction a developer experiences between having clarity on what they want to implement and getting to the point where you have created that thing,” said Spang.

For example, consider integrating with an API to solve a common use case like payments integration. There are many steps involved here, from reading the reference documentation to getting an API key, testing calls and understanding how the service responds. After developers initially integrate the API into their application, they may also have to make continual updates as the service versions. Throughout this journey, DX can be thought of as “how hard it is to figure out how to translate from idea to output,” said Spang.

It’s also important to note that DX isn’t only relegated to public-facing platforms. Having a quality developer experience is just as crucial for internal software. The urgency to improve internal developer experience is increasing with the surge of APIs being developed, especially since the majority of them (58%) are private APIs, according to Postman’s 2022 State of API Report. Depending on the size of a company, internal DX can encompass many areas.

Best Practices for Investing in Developer Experience

So, what are some methods to improve developer experience across the board? Well, having up-to-date documentation, code samples, better examples and standardized documentation rank high as positive developer experience traits. Spang also shared some helpful best practices to improve DX:

Provide scaffolding for the most common cases. Measure patterns around the kind of things people are building with the platform and offer scaffolding to support the common use cases. This might equate to a getting started guide for a common scenario.

Offer sample code libraries. It’s a lot easier to edit code than write it from scratch. With that in mind, create pre-baked environments where developers can play around. Offering working apps, use case templates and glue code can be a practical means to help developers get going more seamlessly.

Start with the reference manual. Walkthroughs and sample code should never replace a complete reference manual. It’s essential to have up-to-date documentation to cater to advanced users from the get-go. From here, you can generate Postman Collections or interactive sandboxes built around the reference specification.

Measure DX success and iterate. One way to monitor developer experience metrics is to record the onboarding flow and measure conversion rates. Where APIs are concerned, this can be tracked by asking how many people get through to making calls? What is the mean time it takes to make the first call? Knowing such metrics can inform how effective your tool’s self-service features are.

One point that’s important for DX is walking the fine line between too much custom work and focusing on the core project. On that note, Spang recommended “making sure whatever you’re building maps to the overall vision of the company.” In essence, if you’re not a consulting shop but a product company, you should stay true to that objective.

“You want to make the path for what people commonly want to do very easy,” said Spang. “Yet, you don’t want advanced users to feel constrained by the platform.”

Examples of Quality Developer Experiences

For those creating developer-facing services, it’s helpful to have a framework to model. So, what are some examples of quality developer experiences?

Well, top public APIs are great examples of where the bar is set for developer expectations these days, said Spang—services like Twilio or Stripe demonstrate relatively seamless developer journeys. Spang also pointed to companies with a strong DevOps and CI/CD background, like Etsy, who have for years invested in usable backend infrastructure that accelerates internal development.

For other sources of quality developer experience, consider the high-ranking developer-favorite technologies from the latest 2022 Stack Overflow survey. Engineers love working with technologies such as PostgreSQL, AWS, Phoneix and Docker. The newer, trending languages tend to be increasingly usable, too. For example, 86% of developers said they love working with Rust while 76.65% dread working with Objective-C.

The Overall Benefits of DX

An investment into developer experience can help improve agility and developer satisfaction, said Spang. For one, an easier path for development increases the velocity in how you ship and evolve projects over time. Secondly, developer experience equates to less burnout and less turnover, both of which can have real business impacts.

The software development industry is growing like wildfire, bringing in waves of entry-level developers each year. Interestingly, the average experience level is decreasing, increasing the need for more abstracted tools and toolkits, said Spang. In this environment, developer experience undoubtedly shines as a competitive advantage.

So, if you’re creating developer-facing tools, consider the experience others will have when using them. Increasing developer experience may just be a defining factor in the project’s success and the long-term happiness of your developer community.

August 25, 2022