Generation-X culture vs Boomer culture

[Trevor]

Well, boomers are their number one target. Even x-ers that may not do anything like that to each other or to Millennials may treat boomers that way for no other reason than sheer spite. It's hard to imagine how they could survive doing that to one another all the time, even if they do expect to get screwed.

Dealing with an X-er boss like that, I'd probably just keep my head down.

[Higgenbotham]

You say to him, "Don't forget to change the oil every 4,000 miles!"

[*] The incompetent Gen-Xer sees the suggestion to change oil as
"endlessly dissecting," to use Higgie's words, and is angry and
hostile at the suggestion. The incompetent Boomer sees it something
irrelevant or mistaken, and simply ignores it.

4. Things that fall into gray areas that can't be proven or disproven are dissected to death, with the Boomer claiming superior knowledge.

John, I read this stuff and just shake my head. It's impossible.

The way it works is the Boomer boss tells the Xer employee to change the oil every 3-5,000 miles. In most cases, the Xer already knows this, but lets it roll. The Xer, being a concrete and practical individual takes the instruction at face value and changes the oil within that range.

About a year later, let's say, the Xer sits down with the Boomer boss for an evaluation. The Boomer boss says, you know, you've been changing the oil every 3,200 miles and that's overkill. Hacker, over in the other department, is changing his every 4,500 miles and is saving his department a lot of money.

The Xer then says, oh, well, I thought maybe the small additional cost of changing the oil more frequently might pay out in longer engine life. The Boomer boss says, no, that makes no difference and Hacker is really the superior employee because he is getting it right.

The Xer then says, oh, OK, when you gave me that range I thought anything within it would be acceptable as long as it got done. The Boomer says, well, really it is but you need to keep in mind that the company's money is valuable and that it's best to aim for the higher end of the range so as to make our department look good next year.

[John]

Dear Higgie,

> John, I read this stuff and just shake my head. It's impossible.

> The way it works is the Boomer boss tells the Xer employee to
> change the oil every 3-5,000 miles. In most cases, the Xer already
> knows this, but lets it roll. The Xer, being a concrete and
> practical individual takes the instruction at face value and
> changes the oil within that range.

> About a year later, let's say, the Xer sits down with the Boomer
> boss for an evaluation. The Boomer boss says, you know, you've
> been changing the oil every 3,200 miles and that's
> overkill. Hacker, over in the other department, is changing his
> every 4,500 miles and is saving his department a lot of money.

> The Xer then sayd, oh, well I thought maybe the small additional
> cost of changing the oil more frequently might pay out in longer
> engine life. The Boomer boss says, no, that makes no difference
> and Hacker is really the superior employee because he is getting
> it right.

> The Xer then says, oh, OK, when you gave me that range I thought
> anything within it would be acceptable as long as it got done. The
> Boomer says, well, really it is but you need to keep in mind that
> the company's money is valuable and that it's best to aim for the
> higher end of the range so as to make our department look good
> next year.

This is an interesting example, but I disagree that this is
characteristic of Boomers or Gen-Xers. This is simply a situation
where the boss was "looking for reasons" to screw the employee, and
found one. This conversation could equally happen if the roles of
Gen-Xer and Boomer are reversed.

You yourself have described the elements of the Boomer personality:

> When Xers call Boomers arrogant, it's because they don't listen;
> they instead ignore, dismiss, or endlessly dissect anything that
> is counter to their beliefs.

To emphasize this, you're identified four elements:

• They don't listen
• They ignore
• The dismiss
• They endlessly dissect

(Am I endlessly dissecting right now in this post?)

The scenario that you've given doesn't contain any of these four
elements, so it's not really an example of Boomer/Xer interaction.

John

[Higgenbotham]

John,

The Boomer manager is truly not trying to screw the Xer employee by saying this, in my experience. What likely happened is there was a meeting and the Boomer got chewed out by a superior for generally overspending is his department. He is simply responding to that and part of that response will be endless minutia over nickels and dimes whereas previously dollars didn't matter.

Onto the specific example. The point the Xer wants covered in the evaluation is whether the concrete instruction was followed. Did the oil get changed every 3-5,000 miles as requested or didn't it? Period. It's a 2 second discussion. The Xer does not want to get into a protracted conversation wherein the optimal miles within the range are discussed at length (endlessly dissected) when there is no agreed upon or known optimal mileage. But the Boomer boss in many cases will want to have that conversation and claim superior knowledge in that gray area, knowledge which simply doesn't exist.

