Forem: Alex Harris

Beyond Review Comments: Building a Friendlier Code Review Process with Code Reactions

Alex Harris — Thu, 14 Sep 2023 12:43:58 +0000

Code Reactions 🚀💩
We welcome all ideas and contributions on GitHub 💚!

TL;DR

We created a vscode extension to add emoji reactions, even 

with comments, to any line of code of any Git repo! React and 

see others reactions to any piece of code straight from your

IDE, and have them follow (or not 😉) the code through 
changes.

The story behind

After almost a decade of writing code in all sorts of environments, in a small startup or in a big enterprise with thousands of developers, we always felt that there were some things that should be alongside our code, but never could be.

Giving and receiving feedback for your code. As developers we learn from others, and their reaction to our code either that being a 👍, 👎 or sometimes even a 💩 or a 🚀, is invaluable to our progress. Unfortunately, apart from reviews we don't really get the chance to tell someone what we think about their code.
Putting a mark or a note in the code. You are going about your task and suddenly you notice a piece of code that has that smell, or just doesn't look right, or is outdated, or uses an old syntax, or looks like it could even be an issue. Now your choices are:
1. Drop the task you are doing and fix it
2. Create an issue somewhere to come back to it at another time (or forever forget)
3. Do it with your task (ouch!)
4. Leaving a comment in the code and puzzling yourself a few months down the line, when the code has moved/changed, with the quiz "what was I referring to here".
Code quality metrics are very cool as a concept! However once used we all know that they feel a bit neither here nor there. Eg is a code bad if it has high complexity? Maybe, maybe not! I'd like to know what my collaborators thinks of the code, which parts are for a 😍 and which for a 🤔 and which repos and files are the ones that might need a look into cause 💩 has started pilling on.

That's why we wanted to make something that's:

Open Source 💚 (share the love!)
It works in the IDE
You can add emojis and comments 🚀
You can see others emojis and comments 👀
Follows (or leaves) the code as it changes

What we built

We built an IDE extension (vscode only for the time being,
Intellij is in the works) that allows you to add emoji
reactions, even with comments, to any line of code of any Git
repo!

You can react and see others reactions to any piece of code straight from your IDE!

And Reactions follow the code!, meaning that it stays there for as long as the relevant line has not changed - whitespace doesn't count as change - and they get removed from the line when it's changed.

This is the first version, so it supports limited amount of emojis for now, and it has only a few features. We are super excited to have the community shape the tool and decide on the new features by contributing on GitHub

Features

Different ways to see reactions and add yours (status bar, inline decoration, annotations, reactions feed panel)
Notifications on new reactions (either on the repo or specifically on your lines)
We didn't want to bloat the IDE, so we created a lightweight website for all the views we didn't feel belonged in the IDE (ie cross-repo data) so you are able to get information for all your projects.

Future features

We are super excited to have your input on GitHub to help us shape the future of this extension with what the community wants and needs!

AdadotTeam / vscode-reactions

Add and see other's reactions to your code!

Code Reactions — Emoji reactions for any Git repo

Add emoji reactions, even with comments, to any Git repo! React and see others reactions to any piece of code straight from your IDE.

Code Reactions is an open-source extension for Visual Studio Code, made by our team at Adadot with a mind to give back to the community.

You saw some nice piece of code? Now you can add a 👍, or maybe even a 😍 and spread the love.

It seems like there might be a bug there? Give it a 🐛 with a comment on your finding 
and come back to fix it when you get the chance.

This code feels like it has quite a smell... You think it might justify a 💩? Leave it there 
and bring the team around to help you scoop all of these.

We give you the ability to react to any…

View on GitHub

Reacting with 💩👍🐛 to Code: How I Built a Free Extension to Add Emojis to Your VSCode

Alex Harris — Tue, 05 Sep 2023 13:13:51 +0000

Code Reactions 🚀💩

Help us with your contributions or with a ⭐ on GitHub 💚!

Install extension →

TL;DR

