Working with beginning programming students, "Yay, now we have an error message that makes sense" has become my catchphrase.

"Read the error message, no wait don't close that go back" when helping people is a definite feeling.

Take a deep breath. Take off your headset. Go outside. Never look at a computer again. Start driving a bulldozer. Life is good.

I’ve lamented here before, but the number of technical people who absolutely freeze up at the sight of an error message is daunting. Being able to interpret errors correctly is a huge step up in this industry; to me it feels like table stakes, but clearly isn’t.

> I’ve lamented here before, but the number of technical people who absolutely freeze up at the sight of an error message is daunting.

"freeze" is still a much better reaction than "quickly dismiss without paying attention". I can understand "freeze"; it's possible to learn and train from there to "good, well done, now read everything and think". I do not understand "quickly dismiss without reading and paying attention".

(I know about the studies for "people dismiss something that isn't getting them their goal", but I still don't understand the mindset that can dismiss something like that even when theoretically trying to figure something out.)

Part of the problem is that we've trained everyone, especially nontechnical people, to ignore and dismiss stuff.

You're using a program. A thingy pops up or unexpectedly shows up that interrupts you.

80% chance it's some stupid ad or newsletter thing. Dismiss with prejudice.

19% chance it's a "oopsie poopsie we did and whoopsie, the server monkeys are working VERY HARD to fix this, sowwy!!" and then the app still works apparently just fine, or if it doesn't you just force close and re-open the app.

1% of the time it's an ad again.

In the remaining floating point error's worth of %, it's an actual actionable thing a user could action to fix the issue.

I don't really blame people for just predicting that a pop up will be useless because it probably will be.

Usually error messages are somewhat nice, What I have problems with at work is "error 395" and such. Where the documentation for the error codes can't be found easily.

(I hate progress openedge)

It's amazing the number of junior engineers I've taught to simply read the error message properly.

Or a junior dev will see "Error 422: thing_id is required" and instead of updating the request they sent to include thing_id they'll report it as if it's a 500 Internal Server Error until you pick up the ticket and read the error message to them.

Of course, they didn't actually put the error message in the ticket, they'll write "backend crashed" and put a screenshot of the front-end crashing because they didn't do any error handling at all.

Or its close cousin: "Yay, now we have a different error message!" When something is totally broken and you have no idea why, this is a promising signpost.

Similarly, the joke that the engineer’s second worst nightmare is, “it doesn’t work but it should”, while their worst nightmare is, “it works but it shouldn’t”.

That’s the surest way to nerd snipe some people. This code doesn’t work, and yet it does. After reading the commit history, it in fact never worked, and yet it has been up until yesterday. What in the actual fuck.

My favorite was C code that was roughly (all functions and variables h:

  int bar;
  
  ...
  foo()
  {
    if(bar) {
      doX();
    else
      doY();
    }
  }

Note that uninitialized globals in C are implicitly zero-initialized.

doY() had been broken for years but nobody ever set bar to be true; doX() was nevertheless being called. Setting bar to zero caused the buggy doY() to happen. Setting bar to one seemed to work, but would occasionally segfault.

Then someone explicitly initialized bar and got a linker error. Turns out in ye olden days of C, before "extern" was a thing there was a feature where variables that were initialized in no more than one compilation unit would be all coalesced by the linker. Before doY was broken, someone defined a function named bar, which then caused bar to have a non-zero (i.e. true) value. Someone later added some broken feature to "doY" and it passed all the tests because changing doY() didn't have any effect.

You're missing the } and { around your else, btw. I'm only mentioning that because I immediately saw it and got ready to read a horrifying story involving the text "#define else".

oh gosh I am.

I thought that was the bug on my first read. Naming collisions suck.

The buggy behaviour of A caused buggy behaviour of B that caused buggy behaviour of C, just so happened to align enough to "look like it is working".

Double fuckup if the thing is backups and your data is gone. Reason why we check not only "does the backup job finished" but also "does the size looks right", because backup with 0 files still returns OK...

Haha yeah, been there. I forget all the details, sadly, but there was some long-present bug with how the frontend architecture word in the dev environment that would keep the changes from being propagated. But every member of the team had set up a workaround so that, on their machine, it would load the correct assets some other, undocumented way, so they wouldn't notice the bug.

I used to do industrial tech support and this gives me the raging anxieties.

I have an exceptional ability to fix things: often I can fix things before determining why they are not working.

This is immensely frustrating because I like to understand mechanical and electrical devices and take pride in my craft, so if I fix something too easily I don't trust that the fix will hold without a mental model of the thing.

No news is bad news.

I don’t like code that compiles cleanly or runs cleanly on the first try. The worst is when I know that code isn’t close to done yet. Without errors my list of actionable tasks is low. I know there are a certain number of problems, and if I can’t see any it’s because they’re invisible, not because I don’t have any.

I came here to say this exactly. There's nothing more stressful to me than when a lot of freshly-written C++ compiles without error or warning on the first try, and then seems to run without issues. I get the distinct feeling that there is a problem that I'm just not seeing yet.

Eh, that heavily depends on language. Some have better tooling to get most of the typical errors out before the compile.

That being said I'm always suspicious and start to fiddle with them if I see test + code pass on first time