Deconcentration of Attention: Addressing the Complexity of Software (2016)
deconcentration-of-attention.com
deconcentration-of-attention.com
First I make a component work. Then make it with work together with the other components. Then refactor them all to look uniform. Then create the generators to make future components look uniform. Then employ them in real life scenarios. Another refactoring is coming after 2-3 projects.
Then a first stable version is coming. At the seventh rewrite.
I had to admit I’ve managed only a few times to reach a level above seven. That’s a fantastic feeeling. You know you have a rock solid foundation and anything you build upon it just lasts.
But how do you negotiate deadlines and keep the upper chain of decision making happy and aware of the value being created with each refactor? Most of the time with the teams I worked with, "works" is the sole metric of success and features keep being sold or promised leaving no room to deal with documented technical debt (and the lack of such documentation).
Free it's like a sabbatical. Whenever I need to learn a new technology I take a sabbatical, build a framework, then go back to produce income with that framework.
For example in September last year I took a sabbatical for learning Design Systems. My first paying customer came this August. This streak took a year, and I'm at the third iteration only.
When on sabbatical, I'm changing locations / cities / countries to be able to support myself during that period. When in production mode, I'm again moving to larger / more expensive places.
Also I'm in a privileged situation / I create a privileged situation for myself to be able to follow this process. Please see my other reply to this thread for details.
https://randsinrepose.com/archives/anti-flow/
as well as
His other piece is fascinating. What else am I missing?