I don’t mind the premise of “think things through before coding”, but I’m a pragmatist and I learn most from doing, and this current mentality is starting to feel stifling.
Whatever happened to “less talk, more action”?
Making prototypes and experimenting is one thing but something I consistently see with the "move fast and break things" philosophy is that production is your prototype. Sure things may go through testing first but at the end of the day features get pushed out to prod once they have an MVP and are iterated on and beta tested more or less live.
I'd love to see SWEs be more willing to sit down, make a prototype, and toss the entire thing away taking the lessons learned to build the real thing rather than trying to build the actual product off the bat or trying to send the prototype straight to production.
All this extra review and rigour is a good thing for anything going to production. The real problem is that we don't build our prototypes outside of production any more. Build your prototype on your own fast and loose but anything that actually gets near the master branch should be inspected and picked apart to the highest of standards.
Because people will die. Software engineers who, say, work in the airline industry don't do this either (they also probably use ada or something like it).
I'd also be willing to bet a significant amount of money that an engineer that works on something like soft drink bottles moves a lot faster than one who designs bridges.
Which is the proposal I tend to write the most when businesses send a requirement my way: "X is important. Ensure X." - whatever X is, you can usually then pretty quickly outline how to do X perfectly, and how much X will cost, and suddenly there's an acceptable degree of X (which is usually outlandishly far below the implied standard of the original request) because as it turns out, they simply didn't think X had any real cost associated with it.
I don't want to pay developers to find a tester, watch them use the new feature using full story/posthog, etc etc. That 1) delays the feature because it still needs to get formal QA treatment and customer feedback. And 2) halves the volume of work an engineer can actually deliver.
For that reason, I think it's important for individuals to own things from idea to implementation to maintenance. You know how best to test your software. You know why you're getting paged for it breaking. You should handle that.
I think the loss of quality when splitting up projects among multiple teams (or even individuals) is why startups produce so much more than huge corporations. (My personal view is that output scales logarithmically with the number of people involved -- to do a project that's 4x more complicated than what one person could do alone, you'll need 2^4 = 16 people. Part of that is all the communication required to hand ideas over from product to engineering, hand software from engineering over to QA, hand maintenance over to SREs, etc. You can skip all that and do more with less.)
During that time we all worked as one. Focus on one workflow, get it down, move to the next one. We finished on time, and the knowledge sharing that occurred during those 2 months were more than years of knowledge sharing than I had previously.
Once we completed the project, we went back to the old style. Productivity dropped like a rock. But during CO-VID we have had glimpses of that crunch style that come when everyone is on a call. Completing a story is so much better when the team completes that story.
A quick local build and cursory click through can be okay but should they be doing the above for every contribution?
More action has led to painfully bad engineering decisions in some working startups i've joined that leads to attrition & perhaps years of refactoring. Sure, the argument could be made, "well that's the learning!" you moved fast and realized it wouldn't scale. And in some cases, you're right and in other cases you wished you hired someone better for the job.
Perhaps, then, to minimize the pain of the future, the less talk more action mentality only works with better engineers who make better decisions. I don't have any data to back up this claim but it sure feels like better engineers who are successful are better at making fewer mistakes when wanting to move fast.