What makes software development complex isn't the code, it's the humans. The most effective way to improve our capabilities in software development is to better understand ourselves.
In this talk, I'll introduce a conceptual model for human interaction, identity, culture, communication, relationships, and learning based on the foundational model of Idea Flow. If you were to write a simulator to describe the interaction of humans, this talk would describe the architecture.
Learn how to understand the humans on your team and fix the bugs in communication, by thinking about your teammates like code!
Edit
Archive
Delete
I'm not a scientist or a psychologist. These ideas are based on a combination of personal experience, reading lots of cognitive science books, and a couple years of running experiments on developers. As I struggled through the challenges of getting a software concept from my head to another developer's head (interpersonal Idea Flow), I learned a whole lot about human interaction.
As software developers, we have to work together, think together, and solve problems together to do our jobs. Code? We get it. Humans? WTF?!
Fortunately, humans are predictably irrational, predictably emotional, and predictably judgmental creatures. Of course those pesky humans will always do a few unexpected things, but once we know the algorithm for peace and harmony among humans, we can start debugging the communication problems on our team.
10. We had an AWESOME team!
We had a MOUNTAIN of automation!
We were DISCIPLINED with best practices!
+
Project FAILURE
11. +
We had a GREAT team!
We had a MOUNTAIN of automation!
We were DISCIPLINED with best practices!
How did we turn this around?
12. The Retrospective
โOur tests arenโt catching our bugs!โ
Our biggest problem
โWell, if we donโt understand
a problem, we should
collect data.โ โWhat data would help us
understand the problem?โ
18. The amount of PAIN was caused byโฆ
Likeliness(of((
Unexpected(
Behavior(
Cost(to(Troubleshoot(and(Repair(
High(Frequency(
Low(Impact(
Low(Frequency(
Low(Impact(
Low(Frequency(
High(Impact(
PAIN(
19. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
Semantic Mistakes
Stale Memory Mistakes
Association Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Creation
Using Debugger
Most of the pain was caused by human factors.
What causes PAIN?
20. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Creation
Using Debugger
What causes PAIN?
Most of the pain was caused by human factors.
Semantic Mistakes
Stale Memory Mistakes
Association Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
21. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Creation
Using Debugger
What causes PAIN?
Semantic Mistakes
Stale Memory Mistakes
Association Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
Most of the pain was caused by human factors.
22. PAIN occurs during the process of
understanding and extending the software
Complex(
So*ware(
PAIN
Not the Code.
Optimize โIdea Flowโ
23. PAIN occurs during the process of
understanding and extending the software
Complex(
So*ware(
PAIN
Not the Code.
Optimize โIdea Flowโ
Data-driven
Improvement
24. My team spent tons of time working on
improvements that didnโt make much difference.
We had tons of automation, but the
automation didnโt catch our bugs.
25. My team spent tons of time working on
improvements that didnโt make much difference.
We had well-modularized code,
but it was still extremely time-consuming to troubleshoot defects.
26. The hard part isnโt solving the problems
itโs identifying the right problems to solve.
โWhat are the speci๏ฌc problems
that are causing the teamโs pain?โ
27. We learned how to learn together
Culture
What changed on our team?
28. The Fifth Discipline
The Art & Practice of the Learning Organization
Peter Senge
The Most INSPIRING Book EVERโฆ
30. We saw the world as one big design problem?
What ifโฆ
31. Coding problem?
Weโve got tools for this.
Service 2Service 1
Human problem?
PANIC!
โLetโs ๏ฌx these HUMAN Problems!โ
A Scary Thought to Engineers
33. Code problems?
Weโve got tools for this.
Service 2Service 1
Humans Become an Engineering Problem
Service 2Service 1
Human Problems?
Weโve got tools for this too.
This Talk: Culture from the Inside Out
45. โWhat is Clojure?โ
Lisp
Functional Language
Groovy
JVM Language
Object-Oriented Language
Clojure!
Functional Language
JVM Language
New Shapes are De๏ฌned Relative to Old Shapes
46. Brain Hack #1
How can you improve your ability to
communicate with your peers and
recognize more details in your experience?
Expand your vocabulary of shapes
47. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
Semantic Mistakes
Stale Memory Mistakes
Association Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Creation
Using Debugger
Expand your vocabulary of shapes
83. caused by
caused by
Consciousness
โWhat if?โ
what if?
what if?
This
SUCKS!
I just brought down productionโฆHow do I avoid the PAIN next time?
What if I had
checked configs?
What if I had
better tests?
Brought down production
84. How do I avoid the PAIN next time?
caused by
caused by
what if?
what if?
Iโll do better
next time.
Consciousness
โWhat if?โ
Brought down production
86. Our PAIN Sensor is Horribly Miscalibrated
Ugly
Bothers us a lot
Dif๏ฌcult
Moderate dif๏ฌculty
is enjoyable
Our entire discipline has evolved in the
absence of a feedback loop.
87. Brain Hack #4
How can you recalibrate your PAIN sensor?
Visualize your โPAINโ
If you want to desire it, call it AWESOME
If you want to avoid it, call it PAIN
96. โMeโ
PAIN
How do we Repair Identity?
No.
PAIN > Disgust
โMeโ
Self-Deception
Self-Deception is a coping strategy
for resolving identity conflicts
101. Identity 2.0:
โI am the one who chooses in the momentโ
Identity 1.0:
โI am the sum of my pastโ
The database is me.
DB
Consciousness is me.
Consciousness
103. =
Me
Consciousness
Refactor the base class
What are the choices you can make everyday
that define who you are?
Identity 2.0 is a principle of continuous choice
117. A path to get us hereโฆ
What I See: Hope for Humanity
118. Strategy to make mastery-level education
FREE to EVERY HUMAN in the world
Challenge 1: $$$$$$$$$$$$$$$$$$$$$$$$
Challenge 2: Unprecedented levels of cooperation
119. I believe the path starts with usโฆ
Learning how to learn together
as a software community
121. We start with our team.
We move toward our industry.
122. 1. Measure Your PAIN
Automated Visibility Tools
Automated FAQ
โIdea Flow Mapsโ
January 1st, 2017
MVP for Individuals (OSS)
June 15th, 2017
MVP for Teams ($)
128. We design the game.
We make up the rules.
We invite the world to play.
129. Janelle Klein
openmastery.org @janellekz
How to Join:
Janelle Klein
Founder of Open Mastery
janelle@openmastery.org
1. Email Subject: โTools Pilotโ
2. Include IDE/Editor, Your OS
FREE!
Editor's Notes
Hi everyone, Iโm Janelle Klein, founder of Open Mastery and author of Idea Flow: How to Measure the pain in software development. Letโs make the pain visible! Well, why?
When weโre kidsโฆ we talk a lot about dreams.
We can be anything, we can do anything. The sky is the only limit.
Then we grow up and we get all rational. Weโve got bills to pay, and a job to do, and a family to supportโฆ weโve got no time for dreaming.
And start applying our engineering skills to conquering the biggest challenges in our world. After I got involved in business, I started to realize thatโฆ
And we start working together as an engineering community, we really can change everything.
And we start working together as an engineering community, we really can change everything.
Humans never seem to do what we want!
Then you start recognizing the patterns, โaha! this is one of those situations, orโฆ I should keep on eye on that.โ
If thereโs one thing that will accelerate your learning faster than anything else, itโs this.
Need to also mention Open Mastery Online. People in the Mentorship program weโre going to build a statical process control system for software development.
Then you start recognizing the patterns, โaha! this is one of those situations, orโฆ I should keep on eye on that.โ
If thereโs one thing that will accelerate your learning faster than anything else, itโs this.
Need to also mention Open Mastery Online. People in the Mentorship program weโre going to build a statical process control system for software development.
Then you start recognizing the patterns, โaha! this is one of those situations, orโฆ I should keep on eye on that.โ
If thereโs one thing that will accelerate your learning faster than anything else, itโs this.
Need to also mention Open Mastery Online. People in the Mentorship program weโre going to build a statical process control system for software development.
Then you start recognizing the patterns, โaha! this is one of those situations, orโฆ I should keep on eye on that.โ
If thereโs one thing that will accelerate your learning faster than anything else, itโs this.
Need to also mention Open Mastery Online. People in the Mentorship program weโre going to build a statical process control system for software development.
Then you start recognizing the patterns, โaha! this is one of those situations, orโฆ I should keep on eye on that.โ
If thereโs one thing that will accelerate your learning faster than anything else, itโs this.
Need to also mention Open Mastery Online. People in the Mentorship program weโre going to build a statical process control system for software development.
ยฉ2014 New Iron Group
Our brain works like a big prediction engine. Imagine your walking down the stairs, thinking about something else, everything feels as it should be.
At this point all your predictions are confirmed.
But then, you discover one of the steps isnโt where itโs supposed to be.
At that moment, everything in your body is paying attention. Am I going to fall? Whereโs the railing? Do I need to brace myself.
This is what happens when your predictions are violated. A conflict is just a violated prediction.
Thereโs this decision point when we validate the code and ask ourselves, โdoes the behavior match our expectations?โ
Thereโs this decision point when we validate the code and ask ourselves, โdoes the behavior match our expectations?โ
When we try to make progress, learning gets in the way. Especially if weโre unfamiliar with the system. And with conflict loops we have to troubleshoot the problem, then rework our solution before we get back to a stable state.
When we try to make progress, learning gets in the way. Especially if weโre unfamiliar with the system. And with conflict loops we have to troubleshoot the problem, then rework our solution before we get back to a stable state.
Quick demo.
So I started keeping track of all my painful interaction with the code and visualizing it on a timeline like this.
The pain started [] when I ran into some unexpected behavior and ended [] when I had the problem resolved.
So that was 5 hours and 18 minutes of troubleshooting, I think everyone would agree thatโs pretty painful.
When thereโs problems evaluating alternatives, we see this red-blue-yellow tumble pattern of trial and error.
First, we discover our strategy wonโt work -- thatโs the red.
then we go back to the drawing board to figure out a plan B, thatโs the blue,
Then we gotta do the rework -- thatโs the yellow.
If I saw this pattern I would ask... [read]
Thereโs this decision point when we validate the code and ask ourselves, โdoes the behavior match our expectations?โ
When we try to make progress, learning gets in the way. Especially if weโre unfamiliar with the system. And with conflict loops we have to troubleshoot the problem, then rework our solution before we get back to a stable state.
Thereโs this decision point when we validate the code and ask ourselves, โdoes the behavior match our expectations?โ
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
Warning: This isnโt for the feignt of heart.
Warning: This isnโt for the feignt of heart.
Thereโs this decision point when we validate the code and ask ourselves, โdoes the behavior match our expectations?โ
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
We have an instinct about what we ought to do:
Warping of experience. Imagining the world we want to live in, and believing it to be true.
Because I really want to solve this problem, like, there isnโt anything in the world, that Iโm more passionate about, but I canโt do this alone. I need your help. Letโs do this together.
And we start working together as an engineering community, we really can change everything.
This is our [read] with companies and community groups around the world, thatโs headquartered in Austin. Weโre all learning together, and helping each other succeed.
The pain isnโt something inside the code, pain occurs during the process of interacting with the code. So I started optimizing forโฆ and I did that, with the help of a data driven feedback loop.
If we donโt make time to deal with emerging risks and emerging risks, we will never get out of this cycle.
This happens all the time in software development. Imagine the idea you had conceptually mapped to an โitโ becomes a โfunction for producing its.โ