3 ms·

> I for one am sick of 'developer productivity' being the excuse for why my goddamned supercomputer crawls when performing tasks that were trivial even on hardw

> I for one am sick of 'developer productivity' being the excuse for why my goddamned supercomputer crawls when performing tasks that were trivial even on hardware 15 years older. The problem here is developer salaries. So long as developers are as expensive as they are the incentive will be to optimise for developer productivity over runtime efficiency.

Kilenaitor 5y ago
We've been making developer experience optimizations _long_ before they started demanding high salaries. The whole reason to go from assembly to C was to improve developer experience and efficiency. It seems fairly reductive to dismiss the legitimate advantages of increased productivity. It's faster to iterate on ideas and products, we gain back time to focus on more complex concepts, and, more broadly, we further open up this field to more and more people. And those folks can then go on to invest in these kind of performance improvements.
- AnIdiotOnTheNet 5y ago
  > It seems fairly reductive to dismiss the legitimate advantages of increased productivity. Certainly there are some, but I think we passed the point of diminishing returns long long ago and we're now well into the territory of regression. I would argue that we are actually experiencing negative productivity increases from a lot of the abstractions we employ, because we've built up giant abstraction stacks where each new abstraction has new leaks to deal with and everything is much more complicated than it needs to be because of it.
  - nicoburns 5y ago
    Hmm... I think our standards for application functionality are also a lot higher. For example, how many applications from the 90s dealt flawlessly with unicode text.
    - AnIdiotOnTheNet 5y ago
      How much added slowness do you think Unicode is responsible for? Because as much of a complex nightmarish standard as it is[0], there are plenty of applications that are fast that handle it just fine as far as I can tell. They're built with native widgets and written in (probably) C. [0] plenty of slow as fuck modern software doesn't handle it even close to 'flawlessly'
dogleash 5y ago
If developers costed one fifth of what they do now, how many projects that let performance languish today would staff up to the extent that doing a perf pass would make it's way to the top of the backlog queue? Come on now. Let's be honest here. The answer for >90% of projects is either a faster pace on new features, or to pocket the payroll savings. They'd never prioritize something that they've already determined can be ignored.
- nicoburns 5y ago
  Hmm, I don’t know about that. When I made a quarter of what I do now, I worked at companies that would happily let me spend two weeks on a task without expecting much in that time.

Kilenaitor 5y ago

We've been making developer experience optimizations _long_ before they started demanding high salaries. The whole reason to go from assembly to C was to improve developer experience and efficiency. It seems fairly reductive to dismiss the legitimate advantages of increased productivity. It's faster to iterate on ideas and products, we gain back time to focus on more complex concepts, and, more broadly, we further open up this field to more and more people. And those folks can then go on to invest in these kind of performance improvements.

AnIdiotOnTheNet 5y ago
> It seems fairly reductive to dismiss the legitimate advantages of increased productivity. Certainly there are some, but I think we passed the point of diminishing returns long long ago and we're now well into the territory of regression. I would argue that we are actually experiencing negative productivity increases from a lot of the abstractions we employ, because we've built up giant abstraction stacks where each new abstraction has new leaks to deal with and everything is much more complicated than it needs to be because of it.
- nicoburns 5y ago
  Hmm... I think our standards for application functionality are also a lot higher. For example, how many applications from the 90s dealt flawlessly with unicode text.
  - AnIdiotOnTheNet 5y ago
    How much added slowness do you think Unicode is responsible for? Because as much of a complex nightmarish standard as it is[0], there are plenty of applications that are fast that handle it just fine as far as I can tell. They're built with native widgets and written in (probably) C. [0] plenty of slow as fuck modern software doesn't handle it even close to 'flawlessly'

dogleash 5y ago

If developers costed one fifth of what they do now, how many projects that let performance languish today would staff up to the extent that doing a perf pass would make it's way to the top of the backlog queue? Come on now. Let's be honest here. The answer for >90% of projects is either a faster pace on new features, or to pocket the payroll savings. They'd never prioritize something that they've already determined can be ignored.

nicoburns 5y ago
Hmm, I don’t know about that. When I made a quarter of what I do now, I worked at companies that would happily let me spend two weeks on a task without expecting much in that time.