Dear Users... (A thread for Sysadmin, Technical Support, and Help Desk people)

[Elvis666]

"Packers" vs "mappers."

Is that original or did you learn it from someone else? That's a great analogy.

I remember when I first had to deal with Windows, I think it was either 2.0 or 3.0. I could not get comfortable with it, having spent years using DOS-based software. Now I can see I was trying to "map" all that new knowledge onto my existing abilities and couldn't do it. It only became easy when I began creating a completely new "map". It was only years later that the two maps finally began to overlap, when I began to code using TurboPascal and Delphi.

 

[alfaniner]

Is that original or did you learn it from someone else? That's a great analogy.

I remember when I first had to deal with Windows, I think it was either 2.0 or 3.0. I could not get comfortable with it, having spent years using DOS-based software. Now I can see I was trying to "map" all that new knowledge onto my existing abilities and couldn't do it. It only became easy when I began creating a completely new "map". It was only years later that the two maps finally began to overlap, when I began to code using TurboPascal and Delphi.

Perhaps that's why I had so much trouble attempting to learn object-oriented programming after decades of supporting COBOL systems. I tried a couple of lesson books (none of that "For Dummies" crap) but I never got past the first couple chapters. I sort of got by when I was doing iPhone apps but a lot of the structure was already there (or had samples) that I could map to my own ideas. But I often didn't know what was going on behind the scenes or why it was doing things a certain way.

 

[Blue Mountain]

Is that original or did you learn it from someone else? That's a great analogy.

Not mine, although I wish it was.

Perhaps the first reference to it is this article Thinking About Thinking from 1997. Wikipedia has a brief article on it, Mapper orientation.

I remember when I first had to deal with Windows, I think it was either 2.0 or 3.0. I could not get comfortable with it, having spent years using DOS-based software. Now I can see I was trying to "map" all that new knowledge onto my existing abilities and couldn't do it. It only became easy when I began creating a completely new "map". It was only years later that the two maps finally began to overlap, when I began to code using TurboPascal and Delphi.

That's a great example. A packer would simply learn all the steps by rote, then get completely confused the next time things changed, which they did a lot from Windows 3.1 to 10. Even mappers find it frustrating because as the amount of knowledge gained increases, the more effort it takes to update and maintain the map(s).

 

[arthwollipot]

Just fine. Because "LOL I'm just not a phone person" isn't something we as society accepts as normal, so it can't go on their character sheets.

But it's okay to be "bad at maths".

 

[Blue Mountain]

Perhaps that's why I had so much trouble attempting to learn object-oriented programming after decades of supporting COBOL systems. I tried a couple of lesson books (none of that "For Dummies" crap) but I never got past the first couple chapters. I sort of got by when I was doing iPhone apps but a lot of the structure was already there (or had samples) that I could map to my own ideas. But I often didn't know what was going on behind the scenes or why it was doing things a certain way.

Same for me, actually. The light finally went on when I had a discussion with a friend who was familiar with OO programming. I asked how about how it handled errors. "So what does the error handler get? A number? A string?"

He replied, "It gets an object,, which you then query using methods for more information. A well designed error object might return an integer code if you ask for "errobj.code()," a string if you ask for "errobj.text()," and the call stack leading to the error (which could be an array of stack objects) if you ask for "errobj.stack()," and so on."

That simple example doesn't cover inheritance, where there's a base error object that can be extended for, say, network errors (and then HTTP errors based on network errors,) operating system call errors, filesystem and hardware errors, etc. Layer 8 errors are a different matter.

 

[arthwollipot]

What it knows and what it knows how to do are the only two things that I have retained of Object Oriented Programming.

 

[novaphile]

Perhaps that's why I had so much trouble attempting to learn object-oriented programming after decades of supporting COBOL systems. I tried a couple of lesson books (none of that "For Dummies" crap) but I never got past the first couple chapters. I sort of got by when I was doing iPhone apps but a lot of the structure was already there (or had samples) that I could map to my own ideas. But I often didn't know what was going on behind the scenes or why it was doing things a certain way.

