Discussion Forum > Improving Faster
In known problem domains with clear solutions and clear feedback for learning, this tends to work. This is because the habits built from repetition directly correlate to increased future success. However, in domains that lack such clear guarantees or feedback loops, this doesn't work so much, and often you have to encourage more exploration and mistakes and dead ends.
March 4, 2021 at 2:42 |
Aaron Hsu
Aaron Hsu
What you say makes sense, but it’s not complete. Take for example, Golfing. Would you say there are clear solutions? There are mistakes, a need for exploration, dead ends. But there is also clear feedback for learning, in the form of practicing a single stroke.
So I think a clear feedback loop is sufficient. But i think other situations also apply. If I look at running, I may not have access to a coach with fancy gait analysis tools, but if I focus on my stride and doing what feels more effective, I ought to be able to improve. I think even fuzzier domains can have this effect. You will need exploring paths for sure, but a focus on mechanics can be valuable, I think. I’m still exploring the concepts.
So I think a clear feedback loop is sufficient. But i think other situations also apply. If I look at running, I may not have access to a coach with fancy gait analysis tools, but if I focus on my stride and doing what feels more effective, I ought to be able to improve. I think even fuzzier domains can have this effect. You will need exploring paths for sure, but a focus on mechanics can be valuable, I think. I’m still exploring the concepts.
March 4, 2021 at 14:06 |
Alan Baljeu
Alan Baljeu
Here's a bigger example: Software development. That's a field that full of creativity and exploration, but I have a suspicion that focusing on correct code (no bugs) will make development much more efficient.
March 4, 2021 at 14:32 |
Alan Baljeu
Alan Baljeu
Most sports like running or golf are more or less closed systems that can be trained through repetition. Even in such closed systems, there is room for exploration, because the optimal solution isn't always known. The key is that your experiences in the past have a very strong signal for your experiences in the future with those things. They usually have known quantity solutions that might not be globally optimal, but are repeatable, and so you can work on improving that. So for instance, you can work on replicating a certain breathing technique and running form or swing technique, and you will see direct improvements if you practice authentically.
I happen to work in software development, on the research/exploration side, so this is an interesting one. As a whole, software development doesn't strictly fall into the "gentle problem" space like sports do, because the best code is written by people who are working outside of the box. However, the vast majority of what most developers do right now is relatively well known and understood. So they train to do those things, and with practice they get very good at that, much like a musician.
But like the music industry, we have something of a momentum problem and a specialization problem. So a lot of what happens in software is approached as a specialist field with known quantity solutions, but this is driving us into corners that are sometimes hard to get out of, and they reduce our ability overall to produce long term better and cleaner solutions.
In a context like this, you usually get pretty good feedback about obvious bugs and errors, so you can concentrate on processes that you can create to result in more "correct" code in that respect, but that's only a small part of the whole, and often the more critical elements, like performance, growth and flexibility of the code, human resources, maintenance costs, fit for purpose, business value, and the like are *much* harder to know, plan, or even understand, and the mistakes made there often have very poor feedback signals, so you might have a non-buggy solution, but it's the wrong solution well executed, and you won't find that out until much further down the road.
This is why certain methods to improve the agility and feedback loops around those more meta levels have arisen, so that we can react to new data faster, as well as enable better intuitive exploration of a domain and encourage cross-domain thinking. But that's getting into the "wicked problem" territory.
I happen to work in software development, on the research/exploration side, so this is an interesting one. As a whole, software development doesn't strictly fall into the "gentle problem" space like sports do, because the best code is written by people who are working outside of the box. However, the vast majority of what most developers do right now is relatively well known and understood. So they train to do those things, and with practice they get very good at that, much like a musician.
But like the music industry, we have something of a momentum problem and a specialization problem. So a lot of what happens in software is approached as a specialist field with known quantity solutions, but this is driving us into corners that are sometimes hard to get out of, and they reduce our ability overall to produce long term better and cleaner solutions.
In a context like this, you usually get pretty good feedback about obvious bugs and errors, so you can concentrate on processes that you can create to result in more "correct" code in that respect, but that's only a small part of the whole, and often the more critical elements, like performance, growth and flexibility of the code, human resources, maintenance costs, fit for purpose, business value, and the like are *much* harder to know, plan, or even understand, and the mistakes made there often have very poor feedback signals, so you might have a non-buggy solution, but it's the wrong solution well executed, and you won't find that out until much further down the road.
This is why certain methods to improve the agility and feedback loops around those more meta levels have arisen, so that we can react to new data faster, as well as enable better intuitive exploration of a domain and encourage cross-domain thinking. But that's getting into the "wicked problem" territory.
March 4, 2021 at 20:24 |
Aaron Hsu
Aaron Hsu
Creating those feedback loops is the point I think. Those are technical tools that one can use to focus on doing things better. There are loops in a problem-idea-development feedback and getting better at tightening that loop will accelerate you. A smaller loop is the code-compile loop. If you become expert at formulating quality code more efficiently you can accelerate. The next loop is Test Driven development. Writing small tests even as you code creates a loop that rapidly confirms if your program is behaving as intended.
In music, it’s full of creative expression, but the one who does it best is the one who masters the scales of his instrument. Everyone can play scales, but who can play faster, with fewer errors, with tone control, with arpeggios, whatever. It’s technique that gets you more ready to focus on the music after.
In music, it’s full of creative expression, but the one who does it best is the one who masters the scales of his instrument. Everyone can play scales, but who can play faster, with fewer errors, with tone control, with arpeggios, whatever. It’s technique that gets you more ready to focus on the music after.
March 5, 2021 at 12:44 |
Alan Baljeu
Alan Baljeu
March 6, 2021 at 6:23 |
Aaron Hsu
Aaron Hsu
Thanks for that. I was secretly fishing for the source of your conviction. I am checking it out.
For the other side, Peak, by Anders Ericsson, the guy who invented the 10,000 hour rule.
For the other side, Peak, by Anders Ericsson, the guy who invented the 10,000 hour rule.
March 6, 2021 at 14:11 |
Alan Baljeu
Alan Baljeu
Aaron and Alan:
Feedback loops can be exceedingly simple. For instance my wife's car has a manual gearbox and even after several years driving it she kept crashing the gears. I told her that every time she changed gear she should mark herself out of 10. Result - she no longer has any problem.
My car is has an automatic gearbox, and I tried the same thing. I became far more sensitive to exactly what happens with the gears according to the road situation. Now I can manage the acceleration and braking so as to achieve the best possible gear and speed for each situation.
Feedback loops can be exceedingly simple. For instance my wife's car has a manual gearbox and even after several years driving it she kept crashing the gears. I told her that every time she changed gear she should mark herself out of 10. Result - she no longer has any problem.
My car is has an automatic gearbox, and I tried the same thing. I became far more sensitive to exactly what happens with the gears according to the road situation. Now I can manage the acceleration and braking so as to achieve the best possible gear and speed for each situation.
March 6, 2021 at 21:05 |
Mark Forster
Mark Forster
Alan:
Peak is referenced and discussed in the Range book. Additionally, I like the Kanban book by David Anderson for discussing this stuff in the context of software technology companies.
Peak is referenced and discussed in the Range book. Additionally, I like the Kanban book by David Anderson for discussing this stuff in the context of software technology companies.
March 7, 2021 at 5:50 |
Aaron Hsu
Aaron Hsu
<<Focusing on efficient execution of accurate typing is among the best work for getting fast. The more accuracy you focus on the better, especially as you begin to increase the speed. One reason for this is that you are much more efficiently programming the brain's neural pathways when you are 100% accurate then when you are less accurate.>>
Aaron was writing about super-fast typing, but I'm thinking this is a universal principle. Replace 'typing' in the first line with any activity where you can measure or judge efficacy. I think the paragraph applies. I'm thinking now, what can I do better?