Demo OK

Demonstrating what I want to do next.

DEMO OK” is a phrase that has a special meaning amongst my circle of BCIT friends.

Of which, the majority of them went on to become software engineers, operations engineers or security analysts. While I initially thought I wanted to go down these paths as well, my experiences in my first few jobs after graduation were far from positive and led me to believe the opposite. In fact, most of them left me doubting whether I was good enough to become an engineer, and had me questioning if building things was what I really wanted to do with my life.

And so, I put engineering on the back-burner and continued to do more soul searching. I didn’t think those words would ever have an impact on me as much as they did in the context of school. However, just recently I had a brush with that phrase which had the same effect of helping validate my efforts and in turn, helped me determine what I want to do next

“Demo Ok” can be used for multiple occasions usually in a positive context. Whether it’s actually completing a good demonstration, achieving something new or explaining that a date went well; its our equivalent of a “thumbs up”.

The meaning behind this idiom originates from a specific instructor we had during our under-grad, whose lessons affected me recently this past week when I did my first code demo at work.

Our core networking and security instructor during our degree was one that I would consider pretty hardcore. He’d studied and worked in network / systems engineering right at the cusp of it’s boom, and was someone that’d walked the walk and had the t-shirts to prove it. While his delivery of material might have sometimes left something to be desired, what I found quite enjoyable was how he had a story or anecdote from his life for almost every topic — such as when discussing microwave links and telling us the story about how one of the techs he knew stepped in between two dishes and got vaporized… to drive home that you should always confirm that the power is off.

Safe to say, having almost seen it all, he had very high expectations for his students — especially since we were going into cyber security. As an electrical engineer originally by trade, he went on about how other engineering vocations had certain standards to hold the title (and wear the ring), and because signing off as say, a structural engineer, carried certain legal implications. For example, signing off plans as the principle engineer on a project like a bridge, would mean that you are signing off as having done a thorough assessment of its integrity and ability to remain safe even at X times the regular load and conditions. It was ones literal seal of approval, and has some relation to the story / significance behind the Engineer’s Ring (or Iron Ring in Canada).

He then noted to contrast, that due to the fast evolving nature of our field (and the de-regulated nature of the internet and software medium in general) that it is not possible to do the same for software engineers — but that we as software engineers should still aim to carry out our duties with the same high standards for ourselves, especially when dealing with cyber security.

Due to this, expectations were high for our projects with multiple hurdles to overcome in order to get a pass.

Problem statements, finite state machines, UML diagrams and psuedocode — these were some of the minimum requirements for submitting an assignment and required showing that thought was put into planning and testing what we built. Sometimes our actual project might have only only been 40 lines of code, but would have still produced close to 10 pages worth of diagrams and documentation.

But none of this would matter, if you didn’t get a “Demo OK”.


Most software engineers working in teams will usually follow a similar process.

  • Analyze the problem.
  • Plan a solution.
  • Write the code.
  • Test the code.
  • Demonstrate the solution.

As in the list above and at BCIT, the last step is demonstrating the code to your team, stakeholders or instructor to show evidence of your solution working.

The format of a demo can change based on the organization but at minimum should:

  • Explain the problem domain.
  • Provide relevant context.
  • Demonstrate the problem if possible.
  • Explain the solution at a high-level.
  • Demonstrate the solution.
  • Ask for questions.

While this doesn’t seem that intimidating, our instructor wasn’t always the most patient when it came to demos which was understandable due to the amount of students and timelines he was responsible for. This meant that it was in your best interest to get a pass on your first try by making sure your demo was air-tight, and that you were able to answer any questions.

And so, many memories come to mind of spending the last night (or hour) before a demonstration preparing. Configuring our test environments, rehearsing our talking points and practicing the sequence of commands that we’d need to enter — all this while also thinking ahead for how to handle any complications and the inevitable question period at the end.

Demonstrations were some of the most stressful times but also those that helped foster teamwork and cohesion amongst some of our cohort.

It was stressful because ones execution of a sequence of actions in a short period of time would be determining the success or failure of weeks (sometimes a term’s) worth of work. It didn’t help that this would usually be in conjunction with a lack of sleep and under a time crunch.

Though at the same time it was during demo time that most of our “set” (BCIT’s term for a cohort) came together.

“Need a patch cable?”
“Give me your code, try it on my machine”
“Did you try _____?”
You’re running this in Python 2 you idiot!

While experiences may have varied for others, I can definitely say that some of my demos only worked because my friends helped me during my demo prep and I am definitely grateful for it — though it made me wonder:

“Would people be this helpful in the real world?”

I hope so.

“You should demo it tomorrow”

While a big aspect of my program was based around writing code, most of my work after graduation was not (minus a brief stint as a front-end developer) and so I didn’t really get to participate in a real development cycle. Similarly, my usual routine of writing code and demonstrating solutions had lapsed and has been replaced by that of writing responses, and solving tickets in my current role as a support engineer.

After a year in support, I could feel my itch to write code and build things growing — and thanks to the powers that be, I was recently given the chance to embed with one of our software engineering teams to spend a portion of my time doing just that.

With that team (Quadra), I got to work on engineering a solution an interesting issue affecting our infrastructure and after some setbacks, research and a lot of help from the wonderful members of the team, we were at a presentable proof of concept by Thursday afternoon.

“Sweet, this looks great. I think you should demo it tomorrow morning.”




It’s been two years since I’d done any code demos so I was noticeably hesitant, but after some persistent encouragement by the team lead, I said yes.

