I've deployed 35,000+ lines of code to prod in 2023 with this flow. I've only had 2 small bugs.
This is by far the most efficient setup I've ever used.
I've deployed 35,000+ lines of code to prod in 2023 with this flow. I've only had 2 small bugs.
This is by far the most efficient setup I've ever used.
(I guess I'm being facetious because I think everyone should read his book of essays. The hardware platforms have changed dramatically since the 1960s, but the wetware hasn't changed a bit)
In theory if your process is perfectly optimized and everyone is doing the correct things all the tike and the goals are well defined then this is true. The biggest bottleneck I see in most projects are that there little to no definition in what needs to be done. It's not a handholding task, it's a lack of clear or continuously fluctuating goals. That ultimately ends to people slowing down.
Business leadership wants to hand the goal of "make money" to the engineering team but IMHO that's an unrealistic expectation and shows poor, incompetent, and or lazy leadership. Someone needs to find the demand signal and be decent at predicting future demand to direct the team towards what needs to be created. At some point, if you think you can hand off lofty lazy goals to an engineering team like this then your role becomes questionable because you have a hybrid engineering/entrepreneurial team who could basically work without your involvement.
Nits aside use the same style and have set a time budget of 50ms for myself. I have even setup nvim to save on every keystroke (one also learns how to not write infinite loops when programming in this style).
This style of programming is transformative because it's like having a persistent repl. It becomes feasible to test every edge case with print debugging as you go. This workflow is also why I have little interest in any language that primarily targets llvm, which will easily blow my time budget in code gen.
/s