Github Copilot and tools that help us code better are cool. But I’m lucky if I spend 90 minutes a day writing code. We really need to optimize the hours we spend reviewing code, updating tickets and tracing where our code is deployed. Learn how I save an hour a day streamlining non-coding tasks. This talk is unique because 99% of developer productivity tools and hacks are about coding faster, better, smarter. And yet the vast majority of our time is spent doing all of this other stuff. After I started focusing on optimizing the 10 hours I spend every day on non-coding tasks, I found I my productivity went up and my frustration at annoying stuff went way down. I cover how to save time by reducing cognitive load and by cutting menial, non-coding tasks that we have to perform 10-50 times every day. For example: Bug or hotfix comes through and you want to start working on it right away so you create a branch and start fixing. What you don’t do is create a Jira ticket but then later your boss/PM/CSM yells at your due to lack of visibility. I share how I automated ticket creation in Slack by correlating Github to Jira. You have 20 minutes until your next meeting and you open a pull request and start a review. But you get pulled away half way through and when you come back the next day you forgot everything and have to start over. Huge waste of time. I share an ML job I wrote that tells me how long the review will take so I can pick PRs that fit the amount of time I have. You build. You ship it. You own it. Great. But after I merge my code I never know where it actually is. Did the CI job fail? Is it release under feature flag? Did it just go GA to everyone? I share a bot I wrote that personally tells me where my code is in the pipeline after it leaves my hands so I can actually take full ownership without spending tons of time figuring out what code is in what release.

1. Optimize Non-Coding Time
Ori Keren
Co-Founder & CEO
LinearB

2. Intro
The developer productivity paradox
Pull Requests: can’t live with them, can’t live w/o them?
Pull Requests: Proprietary Research
How to optimize Pull Request Flow
Agenda / Overview
Transition Time Distraction Time

3. Intro

4. 1987. Wrote my first basic program
2000. Developer
2004. Team lead
2006. Director of Engineering
2007. Interwise Acquired by AT&T
2013 VP Engineering
2016. CloudLock Acquired by Cisco
2019. Started LinearB

5. Recent pod guests 👇

6. Software Development Intelligence platforms are emerging
Business Alignment
Pipeline
Observability
Workflow
Optimization
Are we investing
in the right things?
Are we executing efficiently
and with high quality?
Are we freeing devs
to focus on building?

7. Developer Productivity Paradox

8. Our job as developers is to build but...
● Meetings
● Ticket housekeeping
● Code Reviews
● Planning / Retro
● Design Reviews
6
hours a day
2
hours a day
</>

9. Sync / Time bound
Async
Coding
● Meetings
● Ticket Housekeeping
● Code Reviews*
● Planning / Retro
● Design Reviews
</>
Coding & Non-Coding tasks don’t go together
*Pull requests -> Large part of the non coding time

10. </>
Code more easily
i.e. low-code
Code faster
i.e. Github Co-Pilot
Code more securely
i.e. Snyk
There’s a million developer tools focused on coding
Code your infrastructure
i.e. terraform

11. Rules of Software Optimization
Michael A. Jackson -Rules of optimization:
* Ensure you’re optimizing the right thing
after you already built it and measured
1. Don’t do it
2. (For experts only!) Don’t do it yet*
Michael A. Jackson

12. As an industry we’re optimizing the wrong bucket
● Meetings
● Ticket housekeeping
● Code Reviews
● Planning / Retro
● Design Reviews
6
hours a day
2
hours a day
</>

13. Pull Requests.
Can’t live with them, Can’t live without them?

14. The strongest new methodology
consensus adopted by developers
(Correlated with rise of OS and GitHub popularity)
Pull requests are highly adopted

15. The Problem with Pull Requests
I Just solved a really
important problem,
need a review
Solving yet another very
important problem...
? Ready for your
review now
xx hours later……

16. The problem from a team’s perspective
From ‘The Phoenix Project’ jj
More ‘idle time’ will free up
team members to review
50% free -> 50/50 => 1hr of wait
10% free -> 90/10 => 9hr of wait
But .. we also want to optimize
for throughput
TIP:
Understand and
Manage your WIP

17. The Problem from a developer perspective
I Just solved a really
important problem ...

18. Pull Requests // Alternative View 1
“Don’t use pull requests, use CI instead”
Kief Morris d

