The Decline of Usability (2020)

Things seem to start out well with blank projects; but eventually, somewhere around the mid-scale 30k+ line point, all the advantages of all those incredibly great features in VS Code seem to be offset by scaling issues.

There was a point recently at which I seriously thought I was losing my programming edge. But a recent adventure with a non-VSCode project, and a recent discovery with respect to the VSCode debugger is making me wonder whether it's my tools that have lost their edge.

There are a bunch of things going on in that user interface of Visual Studio code that are completely tanking my productivity.

A telling example: When using the Visual Studio Code GDB debugger, Visual Studio code fetches the local variables of ALL stack frames on ALL threads every time you single-step. This happens even when the thread views are collapsed. As a consequence, it takes between 10 and 30 seconds (depending on how thread-heavy your app is) to single step once. I was pushed over the edge when I dropped into a new project and Visual Studio Code was take three minutes to single-step. (Not a memory issue, not a disk issue, not an inadequate machine issue).

So I did some research. This has been an issue since 2016 in Visual Studio code! The solution (according to message posted in 2016 somewhere on the internet): switch to the CodeLLDB debugger extension.

The result: on the 3-minute code base, single steps take distinctly less than a third of second.

It's like the frog in a boiling pot of water: you don't realize the toxic effect that kind of latency has on your your debugging productivity until it instantly goes away. 3-minute single-stepping is obviously impossible to work with; but the cumulative effect of taking 10 seconds to single step is definitely large. I can debug things orders of magnitude faster than I could before. I don't lose my train of thought. I can set breakpoints fearlessly, and single-step through dozens of lines of code -- all things I couldn't do with the default Visual Studio debugger.

The only peculiar side-effect of CodeLLDB: the debugger expression evaluators use RUST expression syntax even for c++ code. Which isn't actually terrible. It's just very strange.

But there are other things as well: the latency on Intellisense updates, where you have to wait 10 or 20 or 30 seconds for the error squigglies to update. Every edit becomes: type a few characters, wait for 30 seconds to see if Intellisense likes its, type a few characters.... And WHATEVER you do, don't unbalance parens or curlies, which will pin all available CPUS for minutes at a time! (Huge recent productivity improvement -- set the number of Intellisense threads to number of CPUs minus 1!).

In the old days, on much less capable hardware, a compile would fail in 3 or 4 seconds; so you could just "type a few characters; press F7, wait 4(!) seconds, and see if the squiggly went away. Although typically, you would fix a few things, wait 4(!) seconds and see if the squigglies went away. (More-or-less instantaneous checks were run in the editor to check for paren/brace balancing).

Instead, VSCode accumulates rats nests of red squigglies that wont go away until background intellisense completes (which could be 90 seconds or more), or until a compile completes, which runs the constant risk of facing a list of "12,000+"(!) errors in the error window, because you have an unbalanced paren or brace, which can take 10 or 15 minutes to straighten out. And the three or four G++ errors that are legitimate get buried in thousands of Intellisense errors that wont go away (that's a recent regression; you used to be able to temporarily filter out Intellisense errors).

I'm increasingly thinking that Intellisense for C++ is dramatically tanking my productivity as well! I mean it does actually work on toolable languages, like C#+Visual Studio, or Java+Android Studio, where the tooling update time is sub-10-seconds. But for C++ it seems to be a disaster. (Wondering whether it actually does work, though).

Build turnaround: there is NO obvious point in the Visual Studio UI to indicate that a build has completed. A tiny status message buried in the status bar. For some reason, my build output window always seems to come unglued from auto-scroll. And VSCode auto-tabs away from the Errors Window to the Build Window without un-de-autoscrolling. So you hit the F7 key, your eyes glaze over while a toxicly overlong build runs for a minute past the point where the error occurred, and you snap to 3 minutes later realizing that the build finished with errors, ages ago.

Mouse-keyboard context changes. Switching your left hand from mouse to keyboard and back is an expensive operation relatively speaking. By my best estimate, I spend about 40% of my editing time switching between mouse and cursor keys. Whereas... on Visual Studio, major editing operations can be performed entirely from the keyboard. (ctrl+space, cursor cursor, carriage-return is burned into my muscle memory for some reason, even though it's been years since I used Visual Studio -- or is that Android Studio?). There's something seriously wrong there too in the arrangement of short-cut keys, mouse and cursor movements.

Ctrl+Left/Right Arrow! There's a simple thing that is bizarely broken, that has a dramatic effect on my productivity. It does something seriously wrong, I'm not sure what, but it's not productive! It consistently takes you to the wrong edge of identifiers and operators, so you end up pounding on unmodified left or right arrow to get to the right place. I'm DEAD certain Visual Studio does it differently; and it's not a problem I've noticed at all in Android Studio.

I'm convinced that a little time spent on time and motion studies could increase the productivity of average developers by dramatically large amounts. Something in the order of 2 or 3- or 4-times more productive. Most especially for Visual Studio Code, which -- for reasons I still don't completely understand -- seems to be extra-double-plus toxic for productivity.