4 ms·

> , performance should be a consideration from the start Don't obsess over this. Obsess over documenting your design decisions - why you decided one algorithm

> , performance should be a consideration from the start Don't obsess over this. Obsess over documenting your design decisions - why you decided one algorithm or pattern over another and why. Then _if_ after load testing you need to optimise you'll understand some of the tradeoffs you'll have to make (all decisions are tradeoffs).

izacus 1y ago
No, please do obsses over this while designing. The amount of times I have to say "you can't fix these performance issues without rewriting majority of your software" is too damn high. I mean, I make a lot of money as performance specialist, but it's still a dumb waste when you see failing products and companies because their rockstar developers refused to spend 30 minutes thinking about how well their architecture and code performs. You can't fix everything later.
- 4ndrewl 1y ago
  But most organisational failures are not down to performance - they're down to market fit. You don't have performance issues if you don't have a product that people want. :)
  - izacus 1y ago
    I disagree (and have - sadly nonpublic - numbers to prove it). Also, it costs you VERY little to spend some brainpower to design your product to perform well. I honestly really don't understand why so many developers behave like it's physically painful to think for a bit before starting to bash out code. Noone expects you to write microoptimizations, but applying basic knowledge learned in CS classes and knowledge you can read in blogs should not be physically painful. And you can do that outright at the start, at __NO__ cost to your development velocity.
    - 4ndrewl 1y ago
      Agree there's a basic level, and as you say just spend a little time on it but that's table stakes. My reading of "obsess over it" _is_ micro-optimisations which are a distraction if you've got no market fit
ozgrakkurt 1y ago
Obsessing about it when doing design/architecture but not caring so much in terms of raw implementation seems like a good idea? Then if you detect inefficiency you can optimize the code and not the architecture. I am building something with this mindset now, hopefully it will work
- 4ndrewl 1y ago
  I think you're reading something I didn't write. Nothing to do with architecture - rather ensuring you understand what decisions you're making, what other options you might have and why you're choosing not to do something (eg opportunity costs wrt delivery v time optimising)

izacus 1y ago

No, please do obsses over this while designing. The amount of times I have to say "you can't fix these performance issues without rewriting majority of your software" is too damn high. I mean, I make a lot of money as performance specialist, but it's still a dumb waste when you see failing products and companies because their rockstar developers refused to spend 30 minutes thinking about how well their architecture and code performs. You can't fix everything later.

4ndrewl 1y ago
But most organisational failures are not down to performance - they're down to market fit. You don't have performance issues if you don't have a product that people want. :)
- izacus 1y ago
  I disagree (and have - sadly nonpublic - numbers to prove it). Also, it costs you VERY little to spend some brainpower to design your product to perform well. I honestly really don't understand why so many developers behave like it's physically painful to think for a bit before starting to bash out code. Noone expects you to write microoptimizations, but applying basic knowledge learned in CS classes and knowledge you can read in blogs should not be physically painful. And you can do that outright at the start, at __NO__ cost to your development velocity.
  - 4ndrewl 1y ago
    Agree there's a basic level, and as you say just spend a little time on it but that's table stakes. My reading of "obsess over it" _is_ micro-optimisations which are a distraction if you've got no market fit

ozgrakkurt 1y ago

Obsessing about it when doing design/architecture but not caring so much in terms of raw implementation seems like a good idea? Then if you detect inefficiency you can optimize the code and not the architecture. I am building something with this mindset now, hopefully it will work

4ndrewl 1y ago
I think you're reading something I didn't write. Nothing to do with architecture - rather ensuring you understand what decisions you're making, what other options you might have and why you're choosing not to do something (eg opportunity costs wrt delivery v time optimising)