I wish I still had the book...

The very beginning of the first chapter.

"Everything in Java is either a class, an object or an instance. Unless it's an instantiated instance of an object, or an objectified instance of a class, or a classified instance of an instantiated object class... etc."

That's why I design systems and let other people code them.

 

[Elvis666]

"Everything in Java is either a class, an object or an instance. Unless it's an instantiated instance of an object, or an objectified instance of a class, or a classified instance of an instantiated object class... etc."

I remember at one time that would have made sense, but I've been retired for almost six years and haven't coded anything more complex than a small Visual Basic script in Excel since putting it all behind me.

 

[alfaniner]

Same for me, actually. The light finally went on when I had a discussion with a friend who was familiar with OO programming. I asked how about how it handled errors. "So what does the error handler get? A number? A string?"
He replied, "It gets an object,, which you then query using methods for more information. A well designed error object might return an integer code if you ask for "errobj.code()," a string if you ask for "errobj.text()," and the call stack leading to the error (which could be an array of stack objects) if you ask for "errobj.stack()," and so on."
That simple example doesn't cover inheritance, where there's a base error object that can be extended for, say, network errors (and then HTTP errors based on network errors,) operating system call errors, filesystem and hardware errors, etc. Layer 8 errors are a different matter.

I wish I still had the book...

The very beginning of the first chapter.
"Everything in Java is either a class, an object or an instance. Unless it's an instantiated instance of an object, or an objectified instance of a class, or a classified instance of an instantiated object class... etc."
That's why I design systems and let other people code them.

And it's within the first few words that I read nothing that doesn't sound to me like Charlie Brown's teacher. You know, "Wah-waah-wah-waaah-wahh..."

 

[JoeMorgue]

"Packers" vs "mappers." Some people learn things by taking in a bit of information, wrapping it up in brown paper, taping it shut and putting it on a shelf in their brain. These people are packers and they comprise as much as 80% of the general population.

They're the type who, when introduced to copy-and-paste, wonder why they would ever need to use it, then when they have to move a paragraph of text in a word processor labouriously fumble through the steps, or don't even try and re-type the paragraph. Then they have to relearn it for spreadsheets, and learn it yet again if they have to copy something from a web browser to a text editor (if they even recall they can do it!)

Packers tend to not be curious, learn slowly, and learn to do things by rote. They're the type that break down when Yes and No get swapped in a dialogue box.

Mappers, on the other hand, take in new information and try to synthesize it with everything else the know, adding it to a giant map of knowledge and experience gained over a lifetime. These are the types of people who do well in I/T and other knowledge based professions.

Listen if you're trying to sell "I can't function because my computer isn't the DOS machine I was taught a rote, step by step tasking 20 years ago with no understanding of how the process works" as just a valid alternative.... er no.

 

[TragicMonkey]

Grrrrr. I hate it when I go to the trouble to CLEARLY spell out something, and idiots still don't get it. I'm in a situation with data now that there are two possible courses to pursue. It's either A or B. One or the other. No other options, no combination of A & B. They are entirely separate courses, we have to do one or the other.

So I spell this out clearly. In English, and with examples to illustrate. It's not ambiguous, the examples show exactly how the data will look if we do A, and exactly how it will look if we do B. I even highlighted the differences, which are visible and obvious.

The question? "Do you want to do A or B?"

The answer: "Yes, please."

Grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr!

 

[CORed]

Years ago (1994-95 or so) I worked with an IT trainer who knew nothing about IT but was incredibly good at rote learning and teaching. She literally memorised the steps with absolutely zero understanding of why those steps worked, and that was the way she taught IT - to do this, click this, then click this, then click this.

She was incredibly popular.

Yeah. In my experience, that kind of approach works great, right up until the time something or other triggers an error dialog or some such that isn't included in your recipe. At that point, you either have to do some actual thinking (maybe even a Google search or three), or else call IT to do the thinking for you (which is pretty much the main topic of this thread).

 