19. Pull Requests // Alternative View 2
“Ship / Show / Ask”
Rouan Wilsenachd

20. ● Lightweight Reviews (peer reviews) detect
65% of the bugs
● 75% of the bugs are around maintainability
(hard to detect)
● The world needs much more developers
(today 0.3%), pull requests are great for on
boarding (building dev team knowledge
base) and training tool
Pull requests are are here to stay

21. Pull Requests Research
733.4K
Pull Requests
3.9M
Comments
25.6K
Developers
7
Months

22. Proprietary Developer Productivity Research
All pull requests examined 👇
733.4K
Pull Requests
3.9M
Comments
25.6K
Developers
7
Months
33% of PRs are idle
77.8% of lifespan
50% of PRs are idle
50.4% of lifespan

23. Two types of Pull Request idle time
MONDAY TUESDAY WEDNESDAY
Additional
fixes
More comments &
changes requested
Fixes Approved
& merged
Transition Time Distraction Time
Initial
comments
Open
pull request

24. Why transition time hurts developer productivity
Transition Time
Why it happens:
● Hand-offs create delays
● At first glance: all PRs are treated equally Why it hurts productivity:
● Time increases cognitive load
● Longer “reload” leads to lower quality
● More Context Switches

25. Why distraction time hurts developer productivity
Distraction Time
Why it happens:
● Interruptions
● Very Long Tasks
● Need energy breaks
Why it hurts productivity:
● Cognitive reload
● Re-read code
● Re-read comments

26. Proprietary Developer Productivity Research
733.4K
Pull Requests
3.9M
Comments
25.6K
Developers
7
Months
50% of PRs are idle
81.3% of lifespan
Pull requests spanning 1+ day examined 👇

27. Proprietary Developer Productivity Research
733.4K
Pull Requests
3.9M
Comments
25.6K
Developers
7
Months
Making sure your PR is picked within 1hr will
increase its chances to be a
“Less than a day PR”

28. Optimize Pull Request Flow

29. Take more work on the ‘non busy’ resource
I Just solved a really
important problem,
I’ll prepare and
package my PR and
then submit it
I could use a break,
this review looks fairly
clear and short

30. Keep your PRs small to optimize non-coding time
Small PRs get picked
up faster and receive
comments faster

31. Enrich with Data
● Related feature
● Estimate review time
● Risk areas
● Test coverage
Reduce the dependency
● Target relevant reviewers
● Automate as much as you can (checks)
Promote your PRs to optimize non-coding time

32. Estimate the Review Time to optimize non-coding time
Help the reviewer
understand the
workload to optimize

33. Know when your teammate is
reviewing your code
This will cut down on back and forth
Not all context switches are bad
Choose when you turn your async process into
sync, overall you could save yourself time,
energy and increase quality
Finish PRs in one day to optimize non-coding time

34. Build or Use to help Optimize
Non-Coding Time

35. Build or Use Products
to help Optimize Non-Coding Time

36. ● Github + Slack / IDE (+ optional: Jira)
● Make it Customizable and personalized
● Enrich with Context
Pros: Can fit it to team’s DNA / Culture
Cons: Intelligence Level, ROI/Justification
Option 1 - Build your own workflow bot

37. Option 2 - Leverage your git provider
Pros: No Extra Permissions
Cons: Single Source of data, Surprisingly hard to configure

38. Gaps with current Developer Workflow Optimization tools
Noisy
Learning curve
Single data source
Same for every developer
Does not improve productivity

39. WorkerB
Sharon requested your review
for this pull request:
pm-challenge/Linb 123
Estimated review time: 6 min
Only visible to you
Only visible to you
Reduces
idle time
Learns how
you work
Covers full
dev pipeline
WorkerB
CI Check reported successin QA Testing stage
pm-challenge/Linb 155 iteration timestamp
Correlates Git,
Projects & Releases
Cuts the noise
Snooze
5
2
3
Adapts to
your flow state
4
1
Only visible to you
Related Issue: LINB-2065- Outlook/365 sign in
WorkerB saves developers 50 minutes a day

40. Workflow Optimization to take it to the next level
See when your PR has
been approved and
merge right from Slack
Review the code and
approve small PRs
right from Slack

41. One click Jira tickets
Create a Jira ticket right
from Slack or Link your
PR to a Jira ticket

42. The End 😁
Questions?