And yet more sites do it, even on desktop. As far as I can tell, most of them are also doing it in a way that breaks security by validating the username before asking for the password.
I'm a programmer, so I must know how to get X done in Y software.
I don't use or so I'm some kind of Luddite and can't possibly know anything useful about computers.
One thing that fascinates me about #1 is that the absolute raw dependency people have on Google doesn't seem to ever lead to searching for a tutorial.
Good article that I think does a pretty good job of outlining the problems of "Computer time is less expensive than programmer time."
I was "raised" on the idea that end-user time is more valuable than programmer time and nobody really talked about computer time except in the case of unattended-by-design systems like batch processing. Even those were developed to save end-user time by, for example, preparing standard reports overnight so that they would be ready for use in the morning.
I think that one place we went off the rails was the discovery that one way to manage efficiency was by creating different classes of end-user: internal and external. Why would management care about efficiency when the cost of inefficiency is paid by someone else?
So much software is created explicitly for the purpose of getting someone else to do the work. That means the quicker you get something out there, the quicker you start benefiting, almost without regard to how bad the system is. And why bother improving it if it's not chasing customers away?
The left side (linear) looks like the code I write while I'm trying to figure out whether I understand the problem or I'm not quite sure what all I need to do prove that I can (or cannot!) solve the problem.
The code on the right, with all the "abstractions" looks like the code I end up with after I've got everything sorted out and want to make things easier to read, find, and maintain.
I actually find the code on the right easier to read. I treat it like a well written technical manual. For me, understanding starts with time spent on the table of contents just to get a sense of the domain. That is followed by reading the opening and closing sections of each chapter, and finally digging into the details. I stop at any level that meets my needs, including just picking and choosing based on the table of contents if there is no clear need to understand the entire domain in order to accomplish my goal.
I've preferred code written in that "abstracted" style since discovering the joy of GOSUB and JSR on my VIC-20.
I learned that Android was not open under my personal definition of "open" right from the outset, because there was no programmatic access to telephony. My first project was to build an on-board answering machine with call screening capabilities.
I used an answering machine on my landline to avoid paying for caller id and voicemail and wanted to do the same with my cellphone. I was very disappointed to learn that this was not possible, at least with my skillset.
I knew that things were going the wrong way when my Tasker script to manage airplane mode stopped working when Android required locked it away. My use case there was that lack of connectivity at the gym and at home meant that connection attempts were draining my battery and heating up the phone. Now, of course, Android does a much better job of that particular task on its own, but it still makes me cranky. :)
Everything that has happened since has only cemented my opinion that Android is not actually an open platform. I do see many of the changes as potentially valuable security measures for the masses, but I wish that it wasn't quite so difficult for a power user to use the power of the little computer we carry in our pockets.
I'd just like to take a moment to commend you on an absolutely exquisite answer.
Given time, there is a slim chance I could have covered the same ground and no chance that it would have been as clear and concise.
I eventually learned to never trust any restrictions on the user.
I quickly learned to make sure everyone had a copy of decisions made, so that I could charge by the hour for changes. I eventually learned to include examples of what would and would not be possible in any specification or change order.
Maybe I read things too literally, but I thought "Fahrenheit 451" was about a governing class controlling the masses by limiting which ideas, emotions, and information were available.
"Brave New World" struck me as also about controlling the masses through control of emotions, ideas, and information (and strict limits on social mobility).
It's been too long since I read "20,000 Leagues Under the Sea", but I thought of it as a celebration of human ingenuity, with maybe a tinge of warning about powerful tools and the responsibility to use them wisely.
I don't see a lot of altruistic behaviour from those introducing new technologies. Yes, there is definitely some, but most of it strikes me as "neutral" demand creation for profit or extractive and exploitive in nature.
I have two hypotheses for why some kinds of software grow worse over time. They are not mutually exclusive and, in fact, may both be at work in some cases.
Software has transitioned from merely complex to chaotic. That is, there is so much going on within a piece of software and its interactions with other pieces of software, including the operating system itself, that the mathematics of chaos are often more applicable than logic. In a chaotic system, everything from seemingly trivial differences between two ostensibly identical chips to the order in which software is installed, updated, and executed has an effect on the operating environment, producing unpredictable outcomes. I started thinking about the systems I was using with this in mind sometime in the early 2000s.
The "masters" in the field are not paying enough attention to the "apprentices" and "journeymen. Put another way, there are too many programmers like me left unsupervised. I couldn't have had a successful career without tools like Visual Basic and Access, the masterful documentation and tutorials they came with, and the wisdom to make sure I was never in a position where my software might have more than a dozen users at a time at any one site. Now we have people who don't know enough to use one selection to limit the options for the next selection juggling different software and frameworks trying to work in teams to do the bidding of someone who can barely type. And the end result is supposed to be used by thousands of people on all manner of equipment and network connections.
One reason that open source software seems more reliable is that people like me, even if we think we can contribute, are mostly dissuaded by the very complexity of the process. The few of us who do navigate the system to make a contribution have our offerings carefully scrutinized before acceptance.
Another reason that open source software seems more reliable is that most of it is aimed at those with expertise or desiring expertise. At least in my experience, that cohort is much more tolerant of those things that more casual users find frustrating.
I thought it was a good article. Well-written and reasonably well-argued. That said, I think that he missed a couple of things. I had a whole wall of text in preparation for my own blog post, but during the edit it really came down to a couple of things.
I think the industry's obsession with 10x programmers is really about the quest and desire for mastery. Mastery is something that exists in any field, so that means we can look to history for comparisons.
He argues that mastery is disappearing. My opinion is that what he's really seeing is the normal lifecycle of any industry that leads to less dependence on mastery.
Everything from furniture making to mechanical work has gone through the cycle. People doing what they need out of necessity, people getting good enough to offer their services on the market, masters arising from the truly dedicated and/or obsessed, shops run by masters to increase output by using the labour of apprentices and journeymen (and budding masters), and, finally, factories.
The difference between a master's shop and a factory is critically important. In a master's shop, everyone is gaining skill in the profession with mastery always possible to achieve for anyone with the right combination of desire and talent. In a factory, tasks are broken down into their component parts so that mere repetition and maybe some automation is enough to make extract masterful work from the process instead of depending on individual mastery.
Your local mechanic's shop, especially if it's a dealer shop, has more in common with a factory than a master's shop. A race team is where you're more likely to see a master's shop in operation.
I think that what we are seeing is the transition from masters' shops to factories.
There are still passionate people becoming master mechanics or furniture makers. I think the same is true of 10x programmers. But the tools some of those master programmers build will help everyone else do higher quality work and the processes they develop will eventually enable the extraction of masterful products from well-engineered processes executed by low-skilled people and, of course, automation in the form of AI.
So one day the different body parts were arguing over who should be in charge.
The eyes said they should be in charge, because they were the primary source of information about the world.
The stomach said it should be in charge because digestion was the source of energy.
The brain said it should be in charge because it was in charge of information processing and decision-making.
The rectum said nothing, just closed up shop.
Before long, the vision was blurry, the stomach was queasy, and the brain was foggy.
Assholes have been in charge ever since.