We created a vscode extension to add emoji reactions 🚀💩😍, even with comments, to any line of code of any Git repo! React and see others reactions to any piece of code straight from your IDE, and have them follow the code through changes.

Contents

Where did it all start 🦕
What we found 🤯
Building and Spreading the 💚!
Features 🔥
Future 🚀

Where did it all start 🦕

I'm part of a team building an analytics tool. In January we decided to do what we called "replatforming" which was almost a complete architectural change of the entirety of our analytics platform 😱 to handle scale. In the middle of changing hundreds of files in tens of repos, we found ourselves wanting to mark code for later deletion, refactor, etc. Cause of that, we were pilling mountains of JIRA tickets that were soon outdated. It was NOT working for us! 😔

So we quickly hacked together an internal IDE extension that allowed us to put a mark (or an emoji 😉) on the code and find them later!

What we found 🤯

After using the extension internally for sometime we found that it allowed us to keep some things alongside our code, that never could be up to now 😮. So we ended up using it for various reasons, namely:

Giving and receiving feedback for your code. As developers we learn from others, and their reaction to our code either that being a 👍, 👎 or sometimes even a 💩 or a 🚀, is invaluable to our progress.
Putting a mark or a note in the code. You are going about your task and suddenly you notice a piece of code that has that smell, or just doesn't look right, or is super cool!. Give it a 💩 or a 👀 or a 🚀 and write down a comment if need be!
Code quality metrics are very cool as a concept! However once used we all know that they feel a bit neither here nor there. Eg is a code bad if it has high complexity? Maybe, maybe not! I'd like to know what my collaborators thinks of the code, which parts are for a 😍 and which for a 🤔 and which repos and files are the ones that might need a look into cause 💩 has started pilling on.

Building and Spreading the 💚!

We thought other devs out there might want to have something like it, the same way we did so we decided to rewrite it (make the code slightly more decent) and give to the community something that's:

