Dear Users… (A thread for Sysadmin, Technical Support, and Help Desk people) Part 10
 

Damn it. I had to look at someone else's SQL (which always makes me feel dirty, other people's style is weird and off-putting) and I found three mistakes. One's a busted join, one's using a very wrong field to do a join, and the other is doing "where field in (items)" and the items are short by about fifty things that should be included. So now I have to tactfully point out the errors without a) offending them and b) triggering the work to just be reassigned to me.

Sometimes I worry that I'm actually good at my job, which is not in keeping with my chosen view of myself. And for some reason the end users in question on this one seem to like me despite my being as horribly pedantic as I possibly can (I always answer "is this data right?" with "this is an accurate representation of what was in the database at the time the query was run", for example) but it doesn't put them off. Damn it, they're going to ask this be turned over to me on top of all the other crap I'm already doing for them. Grrrrr.

I hate looking at other people's SQL. It never leads to anything good.

Similar conversation with Fitbit support about my daughter's fitbit.

Screen remains blank. It does vibrate and is visible via bluetooth.

"Try rebooting it - when you get a smile it works"
- well suspect I have rebooted it, but the screen is still blank
"OK try connecting it to your phone and changing the clock faces"
-how?
"you need to pair it as in the instructions in the app"
-OK... you do realise that I need to input a 4-digit code that is displayed on the fitbit screen... which is blank.
-OK I failed because the screen remained blank
"try rebooting it."
-I have.


Eventually after about an hour, they sent me an email with a returns label to print out to send it to them.

Time to squeal like the proverbial porker.

This strikes a chord with me--I used to pride myself on being able to write manual SQL code for just about any kind of result I needed. Then at one analyst job we started using SAS Enterprise Guide, and I observed, to my horror, that it was common practice to use visual tools similar to (but more powerful than) MS Access query design screen.

Not only that, but rather than build up the result from nested sub-queries, instead you'd start with your linked source table, and perform a query on it to create a temporary table, then make another query to manipulate the data further, and creating a sequence.

I started out skipping all that and just writing massive manual code in the text editor as God intended, and patting myself on the back for being smarter. I quickly learned the hard way that there were several key advantages to the "dumb" way.

- Troubleshooting was easier with the process in multiple steps. You could easily see what part went wrong, fix just that part, and continue from the last successful step. My way, you had to take it from the top every time you found a bug.

- If the source data or business logic changed, it was easier to modify and enhance. Steps that were done the same way could be easily left alone.

- Someone inheriting the job from me had a chance in hell of figuring out what I was doing to the data and why.

I've had a drink, but people who write unmaintainable code want necking

A colleague tells me that he used to use SPSS, which has some very clever "i think you meant to code that" when running. He said it was weird looking at the output saying something like

Perform function on array string1. No "string" listed - using stringl instead

He also saw a demonstration of a make yourself irreplaceable macro for it, which stripped out all comments, renamed all strings as x1 x2 x3 etc and removed all line spaces so it was a single line of code.

When running?. That sounds like autovivification (which can be a horrible source of problems) on steroids in “hold my vodka” mode.

The last bit: an IBM language called Rexx (big fan) had a oneliner tool that would rewrite a rexx program as one line. Scripting string tokenising language. It was used as a sort of ersatz compile to make shipped code compact and harder to hack. Until someone wrote a deoneline script.

I once wrote a Perl obfuscation program (as if Perl needed it! :p) that changed all the variable and function names to 16 character names comprised of lower case "L" and upper-case "o," and the digits one and zero.

The trouble with being "irreplaceable" is that it also makes it very difficult for you to transfer if you want to, say, accept a promotion into another department. You'd better REALLY like staying in the job you have.

Yes it does sound risky. I mean with SPSS it is going to be analyses, rather than actually effecting something vital. Maybe it was in compiling.


Indeed, and neither of us are data (or software) engineers* as our primary roles - one good friend and colleague was a software engineer for 30 years before his current role... I has assumed he was a hardware engineer, until he told me.



*We design power semiconductor chips and the processes around them - I play around with Gallium Nitride and Silicon, he still just plays around with Silicon.

I’ve had the pleasure and agony of working with two genius programmers* (out of the hundreds I’ve worked with). And they were a total contrast. One produced code that was basically ( ;) ) unreadable, actually even worse than that it was indecipherable but it was incredible efficient and fast. He would claim that the indecipherable code was a necessity for it to be so efficient and fast. The other wrote the most elegant code that was as easy to read as a novel as well as being efficient and fast. Whilst I learned some things from the indecipherable programmer I learnt the most from the readable bloke and I bet 25 years on someone could pick up his code and work with it with hardly any trouble.


*Excluding assembler level programmers - they are just weird and have enough trouble communicating full stop!

For a while 30 years ago I had to write some stuff in A68K. I never documented it as I had no idea how it worked. I was just grateful that the numerous sacrifices I made on the floor of the machine room paid off.

I think people underestimate the superstition level in coders.

The indecipherable code bit was particularly useful when memory was limited from what colleagues tell me - and one now-retired colleague had used magnetic core memory.

Got it.

Indeed.

There are 10 kinds of people in the world,
Those that understand binary,
And those that do not.

No, there are 11 kinds.


Those that understand binary, those that don't, and those that don't care.

I only understand hex.

Why do programmers get Hallowe'en and Christmas mixed up? Because Oct 31 = Dec 25.

LOL :D

I tried to get a witch's phone number but it was in hex.

I tried to get Long John Silver’s number but it was in octal.

That's good. I was tempted to steal it, but then realized I only know two people in real life who could possibly get it, and neither of them has a sense of humor. Now I'm depressed about my social circle. Thanks. Thanks so much.

It was based on an old joke about the lowest definition of a parity error “pieces of seven, pieces of seven”. Obviously it works better spoken than written.

Thanks for the explanation. I would never have figured it out on my own, never having heard that before.

Again, LOL.

Well, now you know 3.

You're depressed? I don't think I know anyone IRL who would get it. How do think this makes me feel? :mad:

Superior?

Sorry, need some help on that one, too. :blush:

And I taught some newby employees how to decipher octal.

Thanks. I needed that.


:mpony

:D

Treasure Island. The pirate Long John Silver has a parrot that repeats the phrase “pieces of eight” - a nickname for the Spanish dollar.

Thank you. That's a bit I'd forgotten about...

So I just had my ear chewed off by The Most Important Person In The Department because I couldn't reset the password on a system that we don't own or manage.

"I'm sorry, ma'am, the new obscenity filter prevents use of those words even as passwords."

Oh. Oh. One of the things I learnt as a user was never to piss off the guys in Technical Support. Not that I ever did (intentionally). I learnt by observation. Nicey-nicey was the rule. :)

Did the MIPITD ever find out who could?

The Director's PA? Yep, seen that many times before. :rolleyes:

When I moved to compressed hours, which means I start at 0700 I joined the little gang of people who check the production batch schedulers to see if there are any jobs down. If there were any I would try to fix them, because that's what I'm paid for, it helps my colleagues and it's good practice for overnight and weekend callout cover.

I've encouraged my teammates to do the same, and one guy does it dutifully every morning and posts a little status report into the team chat.

Except when there's a job down. The first time it happened I thought, "hmmm.... coincidence?" Now, it's happened too many times . This morning, no report, and, sure enough, job down.

I actually had opportunity to make use of the technical support for my ISP very recently. I gave them all the relevant information up front, and did everything they told me to do. They were able to fix my problem in about fifteen minutes. After the call, I gave positive feedback.