Open question: where do you find actual *curmudgeons* in IT today?

[The Gorn]

Don't say this board, please. No easy guesses.

It occurs to me that all we hear about are companies that only hire young kids, and age bias in hiring in IT. I have not heard of companies or groups that keep around a pen of "real programmers" or older IT people.

Are there even older IT people any more with a few rare exceptions?

I'm quite serious - I am struggling with a blog article on the tension between curmudgeons and non-curmudgeons in IT.

I am having some trouble coming up with actual examples of curmudgeons in action, besides this board. It seems to me that you simply don't find actual older cynical types in IT today. So my article may be about a chimera.

By "curmudgeon" I mean any highly experienced and older worker who has a cynical, highly skeptical or somewhat dismissive attitude toward certain innovations and some youth-oriented tech cultures.

Example: a curmudgeon would deem Google's "Summer of Code" competition stupid and worthless. Another example: a curmudgeon always compares everything new to something that came before it, usually negatively.

[DG9]

Not many older IT folk, those that are in a corporate setting have put on a happy face or been let go from what I have seen...

Curmudgeons are not tolerated.

[TRexx]

I work for one.

He's been with the company for 30+ years. No one will dare to argue with him on anything technical. He will readily agree that newer technology is great "for some things" but as soon as anyone suggests that it might make sense to port our 30 year old app to something new, he digs in his heels.  Several times he has been directed to work with folks brought in to design a replacement. His M.O. is brilliant. He attends all the meetings and when asked about how the system works, he readily gives forth about 65% of what they need to know. Then when they come back with their proposal, he smugly asks how they will handle some requirement.   When they say they never heard of that requirement he says it's so fundamental that any idiot would have assumed it, or at least asked the question.   The clueless managers eat this up and the proposal is shelved.

But his real forte is dealing with auditors. Whenever they ask for something he just says "that doesn't apply to our system". Since they don't have the technical chops to disagree, they end up leaving him alone.  Since management doesn't have to fork over $$$$ to address audit issues, they love him.

So the app keeps chugging along, guaranteeing employment for a half dozen people, counting the days until retirement.




 

[Aussie]

Trying to swap in any change to this bank's system is like trying to play Ker-plunk! with marbles made of fulminate of mercury.  Management hasn't outsourced this particular central system, despite other banks going down the outsourcing trail, and you can't help but wonder whether it's because they think, if we get rid of these guys (a central core of about 3 older people), and the system tanks, we'll be out of business before it's all untangled.  I heard the senior guy referred to by management by the Dilbertian moniker 'Phil the Prince of Insufficient Light' on many occasions.

[The Gorn]

These are good responses. I will, of course, consider all subsequent contributions just as highly.

Here's what I see, as you guys have described it:

- Most businesses and development groups really don't like or want curmudgeons around.

- When curmudgeons are around in an organization, they tend to engage in destructive tactics to aggregate and preserve their power, usually by FUDding any proposed improvements or just sitting on a valuable piece of technology.

My original article concept was to present the interaction between curmudgeons in IT who diss everything new, and younger developers who never met a new technology that they didn't love. But what I am seeing here is that curmudgeons are either completely "in" or "out". They are either banned from consideration and completely marginalized, or they are in the catbird position of not allowing progress.

In a practical sense - curmudgeons don't like or want progress or change. No matter how they couch it as "holding you !@^* kids up to higher standards."

I think I need to take any such article in a completely different direction than I had considered originally... real curmudgeons are always in a power struggle of some kind. They aren't just the quaint guy in the figurative rocking chair talking patronizingly to younger people. They tend to be active participants - either being victimized through age discrimination, or victimizing co-workers and peers through negativity, negative judgements and sandbagging progress.

[codger]

TRexx wrote, "Since they don't have the technical chops to disagree, they end up leaving him alone. Since management doesn't have to fork over $$$$ to address audit issues, they love him. "

When I did a stint as an IT auditor, the people I reviewed often tried to BS me, assuming that I was some sort of accountant-turned-IT analyst. Boy were they ever surprised when I pulled the rug out from under them. That sort of game-playing turned out to be very costly to those who participated. Of course this was back in the days when audit findings meant something, and managers actually gave a $hit about the company (beyond their next bonus check). It was not a good tactic to lie or distort to the auditor. It could have career-threatening consequences. One Director's obfuscation to me and my audit questions cost him his highly paid, cushy job. It was great to watch the federal marshals walk him to the door. (1988 at a defense contractor.)

But then, everyone knows that all auditors are IT ignorant, just like all IT staff people are brilliant.

By the way, GB, I'm certain that I'm a curmudgeon, and proud of it. Many times, one of me turned out to actually be worth a whole bunch of shiny new rookies.

[The Gorn]

By the way, GB, I'm certain that I'm a curmudgeon, and proud of it. Many times, one of me turned out to actually be worth a whole bunch of shiny new   rookies.

It's not all about you.

I realized a few days ago when a member's technical interests were being discussed on this board (here, this one, and maybe this as examples) that I almost always take the following positions:

- Study the old thing before considering the new thing.
- Change may be painful, unnecessary or overrated.
- Why in the hell should I care about this new thing?

