Balderdash and the Flowchart

Where I own up to doing something really stupid (back in 1980)

Image by Clker-Free-Vector-Images on Pixabay

Can’t read the full story because you’re not a member of Medium yet? Read it here.

We were all playing Balderdash one night and we’d run out of scoring sheets, so we photocopied more of them and then we had to cut them up (because there was more than one on each sheet of paper).

And as so often happens, that one activity triggered a memory that isn’t even vaguely related to playing the game.

In this case, it was probably the cutting activity that did it — even though my story did not involve scissors or cutting at all.

The flowchart

I recalled a time in the IT department at the insurance company I used to work for (it was probably around 1980) when I was given the task of drawing a flowchart of an entire system — the one that handled general insurance claims (i.e., not life, marine, or motor).

It took me quite a while because there were a large number of programs in that system.

Once I’d finished, I was told to send them off to a retired man they occasionally employed who converted my rough and ready flowchart into a work of art.

He drew the entire thing out by hand and it covered over a dozen sheets of A3 paper.

I’m assuming he must have been a draftsman because it was beautifully crafted.

Anyway, my next task was to use adhesive tape to put them all together before putting it up on the wall as a reference for the entire team.

And that’s when my young, dumbass self made a huge mistake.

Instead of sending the originals off to be photocopied so I could stick the copies together and retain the original master documents, like a smart person would, I just went ahead and used the only copy of this immaculate flowchart that existed.

Not only that, I did a horrible job of sticking the sheets together, but that’s a whole other story.

Did I learn anything from that experience?

Well, my project leader never asked me to do anything similar ever again, so there’s that. 😄

Seriously, though, I won’t say that I never acted without thinking after that incident.

But I was more careful — most of the time.

I once had a job at home where I needed to hang five pictures alongside the stairs, and I needed them to be equally spaced both horizontally and vertically.

So I took the old adage of measure twice, cut once to extremes.

I don’t remember how many times I measured and how many sets of calculations I did, but I knew that if I screwed the job up, my wife would have been furious with me.

So I kept on measuring and calculating until I was positive I’d got the numbers all correct.

And it paid off — it was a beautiful job, even if I say so myself.

But I should have known better

The day I started training school at that insurance company, as a trainee programmer, we were each given a sheet with about 20 instructions on it.

We were told to read the instructions and then follow them.

Three of the six in that class, including myself, made our way to the end of the list, doing all (well, most, as you’ll soon see) of the activities we came across. The other three people didn’t seem to be doing anything, which was puzzling.

It was only when we three idiots were told that the first instruction was to read all the instructions, and the second one was to tell us to stop, that we realized what we’d done.

The exercise was an object lesson in thinking about the entire job first before taking your first step.

I was embarrassed that I’d fallen for it, and while I didn’t vow to never do that again, it has stuck with me. (This happened in the summer of 1979.)

Project development

This is why projects are developed in stages: you don’t move on to the next stage until everyone agrees that the current stage accurately reflects what is required.

For example, you don’t start designing a computer system until you understand and agree what the system is intended to do.

And you don’t start writing any program code until you’ve agreed that the design meets the agreed requirements.

And so on.

It’s why we have the saying, “look before you leap”. And it’s obvious. Except it wasn’t to me, for reasons I do not understand.

After all, it’s not that I’m unintelligent (or so I’m told).

The good news is that when I start a project for myself (e.g., Medium Bookmark Manager), I do follow the basic project development stages.

As an entrepreneur, it’s good sometimes not to have to follow all of the many rules that companies stipulate — but there are some that are simply common sense.

Having said that, I did skip a vital stage with my previous project, Holiday Reminder Alerts, as I wrote about here:

[embed]Two Reasons My Latest Big Project Failed And other contributory factorsmedium.com

In short, I made the mistake of assuming that a tool I wanted would be useful to others, and went ahead with the project without validating its demand first.

(I’m actually in the process of relaunching that product now, so watch out for an announcement — it’s something most businesses could use.)

The problem is, being an entrepreneur means you have to do a lot of juggling (e.g., of priorities, or unexpected events), and when you’re the only person who can do those jobs, something has to give.

But that’s no excuse for omitting an entire stage in the process.

Will I ever learn my lesson?

I hope so, but I have many challenges that make life difficult, including ADHD, aphantasia, being on the (lower end of the) autism spectrum, almost constant headaches, as well as random calls on my time that add to the existing list of distractions.

If those too sounds like excuses, then maybe they are. It may just be that I’m not as smart as some people think. It might even be that it’s not a case of intelligence but something else. Or it might be that I am secretly sabotaging myself, even though that makes no sense.

So, this is both a note to myself as well as a case of “do as I say and not as I do”, but as a general rule, the lesson is to, as I said earlier, look before you leap.