What makes a great developer?
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 .
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.
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.
There are many skills that a skilled developer must learn... What to think, how to code and make code usable and tested, the best way to interact with your colleagues and superiors, and how to adapt your work into the business model. The most difficult of all is the grit to persevere when your hardware, software environment, the development environment, political context and the entire universe seem to conspire to cause your code to not function, work properly, or fail to function on time. This is when you need to take off your big boy britches, throw a smack in the universe's eye and put your nose to the ground or whatever hackneyed phrase gets you to swallow the thing up and get to work. Sometimes , you'll be looking at things that make you feel sick whether you or someone else has left a huge old turd-pile on the plates, and you just need to be grit to change the situation.
The difference in value between good and excellent engineers isn't an issue of time and effort. The best engineers typically put in less effort to get the same amount of work completed. It's partly due to efficiency. Good habits and experiences make an engineer more productive and ready to tackle many tools and more issues.
The differences are in solving problems right the first time. The best engineers do not make simple mistakes that need to be rediscovered, and expensively later. Poor engineers are able to solve issues with hacks that effectively trades the fix for an increase in the technical debt for the software which has to be paid back. The best engineers might even do longer to solve an issue, but they are actually fixing the issue.
admin-https://omegletv.cam/
Some stellar points here! I think partly Google tried to address some of the ingenuity and perseverance you mention here with factors like change failure rate and lead time for changes. Reading between the lines of their report they are trying to quantify a team's ability to ship fast and dust themselves off and try again which when talking about high-growth environments is key.
On your last point about technical debt and taking longer to think about solutions is something that we often have disagreements about in the team. Some of us are more action oriented whilst others are thinking more long term. IMHO this largely depends on product maturity. For young companies / products with a ticking runway shipping fast is a matter of life or death. Tech debt is collateral damage and the best devs are aware of this. For more mature products one can argue that the balance is reversed. It also depends on customer bug tolerance and other factors. Either case, looking at Google's DORA framework they seem to err more towards speed and fast deployments .
Let me know what you think!