So I recognized that am a curmudgeon. I am "anti" new crap. I am not necessarily "pro" old stuff, but I always demand to know what the costs will be and why I or anyone else should pay them. I usually do this before I "permit" a discussion to go forward.

I even do this in real life. When I've had a younger developer preaching some new thing to me, I counter all assertions with demands to know why this is really something that we/I should do.

However, with that kind of attitude in business, nothing new happens. Notice also that technology business doesn't keep older guys around who presumably would be skeptical.

It always seems that it requires new "toys" to stimulate the invention and mercantile processes. In other words, if you don't have incessant new (but actually old) things being proposed, there is no buzz, no interest, no capital ventured, and little innovation.

Where would the IT industry be today, for instance, if "C", FORTRAN, Pascal, and COBOL were the only commercial languages in use? Or if PC operating systems stopped being replaced with DOS?

However, younger developers and those over-enthusiastic about BS new features can do lots of damage and make lots of mistakes.

I guess my bias is toward minimizing my own stress and aggravation - keeping with older stuff that is known and avoiding the pain of dealing with new stuff that is not ready for prime time.

I also believe (strongly, heart of hearts stuff) that the less experienced should be reined in with mentorship.

But there is really no room or place for mentorship in IT today. Mentorship is strongly discouraged and is enforced by laying off and not hiring the older guys. It's all about shoveling shiny new crap out the door.

Partly, "curmudgeonship" gets a bad name because it's self indulgent. It's the older guy telling the younger professional that the young guy doesn't know crap, but it's mainly a defense to establish beneficial power for the curmudgeon.

As a specific example, Origisaurus does this quite consistently on this board with allusions and direct statements. This is a statement of fact. For example, O. told Peter the other day that the latter was too infatuated with every new thing, but offered no specific detail other than a general "I know old guys who would eat your young guys for lunch."

In the final analysis, curmudgeonship is, as I see it, mentorship distorted and made negative by marginalization.

Marginalize all of the mentors with unemployment - effective banishment from IT - and you get inward-looking disdain toward all newcomers.

We have a good deal of this here on this board. I may perhaps be the author of some of it. I have been marginalized in my career, because I have said maybe 10 too many times (at least) in my career "stop the f*cking merry go round and REASON SOMETHING OUT." That gets painted as a bad attitude.

So, to the mainstream of the IT community, curmudgeons are grumpy assholes who should be forcibly shut up and not employed. To the more mature IT worker, being painted as a curmudgeon because he wants to see balance between risk and newness is insulting.

I have chosen to embrace the insult, and live it.

[codger]

I agree. I too "embrace the insult."

I suspect that many of us old (er) IT folks were raised in an environment where one of the primary objectives of any endeavor was that it be "bullet proof." It must also be "efficient." Both of these once worthwhile objectives are now considered quaint at best, retrograde at worst.

Like so many things that require analysis and quantification, it's not taught in public schools, and is looked upon with distrust, much as superstitious tribal peoples viewed things they did not understand.

I can live with it, but I really don't want my name associated with some of the Rube Goldberg-esque train wrecks that are passed off as engineering marvels today. I guess I have too much pride in my work product(s) to be successful in today's business climate.

[David Randolph]

It is vital to understand the requirements for a new technology to be able to be used in a business. It is also important to recognise trends and to see the value in them.

 

For example, the first company I worked for built POS systems. It was designed around the 8008 processor and the only way that they were able to get the performance they needed out of that technology was to design some specialized disk search hardware. All the code was written in assembler. They made a good living out of that technology and built up a bit of "barrier to entry". So when a startup tried to use a network of PC's to compete, the startup failed. The company never learned from that startup. They kept trying to build newer versions of their original idea. Guess what? The original company went under. Today, nobody uses that technology.

 

At some point, new technology and newer languages will overcome the "barrier to entry". It happened to the main frame. It happened to the minicomputer. It is happening to the PC. Sure, the older technology will have a place in the new world. But the new stuff will push our skills and expertise to the side.

 

As a curmudgeon, the task is not to completely block new technology, but to protect the company while it explores such new technology. Thus, it means that we need to identify the true issues with any new technology, identify the standards for "enterprise level" use of that technology, and allow freedom to explore. We need to be learning from other people's use of technology to see how we can benefit from it.

 

Also, we need to know - gut level know - that sales people sell on "sizzle" and expect us to deliver the steak. New technology is "sizzle". Thus, if we are going to oppose the sales team, know that we will be ushered out of the company. Our job is to show how to deliver steak and to make the case to upper management that this particular "cow" might be very expensive and suggest ways to find cheaper cows.

[appsdba]

Call me a fairly young curmudgeon and as a DBA it fits me well.
I have been more so now as dealing with off shore Indians at past few jobs and the need to use a firm hand when they want to push off bad SQL or flawed PL/SQL.

[Origisaurus]

Somewhat tangential.

I worked as a systems guy supporting systems used by a bunch of senior engineers (senior enough that the only exit was retirement) at Big Auto.  Their mission was to investigate claims of unsafe operation of cars.  And they did - went to crash scenes, measured, took pictures, analyzed.  They also did lab work on components that had allegedly caused crashes.