[John]

John,
> The Boomer manager is truly not trying to screw the Xer employee
> by saying this, in my experience. What likely happened is there
> was a meeting and the Boomer got chewed out by a superior for
> generally overspending is his department. He is simply responding
> to that and part of that response will be endless minutia over
> nickels and dimes whereas previously dollars didn't matter.

> Onto the specific example. The point the Xer wants covered in the
> evaluation is whether the concrete instruction was followed. Did
> the oil get changed every 3-5,000 miles as requested or didn't it?
> Period. It's a 2 second discussion. The Xer does not want to get
> into a protracted conversation wherein the optimal miles within
> the range are discussed at length (endlessly dissected) when there
> is no agreed upon or known optimal mileage. But the Boomer boss
> in many cases will want to have that conversation and claim
> superior knowledge in that gray area, knowledge which simply
> doesn't exist.

OK, with that explanation it makes sense.

John

[Trevor]

I have to admit, though, virtually nobody I know changes their oil as often as they should. We delay it far too long.

I remember in Strauss and Howe's theory that during the last "High", the Lost Generation gave up comfort and security in order to help younger generations. I'm wondering if part of that was out of a sense of guilt, because of what some of them had done that led to the Great Depression.

[Higgenbotham]

John,

Back when, in a workplace setting, a young female Boomer got promoted to a Director position. Her immediate subordinate was a Silent, and the Silent was over all the front line supervisors. The female Boomer was a psychopath and the Silent was a terrific manager. The Silent acted as a buffer between the female Boomer's tirades and the staff. He maintained a calm and pleasant atmosphere. He became severely alcoholic. He retired in 1996 or so.

He was replaced by a Boomer and that was when all hell broke loose. The Boomer and Xer staff people would say, "Now that (the Silent) is gone, ALL shit rolls downhill."

[John]

Yeah, we're all a hell of a lot worse off with the Silents gone.

John

[Trevor]

I know; they wouldn't have been stupid enough to create something like the Dot-Com bubble. I suppose in order to truly learn a lesson, you have to have a personal experience.

[John]

*** Federal Aviation Administration: Putting the public in danger

I've been a software engineer for decades, but I've never seen
anything as bizarre as this story, where two Gen-Xers actually risked
putting the public in danger. This story illustrates the problem that
Boomers face with Gen-Xers on many levels, so I want to dwell on it.
Since alleged crimes were committed, I'm only going to identify the
Gen-Xers as "Zeta" and "Epsilon".

I worked for three years as a subcontractor through CSC to the Federal
Aviation Administration (FAA) on a software product called Traffic
Situation Display (TSD) that is widely used by aviation officials
throughout the country. The program displays a map of the U.S. with
tiny little red dots indicating in real time the locations of all
planes in flight, with overlays indicating such things as rain storms
and wind conditions. The user interface is very powerful, allowing
the authorized user to drill down and get information about any flight
or group of flights, detect overcrowding situations, and reroute or
reschedule flights, all in real time.

The product is highly networked, and communicates with dozens of
servers around the country. It sends requests over the network, and
receives not only replies to specific requests, but also continuous
data feeds on such things as flight and weather information. It's
these numerous data feeds that became an issue.

Zeta and Epsilon had been working on the product for over ten years
when I joined the team.

My philosophy as a Senior Software Engineer for decades was that any
data used as input to a software system should be handled gracefully
by the software. This means that bad input data would be validated,
with appropriate action taken if the data is not valid.

As I started in TSD software development, it became clear to me that
no validation checking was being done by TSD, and that there were many
places where bad data would crash TSD. Also, this problem became
significantly worse during the time I worked on the project, since
many new data feeds and networking threads were being added. So in
all the new functionality that I developed, and in all the many bug
fixes that I implemented, I always put in plenty of data validity
checking.

This is analogous to building a house and putting in fuse boxes, so
that an electrical overload won't burn down the house. This is basic
in Software Engineering principles. You protect your software product
from bad data. This is what I had done my entire career, and in the
good ol' days before Gen-Xers took over, this was considered a GOOD
thing.

But this greatly infuriated the Gen-Xers Zeta and Epsilon, who began
complaining that I wasn't "adapting" to their style of programming,
which was to ignore error and validity checking, and just let TSD
crash when it received bad data.