That familiar heaviness on the back of my head just above my ears returned, a common indicator of eustress for me.

And so I went home, and I went over the problem.. “Why are we doing this? What problem are we trying to solve? Why do they want to hear about this?”

I thought about it right before bed, anxious about how the demo would go. I thought about it when I woke up, worried if my code would work as expected.

I got to work early and wrote down all the commands needed for the demo in a special doc.

I thought in my head about how to best deliver the context:

“Should I explain what’s on each screen? Does this make sense?”

Thankfully my engineering team invited me onto a Google Hangout prior to the demo to go over any final concerns.

As we went through the practice demo, things were not going well — I was fumbling commands, tripping over my words and at one point, got confused as to which screen was which and tried running commands on the wrong host.

The team members could tell that I was nervous and started chiming in with ways to help. One of them offered to take on running a command in-case I needed to reset so that it was one less thing to worry about and the team lead mentioned that he’d do the intro for me so that all I’d have to do is focus on running the commands for the demo.

Wow, so people ARE just as helpful in the real world.

And so I walked over into the demo room and connected to the WebEx where I was thankfully greeted by some familiar places.

“Oh sweet, welcome T! Excited for your demo…it better work on the first time!” pressure.

“Speaking of demos, did you guys hear about that episode of (some tv car show) where this nervous demonstrator freaked out and went on to (do something completely bad)? Here, let me grab the link”.

He said with a friendly grin.

GEE THANKS There’s that anxiety building.

And then I looked over at the screen with the WebEx, only to see like 18 people I’d never met before who I would also be presenting to.


My demo environment.

The first demo began and I started freaking out. I had my consoles open but in running through the sequence of steps to prepare I was entering things wrong. I was mistyping commands and kept on triggering the “bonk” sound effect on my laptop and had to mute my sound. I could also feel the active ingredient in my anti-perspirant starting to kick in.

First demo — question period, last chance to prep. I let the anxiety wash over me and start executing small fixes:

  • Run all the required commands and cancel them so that I can easily recall them via hitting the up arrow.
  • Have my note with the commands on the side.
“Alright T, you’re up!”

I took a deep breath..and hit the “Share screen” button on the WebEx to start. Almost immediately it felt as if everything outside of my laptop lost focus and as if my ears went into noise-cancelling mode fuzzing out all the high frequencies in my soundscape.

I can’t remember exactly what happened next, but I do remember feeling as if I was back in room 323 at BCIT — with my instructor looking back at me with an air of impatience waiting for me to get on with it.

“Hey everybody, my name is T and I’m a member of the support team currently working with Quadra to solve the issue of…”

Wait, wasn’t Rahim (the team lead) supposed to do my intro? Welp, I’ve already started, time to keep going.

“As you may have experienced in the past, this problem usually occurs when…”

Two faces in the room nod,

Sweet! I’m not completely talking out of my rear.

“So our solution was to….”
“For this test, we’re going to…”
“If all goes according to plan, we should see this happen on this screen..”

I’m not sure where this is coming from, but lets keep it going!

My mouth keeps firing off the talking points, while my fingers type out the commands and somehow all the right ones are being entered, in sequence and displaying the right out. I’m not quite sure how I’m doing this, but I keep going until I hear myself say:

“…which we hope to do in our future implementations. Does anyone have any questions?”

The room comes back into focus.

I notice I can hear the noise of the person next to me exhaling.

It clicks that I’ve just finished the demo and have a brief moment of relief before the knot in my stomach clenches and I realize:

Oh crap, it’s time for questions.

“Wow, this is great!”

Uh..that doesn’t sound like a question.

“So what layer does this work at? I know that this problem occurs at ___ but how does this affect us at _____?”

Aaaand I’m drawing a blank. I start trying to grasp at straws in my head, trying to devise a solution when thankfully I hear the team leader unmute his mic:

So in your case, this affects you when _____

I’m saved.

A few more questions are posed and he jumps into answer them all.

Finally there’s a small silence to indicate that no one has any further questions and I scan around the room to see smiles. With that I explain I need to jump into another meeting and leave the meeting room with my internals feeling in a state of flux.

I start mentally debriefing myself:

“Maybe I should’ve done this..but I did that well.. I wonder if they got that” before coming back to the all to familiar back-and-forth in my mind where I wonder if I’m good enough to be an engineer.

I look down at my phone buzzing to see a message from the team lead:

“You did great! Good job!”

And just like that, all the work we’d done over the past few weeks, all the fears and anxiety I had just evaporated — to be replaced with a cool splash of satisfaction.

This experience taught me a lot of things:

First, that school actually prepared me decently well for real world demonstrations by showing me the importance of preparation. Granted that this was a pretty small project, school taught me that you should practice your demonstration many times and be ready for any eventuality.

Second, I learned that the being in the right type of environment and team does indeed have people that are this helpful in the real world. I can’t thank the Quadra team enough for taking me under their wing, encouraging me and helping me get the project this far.

Third, that it feels good to demonstrate that you built a thing! I know that especially at school, I looked at demo’s as nothing more than just as a necessity for ticking off an assignment.

But having been on the sidelines and watching the demos of other engineers thinking:

“Holy cow, look at how they built that cool thing!”

It feels awesome to know that you helped build something cool, and something that might go on to fix problems in a live production environment someday.

I think above all, this experience demonstrated to me that:

Hey, maybe I can be an engineer, because I just presented on something we worked on and even though it’s real life, no matter the setbacks you encounter to get there — it all doesn’t matter as long as you get a:

Demo OK.