They announce a new Number Two
Hopefully not with the phrase: Whoa! Heavy shit!.
"We all know what we're doing today? Good. Do your best!" With that cheery note, our new project director sweeps out of the 10:00 stand-up meeting and away to… someplace or another, I don't know, wherever it is that project directors go. Project managers can be found everywhere, usually nearby a waste basket overflowing with …
1. HOPEFULLY = ADVERB
2. HOPEFULLY is shorthand for "I am hopeful that..."
It is a standard part of English, whether you choose to use it or not. And even those who do not use it know what it means, as there is no ambiguity between the two meanings as they are, as you spotted, different parts of speech.
I was once on a project that had an error logger, with output going to a printer when desired. The slightly confused developer was asked what he would do if the error logger had an error. He said he would log the error. We pointed out that he was exclusively in charge of the printer, so he could print whatever he needed to. He said "Oh".
That was the only good thing in that particular review.
I can understand that one, at least. The computer is absolutely unable to do anything about a hardware error, so it tells you about it. Then waits for input indicating that the error has been fixed. Admittedly, it could have been made more coherent by phrasing it "Keyboard not found. Fix it, then press f1 to continue".
On a complete tangent, this was the first error I ever diagnosed and fixed. I was 8 or so years old, and my dad started discreetly unplugging the keyboard from the computer in an attempt to stop me and my brother from playing Doom on his computer after school before he got home. It worked... the first time. Then it kind of backfired, because I usually remembered to unplug the keyboard again before he got home :D
This all comes down to the fact that specifications only ever specify what software should do when it succeeds (the "golden path"), and never, ever, lay out the requirements on how to handle error conditions, exceptions, and so forth. There might be a whole team of UI designers arguing about whether the main screen font should be 9.5 or 10pt and exactly what shade of corporate blue it should be, but they never spare a second's thought to specifying the wording of error messages.
This is further exacerbated by the fact that most developers aren't English Language graduates, or technical authors, but they are being asked to write simple, concise, yet useful and meaningful messages, and to spend time doing so which has not been budgeted for. Because it hasn't been put on the spec.
If they have been taught well, a good developer knows that a useful UI message should contain three things: what happened, what this means, and what the user can do about it. A canny developer also knows that the same message should be written to a log file, because the user will ignore it. A developer who has had proper paranoia drilled into them will also add a stack trace to that log file (but not the message box, no need to scare the user with terms like "Illegal Operation"!)
The solution to this is to employ BAs who can both liaise with users and also understand the software inside and out, so that the mythical complete specification gets written in the first place. Of course, such beings are far too busy off fighting supervillains to do a day-job that pays a BA's salary.
BAs as is Business Analyst, not Bachelors of the Arts. A mythical being who can gather complete requirements from a client and translate these into unambiguous instructions, including all those requirements that are "obvious" or "standard" but about which no words have ever been uttered.
These unspoken requirements may be something as basic as making sure the tab order on a form is correct, to reporting requirements for detailed audit-level reports of every action taken through the system. You know, anything that's "obvious".
In my experience, specs tend to end up with about 60% of everything that needs to be done. Of the remaining 40%, 30% is obvious stuff like error handling, and the other 10% is the bits where the spec doesn't go into enough detail, and you end up having to go back to the client yourself to tease it from them. Things like "what format do you want this export file in," "what are the valid expected values for this field," and so on. Half the time, you find out that the client hadn't even thought about it and somehow thought that you would magically know what they want before they do.
what happened, what this means, and what the user can do about it
Frequently, the "what happened" will actually mean nothing to the end user, will not be related to what the user has done and be beyond the user's means to correct.
A certain online banking system will, in these circumstances, give the user an error code and a phone number to call to report it. If you phone the number, they don't ask for the error code and don't want it if you offer it. And, of course, if you want someone to assist you with the failed transaction, they can't do it unless you're registered for telephone banking - in which case they still have to pass you on to another team. It's not just the developers producing the right message, there has to be a support chain to make use of it.
And, as we all know, the only real thought that goes into user support is how to reduce its cost.
Often, from the user's perspective, the "what happened" part doesn't need to be more than "something went wrong".
For example, a bad error message might be:
ERROR 1234 occurred - TRANSACTION FAILED CATASTROPHICALLY.
Line 43 COMMIT TRANSACTION Stack Trace: ...
Retry/Abort/Cancel?
A better message might be:
A problem occurred when saving the record.
No changes were saved.
Please try saving again.
If this problem persists, please contact support by clicking here.
(with the "here" part being a link that will post a full error log to a support portal, or provide details of a support helpdesk / number, how to send an appropriate error log, etc.)
Often, from the user's perspective, the "what happened" part doesn't need to be more than "something went wrong".
While you're right on the customer/user message, sometimes it's a good idea to add to the contact support bit with some details for them to pass along if possible. Hopefully something better than "it's broken".
That's true, but maybe developers could do the rare power users the courtesy to hint about what's going on, since obviously support won't care, even if you manage to get hold of an (alleged) human. After having switched it off and on a couple times you're on your own: Remember, we take our customers' satisfaction very seriously, now get lost already.
At some point the unfortunate user is sitting there, wondering what might have gone wrong, and most importantly how to fix it somehow (since chances are he wasn't doing that just for fun). He is the one with a deadline over his head, and suddenly that piece of #@%§ announces that it didn't like something, and thus will arbitrarily scuttle all the user's efforts to get his work done on time and go home.
A hint how to placate this stupid heap of metal and plastic would go a long way...
This post has been deleted by its author
While you're right on the customer/user message, sometimes it's a good idea to add to the contact support bit with some details for them to pass along if possible. Hopefully something better than "it's broken".
It's even better to not rely on the user to relay technical details which they don't understand. This is what logging is for (which is where you stick your stack trace / line with error / error details / etc. go). Even better is an automated bug report all wrapped up and ready to submit when click the "contact support" link. Give the user a reference number for it which they can write down. If you're wary of lots of automatically submitted files, for security reasons, give the user the ability to find and email you the log file.
"Often, from the user's perspective, the "what happened" part doesn't need to be more than "something went wrong".
Possibly - but I'm reintroducing the Birch for programmers whose error messages are too cutesy..."bruh, totally tough shit occurred, no joke. Better luck next life!"
True, except that getting things done right costs money, so "reducing the cost" dictates you do a rushed quick and dirty job.
Customer support is an automated maze ending in a bottomless pit, and thus can handle as many customers as needed, so why worry? Just promise the next version will be fixed, hope springs eternal.
Well yes, but that was a primitive text-only 1970s system.
These days you could have that error message sung to you in polyphonic choral 5.1 audio, with an accompanying Moment Of Divine Intervention rendered on the screen.
The error would be just as impenetrable but would look amazing.
Progress.
As I think I mentioned in my column. But only a posho or someone showing off on LinkedIn would use "effect" as a verb these days, and there is no real-world use for it in a UI Just imagine a word processor with a Search/Replace dialog that instead of having a REPLACE button had one that read EFFECT THE REPLACEMENT. Like I said, Lord effing Grantham.
This post has been deleted by its author
You've reminded me of a story I heard years and years ago. My memory wants to say it was originally related by Alan Bennett, the playwright, but I could be mistaken.
Anyway, very young AB, or whoever, was due to perform in the school end-of-term play. His mother (working class) spoke to the teacher (posh) and got told in cut-glass tones what costume was needed for the child. Ma worked hard all week stitching and stuffing and sewing and cutting, and made the - unusual - costume for her son. It was a green Brassica sphere, with leaves and a stalk.
Gets to school on the day of the play, son waddling awkwardly, as wide as he is tall, and the teacher sees the costume.
"No, Mrs Bennett! I said a sprite!"
I see what you did there, but to wear my pedant's hat, effecting a change and changing something are semantically different. Of course, most people using the former probably actually mean the latter, but there is a different implication of agency between the two, on the one hand, being the agency that makes something happen, but not necessarily doing it yourself, and on the other, being the one that actually does the thing.
For example, my boss's boss's boss effects lots of software changes, but, thankfully, doesn't change any code himself.
In the UK, there is no difference between inquiry and enquiry. I just checked in the Oxford English Dictionary - and if that's not definitive, I don't know what is.
If you look up "enquire, enquiry" it says "see inquire, inquiry". And when you look up "inquire" it says "inquire, en-".
They are just two different spellings of exactly the same work.
I'd go further and say that even if the student in question had meant to write "affects", they'd not actually specified what the effect would be. You know, whether it does something like blocking thrombogenesis* by some mechanism, useful for example, if someone is suffering from something like a pulmonary embolism, or speeds it up, useful if someone with a clotting disorder is bleeding out...
In other words, even if they got the right word (affects/effects), the answer is woefully non-specific. A bit like saying "this medicine cures an illness".
*The formation of blood clots
If I delimit that regex with ^$ I still get 34 hits by grepping over /etc/dictionaries-common/words. I started to compose a witty post containing all of them, but failed at "appositive" for the good and sufficient reason that I have no idea what it means. Insert evocative attractive alternative here.
Most (any?) Linux installation has a file in "/etc/dictionaries-common" called "words". Now this isn't what people usually know as a "dictionary" (something explaining words' meanings), it's a computer dictionary, ie. just a long list of English words in alphabetical order. I don't know what it is for, maybe for spellchecking?
It used to be "FILE NOT FOUND" (or for the really old: 2). Unless told to do otherwise Python3 actually tells you which file was not found. Perhaps in a few more decades software will also tell you where the file was not found so you can put it in the right place. (Or possibly RTFantasticM until you find how to tell the software to look in the directory where the file actually is.)
Not always. There are still far too many occasions when I see a pop-up "An unexpected error has occurred", which is
a) irritating since it implies that there are expected errors.
b) downright annoying: if you don't tell me which fscking error, how can I fix it?
Expected errors are the ones that have distinctive, though not necessarily helpful, error messages. They're often called exceptions. Some people insist there is a difference between errors and exceptions, but I've never been convinced.
Unexpected errors are the ones that management said to ignore. In theory, they would make that call on the basis that handling the error elegantly is not a cost-effective use of development time. In practice, I often suspect the real reason is that it would be too embarrassing to admit the possibility of this error happening, and would make the entire project look like a colossal waste of time.
we usually say 'errors' happen in business code, they are the unhappy flows such as input doesn;t pass validation, you can't book that on a holiday day, and can be corrected by the user with a helpful nudge in the right direction with an error message.
Exceptions are in technical code, disk full, network down, cockup in the code, and there is nothing the user can do except retry (if temporary) or call support and raise a ticket.
My favourite one (in a development system that somehow made it to live) was a response to a missing mandatory field for the applicant's sex [though I suppose nowadays we should say "gender choice"]
Sex is mandatory - please make an insertion
Heh, confirmation dialogs. At $newJob they gave me a Windows laptop that's so locked down I can't install the tools I need to develop with it. So I'm using my personal Linux machine, but thanks to Teams on Linux[1] not having video or screen sharing I still have to use the laptop for meetings.
So yesterday I'm on a call, and a dialog box pops up in the lower right of the screen. Says I need to reboot for "critical updates", and the only way to close the dialog box is to click the sole "OK" button. Cue a spontaneous reboot in the middle of my call.
This and other Windows usability issues makes me wonder how people put up with this crap. Perhaps if you've only eaten sh*t sandwiches your whole life you think they taste nice and can't imagine anything better?
[1] Apparently it did at some point and then MS removed the functionality in an update!?!
I've got a slightly better one than that. I'd just installed Microsoft's own minidump file analyser for Microsoft's own minidump files onto one of the production database servers (there was some sort of pseudo-justifiable reason for doing this on prod).
The installer finished and declared that to before using the software there'd need to be a reboot, and asked if I wished to do this now. Two buttons, OK and Cancel (or possibly Yes and No).
Knowing that this message was almost always untrue and I'd be able to use the software without a reboot, and also knowing that if it didn't work I could just schedule the reboot into a maintenance window, and also liking a tidy desktop, I of course clicked Cancel (or No). Cue immediate reboot of production database server.
It certainly taught me a lesson but if I ever get locked in a room with the person responsible for that particular dialogue box it won't be pretty.
"Please" is usually superfluous in dialogues.
The number of people who will actually read the dialogue is inversely proportional to its length. Most people will manage up to about five words, but beyond that the ratio drops off rapidly. So every word counts.
Saying "please" actually makes your message harder to read. You can make a good case that it's also, perversely, discourteous, because it's unnecessarily and unproductively increasing the cognitive load on the reader.
> The number of people who will actually read the dialogue is inversely proportional to its length
But directly proportional to its gravity. The spammy annoying messages like "You've just saved, do you want to save again?!" won't get read, but if your program freezes and you're about to lose hours of work (and potentially your job), chances are you'll read the error message like a holy tenet.
Of course there are the entitled and the stupid who will rip out the power cord and throw the computer out of the window, expecting their tantrum to scare destiny to fix everything, but most people will have a good look at it (as soon as their hearts start beating again).
At this point, some intelligible explanation on why the roof caved in would be welcome, something more helpful than a random, nondescript, generic message. It being funny doesn't help any BTW. If there was a time for the developer to brag, this is definitely not it...
"This will effect all the files in the current location. Do you wish to continue?"
This is one of my pet hates...almost always it should be "affect" (or will "have an effect on")
FFS will someone start teaching grammer again?
I remember at primary school (late 1960s)having "grammar" and "vocabulary" textbooks to work through..not to mention the *daily* spelling tests of 20 words practised overnight.
Don't get me started on "x has been IMPACTED by y" currently the new fashion.
You mean "x has been affected by"...constantly using "impacted" inapproptiately just loses ....er...IMPACT..er...
Wow, got that off my chest and I need to lie down with a GTN tab (I don't have angina but..)
>The one that boils my piss is 'loose' as a verb.
Ah yes. Far too many people on the Internet "loosing their temper".
Rogue/Rouge is another one that people seem to have trouble with.
You may enjoy reading Reddit's /r/BoneAppleTea, which is a home for such perversions of the English language. Don't blame me if it superheats your piss though.
"FFS will someone start teaching grammer again?
A certain Grammer School agrees with you :-)
My kids' school has taught them to distinguish between effect and affect. I assume it's theoretically done the same for all their peers, but there's always the kids who are too cool for spelling.
As for "impacted", that hasn't been new since I was doing my time as a tech journalist - in the 1990s.
The eggcorn that bothers me most, because I see it so often from people who ought to know better, is "free reign" (or, relatedly, "reign in").
@veti “kids who are too cool for spelling”
So, when my teachers were calling me thick because I could not spell. They really meant I was the cool kid. That’s nice to know.
I went to school in the 60’s, we had spelling tests as described by Jean Le PHARMACIEN, no amount of practice resulted in me remembering the spelling for more than a few words. Couple of days later I would have forgotten them as well. Corporal punishment did not seem improve my ability to spell either.
I still can’t spell, and nothing is going to change that, it is something I and others are not able to master. But whatever the reason it is not because we are too cool for spelling or lazy (as some of my teachers said).
Thank God for word processors with spellcheckers. Meaning not being able to spell is no longer the problem it was in the past.
The point at issue is that there are words which have only a minor difference in spelling, stationary and stationery for example, which mean quite different things. The spillchucker won't help with those, you need to make a personal* effort to distinguish between a shop that's the opposite of mobile and one which sells envelopes.
* As opposed to personnel.
Minor difference in spelling, but complete opposite in meaning. How about hyper and hypo? Then there are ones you've got to be careful with, such as ordering tortelloni vs tortellini, ravioli vs raviolo, etc. ad infinitum.
What is it with the Italians?
This one has always confounded me. Being part of a voluntary first responder team where clarity and time are of the essence, why have two words that sound so alike on a radio in bad weather. ''the casualty is hypoglycaemic / hyperglycaemic. Fucking bonkers.
@Doctor Syntax I can’t spell, but I can read. When I see the word written I recognise it. If I could not do that a spell checker would not be of use to me, as I would not know which of the suggestions is the one, I want.
Actually, if I could not do that, I would not be able to read. ;)
It's well documented that one's own writing is the most difficult to proof-read because what is "read" is what's intended to be there rather than what is actually there. I'll rely on a spell check for words such as accommodate (yes, missed the double m again) and recommend (got it first time!) but the pairs have to be known.
I once logged an error message in a program where it should not have been possible to get to. The message was "Committing seppuku! Arrrgggghhhhh!" followed by the program terminating. One of my fellow programmers on the team managed (somehow) to trigger it. He came to my desk, looked accusingly at me and said, "You wrote this, didn't you?" I had to allow as how I had, so we went over the code together to figure out how he'd managed to trigger the message.
Back in the early 2000s a colleague showed me a supposedly (his words) ultra-stable if not crash-proof OS: Linux (Red Hat, IIRC). I played with it for a minute, and promptly triggered a kernel panic... How? IIRC while trying to change the wall paper (using the GUI)... I must have clicked the GUI elements in a sequence the desktop program was not built to handle. My colleague, who was quite Linux-savvy, never managed to understand how I had done it, or to reproduce the error...
My point is, "unlikely" errors aren't unlikely for everyone (as you have all already noticed). What happens is that people "who know" usually stay inside a well-trodden work path, inside which all problems have eventually been found and eliminated. New and still incompetent users won't use those safe paths, simply because they don't know them, and will thus happily step on all those land mines left which the savvy people will never encounter.
"[...] and will thus happily step on all those land mines left [...]"
Back in my days of in-house mainframe system support. There were days when we would find a stack of OS dumps (post mortems) waiting for us. Our first question was "OK - who has just recruited a new graduate in their application software development team?"
I worked on a real-time system where run-time errors were heatedly discussed. If abc process crashes, what does abc do with all the other processes sending messages to it? Does it "sink" them? (Maybe then abc process serves no purpose and is redundant). Does abc queue them up? (Which makes the whole system immediately fall off a cliff).
One thing I built into all my programs (the bosses turned a blind eye to it), was to create a ring buffer containing the last x,000 events. Every time I received a message, or got data from a live input, I would record it in the ring buffer. Many times it covered my backside. The great thing was, I actually enjoyed analysing dumps of my own processes. The best one was where I deduced that a different department had been working over the weekend and they had not designed pull-up resistors into their circuitry when interfacing with our mainframe. My boss got prints of the circuit design first, just to make sure my hunch was right.
"[...] with every minor release, it seemed the current dialog scripts would be routinely wiped and reverted to those written a year earlier, [...]"
An range of X25 switches had an operator's console that was essential after loading an updated version of the OS. There were two development teams for the system - each responsible for producing chronologically alternate versions. They were also located in different US states.
Unfortunately each team had different basic settings for the management console's asynchronous protocol. You had to remember which team was the current "live" one before you could get the system to respond.
Reminds me of a couple of years ago when I was one of a development team of two, struggling to meet increasingly ridiculous deadlines. So obviously to relieve our burden they hired a project mangler to encourage us to work smarter, not harder. They never did figure out why we would mutter darkly about someone called 'Jen'.