Open Source 💚 (spread the love!)
It works in the IDE (we don't want another! tool)
You can add emojis and comments 🚀
You can see others emojis and comments 👀
Follows (or leaves) the code as it changes. Meaning that it stays there for as long as the relevant line has not changed - whitespace doesn't count as change - and they get removed from the line when it's changed 🔥

So we went ahead and build just that! (vscode only for the time being, Intellij is in the works)
Get extension →

Features 🔥

Different ways to see reactions and add yours (status bar, inline decoration, annotations, reactions feed panel)
Notifications on new reactions (either on the repo or specifically on your lines)

We didn't want to bloat the IDE, so we created a lightweight website for all the views we didn't feel belonged in the IDE (ie cross-repo data) so you are able to get information for all your projects.

Future 🚀

We are super excited to have your input on GitHub to help us shape the future of this extension with what the community wants and needs out of this tool!

AdadotTeam / vscode-reactions

Add and see other's reactions to your code!

Code Reactions — Emoji reactions for any Git repo

Add emoji reactions, even with comments, to any Git repo! React and see others reactions to any piece of code straight from your IDE.

Code Reactions is an open-source extension for Visual Studio Code, made by our team at Adadot with a mind to give back to the community.

You saw some nice piece of code? Now you can add a 👍, or maybe even a 😍 and spread the love.

It seems like there might be a bug there? Give it a 🐛 with a comment on your finding 
and come back to fix it when you get the chance.

This code feels like it has quite a smell... You think it might justify a 💩? Leave it there 
and bring the team around to help you scoop all of these.

We give you the ability to react to any…

View on GitHub

"engineering managers have it easy"

Alex Harris — Thu, 23 Mar 2023 16:30:34 +0000

Next up on the "engineering managers have it easy" series: long working hours.

At Adadot we analysed data in 38,000 developer datasets from GitLab, GitHub, and Google Calendar.

In our sample, which is comprised of mostly early stage startups, we identified that managers are working an average of 16 hours per month outside of normal working hours.

This is ten times longer 😱 than developers in
their teams.

They are also sending messages and continuing to communicate
for almost ten extra hours per month 🔥 .

This is ten times more than juniors in their teams, again. 😩

Why do they burn the midnight oil? In early stage startups managers are more likely to own a piece of the pie in the form of stock options.

Next time someone says its not worth it giving out equity to employees you can show them this.

Engineering managers have it easy, right?

Alex Harris — Tue, 21 Mar 2023 16:16:24 +0000

Engineering managers have it easy, right?

Well it turns out they are some of the hardest working engineers, at least in early stage startups.

At Adadot we analysed data in 38,000 developer datasets from GitLab, GitHub, @Slack and Google Calendar.

As far as activity goes they commit 10x times more often and volume wise 50% more than juniors. Is this the true measure of a #developer? Of course not!

More importantly they are very present in collaboration activities sending over 100x more messages than non-managers.

More data to come on this.

Become a manager they said...

It will be fun they said...

Ideal ratio of #developers to non-tech staff

Alex Harris — Mon, 20 Mar 2023 16:18:35 +0000

Do you know what the ideal ratio of developers to non-tech staff is?

I was listening to The Engineering Leadership Podcast today when Kenny Shin, the CTO of Fundrise mentioned that the ratio for them ended up being about 30%.

"We generally needed about to have about 1/3 of our staff to be engineering no matter what size we were"

At Adadot we analysed data in 38,000 developer datasets from GitLab, GitHub, Slack and Google Calendar.

The 1/3 rule holds broadly true but there are nuances:

It depends on whether its a tech company or a tech assisted company, like a marketplace. The #engineering teams in the latter can be as low as 10%
In some really tech-heavy businesses like SaaS the engineering component can be up to 70%
Stage matters. In the very early days teams are more engineering heavy

Why does this matter right now?

Most companies are responding to current market conditions with layoffs, however, they are not adjusting their roadmaps to the same degree.

If the ratios are unbalanced this has a direct impact of the engineering team's ability to perform.

What can Slack tell me about my developer team's culture?

Alex Harris — Thu, 16 Mar 2023 15:58:06 +0000

What can Slack tell me about my developer team's culture?

Surprisingly, a lot!

At Adadot.com we analysed data in 35,000 developer datasets from GitLab, GitHub, Slack and Google Calendar. Here are some findings:

The vast majority of messages will always be Direct messages to colleagues and that's normal. When the ratio of public vs private messages falls below 10% this can create a number of issues

📃 More need for documentation. If solutions are not being shared openly in a searchable environment like Slack, it means you will need to formally document more.

🤗 Culture of safety. If developers are not feeling confident enough to raise challenges or solutions publicly are you seeing the effects somewhere else, for example overall code quality?

🔎 Visibility. Are the engineering leaders leading by example by being visible across the team and / or the organisation?

Some of the best performing teams we see either:

Have a higher public vs private message ratio than 10%

Are actively working to increase it

Stats about developer Focus Time

Alex Harris — Wed, 15 Mar 2023 15:25:15 +0000

Do you know what most developers complain about?

Lack of Focus Time. This is time ringfenced for doing deep work.

At Adadot we analysed data in 35,000 developer datasets from GitLab, GitHub, Slack and Google Calendar. Here are some datapoints:

📌80% of developers have focus time at some point during the week.
📌20% of them deliberately set up focus time in their calendar
📌10% use specialised apps for it

Here is what surprised us:

😱Up to 60% of developers experience some sort of distraction during focus time daily
😲The more senior the developer, the more likely to set up focus time in their calendar. Also the more likely to get distracted
😵Slack messaging, not meetings, was the main culprit in those distractions

Does this tally up?

Is there such a thing as too few meetings?

Alex Harris — Tue, 14 Mar 2023 15:56:45 +0000

Developers, is there such a thing as too few meetings?

Apparently yes!

At Adadot we analysed 35,000 datasets from #developers using GitLab, GitHub, Slack, and Google calendar.

The results surprised us!

Most developer teams of 5 devs+ spent between 2-5 days in meetings per week collectively.

About 20% of teams, however, spent less time than that.

The teams that had too few meetings tended to compensate by spending more time in Slack.

Overall, the "efficiency gains" for those teams were actually negative, meaning they were spending overall more time going back and forth on messages than they would have done if they had a meeting to get to the bottom of things.

Slack message that should have been a meeting anyone?

Senior devs collaborate more

Alex Harris — Mon, 13 Mar 2023 17:07:12 +0000

Did you know that you can tell the seniority 🧓 of a developer based on the ratio of time they are spending on collaboration vs code?

We analysed over 35,000 developer datasets across Gitlab, Github, Slack, and Google Calendar. This is what we found.

More senior developers are spending up to 30% more time on collaboration tasks such as Slack messages and meetings than junior devs 👶 .

What does that mean for you?

Well, if you are aiming for a promotion to the managerial level you might want to increase the proportion of time you allocate to those activities.

The key?

The collaboration activities must be rendering you "visible" within the team. This means that its often better to answer a question on a public Slack channel than a private message.

What is the best way to measure developer productivity in 2022?

Alex Harris — Mon, 18 Apr 2022 16:58:31 +0000

*What exactly are we measuring when we assess developer productivity? *

Is it the number of lines written per working day? The minutes (or hours and days) between an impairment to service and a hotfix rolling out? Or maybe it’s the amount of times a developer checks their posture during a standup.

Whatever you are measuring when looking at either your own productivity or that of your team – and however you are measuring it – it might be time to expand the metrics a little. Measuring productivity is essential in making improvements to software development and delivery, but we believe there is more to developer productivity – and crucially sustainability – than simply the speed at which they write their code.

What does developer productivity mean?

A productive and successful developer is one who writes code quickly and accurately; at least, this is the currently accepted industry standard. And for good reason. Of course speed and accuracy benefit the team and the organization at large: lead times remain low, change failure rates stay minimal, and software delivery is on time and of high quality.

The current paradigm of measuring developer productivity is based on a framework of four key software delivery performance metrics. By collating years of survey data from thousands of DevOps professionals, Google’s DevOps Research and Assessment team (DORA) were able to identify these four crucial benchmarks to measure developer productivity. This allows teams to define their output between [Elite and Low], and flag the areas they need to push in to drive further success.

The four Accelerate metrics used to measure productivity:

Deployment frequency:
This is a measure of how often your team is successfully deploying code to production. As you would expect Elite teams deploy the most frequently – multiple times a day in fact – but the standard rate is around once per week.

Lead time for changes:
As well as how often code is deployed, it’s important to measure the pace of delivery. How much time does it take for committed code to reach production? More efficient teams report shorter lead times: less than one day for Elite performers, with the standard being one week.

Change failure rate:
What percentage of changes to code result in deployment failures or bugs requiring patches, rollbacks or other hands-on fixes? Elite teams report a rate of 0% – 15%, whilst in the most recent 2021 State of DevOps report the standard for High and Medium teams increased to 16% – 30%.

Time to restore services:
This final metric is used to measure the time it takes to restore normal services in the event of incidents that impair users. Faced with unplanned outages or incidents, Elite teams recover services within an hour, whilst the standard time is around a full day.

Why measure DORA metrics?

The DORA metrics take a relatively holistic approach to productivity. Measuring both deployment frequency and lead time helps teams to identify if they are reaching their internal goals and their organization’s reliability targets, or if they need to retool aspects of their development cycle to make it more efficient. Combined with an accurate appraisal of change failure rate and time to restore services, these metrics measure stability, quality and tempo of developer work, providing teams with a clearer picture of overall productivity.

Tools like Haystack and Linear B help to measure the above metrics by providing constant analysis of your team’s performance, pulling data from streams including GitHub and GitLab to help you spot blockers in your software delivery performance, and make sure your team is efficiently hitting all four metrics.

But are there limitations to the DORA framework?

What DORA doesn’t tell you

What these four metrics fail to quantify is that even the single best developer in the world has a flaw they share with all the others: they are only human.

Big, fast numbers in relation to the DORA metrics are fantastic until they drop off for no clear reason, or if you find your team excelling in lead times but falling seriously short in restoring service.

If you are neglecting to measure the person as a whole then you’ll inevitably miss the reason for inconsistent productivity: there is no sustainability in measuring productivity and code-centric metrics alone.

Collaboration and wellbeing

Real people can’t be measured purely by output; they need wellbeing checks to put the brakes on burnout, a work-life balance so they can thrive in both, and they need a positive culture of open collaboration to dedicate their full selves to work.

In DORA’s own State of DevOps Report 2021, they reported that teams sharing a culture of encouraging “information flow, trust, innovation, and risk-sharing” were more likely to report better software delivery performance, and that valuing psychological safety was indicative of a high performing team.

If you’re looking to make developer success and productivity truly sustainable, you’ll need to expand your metrics to include both wellbeing and collaboration as measurable data.

Luckily, we’ve got the tool for that.

Adadot: The fitness tracker for work

Here at Adadot we are on a mission to redefine the industry’s understanding of ‘good’ development work by combining code-based software delivery metrics with person-based wellbeing and collaboration data, to make developer success sustainable.

We pull all the productivity data you’d expect from platforms including GitLab, Jira and Google Workspace, and combine these with data from collaboration tools like Slack to give you big-picture insight into you and your team’s software delivery performance. But it is the insights we give you from this data which sets us apart.

How are you managing your work-life balance?
How many times have you replied to a Slack message well into the evening?
Are you forging strong working relationships by collaborating with the same developers on multiple projects?

With dedicated dashboards for both Wellbeing and Collaboration along with Work, measuring metrics including out-of-hours communication, responsiveness, and time spent on collaborative coding projects, Adadot has the answers to the questions that can help you on your journey towards sustainable development success.

We even provide tips and insight based on the data we measure, including cutting down on meeting times for focused work, reducing excessive fragmentation across multiple projects, and monitoring out of hours work to mitigate burn-out, helping you ensure that your success and productivity is viable, healthy and long-term.

We aren’t replacing the DORA metrics, we’re just making them more human. Find out more about how we can help measure true developer performance in http://www.adadot.com

What do great developer teams have in common?

Alex Harris — Tue, 12 Apr 2022 11:33:20 +0000

The 2021 Accelerate State of DevOps Report: Part 2

As we discussed in [Part 1] of our report, defining yourself as a ‘great’ developer is a little more complicated than simply setting the timer and seeing how much code you write. The Accelerate State of DevOps report – a data driven annual research paper from Google Cloud’s DevOps Research and Assessment team (DORA) – takes a more holistic approach to the definition, measuring a variety of global teams against four software delivery metrics. Out of this data they then rank performance into Low, Medium, High and Elite.

We know Elite teams are leading the charge on the four Accelerate metrics, but how do they do it? An Elite team is made up of elite developers, and thankfully the 2021 Accelerate State of DevOps report does explore some trends that highlight practices unique to Elite and High performing teams. Check out our sum up below for some actionable steps you can take to grow your developer skills and seriously boost your performance.

How to Become an Elite Developer

Multi-Cloud Use
2021’s report confirmed the continued rise of multi-cloud and hybrid cloud use, and threw light on the benefits this can bring to business outcomes. The most frequently cited reason for moving to a multi-cloud solution was to take advantage of the unique benefits of the different providers, with availability, disaster recovery contingency and legal compliance also factoring into the decision.

It’s telling that those who used a multi-cloud or hybrid cloud approach were 1.4 times more likely to excel in all four of the Accelerate metrics, as well as being 1.6 times more likely to meet or exceed their organizational performance targets.

Embracing SRE
Whilst a relatively new movement, adopting Site Reliability Engineering (SRE) principles in alignment with DevOps can make very real improvements to software delivery and operational performance. With a focus on cross-functional communication and psychological safety, SRE promotes practical tools and solutions to boost a team’s reliability, including a metric framework built around service level indicators and service level objectives.

DevOps and SRE clearly share a common philosophy, and an approach that incorporates both has evident benefits, with Elite performers being 2.1 times more likely to implement some form of SRE practices than Low teams. Those who do are 1.8 times more likely to achieve better business outcomes, making SRE an essential philosophy for great developers.

Documentation
Well organized, high quality and easy to find internal documentation was another trend that the 2021 report found essential in the continual success of Elite teams. With complex ways of working using ever more complicated systems, clear documentation using tools like Confluence can be the difference between a team with a defined set of goals and processes, and one that grinds to a halt at the first hurdle.

The report highlighted that teams with quality documentation are 2.4 times more likely to report better SDO performance, and suggested the following steps to improve the way you organize the information your team shares:

Document critical use cases

Create guidelines for making future changes to documentation
Ensure clear ownership over different aspects of documentation
Embed documentation into the development process
Recognise documentation work during reviews and promotions

Security
Security threats only grow smarter alongside technology, so it is increasingly important to adopt the approach that security issues are an inevitability rather than a possibility, and integrate checks and practises into each step. 2021’s report continued to prove that successfully embedding security processes into the entire development cycle can have a direct benefit to software delivery performance and reliability:

Elite teams who reported having met or exceeded reliability targets were much more likely to have integrated security protocols throughout their development process – twice as likely as the other teams.

Across the board, those teams that integrated security processes were 1.6 times more likely to achieve their organisational goals, highlighting that a preventative approach to security can directly increase the value of a development team to a business.

Along with highlighting the above, DORA recommends the following actionable security steps in their report:

Test: Ensure security requirements are part of the automated testing process.
Integrate: Have information security (InfoSec) give insight during each step of the software process.
Review: Carry out frequent security reviews for all major features
Prepare: Ensure InfoSec are involved right from the planning stage of development, to give the team plenty of time to fix any concerns.

Culture and Burnout
The final advice from DORA’s report shifts focus away from the technical side of development and instead encourages teams to analyse the culture fostered in the workplace, and how this might be directly contributing to or helping to mitigate that dreaded phenomena: developer burnout.

There were two standout culture markers to identify within a team, both referencing Westrum’s Organizational Typology:

Generative culture: With the cross functional, multidisciplinary nature of DevOps, it should come as no surprise that a positive feeling of belonging and inclusion within a team’s culture has direct benefits on performance, and goes a long way in helping to reduce burnout. In fact the report found that Elite performers meeting their reliability targets were 2.9 times more likely to work in a generative culture than Low teams.

Performance oriented: As opposed to power or rule-oriented organizations, those that subscribe to a performance based culture – one that promotes trust, innovation and risk sharing – were more likely to see high software delivery performance.

So now you know exactly how to define a great developer, and even have some tips on getting there yourself.

What makes a great developer?

Alex Harris — Mon, 11 Apr 2022 17:25:25 +0000

The 2021 Accelerate State of DevOps Report: Part 1

It might come as a surprise, but there’s more to being a great developer than the quality of your code. To define what makes a truly Elite developer in the post COVID-19 world would take years of research, mining data measured against almost countless metrics. Thankfully Google Cloud’s DevOps Research and Assessment team (DORA) have done the hard work for us with exactly that in the State of DevOps report 2021 .

Whilst you really should find time to take in the whole report, we’ve got you covered with the main takeaways from the 2021 Accelerate State of DevOps report below, where we reflect on exactly how the report defines a ‘great’ developer. And don’t worry if you’re not quite there yet; check out part 2 for actionable tips from the report to help boost your performance as a developer.

What is the State of DevOps Report?

Consolidated from data contributed by over 32,000 professionals worldwide, this annual long-running research report deep dives into carefully selected metrics measured over years, and provides invaluable insight into industry performance, delivery and operations. This resource is essential reading for developers, and can help you raise the bar from being a good developer to a great one, and perhaps even Elite.

Who took the State of DevOps Report survey?

The report pulls data directly from survey results gathered from industry professionals around the globe, running the gamut across demographics and firmographics. With workplace and industry culture directly contributing to the success of developer teams (more on that in [Part 2]), it’s vital to understand the characteristics, traits and attributes that make up the industry. See some samples below:

Demographics of those surveyed:

Gender: 12% of those surveyed identified as female, 1% as non-binary.
Disabilities: 9% reported having a disability.
Underrepresentation: 17% identified as belonging to an underrepresented group, which can include race, gender, or another characteristic. Firmographics of those surveyed:

Departments: 23% of respondents work in development or engineering teams, 21% in DevOps or SRE.
Industry: 33% work in technology, followed by financial services and retail.
Team size: 62% of those surveyed work in teams of 10 or less people, with 6% working solo.

Software Delivery Performance Metrics

The report uses four software delivery metrics to rank the teams surveyed, using these metrics to identify them as Low, Medium, High or Elite performing teams.

What are the four Accelerate metrics?

Deployment frequency: how often is new code deployed to production?

Lead time for changes: what is the length of time between code committed and production?

Time to restore services: in the event of incidents that impair users (e.g outages), how long does it take for your team to resume normal services?

Change failure rate: what percentage of deployments to production result in impaired service requiring a hotfix, rollback or patch?

The fifth metric:

2021’s report also measured a fifth metric reflecting operational performance: reliability. This has shifted from the previous report’s measure of availability, in an expansion to also include performance, latency, and scalability under the umbrella of ‘reliability’. To put it more simply, Reliability is a measure of how likely a team is to keep promises about their software.

What makes an Elite development team

Having measured all the teams surveyed against these four metrics, the report uses this data to categorise them into Low, Medium, High or Elite, with clear performance definitions for each tied to the four metrics above. As you would expect, the difference in software delivery performance between Elite and Low teams is notable throughout.

Elite vs Low teams
Deployment frequency:
Whilst Elite teams are deploying on-demand and multiple times daily, Low teams deploy less than once every six months. This is a decrease in performance for Low teams compared to the 2019 report.

Change failure rate:
When it comes to new services requiring fixes, Low teams can almost double that of Elite teams at up to 30%, with Elite teams reporting just 0%-15%.

Lead time for changes and time to restore services:

The most impressive strides Elite teams are making are in lead time for changes and time to restore services, in which they are racing ahead with 6570x faster times (yes, 6570!) than Low teams: less than one hour in both metrics for Elite teams as opposed to the six months or more it takes Low teams.

High and Medium teams
High and Medium teams add some markers in between the two extremes, and should help you identify where you land in the rankings:

Deployment frequency:
High teams deploy between once per week and once per month, whilst some Medium teams are deploying much less frequently at once per six months.

Change failure rate:
Surprisingly the change failure rate between High, Medium and Low teams is consistent at between 16%-30%, an increase for both High and Medium teams since the last report.

Lead time for changes:
High teams report lead times of between one day and one week, whilst Medium teams can take upwards of six months.

Time to restore services:
When it comes to restoring impaired services, High teams take less than one day where Medium can take anywhere between one day and one week.

How do they do it?

It’s of no surprise that the most successful teams are those with the most frequent deployments, shortest lead times, fastest times to restore services, and lowest change failure rates. Using the above data, you can see where you and your team are ranking in these metrics from Low to High, and just where you land on your journey to becoming a ‘great’ developer.

But if you still have a way to go, how do you make the jump between the rankings? What steps are Elite teams taking that give them the edge? Well help is on hand: the report highlights a variety of actions and processes that have driven software delivery performance success for teams across the four metrics in 2021, including multi-cloud use, the integration of SRE principles, and a drive to mitigate burnout. Don’t worry if time isn’t on your side – we’ve got all the need to know details in the second part of our coverage of the 2021 Accelerate State of DevOps Report.

The original piece lives here: https://insights.adadot.com/2022/03/29/what-makes-a-great-developer/