Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Developer Productivity Engineering by Panayiotis Thomakos Ruby is often praised for being a happy language. For highly motivated developers, a large part of happiness is tied to being productive. How can we extend the productivity gains we experience from writing Ruby to an entire engineering organization? At Strava we are experimenting with a framework we call Developer Productivity Engineering (DPE). DPE applies the principles of Site Reliability Engineering, developed by Google, to improving productivity through automation for both individual engineers and engineering organizations. This talk is a detailed view of the DPE framework and our experience with it so far.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In the presentation titled 'Developer Productivity Engineering' by Panayiotis Thomakos at GoRuCo 2017, the focus is on enhancing developer productivity through a structured framework known as Developer Productivity Engineering (DPE). Drawing inspiration from Site Reliability Engineering (SRE) principles established by Google, DPE aims to improve productivity by automating repetitive tasks. **Key Points Discussed:** - **Definition of Productivity:** Productivity is closely linked to happiness, which stems from engagement in challenging tasks versus monotonous activities. - **Role of Automation:** Although DPE is not solely focused on automation, it represents a significant aspect of the framework. The importance of strategically determining when to automate tasks is emphasized. - **Framework Overview:** DPE can be broken down into three steps: identify, measure, and prioritize productivity bottlenecks within an organization. - **Criteria for Identifying Toil:** Seven criteria are proposed to assess whether a task is a candidate for automation: - Manual - Repetitive - Automatable - Tactical rather than strategic - Not yielding enduring value - Scales with organizational growth - **Measuring Productivity:** Instead of tracking time, the speaker suggests measuring toil and collecting feedback from team members on manual tasks. Tools should be instrumented to understand their performance better. - **Prioritization of Automation:** The speaker outlines a method to prioritize automation based on four cost factors: toil cost, implementation cost, maintenance cost, and onboarding cost. This approach assists teams in determining which tasks should be automated first. **Case Study:** An example from Strava is shared, where the mobile release process was identified as labor-intensive, costing approximately 20 developer hours weekly. After implementing automation, it is estimated that the organization will save 17 developer hours per week. **Conclusion:** The principles of Developer Productivity Engineering can be practically applied not only within organizations but also for personal projects, leading to significant time savings and improved productivity for developers.
Suggest modifications
Cancel
