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 specific 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…
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 Defined 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
Difficult
Moderate difficulty
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
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.
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.”