• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

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

Status
Not open for further replies.

TragicMonkey

Poisoned Waffles
Joined
Jun 28, 2004
Messages
74,829
Location
Monkey
Posted By: Darat
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.
 
Last edited by a moderator:
Have a site down because the Comcast Business Modem won't power on.

After spending 2 hours on hold and then over an hour going down the checklist:

Me: "It won't power on."
Comcast: "Have you tried restarting it?"
Me: "It won't power on."
Comcast: "Do you see any activities lights?"
Me: "It won't power on."
Comcast: "Unplug it from the wall, wait 10 seconds..."
Me: "IT... WON'T... POWER... ON."

I got an appointment for a tech to show up between 10 and 12 today. It's almost 4. I've been on hold since 2, and their chat window literally has "Thank you for your continued patience, we will be with you momentarily." repeated 49 times (I counted.)

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.
 
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.
Time to squeal like the proverbial porker.
 
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.

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.
 
Last edited:
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.
 
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.
 
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.
 
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.


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.


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.

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.
 
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!

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.
 
Status
Not open for further replies.

Back
Top Bottom