To slow down is to end up default dead; the rhythm and pace of how technology is supposed to be built does not allow for consideration of social consequences. (Jasmine Wang)
Moving fast but not breaking things
A activity → core business activity (actual value producing activities) B activity → reduce product-cycle time, make faster, smarter, higher-quality A activities (increase velocity) C activity → reduce improvement-cycle time, make faster, smarter, higher-quality B activities (increase acceleration)
This is exactly what I mean when I talk about “bootstrapping.” It is a very American term – the image is of someone able to perform the wonderful, impossible trick of pulling himself up by pulling up on his own bootstraps – but the idea is one that we put into practice every time that we “boot up” a computer. A small bit of code in a permanent read only memory knows how to go out to the disk to get more instructions, that in turn know how do to even more things, such as getting even more instructions. Eventually, this process of using successive steps to lead to ever bigger steps, building on each other, get the whole machine up and running. You start small, and keep leveraging what you know at each stage to solve a bigger and bigger problem.
Velocity vs Acceleration
Velocity vs Acceleration based execution. Insightful read on how orgs can be moving fast but not be innovating. How do we have a high acceleration org rather than just a high velocity one?
The Coming Software Apocalypse
Source: The Coming Software Apocalypse by James Somers
- occasionally shift the pile of sand so it settles in a more stable configuration
- take time to understand the actual tech youre working on and the problems you’re trying to solve
- talk it out with people
“The problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. → software and politics