Coding is a very complicated job, especially for non-techie folks.

So what happens when a coder is forced to teach somebody else what they do?

In this story you’re about to learn exactly that!

Let’s take a look!

“Teach him how to do your job”, Okay Boss!

To keep it short, 15 years ago and some change, I worked for a local computer programming company that made automation software.

Our company got bought out by a bigger national company, and after the dust settled, corporate decided they were going to send “a liaison” down to our local office to “learn how you do things to be a better bridge between offices.”

Aka, “Hey new hires, teach our guy how to do your job, so we can let 3/4’s of you go before next quarter.”

Now, here comes the liaison guy.

None of us were happy about that, but our new corporate overlords had spoken.

A month or so later, here’s our “liaison” fellow all ready to go.

“So, show me the interface!” he said.

Oh, thats when we all stopped, looked at each other, and grinned.

It’s almost impossible to explain everything in such a short period.

For you see, the reason it took us so long to bring new people up to speed is that we didn’t “configure” new projects. “Configure” in this corporate speak meant “Go check off the boxes in an interface until it does what you want.”

Noooo, my good friends, we coded everything by hand.

Our main program accepted straight up VB files. Not even scripts, full on files, and our new friend here was NOT a programmer. At all.

The guy didn’t know a for loop from a bubble sort.

Although they didn’t want to, they had to comply.

So, as we were instructed, we started walking him through our code.

“Here’s our X policy. It’s the most common one we use, and is about 1,500 lines of code in it’s base form…”

“Didn’t you guys say you had some default policies you worked from?”

“Oh yeah, but they end up being more trouble trying to customize than it is to just write the entire thing from scratch. So up here is where we’re declaring our global variables…”

Poor guy couldn’t keep up with all the technical discussions.

To our friend’s credit, he tried. Oh, he tried for DAYS.

And every time we thought he was about to figure something out, we intentionally switched him up to an even worse one.

We hired requiring a computer science degree, 6 months of on-site gearing up, and another 6 months of shadowing before we would let ANYONE handle a project on their own.

This poor guy got the full year’s worth of training in a week.

The liaison officer gave up eventually.

To his credit, on his last day, he flat out told us he was sent down to learn how to replace us, but that he was going to tell them that we were doing a great job, and if anything, our timeframes were surprisingly short given what we were doing.

We ran that department for a good 5 years before the inevitable revolving door of upper management decided to bring in a new “easier-to-use” suite.

People are STILL kvetching about “Man I miss X. It could have done this in half the time…” and instead of a 5-man team upkeeping everything, we have multiple departments that still can’t manage to fix a broken image link in the new stuff 10 years later.

Here’s how the people on the Internet reacted to this story.

Yup, it looks like it.

It’s not a good idea after all.

Thumbs up to the liaison guy for trying.

When all they see are people behind the computer…

Real programmers know that this isn’t possible.

Why fix something that isn’t broken?

Poor liaison!

If you liked that post, check out this one about an employee that got revenge on HR when they refused to reimburse his travel.