jadero

There was a thread elsewhere asking whether a toggle should show current state or the state desired. There was enough disagreement that it quickly became apparent that, whatever else the toggle does, there should be something external to the toggle showing the possible states, indicating which way to move the toggle regardless of toggle appearance.

Hey, me too! Although I took a transition job in between as public works foreman for a small village. (Single person doing everything from water treatment to sewer cleanouts, snow clearing to cutting grass.)

Sewing for sure, especially machine sewing. I feel like I've got as much time invested in fighting and maintaining our sewing machines as in our Windows machines. 😛

And then there's that whole transition between pattern (spec) and outcome that is oddly reminiscent of far too many of my software projects!

Knowing how a switch works in a circuit and how it's typically represented in schematics, I would guess that moving the switch toward the body of the gun should be off.

But if actually placing a bet, I'd put my money on it being the other way.

You've just described my 50 years in the workforce, jumping from job to job, only just barely anything resembling an actual career.

I haven't yet started blacksmithing, but it's the next logical progression. Other than a (very!) occasional boat and the odd bit of furniture or cabinetry, I seem to spend most of my time making tools, jigs, and fixtures.

#5? (Me): pronounced S.Q.L. except for Microsoft's product which is pronounced "sequel server".

I call that the "nerd equivalency problem". I think it's the source of much (most? all?) of the problems with software that comes out of organizations that are not programming shops by nature.

"We're not moving fast enough (or, "I have this great idea!"), hire another nerd!"

The problem also exists within individual programmers ("sure, I can do that UX/UI thingy, just let me finish building this ray-tracing thingy"), but that's just an ordinary cognitive weakness that affects us all (thinking that being expert in one field makes one expert in all). It's the job of proper leadership to resist that, not act as though it's true.

Every time I see a set of instructions like this, I can't help thinking that someone forgot that we're using computers.

That's very closely related to something I've come to think about tech: nerd equivalency. If there is a computer involved, then a nerd is required and they are all interchangeable.

Basically, someone says "we're not moving fast enough, hire another nerd!" and nobody in the chain of command or in the hiring process has a clue which particular skills are required, assuming that everyone can do everything.

That's why so many corporate projects have what amounts to random people doing randomly assigned work producing insecure, unreliable products with obscure and even hostile UIs.

AI is cool technology (imo), but currently it's just the latest bait for CEOs, managers, etc. Somehow these kinda people are just so vulnerable for hype words without ever thinking more than as second about how to use it or whether it's even useful.

I think that's a general problem with most technology that is fundamentally about computing.

People outside any field have only the barest grasp of that field, but the problems are so much worse as soon as computers are involved. They are so ubiquitous and so useful to so many people with little or no training or understanding that everyone just succumbs to a form of magical thinking.

Unless, of course, that programmer has any number of mobility issues that limit their use of the keyboard, in which case something like cursorless might be the only option.

I urge you to take a look at it. Some even claim that it's more productive than the keyboard. I don't know how the VSCode voice feature works, but if it makes integration of cursorless easier or better, then I'm all for it.