With regards to the unintuitive nature of compounding returns over a long period of time, I wanted to understand better how we advanced our society so quickly and why it appears to be going faster day by day.
With regards to investing, the current human lifespan is just out of reach from truly seeing the absurd affects first hand of continuously small compounding over long periods of time.
This is the avg annual returns at 100-500 years with 3% CAGR compound annual growth rate
19.21863% (100 years)
184.67790%
2366.17116%
34105.92955%
524375.44683% (500 years)
542K% is absurd.
However, I think this might be slightly flawed.
"But most of us struggle to grasp the power of tiny continuous improvements. A 1% improvement may seem marginal, but do it every day for one year you will improve 37x!"
This assumes that you continually make 1% improvements every single day (1% better than the previous day). I think it's actually linear. You save 1% of your days time every day, but you aren't 1% better than the previous day). At the end of the year, given that you do this 365 days a year, you will save 3.65 days worth of time.
maybe more if you take that 1% of time savings each day and try to increase your productivity further.
Given all this, I think TDD saves me more than 1% in productivity :)
Hey Ben! Nice to see you here. Sorry for the late response. It took me time to process this!
In that quoted statement, I specifically talk about skill improvement. I don't equate 1% skill improvement to 1% time-saving. The more you practise it, the better you'd get, and that improvement each time could be seen as a 1% marginal improvement. It took me ~6 months of deliberate practice to adopt TDD.
I see skill improvement as compounding because, at some point, it'll become automatic (habit).
I think skill improvement is only compounding if the skill that you're improving is the skill of compounding (scaling).
As an analogy to software, the skill that you would be improving is the skill utilizing multiple cores. I can only overclock a single core so much till it overheats. But If I work on the skill of utilizing multiple cores, there is no limit to how much work can be done.
I imagine if I'm working at Chipotle as a single core, I could increase the efficiency of chopping vegetables and serving customer's till I reach a theoretical limit of how fast my limbs can move, till I overheat. Every day that I learn how to chop vegetables faster or how to checkout on the POS system faster doesn't equate into compounding returns.
So I think that the skill improvement would be closer to linear if you are using the same testing framework / patterns day in and day out and you are just learning how to type faster or how to apply the same pattern/framework faster.
However, if you are every day learning how to make the test framework or application more testable every day, then this is closer to compounding returns. You are improving your tools versus how fast you are improving using those tools
Looking at the software engineering space and what is published, there always seems to be ‘something’ that is ‘driving development’.
TDD = Test Driven Development
BDD = Behavior Driven Development
DDD = Domain Driven Development
etc
All of these encode an intent with which software development proceeds. And that, IMO, generates the critical question: What is the most beneficial way for me to provide direction and momentum to the work I am doing?
DDD acronym ends with "Design", but I agree with your observation. Could you clarify your question? Are you trying to choose one approach over the others and which one is the 'most beneficial' one? In my experience, TDD, BDD, and DDD are not mutually exclusive.
The question is not one for you to answer to me. It is meant as a generative question to guarantee that something is ‘driving’ our work and generates momentum. I see that as the most substantial benefit of TDD.
I used language to get to the main ideas behind TDD. Yes, the examples are not mutually exclusive. They were only used to demonstrate a pattern of intent behind methodologies.
Apologies for the misinterpretation, James! Yes, I completely agree that these methods, including TDD, provide direction and momentum to our work. They establish a workflow that generates a positive feedback loop.
Your comment on the 'positive feedback loop' interests me. What is the positive feedback that enables looping? Are there such negative signals as well? And is there a benefit to them?
(Now, I am directly addressing you with a question. Apologies for the earlier confusion.)
You may have better results without TLWs/Three Little Words.
I had to look up TTD to understand the article that is a no no. It assumes the first step of me knowing what I am trying to find out. I had red the whole article before that.
The problem with trying to find out something is that you may be a blank sheet starting out. Always assume everyone is a blank sheet looking for information before you use shorthand on them.
Hey Wisen! Ben here,
With regards to the unintuitive nature of compounding returns over a long period of time, I wanted to understand better how we advanced our society so quickly and why it appears to be going faster day by day.
With regards to investing, the current human lifespan is just out of reach from truly seeing the absurd affects first hand of continuously small compounding over long periods of time.
This is the avg annual returns at 100-500 years with 3% CAGR compound annual growth rate
19.21863% (100 years)
184.67790%
2366.17116%
34105.92955%
524375.44683% (500 years)
542K% is absurd.
However, I think this might be slightly flawed.
"But most of us struggle to grasp the power of tiny continuous improvements. A 1% improvement may seem marginal, but do it every day for one year you will improve 37x!"
This assumes that you continually make 1% improvements every single day (1% better than the previous day). I think it's actually linear. You save 1% of your days time every day, but you aren't 1% better than the previous day). At the end of the year, given that you do this 365 days a year, you will save 3.65 days worth of time.
maybe more if you take that 1% of time savings each day and try to increase your productivity further.
Given all this, I think TDD saves me more than 1% in productivity :)
Hey Ben! Nice to see you here. Sorry for the late response. It took me time to process this!
In that quoted statement, I specifically talk about skill improvement. I don't equate 1% skill improvement to 1% time-saving. The more you practise it, the better you'd get, and that improvement each time could be seen as a 1% marginal improvement. It took me ~6 months of deliberate practice to adopt TDD.
I see skill improvement as compounding because, at some point, it'll become automatic (habit).
I think skill improvement is only compounding if the skill that you're improving is the skill of compounding (scaling).
As an analogy to software, the skill that you would be improving is the skill utilizing multiple cores. I can only overclock a single core so much till it overheats. But If I work on the skill of utilizing multiple cores, there is no limit to how much work can be done.
I imagine if I'm working at Chipotle as a single core, I could increase the efficiency of chopping vegetables and serving customer's till I reach a theoretical limit of how fast my limbs can move, till I overheat. Every day that I learn how to chop vegetables faster or how to checkout on the POS system faster doesn't equate into compounding returns.
So I think that the skill improvement would be closer to linear if you are using the same testing framework / patterns day in and day out and you are just learning how to type faster or how to apply the same pattern/framework faster.
However, if you are every day learning how to make the test framework or application more testable every day, then this is closer to compounding returns. You are improving your tools versus how fast you are improving using those tools
Looking at the software engineering space and what is published, there always seems to be ‘something’ that is ‘driving development’.
TDD = Test Driven Development
BDD = Behavior Driven Development
DDD = Domain Driven Development
etc
All of these encode an intent with which software development proceeds. And that, IMO, generates the critical question: What is the most beneficial way for me to provide direction and momentum to the work I am doing?
DDD acronym ends with "Design", but I agree with your observation. Could you clarify your question? Are you trying to choose one approach over the others and which one is the 'most beneficial' one? In my experience, TDD, BDD, and DDD are not mutually exclusive.
The question is not one for you to answer to me. It is meant as a generative question to guarantee that something is ‘driving’ our work and generates momentum. I see that as the most substantial benefit of TDD.
I used language to get to the main ideas behind TDD. Yes, the examples are not mutually exclusive. They were only used to demonstrate a pattern of intent behind methodologies.
Apologies for the misinterpretation, James! Yes, I completely agree that these methods, including TDD, provide direction and momentum to our work. They establish a workflow that generates a positive feedback loop.
Your comment on the 'positive feedback loop' interests me. What is the positive feedback that enables looping? Are there such negative signals as well? And is there a benefit to them?
(Now, I am directly addressing you with a question. Apologies for the earlier confusion.)
You may have better results without TLWs/Three Little Words.
I had to look up TTD to understand the article that is a no no. It assumes the first step of me knowing what I am trying to find out. I had red the whole article before that.
The problem with trying to find out something is that you may be a blank sheet starting out. Always assume everyone is a blank sheet looking for information before you use shorthand on them.
What is TLW?
I assumed this is about the lack of explanation of what the acronym TDD mean. Thanks for your feedback, I'll make sure to cover that for future posts.