4 ms·

I think this quote summarizes hackers today: ``[T]ime spent sweating memory is time you're not writing your app. The hard part is developing the experience is t

I think this quote summarizes hackers today: ``[T]ime spent sweating memory is time you're not writing your app. The hard part is developing the experience is that you need to know when you need to care." Not having to worry about memory is now a luxury we can afford in the age of plenty. While writing an efficient spellchecker would have been a great feat in the 80s, there's no point of that when you can load the whole dictionary file in memory. In other words, memory management is a #highclassproblem for many developers--you worry about efficiency once you have a lot of adoption. (Within reason; if your app is unbearably slow that isn't good.)

PavlovsCat 11y ago
We also live in the age of plenty in regards to how many things we have running at the same time, or how many tabs there are open in a browser. Things can add up pretty quickly. And why settle for "without optimizing it's slightly faster than things used to be when people had to optimize", when you can have "optimized, it's orders of magnitude faster than things used to be"? > you worry about efficiency once you have a lot of adoption. Sometimes things can be tricky to refactor if you didn't move carefully at every step. Initially not worrying about efficiency at all might mean having to rewrite from scratch once you do. Of course, this can't be generalized. Sometimes it really, really doesn't matter, unless you care about craftsmanship as a value in and of itself -- taking 10-20% more time to write code that makes you happy and proud might very well make you more effective in the long run.
- fixermark 11y ago
  If you can sell it as faster than the alternatives, it makes sense to optimize. But in the web-focused marketplace, adding 6 months to your launch calendar to get something fast to market may mean someone else's good-enough solution becomes the entrenched, de-facto standard that you are now fighting to prove you're superior enough to that it justifies people's time cost to move their data to your solution. That's the risk tradeoff.
  - PavlovsCat 11y ago
    It really depends, avoiding some pitfalls isn't always that much more work, but merely requires knowing (and caring) about them in the first place.
    - kylequest 11y ago
      It's easy to point out the places where you could've done a bit more optimization after the fact. And, yes, sometimes those optimizations don't cost an arm and a leg, but it's very easy to fall into the premature optimization mode that kills the product and the company. Not everybody has tons of funding in the bank. For some startups shipping a day later can put you in the death spiral trajectory. Timing is a huge factor in a startup success. It's easy to think why not just do it right in the first place. Aside from the timing you, as a startup, don't really know what "it" is or "it" is constantly moving. Committing to perfection at that stage can be a sure way to kill the company. Even if "it" is known and it's not changing you still need to keep in mind the Gall's Law.
- jasonjei 11y ago
  That's the problem AirBnb has right now, according to a friend. Using Ruby has scaled AirBnb's business to great heights. However, it has heaped to performance and code separation of concerns and structure debt. Of course, AirBnb can now afford to move things to Java/Scala and things that are better for multinational companies. For AirBnb, it's really hard to fix a lot of these things since the product requires good uptime.

PavlovsCat 11y ago

We also live in the age of plenty in regards to how many things we have running at the same time, or how many tabs there are open in a browser. Things can add up pretty quickly. And why settle for "without optimizing it's slightly faster than things used to be when people had to optimize", when you can have "optimized, it's orders of magnitude faster than things used to be"? > you worry about efficiency once you have a lot of adoption. Sometimes things can be tricky to refactor if you didn't move carefully at every step. Initially not worrying about efficiency at all might mean having to rewrite from scratch once you do. Of course, this can't be generalized. Sometimes it really, really doesn't matter, unless you care about craftsmanship as a value in and of itself -- taking 10-20% more time to write code that makes you happy and proud might very well make you more effective in the long run.

fixermark 11y ago
If you can sell it as faster than the alternatives, it makes sense to optimize. But in the web-focused marketplace, adding 6 months to your launch calendar to get something fast to market may mean someone else's good-enough solution becomes the entrenched, de-facto standard that you are now fighting to prove you're superior enough to that it justifies people's time cost to move their data to your solution. That's the risk tradeoff.
- PavlovsCat 11y ago
  It really depends, avoiding some pitfalls isn't always that much more work, but merely requires knowing (and caring) about them in the first place.
  - kylequest 11y ago
    It's easy to point out the places where you could've done a bit more optimization after the fact. And, yes, sometimes those optimizations don't cost an arm and a leg, but it's very easy to fall into the premature optimization mode that kills the product and the company. Not everybody has tons of funding in the bank. For some startups shipping a day later can put you in the death spiral trajectory. Timing is a huge factor in a startup success. It's easy to think why not just do it right in the first place. Aside from the timing you, as a startup, don't really know what "it" is or "it" is constantly moving. Committing to perfection at that stage can be a sure way to kill the company. Even if "it" is known and it's not changing you still need to keep in mind the Gall's Law.
jasonjei 11y ago
That's the problem AirBnb has right now, according to a friend. Using Ruby has scaled AirBnb's business to great heights. However, it has heaped to performance and code separation of concerns and structure debt. Of course, AirBnb can now afford to move things to Java/Scala and things that are better for multinational companies. For AirBnb, it's really hard to fix a lot of these things since the product requires good uptime.