6 ms·

Well yea and no, ideally you are not “throwing” that RAM away, you are paying for a more flexible software that can be more easily changed in the future, or to

by seer 6y ago

Well yea and no, ideally you are not “throwing” that RAM away, you are paying for a more flexible software that can be more easily changed in the future, or to be able to pay much less for your developers, often both. Nobody wants slow software, its just cheaper, in upfront and maintenance costs. Going with analogies, its like a race car mechanic complaining that a car is using like 3 cylinders where it could have 8. Sure but some people have other priorities I guess.

pdimitar 6y ago
> you are paying for a more flexible software that can be more easily changed in the future In theory yes, in practice this almost never happens. 95% of the teams just quickly mash the product together and peace out before anyone notices what mess did they make. And then you have some poor Indian / African / Eastern European team trying to untangle and improve it. Seen it literally tens of times over a course of 19 years career. > Nobody wants slow software, its just cheaper, in upfront and maintenance costs That is true. But nowadays it's more like taking a loan from the bank and running away to an uninhabited island to avoid paying it off.
- seer 6y ago
  Maybe it didn’t really come across I am totally in the performance camp and love to be able to craft a beautiful, lean and responsive UI if nothing else than for seeing the joy on users’ faces when they are delighted (amazed!) that what they wanted done happened so fast. But time and time again I see that projects with a fast “enough” interfaces and flexible systems win out on more specialized, faster ones. And I hate that but here we are. Sometime we see a really performant piece of software hit the sweet spot of functionality for a while (for example sublime text) but then get overtaken by a fast enough but more flexible alternative (vacode)