If you think that this is bizarre then believe me, that's the
least of it.

After about a year, I fixed a bug in Zeta's code that he had been
unable to fix himself, though he'd been trying to find it for two
months. It was a serious bug, and I found it by designing and
implementing some analysis software that isolated it automatically.
This completely infuriated Zeta and Epsilon.

That's when they decided to take revenge. They particularly targeted
all the error and validity checking code that I had implemented, and
removed all of it over time.

I've been a software engineer for decades. I've worked for dozens of
clients and employers, and I've helped bring hundreds of software
projects to completion. I've worked alone, in small groups, in large
groups, as project leader, as project follower. You name it, and I've
done it.

But I have NEVER seen anything like this -- programmers wilfully
deleting another programmer's code out of revenge, especially validity
checking code. I was absolutely flabbergasted that this could
possibly go on, and I became even more astonished as it became clear
that they were going to get away with it.

I wrote numerous memos to my manager describing what was going on,
documenting new bugs and problems that they were causing. I wanted
everything to be "on the record." Furthermore, I documented numerous
lies that Zeta and Epsilon were telling on a daily basis, as well as
the massive amounts of information that they were withholding from
their management. I wrote that if they had tried this at many of the
companies I'd worked at, especially the financial institutions, then
there would be firings and possibly arrests.

I'm actually surprised that I wasn't fired, though I was grateful that
I wasn't, despite the hostile work environment. But despite numerous
memos and verbal warnings to my managers, they simply didn't believe
me. The programming language C++ was as inscrutable to them as
Sanskrit, so they were unable personally to evaluate what I was
saying, and they chose to believe Zeta and Epsilon, as they'd been on
the project much longer than I had.

Since Zeta and Epsilon were able to get away with this for well over a
year, a lot of the code in the final release of TSD is a pile of crap,
with many problems. With regard to data feeds, TSD is completely
unprotected, since Zeta and Epsilon systematically deleted all the
data validity checking code in the system.

TSD's code is like a house where the electrician had strung wires
every which way, with no logic or fuse boxes. All the light switches
work, but if you plug in an extra appliance, then the house burns
down. And every time that I added a "fuse box," Zeta and Epsilon
deleted it.

To show how farcical this became, about two months before I left the
project, one of my managers complained to me that a couple of features
of "replay" that had been assigned to me months earlier were not
working. The following is the memo that I wrote in reply, paraphrased
and simplified for a non-technical audience:

"These are my comments on the two bugs that you
assigned to me on Friday.

The first issue is working fine on my workstation. We've now been
through several iterations of this kind of thing. In each case,
it's always been that Epsilon deleted my code, or Epsilon ignored
my code. I have no idea what the problem is this time. All I
know is that this is working correctly on my workstation, and HAS
BEEN WORKING CORRECTLY FOR MONTHS.

The second problem says that CIWS (the precipitation weather
display) doesn't work with replay.

CIWS used to work with replay several months ago, but Epsilon
deleted my code.

You told me not to bother with it, because "there's no point,
since would just be chasing my own tail."

I sent you an e-mail message on this subject several months ago.
Obviously, this e-mail message was simply ignored. For your
convenience, here's the text of what I wrote to you:

"Three of the bugs had already been fixed, but the
fixes had apparently been ignored.

There's still an outstanding issue that replay doesn't yet
work with CIWS, since at one point you told me that "there's
no point, since would just be chasing my own tail." I did
once get replay working for CIWS, but that code was all
deleted by Epsilon and Zeta, along with the code that prevents
TSD crashes by validating shared memory.

In order to implement replay with CIWS, I'll need to modify
Epsilon's and Zeta's code. There's no point to my doing this,
if my modifications are simply going to be ignored and
deleted. Therefore, Epsilon's and Zeta's permission will be
required for that functionality to be
implemented."

First, it's worth reminding you that Epsilon and Zeta have deleted
all the error checking and validation code that I put in to keep
TSD stable. This has all been completely deleted for absolutely
no reason whatsoever.

As for replay working with CIWS, my code was working correctly
months ago. But Epsilon's code has changed since then. I've
reviewed Epsilon's code, and for replay to work with CIWS, I would
have to modify and restructure sections of Epsilon's code, and
repair some design issues.

That would be no problem at all for me, though it would take a few
days. I'm perfectly willing to do that if you want, but my
experience is that if I fix Epsilon's code, then all I get for my
trouble is to be crapped on by you and Epsilon. Decency, honesty,
competency and professionalism count for absolutely nothing in
this group.

