5 ms·

Similar experience as a PM and as a technical director: the vast majority of devs, outside maybe 3d rendering or HPC, do not understand nor care about performan

by Aeolos 6y ago

Similar experience as a PM and as a technical director: the vast majority of devs, outside maybe 3d rendering or HPC, do not understand nor care about performance optimization. Implementing some feature, fixing a bug, refactoring code to improve DX? Sure, happy to do, you don’t even have to ask. Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? No chance, unless the PM forces the matter. My hope is that some of that can be taught and embedded into the team culture, but the reality is that day-to-day web development is simply too far abstracted from the underlying software and hardware, and getting your average javascript programmer to care about milliseconds is an uphill battle. The sad thing is that users do definitely care, and the evidence shows up again and again: user behaviour tests for 100ms vs 500ms responses, the reviews of the new M1 processors, ...

TeMPOraL 6y ago
> Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? Is anybody even teaching people these things? I do the above as a matter of course, but I've learned how and why through osmosis, over the years, mostly because I dabble with gamedev as a hobby (and because I care about performance). None of that was covered in any of my university courses. And, out of the people I worked with, I was and am literally the only one who knows how to do any of that.
- Aeolos 6y ago
  You hit a vein of truth here, I don't recall any of that being covered in a university course or in any of the companies I've worked with. My knowledge too comes from dabbling with gamedev, programming/hacking underpowered hardware (90's consoles), and spending (too much) time on open-source projects where performance optimization mattered. I don't expect my colleagues to have the same kind of experience, but I would expect someone presenting as a "senior frontend engineer" to understand the GC impact of allocating thousands of objects in a tight computation loop; or of doing heavy computations / updating the DOM inside a mouse move event handler. On the other hand, Slack is worth $27.7B and is still selling a product that has frustrating multi-second delays on standard keyboard interactions, so I don't know. Maybe I am really just expecting too much.
yellowapple 6y ago
That raises an important question, though: is it really true that the developers don't care? Or is it more a matter of these performance improvements falling to the wayside because management pushes features and/or bugfixes first? I've definitely seen both in the wild, so it's an important question to ask every time, rather than sticking to a blanket assumption of "devs neither understand nor care about performance optimization".
- Aeolos 6y ago
  That can definitely be the case. In our case, we sometimes have MR's that specifically mention things like "I did X as a shortcut to get this running, we will have to optimize this before we can do Y", which are totally fine and laudable. However, we also have MR's where e.g. moving the mouse causes jank / slows updates down to <20 fps. Doing a paired review on those leads to the observations above: many developers simply don't know how to measure and optimize code, and even less how to estimate impact before writing that code. It would be easy to dismiss this as "bad developers", but I've seen it so many times over the last two decades that I think it runs deeper than that. And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field.
  - webmaven 6y ago
    > And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field. Has anyone ever done an analysis of what exactly VSCode does differently than a typical Electron app? Where it deviates from the garden path?
  - yellowapple 6y ago
    > slow bloated Electron apps - except VSCode which is fast Is it, though? I'll give VSCode credit for being better than your average Electron app, but it (and Azure Data Studio, which last I checked is based on VSCode) ain't exactly a speed demon, either. Then again, I'm typically running something like Emacs, which is a lot lighter-weight (at least before I blow up ~/.emacs.d), so I'm probably just spoiled :) It's certainly faster than Visual Studio, but it also has far fewer features.

by Aeolos 6y ago

TeMPOraL 6y ago

> Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? Is anybody even teaching people these things? I do the above as a matter of course, but I've learned how and why through osmosis, over the years, mostly because I dabble with gamedev as a hobby (and because I care about performance). None of that was covered in any of my university courses. And, out of the people I worked with, I was and am literally the only one who knows how to do any of that.

Aeolos 6y ago
You hit a vein of truth here, I don't recall any of that being covered in a university course or in any of the companies I've worked with. My knowledge too comes from dabbling with gamedev, programming/hacking underpowered hardware (90's consoles), and spending (too much) time on open-source projects where performance optimization mattered. I don't expect my colleagues to have the same kind of experience, but I would expect someone presenting as a "senior frontend engineer" to understand the GC impact of allocating thousands of objects in a tight computation loop; or of doing heavy computations / updating the DOM inside a mouse move event handler. On the other hand, Slack is worth $27.7B and is still selling a product that has frustrating multi-second delays on standard keyboard interactions, so I don't know. Maybe I am really just expecting too much.

yellowapple 6y ago

That raises an important question, though: is it really true that the developers don't care? Or is it more a matter of these performance improvements falling to the wayside because management pushes features and/or bugfixes first? I've definitely seen both in the wild, so it's an important question to ask every time, rather than sticking to a blanket assumption of "devs neither understand nor care about performance optimization".

Aeolos 6y ago
That can definitely be the case. In our case, we sometimes have MR's that specifically mention things like "I did X as a shortcut to get this running, we will have to optimize this before we can do Y", which are totally fine and laudable. However, we also have MR's where e.g. moving the mouse causes jank / slows updates down to <20 fps. Doing a paired review on those leads to the observations above: many developers simply don't know how to measure and optimize code, and even less how to estimate impact before writing that code. It would be easy to dismiss this as "bad developers", but I've seen it so many times over the last two decades that I think it runs deeper than that. And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field.
- webmaven 6y ago
  > And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field. Has anyone ever done an analysis of what exactly VSCode does differently than a typical Electron app? Where it deviates from the garden path?
- yellowapple 6y ago
  > slow bloated Electron apps - except VSCode which is fast Is it, though? I'll give VSCode credit for being better than your average Electron app, but it (and Azure Data Studio, which last I checked is based on VSCode) ain't exactly a speed demon, either. Then again, I'm typically running something like Emacs, which is a lot lighter-weight (at least before I blow up ~/.emacs.d), so I'm probably just spoiled :) It's certainly faster than Visual Studio, but it also has far fewer features.