How to Improve Developer Productivity • Jez Humble • YOW! 2020
Vložit
- čas přidán 10. 11. 2023
- This presentation was recorded at YOW! 2020. #GOTOcon #YOW
yowcon.com
Jez Humble - SRE at Google Cloud & Lecturer at UC Berkeley @JezHumble
RESOURCES
continuousdelivery.com
github.com/jezhumble
/ jez-humble
/ jezhumble
sre.google/resources
ABSTRACT
Wouldn't it be great if we could rank developers based on their productivity, reward the best ones, and make sad noises at the others?
Don't be silly, developer productivity isn't an innate ability that you can measure and rank!
This talk will discuss how to think about and improve productivity based on the longest-running academically rigorous research investigation into the practices and capabilities that drive high performance in software delivery. Find out what drives productivity, how you can do more of it, and why it's important. Discover how tools and culture both impact productivity, and how to make a research-based argument for reducing technical debt. [...]
RECOMMENDED BOOKS
Nicole Forsgren, Jez Humble & Gene Kim • Accelerate • amzn.to/442Rep0
Kim, Humble, Debois, Willis & Forsgren • The DevOps Handbook • amzn.to/47oAf3l
Jez Humble & David Farley • Continuous Delivery • amzn.to/452ZRky
Jez Humble, Joanne Molesky & Barry O'Reilly • Lean Enterprise • amzn.to/47pcOXD
/ gotocon
/ goto-
/ goto_con
/ gotoconferences
#DeveloperProductivity #SLO #SRE #ChaosEngineering #Serverless #PlatformEngineering #2Sigma #GoogleCloud #JezHumble #DevOps #Accelerate #YOWcon
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
czcams.com/users/GotoConf... - Věda a technologie
I loved this talk. Is this deck available anywhere?
Don't force them to use Scrum. Don't force them to use Java.
SCRUM is a time suck
I like scrum and it works well for our team. I chose to work somewhere that uses scrum though. If we decided to abandon scrum for something less structured, I’d probably leave tbh, so I can sympathize with the opposite scenario. There’s more than one way to get work done
Scrum is a scam
I measure by number of merge requests done. It involves many different aspects:
* code review process
* communication with peers
Generally I see great correlation between high performers and number of merge requests completed. It is not a single measurement of course, I also take into account how active person on other code reviews, what his impact in general teams productivity, how much time he spent on non-development task, how much he invested in knowledge of other peers, etc
I think you missed the part when he said "it's not a good idea to measure individual productivity", which of course you can disagree with but you gotta have solid data if you were to contradict with the DORA research i.e. it can't be just an anecdotal sample
@@maf_aka that's terrible statement that you shouldn't measure individual productivity.
It absolutely makes sense, but we have to eliminate in this case competion and focus on collaboration to avoid brilliant jerks which take care about theirself only. That's my 10 years experience and practice shows that individual performance meters
@@sergii-mgx his words not mine 09:24
but also like I said, you're not gonna convince people with your anecdotal "10 years experience" statement vs a large sample size yearly controlled research like DORA, sorry.
@@maf_aka focus on outcomes, measure individual productivity = succees ;)
Thanks for the talk. I don't get idea of not measure individual performance. It's needed for example if company have different level of bonuses based on performance, or if an engineer want to get promotion. How is it solve in google way?
It is all a matter of risk analysis. Some industries and applications are not suitable for deploying daily because the risks outweigh the benefits. In some industries an hour outage is a very big deal. There is no golden rule that applies to all teams and products.
You can still deploy daily to a staging env, even if you can't do prod
I believe you have to ask Jez Humble himself @jezhumble because this talk was three years ago.
develop better no-code tools and use these