So tell me what you want me to do, but if you want me to
modify Epsilon's code, then please make sure that he won't simply
delete it, including whatever error and validity checking code
that I, as a professional software engineer, consider to be
necessary for the implementation's stability."

Obviously I had become quite angry at the hostile work environment,
and was no longer shy about making my feelings known. Incredibly, my
managers still didn't believe me, and completely ignored this memo
again, as well as the verbal warnings I gave. They believed that I
was a Boomer making stuff up, that I didn't know what I was talking
about, etc. etc.

Finally, at the very last minute before project freeze, my manager
told me to get "replay with CIWS" working, and that all I had to
do was change one line of code.

This moment encapsulates so much that's wrong with the Gen-X culture
(though this manager was a Silent, not a Gen-Xer, but he believed
everything that the Gen-Xers told him). He was so contemptuous of me,
that he simply ignored everything I told him, and decided that it was
simply crap. And this was the moment that he was going to prove that
I was full of crap, by telling me that all I had to do was change
one line of code, and that everything I'd written in my previous
memos was a lie.

So I explained to him that actually getting "replay with CIWS" working
was actually a very big task, that I'd had it working several months
earlier, but that Epsilon had deleted my code, as I had explained
in several memos. Furthermore, since other things had changed,
it would now take several days to re-implement "replay with
CIWS."

At that, my manager went scurrying down to Epsilon's office, probably
to tell him just to change the line of code himself. Of course,
Epsilon was completely clueless and had no idea how to get "replay
with CIWS" working, and had to admit that he'd been lying all along.

So the manager came back to me and told me to start working on it.
It took me about a week, and it screwed up the project schedules,
when it could have been taken care of much earlier.

This is just one more example of how destructive and nihilistic
the Gen-X culture is.

But even now, as incredible as the story is so far, there are still
more incredible events to be told. If you think it's unbelievable
so far, wait till you read this.

One day, about three weeks before I left the project, I brought up TSD
on my workstation, and it crashed immediately. It turned out that the
same thing was happening to everyone on the floor. I entered a
debugging session, and determined that the crash was caused by bad
lightning data (the lightning component of the CIWS weather data feed)
that was being sent to it. The problem was that the TSD code
contained no validation checking for the lightning data at all, and
receiving bad data caused TSD to crash.

Now suppose that TSD is installed in centers across the country, and
someone sends out bad lightning data, or bad data in any of the other
numerous data feeds. The result would be that ALL TSDs across the
country would crash at the same time, possibly causing an airline
crisis that might put lives in danger. And this was not a far-fetched
scenario, because it had already happened within our work group. It
could happen at any time in the field -- in a couple of months, or the
next year, or the year after that.

The situation was made MUCH WORSE because the FAA was moving the TSD
project to a group in New Jersey, where no one had the vaguest clue
how TSD works. Thus, if a crisis DID occur, the New Jersey group
would look like idiots.

If such a crisis occurred, the blame would fall squarely on Zeta and
Epsilon. These jackasses were not simply negligent in not validating
input data; they wilfully destroyed government property, repeatedly
lying to their management about it, and in so doing put the lives of
the public in danger. They could be criminally prosecuted, and in my
opinion that would be well deserved.

If I had been able to do the job that I was hired to do, then TSD
would be a very solid product. Every data feed and every data
interface would have a rock-solid implementation, with complete data
validation, and the ability to withstand anything thrown at it.

Instead, when I left, it was a shoddy, fragile product that cannot
withstand stress, and in some scenarios may be a danger to the public.
As a professional Software Engineer with decades of experience, I
cannot find the words to express how sickened and revolted I was at
this situation. It almost made me want to vomit.

One of the reasons that I went into so much detail about this is
because TSD may well go into production use around the country
with these bugs unfixed.

My manager apologized to me for not believing me for a year and
a half, saying that Zeta and Epsilon had committed some other
infractions with other people, which led to the revelation that
everything I had complained about was completely true.

But he also told me this: The FAA had run out of funding, and would
not fund fixing the problems I'd identified unless an actual crisis
occurred.

So I'm hoping that someone responsible from the FAA sees this
story, and takes steps to make sure that these bugs in TSD are
fixed. It could be very dangerous to the public if suddenly
all the TSDs across the country all crashed, all at once.

John