IBI-063-Data Engineering

0
59

Note: You can listen to the blog post on the video or read the blog post.

Hello and Welcome.

I am Esther.

I am Peters A I Assistant to create voice overs.

I will simply read Peters blog posts, so that you have a choice of reading the blog post, or listening to my voice.

Hello and welcome Gentlemen.

As I have recently announced on my channel.

I will be doing some opinion pieces and response videos.

In the world of social media it is very well understood that response videos and opinion pieces are far more widely viewed than straight up factual videos that are educational.

Personally, I think this is sad, but it is what it is.

This blog post is my opinion piece on the now widespread use of the term data engineer.

The men in my industry segment made it clear they did not wish to hear what I have to say in the early part of this century.

The men in my industry segment decided they would rather listen to the vendors than listen to me.

And now we are twenty years later.

The men in my industry segment are a laughing stock to the business side of the house.

There is no other way to characterize the data warehousing and business intelligence space today other than a laughing stock.

And gentlemen?

It is not our industry that is the laughing stock.

It is the men in our industry who are the laughing stock of the men on the business side of the house.

It staggers me that men are so willing to be a laughing stock.

But men most certainly are willing to be a laughing stock in their profession.

I was recently in a meeting with the chief executive officer of a small company.

She actually asked me why my young peers are so ignorant and so arrogant.

I explained to her that they sincerely believe they are more important to the business than the real business people.

I explained to her that they forget they are the servants of the business.

She asked me about the history of this given how old I am.

I explained that it is a phenomenon across the western world that has been ongoing since the nineties.

I told her that I had objected and tried to teach technology people to be more humble but my colleagues and I were not listened to.

She thanked me for my honest response.

Today I wish to forward an unpopular opinion in this public post.

The term data engineer is laughable.

This is like calling Katy Perry an astronaut because of her 4 minute trip into lower space.

Please allow me to share with you a little bit of history of engineering and engineers.

In Roman times most people could not read or write or do anything more than basic mathematics.

So if a village wanted a bridge built for whatever reason they had to hire and pay a bridge builder.

The bridge had to be built and paid for before the first horse and cart crossed it.

So how did villagers decide which bridge builder to buy the service of having a bridge built from?

And how were they to know they were not being ripped off by a charlatan?

The villagers came up with a test.

That test was that when the bridge was finished, and before final payment was made, they would put rocks in carts and have those carts pulled across the bridge by oxen.

They would load up the bridge with the maximum load the bridge builder said the bridge could hold.

The trick was that that the bridge builder was required to stand under the bridge while this stress test of the bridge was performed.

Of course, if the bridge failed the bridge builder would die.

This was a good way of making sure that charlatan bridge builders would not volunteer to build the bridge.

When you had to guarantee the quality of your work with your life you make sure you know what you are doing.

It’s not a complicated idea.

As much as it will upset people in the data warehousing area?

Please allow me to put this question.

How many self described data engineers would stand under the figurative bridge of their data products where the price of a failure in their data product was paid for with their life?

Of course, we all know the answer to that question is none.

There is no person in the data space, including me, who would guarantee their data products with their life.

Gentlemen.

One of my uncles was a builder.

My very first job outside my home was to stand with my cousin at his fathers building sites and fetch the tools from the men’s trucks when they called for us to fetch the tool.

In this way the builders did not have to climb down from where they were working to fetch a tool that had become necessary to use.

In this way I knew the names and uses of all the tools the builders used by the time I was eight years old.

And yes, one day I was sent on my push bike to the local hardware store to buy a long weight.

Every little boy I knew who helped out the men on building sites were sent on their push bike to buy a long weight.

It was a right of passage for us boys to be sent to buy a long weight.

So right from the time I was a small boy I understood the difference between engineering and building.

I knew that if my uncle and his fellow builders did not build the houses properly someone might be killed when it collapsed.

This is very much more so the case when the building is a skyscraper, when the building is a major bridge, when the building is a long tunnel.

Consider the jet airplane, for example a Boeing seven four seven.

They travel along at one thousand kilometres per hour at forty thousand feet over very wide oceans with no landing strip in the case of needing a reboot.

Skyscrapers, major bridges, long tunnels and seven four seven airplanes all have one thing in common.

They are designed by engineers.

The cost of a design flaw can be hundreds, or even thousands, of lives.

Engineers do their work to a level of quality that they would quite happily stand under the bridge, or bet their life on their product, because they know it’s not going to fail.

Self described data engineers will not stand by their product because they know their products fail regularly.

Self described data engineers are trying to appropriate the respect and the credibility of real engineers, earned over thousands of years, without putting in the work to earn the right to use the title.

This is the same as men who claim to have been in the armed services and served in combat zones when they have done no such thing.

Stolen valour and stolen credibility and stolen respectability are all similar things.

They are all bad in my opinion.

One of the many reasons that these are bad things is that they demean and devalue those men who actually did earn those titles by their actions.

Please allow me to give you an example from my own career.

I was an “IBM Systems Engineer” in the nineteen ninety one to nineteen ninety four period.

To earn the title “Systems Engineer” this is what I had to do.

Firstly, I was already the youngest System Architect ever in IBM Australia.

I was running the technical side of a four million US dollar four hundred work month development project in nineteen eighty nine at the age of twenty five.

It was to be implemented into twenty IBM countries including Japan, Australia and Canada.

It was the system that calculated prices for IBM products.

I started software development in nineteen eighty two as an eighteen year old trainee.