- anthk 6y ago
  >Eastern European Eastern European coders are highly competent, they did magic back in the day with just a ZX Spectrum.
  - pdimitar 6y ago
    As an Eastern European programmer, I agree. A lot of us are called to fix messes left by primadona devs (who are taking home $200K a year for the privilege of making other people's lives a living nightmare).
    - tharne 6y ago
      To be fair, most of those "primadona devs", as you call them, would much prefer to write well-designed programs cleanly coded, but are given completely unreasonable timeframes and staffing then told to create an MVP then turn it over to offshore. Very few people enjoy producing junk, but management (and customers) often demand junk today rather than quality tomorrow.
      - pdimitar 6y ago
        Obviously neither me nor you can generalize -- both extremes exist. Given the chance I'd likely collect a fat paycheck and bail out at the end of the contract as those other people did. But that attitude is responsible for the increasingly awful mess that modern software is becoming. Almost everyone is at fault, me included. The perverted incentives of today's world are only making things worse.
      - ridethebike 6y ago
        Primadona dev here :) >> most of those "primadona devs", as you call them, would much prefer to write well-designed programs cleanly coded Most of them - yes. But there's a non-negligible chunk of them who are too careless or incompetent to care about quality - they've been around long enough to gain knowledge about project and get Vice-President title(inflated ego included). It is especially visible in big banks (I suppose it's typical for other big non-tech corps as well) where tech culture is generally on poor side. edit: grammar
    - seer 6y ago
      Hah true dat. Been my life for the last couple of years :-D Managed to pull through a project that “failed” two times and was 2.5 years behind schedule...
- mynameisash 6y ago
  > In theory yes, in practice this almost never happens. 95% of the teams just quickly mash the product together and peace out before anyone notices what mess did they make. Much of my work is in highly parallelized computing (think Spark across thousands of nodes) processing 10s or 100s of TiB at a time with declarative syntax. It's super cool. Until someone decides they're going to use this one line expression to process data because it's just so easy to write. But it turns out doing that absolutely destroys your performance because the query optimizer now has a black box in the middle of your job graph that it can't reason about. Bad practices like that occur over and over again, and everyone just figures, "Well, we have a lot of hardware. If the job takes an extra half hour, NBD." Soon, you have scores of jobs that take eight hours to run and everyone starts to become a little uneasy because the infrastructure is starting to fail jobs on account of bad data skew and vertexes exceeding the predefined limits. How did we get here? We severely over-optimized for engineer time to the detriment of CPU time. Certainly, there is a balance to strike, no doubt. But When writing one line of code versus six (and I'm not being hyperbolic here) becomes preferable to really understanding what your system is doing, you reap what you sow. On the plus side, I get to come in and make things run 5x, 10x, maybe even 20x faster with very little work. It sometimes feels magical, but it would be preferable if we had some appreciation for not letting our code slowly descend into gross inefficiency.
  - pdimitar 6y ago
    Death by a thousand paper cuts. Classic.

by seer 6y ago

pdimitar 6y ago

> you are paying for a more flexible software that can be more easily changed in the future In theory yes, in practice this almost never happens. 95% of the teams just quickly mash the product together and peace out before anyone notices what mess did they make. And then you have some poor Indian / African / Eastern European team trying to untangle and improve it. Seen it literally tens of times over a course of 19 years career. > Nobody wants slow software, its just cheaper, in upfront and maintenance costs That is true. But nowadays it's more like taking a loan from the bank and running away to an uninhabited island to avoid paying it off.

seer 6y ago
Maybe it didn’t really come across I am totally in the performance camp and love to be able to craft a beautiful, lean and responsive UI if nothing else than for seeing the joy on users’ faces when they are delighted (amazed!) that what they wanted done happened so fast. But time and time again I see that projects with a fast “enough” interfaces and flexible systems win out on more specialized, faster ones. And I hate that but here we are. Sometime we see a really performant piece of software hit the sweet spot of functionality for a while (for example sublime text) but then get overtaken by a fast enough but more flexible alternative (vacode)
anthk 6y ago
>Eastern European Eastern European coders are highly competent, they did magic back in the day with just a ZX Spectrum.
- pdimitar 6y ago
  As an Eastern European programmer, I agree. A lot of us are called to fix messes left by primadona devs (who are taking home $200K a year for the privilege of making other people's lives a living nightmare).
  - tharne 6y ago
    To be fair, most of those "primadona devs", as you call them, would much prefer to write well-designed programs cleanly coded, but are given completely unreasonable timeframes and staffing then told to create an MVP then turn it over to offshore. Very few people enjoy producing junk, but management (and customers) often demand junk today rather than quality tomorrow.
    - pdimitar 6y ago
      Obviously neither me nor you can generalize -- both extremes exist. Given the chance I'd likely collect a fat paycheck and bail out at the end of the contract as those other people did. But that attitude is responsible for the increasingly awful mess that modern software is becoming. Almost everyone is at fault, me included. The perverted incentives of today's world are only making things worse.
    - ridethebike 6y ago
      Primadona dev here :) >> most of those "primadona devs", as you call them, would much prefer to write well-designed programs cleanly coded Most of them - yes. But there's a non-negligible chunk of them who are too careless or incompetent to care about quality - they've been around long enough to gain knowledge about project and get Vice-President title(inflated ego included). It is especially visible in big banks (I suppose it's typical for other big non-tech corps as well) where tech culture is generally on poor side. edit: grammar
  - seer 6y ago
    Hah true dat. Been my life for the last couple of years :-D Managed to pull through a project that “failed” two times and was 2.5 years behind schedule...
mynameisash 6y ago
> In theory yes, in practice this almost never happens. 95% of the teams just quickly mash the product together and peace out before anyone notices what mess did they make. Much of my work is in highly parallelized computing (think Spark across thousands of nodes) processing 10s or 100s of TiB at a time with declarative syntax. It's super cool. Until someone decides they're going to use this one line expression to process data because it's just so easy to write. But it turns out doing that absolutely destroys your performance because the query optimizer now has a black box in the middle of your job graph that it can't reason about. Bad practices like that occur over and over again, and everyone just figures, "Well, we have a lot of hardware. If the job takes an extra half hour, NBD." Soon, you have scores of jobs that take eight hours to run and everyone starts to become a little uneasy because the infrastructure is starting to fail jobs on account of bad data skew and vertexes exceeding the predefined limits. How did we get here? We severely over-optimized for engineer time to the detriment of CPU time. Certainly, there is a balance to strike, no doubt. But When writing one line of code versus six (and I'm not being hyperbolic here) becomes preferable to really understanding what your system is doing, you reap what you sow. On the plus side, I get to come in and make things run 5x, 10x, maybe even 20x faster with very little work. It sometimes feels magical, but it would be preferable if we had some appreciation for not letting our code slowly descend into gross inefficiency.
- pdimitar 6y ago
  Death by a thousand paper cuts. Classic.