[JoeMorgue]

And let's be honest here. It's 2020. If the process had already been reduced to the point that there was no ambiguity, no variation, and was a simple "X then Y then Z, exactly the same every time" the process would already be automated and a person wouldn't be doing it.

It's the whole "I shall replace you with a simple shell script" thing mentioned earlier.

Basically these people are demanding their jobs be made so easy that there is no reason for them to actually be doing it.

A computing process that has been reduced to "I push one button and everything just magically happens" very, very rarely needs the "I push one button" step at all.

 

[CORed]

I wish I still had the book...

The very beginning of the first chapter.

"Everything in Java is either a class, an object or an instance. Unless it's an instantiated instance of an object, or an objectified instance of a class, or a classified instance of an instantiated object class... etc."

That's why I design systems and let other people code them.

My take on object oriented programming is that it's just a different (and for me, a far less intuitive one) of organizing the code. When you get down to the methods, you're doing the same things you would do in the functions or subroutines of a prcocedural language. How you get there, though, is quite different. I've worked with object orented code, and gotten good results, both using objects and writing my own, but I really find procedural coding to be much more natural for me.

Object code, especially if you use classes with a long inheritance chain, uses more system resources too, as every class in that chain has to get loaded into memory. If you want to make your modern PC or webserver run like a 386, just code something complex in Java (well there's a lot of other stuff that makes the JVM a slow resurce hog, but that's a good chunk of it).

 

[caveman1917]

Grrrrr. I hate it when I go to the trouble to CLEARLY spell out something, and idiots still don't get it. I'm in a situation with data now that there are two possible courses to pursue. It's either A or B. One or the other. No other options, no combination of A & B. They are entirely separate courses, we have to do one or the other.

So I spell this out clearly. In English, and with examples to illustrate. It's not ambiguous, the examples show exactly how the data will look if we do A, and exactly how it will look if we do B. I even highlighted the differences, which are visible and obvious.

The question? "Do you want to do A or B?"

The answer: "Yes, please."

Grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr!

How is it a bad thing that you get to choose yourself? Just choose whichever happens to serve you best and do that one.

 

[TragicMonkey]

How is it a bad thing that you get to choose yourself? Just choose whichever happens to serve you best and do that one.

This project is too high-profile to skip the CYA step. I need written agreement to whatever approach I take or else when it inevitably blows up (the whole project is a stupid idea) those in charge will scramble to place blame, and I don't want it landing on "TM did the wrong thing, he should have asked".

I have two conflicting psychological drives: Get This Crap Over With versus CYA. Instincts tell me this is a CYA thing.

 

[caveman1917]

This project is too high-profile to skip the CYA step. I need written agreement to whatever approach I take or else when it inevitably blows up (the whole project is a stupid idea) those in charge will scramble to place blame, and I don't want it landing on "TM did the wrong thing, he should have asked".

I have two conflicting psychological drives: Get This Crap Over With versus CYA. Instincts tell me this is a CYA thing.

But you did ask. It went like this:

"Do you want to do A or B?"
"Yes, please."

So they said yes to "A or B" meaning you can either choose A or choose B to fulfill the request for "A or B" to be true.

 

[xterra]

TM, apparently you need to send another memo that says, "You children can have either pie or cake. You can't have both. Until I know which one you want, you're getting nothing."

 

[Dr. Keith]

This project is too high-profile to skip the CYA step. I need written agreement to whatever approach I take or else when it inevitably blows up (the whole project is a stupid idea) those in charge will scramble to place blame, and I don't want it landing on "TM did the wrong thing, he should have asked".

I have two conflicting psychological drives: Get This Crap Over With versus CYA. Instincts tell me this is a CYA thing.

Respond with: I'm not clear. Does that mean you want (whichever one you think will make your life better)?

 

[Norman Alexander]

All these people who in training struggle with cut-and-paste. And yet in the coffee break they are playing Solitaire at a million miles per hour. I usually find it's a matter of motivation, not skills limitations.