I was the best trainee who ever came into IBM in terms of work delivered and then promotions and pay-rises.

I was the “rising star” in IBM Australia’s IT shop.

A lot of older guys actually protested my promotion to be the System Architect for that project in January nineteen eighty nine.

Even so, in nineteen ninety, my transition year, I had to go to “IBM System Engineering School” and start with the trainees.

For each class this included having to master manuals in the region of three thousand pages.

We would have an entry exam on the three thousand pages of manuals where you had to get seventy percent or get kicked out.

We then did three weeks of extremely intense “school” where about thirty percent of the students dropped out and resigned from IBM.

Their response was usually along the lines of.

Quote.

I did not realize this is what I signed up for at IBM, I am out.

End quote.

The failure rate was much higher for the ladies.

Many of the ladies would simply break down and cry realizing that they would never be able to do the job they had dreamed of.

For some reason the ladies who wanted to be IBM Systems Engineers did not realize that they would not simply be passed through the system as quota women.

Making sure IBM computers ran faultlessly was still considered important at IBM in nineteen ninety.

I did midrange school and large systems school.

This was despite having never even seen an AS four hundred at the time.

I had the great advantage of having a photographic memory.

In my midrange entry exam I only got seventy two percent.

That is how hard these exams were.

I got one hundred percent on the mainframe entry exam.

Trainees then did months of branch work understudying to your mentor before you would be allowed to even speak to a customer.

That would get you to “associate” level in 2 years as a new hire.

I was fast tracked to “associate” level.

Then I had to spend nineteen ninety two and nineteen ninety three working as an “associate” before I was finally promoted to full “engineer” level in December nineteen ninety three for my efforts that year.

As an IBM Systems Engineer it was your job to help the customers configure the IBM hardware and software for maximum performance so that their investment in our hardware gained the maximum return on that investment.

I note that reliability was not considered a factor in as much as our mainframes were expected to be one hundred percent reliable.

Just like an airplane.

It was a very tough and demanding job.

It was FAR harder than just being the youngest System Architect in the country running a four million US dollar four hundred work month development project at the age of twenty five.

The expectations and hours were off the charts.

Less than half the people who started ever made it to Associate level. They left for less stressful jobs.

I made a comment just today that in nineteen ninety three I was getting home from work at around one in the morning.

I would put on my jogging gear and go for a one hour jog in my neighborhood to get some exercise.

Then I would make myself a sandwich and have a shower and get to bed around three in the morning.

Then I would get up at six in the morning and do it all again.

That was the only time I could find to go and get my exercise to keep up my energy and well being.

That is what it was like some times to be an IBM Systems Engineer.

Mistakes could end your career at IBM as a Systems Engineer.

Please allow me to give you an example.

In my very first IBM customer account I made a mistake.

This was in April nineteen ninety one.

I put some software on the development mainframe that talked to DB two.

But the communications controllers that we attached our data analysis server to were attached to the production mainframe.

So the development mainframe had to send data via the production mainframe to the DB 2 gateway on a Local Area Network server.

There is a parameter on the development mainframe in the Virtual Telecommunications Access Method software called V PACING.

This parameter defaults to zero.

This parameter had to be set to one or the production mainframe would crash.

There was no mention of this parameter in the manuals for the software I was implementing.

So I did not make the change.

As an IBM systems engineer one of the rules was that you do not change any configuration parameter unless you knew that it had to be changed.

My mistake had the effect of crashing the production mainframe, twice, within an hour.

I had to go through a very detailed investigation and then a tribunal hearing organized by the customer.

The customer System Network Architect expert testified on my behalf.

He said that there was no mention that this parameter must be set to one in any manual that I could reasonably be expected to have read.

He testified that even a man with five years experience in communications software might have made the same mistake.

He recommended to the tribunal that I should be found guilty of causing the outages, but that I should not be punished in any way as there was no way for me to know I was making a mistake.

If his opinion had been otherwise I would have lost my job.

I had a wife and three children to feed at that time and there was a recession.

So I was very thankful for this mans honest testimony.

That is what it looked like to be an “IBM Systems Engineer” at that time.

One mistake could end your career.

You were held accountable for everything you did.

How many self described data engineers would accept that their products must have one hundred percent up time and that any mistake in the products or any outages in the availability of their products would result in their termination without a reference?

None.

Absolutely none.

This is an opinion piece.

My opinion is this.

No man should use the word Engineer in his professional biography unless he is willing to be punished by losing his job, without a reference, if he makes a mistake that he should not have made and could have avoided with more careful application of his skills.

If a man is not willing to be terminated from his job after being found guilty of making a mistake he could have avoided by an internal tribunal?

He is no engineer.

He is something else.

Perhaps he is a programmer.

Perhaps he is an administrator.

But he is not an engineer.

Not even close.

That is my opinion.

If you have a different opinion?

You know what the comments section is for as well as I do.

Please feel free to share your opinions in the comments section.

And with that?

I hope you found this blog post interesting and informative.

Thank you very much for your time and attention.

I really appreciate that.

Best Regards.

Esther.

Peters A I Assistant.

Carphone Warehouse Reference Video:

Previous articleIBI-060-Open Letter White Disenfranchised Men
Next articleIBI-064-My Audio Resume
Peter Nolan
Peter Nolan is one of the worlds leading thought leaders in Business Intelligence. Across his 34+ years in BI Peter has consistently invented new and innovative ways of designing and building data warehouses. SeETL now stands alone as the worlds most cost effective data warehouse development tool.