Last week, I had the opportunity to teach SQL (Structured Query Language) to 14 middle and high school students in our homeschool co-op. I use my company’s Volunteer Time Off program to make this possible.

In a previous article, I shared how I helped one of my students repair his broken laptop with a soldering pencil. If you missed that article, check it out here.

I am teaching a digital literacy course, which covers a wide variety of subjects. Just a few weeks prior, I taught the students how to use Excel. Now we were diving into SQL. I knew it would be a big jump and I didn’t know how they would handle it.

I used our brief classroom time to teach basic concepts about relational database systems, share the terminology, and give some hands-on experience with a SQL interpreter. For our class, we used sql.js hosted publicly on AWS here.

Just so the students could see how it all worked, I provided them with sets of statements to copy and paste into the command line. The hour flew by fast and before I knew it, we were out of time.

This was our first lesson involving a programing language. Just before I dismissed the class, I asked them what they thought of their first exposure to coding.

One of my students said, “It was mostly just copy/paste.” I responded, “You have no idea how accurate that observation truly is.”

Debugging the homework

I gave each of my students a homework assignment. They needed to create their own tables in a database based on certain requirements, but I didn’t provide the code. They also needed to write several queries against the database to return certain result sets and display the data in different ways.  

They had been taught the commands. They had seen them work. Now they had to write them by hand for the first time. I heard from several students that what took them minutes in class was taking them hours at home. Why was this the case? Debugging.

Computers are incredibly literal. They don’t care what you mean. They will execute exactly what you tell them to execute. The most common problems were syntax errors, typos, and case sensitivity issues.

In our modern world, communication through technology requires much less precision. We voice-text. We autocorrect. We use Grammarly on our blog posts. Even if the technology mangles our message a bit, the human on the receiving end usually knows what we mean.

I knew that writing computer code and dealing with this requirement for precision would frustrate some, but to my delight, most of the students enjoyed the challenge and were hungry for more.

Clarity

This caused me to reflect on my own leadership communication. In the workplace, many effectively communicate with each other through a variety of informal styles with good success. Familiarity and relationship will fill in the gaps, and intent will be well-preserved.

I’ve come to believe that leadership communication in the workplace is more like a software engineer working with a SQL interpreter, than a voice-text chain among friends.

Everyone in a leadership position has experienced this: Sometimes your team members take your communicated statements very literally. Too literally. They completely miss the point. And then you need to deal with the fallout. Why is that?

The leader-follower relationship in the workplace is more formal. Like software engineers, leaders need to be more careful with their language. If they don’t, then their communication will blow up, just like bad code pushed to production. They will need to figure out what went wrong like a software engineer staring at a debugger at 3 AM hopped up on Red Bull.

I’ve always believed that engineers make good leaders. Perhaps the skill of code precision prepares them well for the leadership task of clear communication.

I hope you’ve enjoyed this story. After 23 years in the technology profession, it’s eye-opening to see how young students experience it for the first time. As always, I hope you can apply this lesson to your leadership practice and share it with your colleagues.

Podcast: Play in new window | Download