Sometimes they found stuff, and components were re-engineered and corrected in the field, mostly by service bulletins.  You never heard of this aspect because they caught and corrected them early on, before it became a Big Deal^tm.  Often the first NHTSA heard of a defect was when they got a letter (plus 50 or 100 pages of documentation, all lawyer-reviewed) from the Director (2 reports away from the CEO).

Ignoring the culture aspect, compare this with Toyota's fiasco.

If anyone at Toyota knows the cause(s) of the crashes and fatalities, top management isn't saying.  There are several possibilities of the causes that I (and auto industry guys) can think of that Toyota hasn't mentioned.  Meanwhile we get serial fairy tales, Toyota is losing billions, and the fat lady isn't ready to sing.

In this parable, the curmudgeons are the Big Auto engineers and their bosses taking nothing on faith but demanding facts and data, while the "others" are Toyota execs and maybe engineers hoping they could get away with it, because faking it worked in uni, didn't it?

[The Gorn]

It is vital to understand the requirements for a new technology to be able to be used in a business. It is also important to recognize trends and to see the value in them.

This relates somewhat to current challenges that I am facing with a co-worker.  The guy is great at identifying candidate technology and recommending it. But he has not earned any stripes on problem solving or creating new code or systems on our project yet. His interest seems to be devoted to "the new" and he seems to have little interest in understanding the (non sexy, proprietary, internal, no Slashdot bragging rights) nature of our current product code.

I believe that a key qualification for someone to be respected when they propose new technology is that they must establish their qualifications first with accomplishments.

They basically have to demonstrate that they already get their work done.

Most people on this board fit that standard neatly. When a person on this board says that he is interested in Android, I take that as a working professional looking to expand their repertoire to a green field.

With someone who doesn't seem to have delivered anything in sight, I may be curmudgeonly about such a proposal and press them on what they are going to do with it.

[Origisaurus]

Where would the IT industry be today, for instance, if "C", FORTRAN, Pascal, and COBOL were the only commercial languages in use? Or if PC operating systems stopped being replaced with DOS?

Language question first.  The answer is "object model".   Those "primitive" languages' object models were so rudimentary that most C++, etc. programmers wouldn't even recognize them as object models.  It's not about the syntactical constructs, it's about the object models and development environments.  "Languages" are collections of syntactical constructs, separate from development environments.  Object models are ways of insulating the programmer from the underlying data structures, thus sparing him/her from the brain-hurting task of understanding them.

There is no reason at all that a GUI IDE can't use the syntactical constructs of "C", FORTRAN, Pascal, or COBOL to implement logic within an O-O environment.

OS's.  I think you mean Windoze, not DOS.  DOS is an OS, began life as QDOS (quick and dirty operating system).  Windoze 3.1 was an obvious GUI layer over DOS 6.0, and later Windoze versions merely hide the fact that they are a presentation layer over an OS.

And now we have Windoze-like presentation layers over various *ix, which we all know is truly an OS.

[The Gorn]

OS's.  I think you mean Windoze, not DOS.  DOS is an OS, began life as QDOS (quick and dirty operating system).  Windoze 3.1 was an obvious GUI layer over DOS 6.0, and later Windoze versions merely hide the fact that they are a presentation layer over an OS.

And now we have Windoze-like presentation layers over various *ix, which we all know is truly an OS.

My overall point was that each of the early technical innovations I listed was probably defended vehemently by curmudgeons in their day.

I had many circular arguments with others, with myself on either side of the "use it & cherish it" or "dump it" line, over most of these things.

I used DOS as one example of a subject that would have elicited curmudgeon like judgenents.

In its time, DOS could handle the classes of applications that were thrown at PCs. My argument back then would go "but you can extend DOS with XXXX and YYYY and QQQQ at much less technical risk than going to Windows/Unix/OS/2." I really did argue that, and I believed it.

In reality, the PC and desktop software industry just wasn't going to grow much unless something that was more functional than DOS came along. Windows made PCs attractive to new users and enabled multitasking. And so it went.

My curmudgeon instincts made sense in terms of preserving that which was of value. They made no sense in terms of finding new markets that could be sustained.

[David Randolph]

There are two major issues with curmudgeontry. These are business issues and not technical.
1. Some systems need to have near perfect operations. I recently saw a letter to the editor where someone mentioned how simple the technology was on the moon rover "and it worked!". I snorted as I knew what the letter writer did not - I knew how much effort went into every line of code on that machine. It worked because it had gone through extreme levels of quality checking on both the design and the implementation. Systems like the back bone of the Internet need this kind of perfection.
2. Most business questions need a quick answer that is not necessarily a "completely correct" answer. A "good enough" answer is sufficient. Business decisions have to be made at the 85% knowledge level or they are being made too late.
What the new types of programming bring is the abillity to get to that 85% level at a lower cost. That is why they are useful. Much of software development fit that situation.
Besides, object oriented programming can be done in assembler. I've done it when the only languages I had available to me were Cobol and assembler.