Digging one level deeper into the details of Idea Flow Learning Framework, we'll do this second session as a group troubleshooting game! After we play the game, we'll do an "Experience Review" and analyze the causes of diagnostic difficulty, the nature of decision-making, and discuss strategies for making better decisions.
**The Troubleshooting Game:** I'll split the audience into two teams. Team 1 will stealthily hide a bug in the code. Team 2 will have to track down the bug in as little time as possible. Then Team 2 will have their chance to stump Team 1. The team that troubleshoots the bug the fastest will walk away with an exciting prize!
After we play the troubleshooting game, we'll do an "Experience Review" with each team's coding experience. Rather than optimizing the code, we'll focus on optimizing the problem-solving process. We will:
1. Visualize and discuss the differences between code sandwiches
2. Identify the major factors that caused diagnostic difficulty
3. Discuss the troubleshooting strategies used by each team and what made them more or less effective.
While it's certainly challenging to understand how we think and make decisions, it's an incredible opportunity to learn. By recognizing the inputs to our decisions, and how we evaluate trade-offs, we can compare our internal decision-making logic with our peers. With objective feedback on the consequences of our decisions, we can systematically optimize developer experience.
Learn how to master the art of software development with Idea Flow Learning Framework!
2. What is this talk about?
Process of Idea Flow Learning Framework
How to do “Experience Reviews”
The Troubleshooting Game!
The art of troubleshooting
14. Three Stages of Mastery
Visibility
Clarity
Awareness
See
Explain
Predict
15. Idea Flow Maps visualize the
experienced difficulty of a problem-solving task.
Visibility
See the pain
“Friction”
16. Our level of understanding
is constrained by the diversity of our conceptual metaphors.
Clarity
Expand your vocabulary of patterns
17. Awareness
Predict the consequences of decisions
The quality of our decisions is limited by our ability to
ask the right questions at the right time.
18. Imagine your brain is a
decision-making engine
written in code.
Breakpoint
Stop and Think!
19. What’s a Decision Principle?
1. How do I evaluate my situation?
2. What should I optimize for?
Answers Two Questions
Pseudo code for making trade-off decisions
43. Experiment
Time
Time Warp Bias
Setup Experiment Analyze Results &
Decide Next Experiment
Execute
“Optimize experiments for human cycles.”
“How could I reduce the time spent on human cycles?”
44. Was it time-consuming to setup the inputs?
What made it time-consuming?
Was it fast or slow to execute the experiment?
What made it time-consuming?
Was it time-consuming to analyze the results?
What made it time-consuming?
Execution
Decide
Next Action
Setup Inputs
How could we have reduced the human cycles?
Time Warp Questions
45. Code Sandwich
Behavior Complexity
Observability
Ease of Manipulation
“How can I reduce the thickness of my code sandwich?”
“Optimize for low diagnostic difficulty.”
The thickness of the
sandwich increases
troubleshooting
difficulty
46. What behavior were we trying to understand?
Was the core behavior complex or simple?
How difficult was it to see what was going on?
What made it difficult to see?
How difficult was it to manipulate the behavior?
What made it difficult to tinker?
Observability
Ease of
Manipulation
Behavior
Complexity
How could we reduce the thickness of the code sandwich?
Code Sandwich Questions
47. Cloud of Possibilities
“How can I generate clues to eliminate some possibilities?”
“Optimize the experiments to generate useful clues.”
48. Was the cloud of possibilities big or small?
What were some of the clues we saw?
Were some of the clues more useful than others?
Scope
Narrowing
Speed
How could we have have narrowed the possibilities faster?
Cloud of Possibilities Questions
59. Learn
Optimize
Optimize - What strategies could have reduced the pain?
Focus
Observe
Conclude
Focus: How could we have reduced the experiment pain?
60. What were some other possible options?
At what point did we choose an option?
What inputs did we consider?
How did we evaluate the situation?
Breakpoint
Stop and Think!
61. What if we had thought about
decision principles?
Which might apply?
Breakpoint
Stop and Think!
63. Learn
Learn - What questions should we ask ourselves in the future?
Focus
Observe
ConcludeOptimize
Focus: How could we have reduced the experiment pain?
64. 14:230:00
I want to avoid this…
Thinking Checklist
Is my current approach likely to cause a thick sandwich?
Situation: start of subtask
Let’s Make a Checklist!
“What question could I ask my future self to
recognize similar risks in the future?”
“In what situation would I ask the question?”
65. 0:00
Stop and Think:
Is my current approach likely to
cause a thick sandwich?
Predict: Low Experiment Pain
Strategy Experiments
66. 18:120:00
Stop and Think:
Is my current approach likely to
cause a thick sandwich?
Predict: Low Experiment Pain
False Prediction
Strategy Experiments
67. 18:120:00
Stop and Think:
Is my current approach likely to
cause a thick sandwich?
False Prediction
Strategy Experiments
High-Risk Situations
1. Can’t isolate from bootstrap
2. Observe through visualization
3. Manipulate through database
4. Too many changes at once
Q: Is my current approach likely to
cause a thick sandwich?
Start of Subtask
73. Learning is Knowledge Expansion
Iterate - What type of learning do we need most?
Should we broaden the data?
…expand vocabulary?
… or run experiments?
84. IFM Tools
IFM Tools
IFM Tools IFM Tools
IFM Tools
IFM Tools
Idea Flow Analytics PlatformPrivate data
Companies Learning Together!
Revenue from
membership fees
to fund core
development
85. @janellekz
Open Mastery 2016
Join us! @openmastery
janelle@newiron.com
Thank you!
Free e-book if you sign up
before publish day! (Jan 2016)
Tweet about #ideaflow!
IFM Tools available at:
github.com/ideaflow/tools
Notas do Editor
Hi Everyone, I’m Janelle Klein, from Austin, TX. Been a developer for 15 years, then did consulting for a while, and now I’m CTO of a software-niche recruiting company that specializes in technical assessment and mentorship. The project I’ve been working on over the last several years has been to figure out how to codify and teach the art of our craft. So while it might seem a little weird to work for a recruiting company, technical assessment and mentorship really go hand in hand, that in order to teach a skill, we have to be able to correctly diagnose the concepts that are missing. It’s like troubleshooting people’s brains. Brains are really cool.
So what’s this talk about — the art of better. It doesn’t get more abstract than this. So I’m going to take this abstract fuzzy notion of better that we don’t even have words to describe, and I’m going to break it down into concrete conceptual models, strategies, and things we can actually measure. The philosophy behind my mentorship technique, and my book.
The pain isn’t something inside the code, pain occurs during the process of interacting with the code. The problems I focused on fundamentally changed.
See the pain
Rework Risk is driven by the likelihood...
Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements.
The longer we delay before making corrections, the greater the rework.
It’s not good or bad, it just is.
It’s not good or bad, it just is.
It’s not good or bad, it just is.
Rework Risk is driven by the likelihood...
Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements.
The longer we delay before making corrections, the greater the rework.
But that wasn’t enough either… despite those things, he was still struggling.
Focus on one decision principle until you have it down.
1. Basically draw a picture of what I’m planning to do and list out the subtasks.
2. Then record an Idea Flow Map during the task.
3. Then both of those, the decisions we made and the results of the decisions,
we think about how they’re connected and how we can do better
4. Lessons learned meeting, I do monthly to share problems, discoveries outside the team. Just let anybody come that wants to come.
[pause]
Instead, we want to understand what’s causing the biggest problems, so we can solve those things first.
That’s where the modeling framework comes in.
The weekly focus meeting drives the process -- there’s 4 steps: [read]
Instead, we want to understand what’s causing the biggest problems, so we can solve those things first.
That’s where the modeling framework comes in.
The weekly focus meeting drives the process -- there’s 4 steps: [read]
Only a handful of things that cause excessive troubleshooting time.
We optimize for execution time, even when the time spent on human cycles can completely dwarf the execution time. Why do you think that is?
We were trying to do all the right things. We had CI, unit testing, design reviews, code reviews. All that stuff you’re supposed to do.
What behavior are we trying to understand or validate?
Is there anything in the way of our observations?
What aspects of the behavior are we trying to manipulate?
Is there anything preventing us from easily changing the behavior?
How complex is the behavior we’re exercising?
Is there a way to reduce the complexity?
We were trying to do all the right things. We had CI, unit testing, design reviews, code reviews. All that stuff you’re supposed to do.
We were trying to do all the right things. We had CI, unit testing, design reviews, code reviews. All that stuff you’re supposed to do.
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.
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.
Rework Risk is driven by the likelihood...
Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements.
The longer we delay before making corrections, the greater the rework.
Rework Risk is driven by the likelihood...
Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements.
The longer we delay before making corrections, the greater the rework.
Focus on one decision principle until you have it down.
Rework Risk is driven by the likelihood...
Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements.
The longer we delay before making corrections, the greater the rework.
Think about the scope of your knowledge as three concentric circles.
Each circle limits the growth of the circles immediately inside it.
When we’re trying to expand our knowledge, we can’t understand what we don’t see. We can’t be aware of what we don’t understand.
Visibility constrains Clarity constrains Awareness.
To expand our knowledge, we have to [] focus on breaking the most limiting constraint.
Think about the scope of your knowledge as three concentric circles.
Each circle limits the growth of the circles immediately inside it.
When we’re trying to expand our knowledge, we can’t understand what we don’t see. We can’t be aware of what we don’t understand.
Visibility constrains Clarity constrains Awareness.
To expand our knowledge, we have to [] focus on breaking the most limiting constraint.