alt Hacker NewsThe timing of this article and the submission seems to coincide (and possibly a reaction) to the other story on HN frontpage: Working quickly is more important than it seems (2015) (jsomers.net)
To clarify, some are misunderstanding James Somers to be advocating sloppy low quality work, as if he's recommending speed>quality. He's saying something else: remove latencies and delays to shorten feedback loops. Faster feedback cycles leads to more repetitions which leads to higher quality.
"slowness being a virtue" is not the opposite of Somer's recommendation about "working quickly".
Replies
Totally agree, how I see it, it's related to taking time to sharpen your axe.
Having a defined flow that gives you quick feedback quick and doesn't get in the way.
I you are writing, then you'd be using an app that you can quickly do what you want, e.g shortcuts for bold, vim/emacs motions, that "things-not-getting-in-the-way" state is what leads to flow state, in my opinion.
Muscle memory is action for free, then you can focus on thinking deeper.
Same happens with coding, although is more complex and can take time to land in a workflow with tools that allow you to move quick, I'm talking about, logs, debugger (if needed), hot reloading of the website, unit test that run fast, knowing who to ask or where to go for finding references, good documentation, good database client, having prepared shortcuts to everything ... and so on.
I think it would be could if people would share their flow-tools with different tech stacks, could benefit a lot of us that have some % of this done, but not 100% there yet.
There is a very important concept in security engineering around feedback loops. Consider the following: A vulnerability is discovered 5 years after it was introduced. The issue is patched and life goes on for the engineering organization that discovered it. Some time passes and they discover an architectural flaw and that the issue was not isolated. They must now expend precious effort fixing this entire flaw and the 5 years of dependencies that accreted on it. Now, consider, the team that designed this system and the engineer that implemented it discover the vulnerability leading to the architectural issue within two weeks. They refactor the code and eliminated generational security debt. Not to mention the engineers that wrote the code are not around 5 years later further increasing the "interest" on the debt.
I would note you might see this as another bland "shift left" argument and you could definitely view if through this lens. But if you consider it from a systems thinking lens it actually incorporates dynamics that are not typically included in shift left. It helps you consider the system within your organization and how to shorten those feedback loops. It also, conveniently, makes engineering organizations stronger as a whole as these feedback loops are also intrinsically linked to the organizations software development process as a whole. It is pretty hard to have a tight security vulnerability discovery loop without a good software engineering practice around it. For security issues like this they are effectively a strict subset of software quality issues.
You can apply this feedback loop shortening to /so/ many things in life.
The actual link:
To add, add some "slowness" before starting work - fix the latencies and delays, and plan what you're going to make instead of figuring it out as you go.
Shortening feedback loops was what Kent Beck and TDD advocates were emphasizing. Now TDD has been ruined by "experts", people are realizing the importance of fast feedback loops from a different perspective.
I've started to come around to this point of view, where I break down something i want to learn into more modular loops that I can get the most iterations of the basic result I want to get and save the rehearsing the whole thing for the end when I feel confident with each part. Otherwise, you basically have to unfluently rehearse and rehash content you're likely good for at the peril of never getting around to as or more important stuff further along
Festina lente.
Correct, it is the speed of iteration that is important. [0]
If AI can do the OODA loop faster without getting fatigued, even though it is worse quality, like the F-86, it will win 10 out of 10 times.
EDIT:
> Boyd knew both planes very well. He knew the MiG-15 was a better aircraft than the F-86. The MiG-15 could climb faster than the F-86. The MiG-15 could turn faster than the F-86. The MiG-15 had better distance visibility.
> The F-86 had two points in its favor. First, it had better side visibility. While the MiG-15 pilot could see further in front, the F-86 pilot could see slightly more on the sides. Second, the F-86 had a hydraulic flight control. The MiG-15 had a manual flight control.
> Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster.
> Without hydraulics, it took slightly more physical energy to move the MiG-15 flight stick than it did the F-85 flight stick. Even though the MiG-15 would turn faster (or climb higher) once the stick was moved, the amount of energy it took to move the stick was greater for the MiG-15 pilot.
> With each iteration, the MiG-15 pilot grew a little more fatigued than the F-86 pilot. And as he gets more fatigued, it took just a little bit longer to complete his OOPA loop. The MiG-15 pilot didn’t lose because he got outfought. He lost because he got out-OOPAed.
[0] https://blog.codinghorror.com/boyds-law-of-iteration/