3 ms·

I completely disagree with idea of moving fast at any cost. There's a saying in the marines (I think, maybe navy)... "slow is smooth, smooth is fast" It's abo

by proc0 2y ago

I completely disagree with idea of moving fast at any cost. There's a saying in the marines (I think, maybe navy)... "slow is smooth, smooth is fast" It's about first getting the basics right, so you go slow, which then allows you to perform smoothly, and when you perform smoothly you can then accelerate and move quickly. This applies to software development, in my experience. I think codebases have this quality of snowballing, and the snowball can either be good or bad. At first you add code quickly, which means that your snowball will be one of complexity later. If instead you slow down at the beginning and deal with complexity early, the snowball becomes productivity later. This is hard to explain on non-technical terms though, and it's a hard sell for business and marketing oriented people, mostly because they can't immediately connect the dots to profit (understandably, but also it's just so obvious companies hit the same problems over and over again). The business value is indeed there, after you snowball into compounded productivity because you architected an application that scales smoothly.

bad_username 2y ago
> This is hard to explain on non-technical terms though, and it's a hard sell for business and marketing oriented people, mostly because they can't immediately connect the dots I think managers are usually capable pf connecting the dots. I guess the problem is that for managerial roles it is very hard to distinguish between engineers who are slow because they are careful and methodical (thus enabling future growth) and engineers who are slow because they are bad or lazy or prone to bikeshedding (thus enabling nothing). Since the cost of error here is very high, they tend to err on the side of caution,and discourage slowness altogether.
- proc0 2y ago
  The reason that's a problem is because of how most companies structure their engineering roles. Individual contributors are the bottom part of the metaphorical pyramid. IC engineers are meant to be managed because by definition the progression of the career is to move towards doing less code and managing projects and people... that means that you will not have high level contributors that you can trust because they're all doing more management work. In other words companies don't see the value of highly experienced code contributors, because writing code is seen as the relatively easy part of the job, and the engineers who manage people are "force multipliers", etc. But in my opinion this is just a structure that enables the 'move fast' mentality, and the 'scale by adding people' mentality, both of which can be fine but the consequence is code that breaks, is unreliable, and hard to maintain.
CobaltFire 2y ago
That’s not what the saying means. It means when you go slowly enough, you maintain control and get the outcome you want. This allows for the highest probability of getting it right the first time, and not wasting time on fixing screwups. It has nothing to do with going fast later. It has to do with going as fast as you can while maintaining control (generally of your weapon).
- proc0 2y ago
  I think that still makes sense in the context I'm using. Do things carefully when building software in the beginning so that you have less issues as it scales and then you are iterating very quickly because of the lack of issues.

by proc0 2y ago

bad_username 2y ago

> This is hard to explain on non-technical terms though, and it's a hard sell for business and marketing oriented people, mostly because they can't immediately connect the dots I think managers are usually capable pf connecting the dots. I guess the problem is that for managerial roles it is very hard to distinguish between engineers who are slow because they are careful and methodical (thus enabling future growth) and engineers who are slow because they are bad or lazy or prone to bikeshedding (thus enabling nothing). Since the cost of error here is very high, they tend to err on the side of caution,and discourage slowness altogether.

proc0 2y ago
The reason that's a problem is because of how most companies structure their engineering roles. Individual contributors are the bottom part of the metaphorical pyramid. IC engineers are meant to be managed because by definition the progression of the career is to move towards doing less code and managing projects and people... that means that you will not have high level contributors that you can trust because they're all doing more management work. In other words companies don't see the value of highly experienced code contributors, because writing code is seen as the relatively easy part of the job, and the engineers who manage people are "force multipliers", etc. But in my opinion this is just a structure that enables the 'move fast' mentality, and the 'scale by adding people' mentality, both of which can be fine but the consequence is code that breaks, is unreliable, and hard to maintain.

CobaltFire 2y ago

That’s not what the saying means. It means when you go slowly enough, you maintain control and get the outcome you want. This allows for the highest probability of getting it right the first time, and not wasting time on fixing screwups. It has nothing to do with going fast later. It has to do with going as fast as you can while maintaining control (generally of your weapon).

proc0 2y ago
I think that still makes sense in the context I'm using. Do things carefully when building software in the beginning so that you have less issues as it scales and then you are iterating very quickly because of the lack of issues.