3 ms·

The older and more experienced I get, the more I lean towards not implementing anything more than the bare minimum. I think juniors are more prone to building

The older and more experienced I get, the more I lean towards not implementing anything more than the bare minimum. I think juniors are more prone to building supposed "technical assets" in the hope it might get used. This could be microservices or a nosql db, or kubernetes operators, etc. Part of this is just a desire to try things and do some resume driven development (which I guess is fair). These things do inevitably end up being tech debt a good portion of the time, though the other portion are good innovations which unlock opportunities. With experience comes an appreciation of what is really needed and a knowing of what is needless, and also the ability to create a solution closer to when it is needed (both because one is quicker at coding it, and because with a delay comes better data and thinking on the solution). I think building a good theory and consensus among the team ahead of time might be a better use of time.

Xmd5a 2y ago
There is indeed this important aspect, but with this mindset we would never have implemented compilers, databases with their own query language, etc... I never lost a bet I made in """overengineering""" a solution to a problem and was always proven right in a matter of months. This is especially easy when the proposed solution brings structural improvements to the time it takes to implement a certain class of features. It's just a matter of comparing the time it takes to implement that "sophisticated" solution vs the speedup to implement such a feature using said solution times how many potential features there are in this class times the probability the company will need it at some point. And yes, in my case this implied writing "mini-compilers" or "mini-debuggers".
- liampulles 2y ago
  I think you are a better developer than I. ;)
mmcnl 2y ago
I agree 100%. If you want to deliver valuable software you need short iterations because you need to validate assumptions. Anything you build more than the bare minimum is not included this feedback loop so your assumptions are not getting validated and you don't know if you're building the right stuff. This is not easy though. You don't want to paint yourself into a corner because of earlier design decisions that turned out to be unexpectedly very costly. So you need to have some set of assumptions that you will not get a chance to validate soon. I guess experience helps here.

Xmd5a 2y ago

There is indeed this important aspect, but with this mindset we would never have implemented compilers, databases with their own query language, etc... I never lost a bet I made in """overengineering""" a solution to a problem and was always proven right in a matter of months. This is especially easy when the proposed solution brings structural improvements to the time it takes to implement a certain class of features. It's just a matter of comparing the time it takes to implement that "sophisticated" solution vs the speedup to implement such a feature using said solution times how many potential features there are in this class times the probability the company will need it at some point. And yes, in my case this implied writing "mini-compilers" or "mini-debuggers".

liampulles 2y ago
I think you are a better developer than I. ;)

mmcnl 2y ago

I agree 100%. If you want to deliver valuable software you need short iterations because you need to validate assumptions. Anything you build more than the bare minimum is not included this feedback loop so your assumptions are not getting validated and you don't know if you're building the right stuff. This is not easy though. You don't want to paint yourself into a corner because of earlier design decisions that turned out to be unexpectedly very costly. So you need to have some set of assumptions that you will not get a chance to validate soon. I guess experience helps here.