By Scott Smith
I recently attended Desert Code Camp as an application development Presenter. My presentation topic was Spring Data and MongoDB. I thought I would share a little bit of experience and a little background and history that helped lead up to the event.
I was 15 years old when I first experienced what it was like to give a lecture. I was taking a summer Geometry class. I was trying to get ahead and graduate early from high school. I hated high school and I could not wait to get out of there. I did sports and other things but I was cocky and anxious to get going with bigger and better things.
My teacher noticed a couple of us were doing well in the class. He had this philosophy of teaching where he people should only teach subjects in which they were not naturally proficient. He claimed he was not good at Math, but an excellent writer. He thought he could contribute more by being a math teacher rather than an English teacher because he understood the struggles of learning math.
One day he came up to me and asked me to lecture the next section. He told me to take a little time, read ahead, and prepare to present it. In my thinking I thought this would be a piece of cake. The topic material was easy to understand and I thought nothing of being called upon to show others how it was done.
I was in for a very rude awakening. I was a typical self-absorbed teenager who did not realize that understanding the material was only the first step. Communicating these ideas to others was the challenge. I was communicating to people who had flunked geometry before and were taking it again. My style was disjointed and unorganized. My mind was scattered and the topic material was illogically laid out.
My presentation was a total disaster. The teacher jumped in to help me a few times. I was not in tune with the people around me. I could not relate and I was embarrassed because I knew I was floundering... and everyone was disgusted, especially me.
This humiliating experience was one of the best things to happen to me. In addition to being an important life lesson on the value and difficulty of teaching, it made me take a hard look at myself. Was I in tune with the people around me? Was I communicating clearly in an organized way? Were my students lost or struggling? Did I need to find another way to connect? How was I to help students learn in their way, not mine?
I had a chance to learn more in college working for the math department at Arizona State University as a tutor, tutoring at several community colleges, technical colleges, and even in a local high school’s after school tutoring program. Subjects included math, physics, chemistry and programming.
I enjoyed the challenge, not so much of the subject matter, but of finding ways to make discouraged students understand something they were struggling to grasp.
In software development, we sometimes find ourselves having to present to people who do not have a clue what we are doing. Boiling the concepts down to something a layperson can follow is necessary and often challenging. I use the term layperson loosely because some of those so called lay people are CEOs, VPs, or other upper management--all smart people who are not experts in the subject material.
In my experience being a lead of team and architecting systems, I have often found myself having to teach tough concepts to other programmers. Sometimes they are not too nice about it either. It is one thing to sit in the audience and poke holes in someone else’s ideas. It is quite another to lay yourself out there completely, possibly becoming a target of criticism and even vitriol.
Even if you have a great system designed, it only takes one little mistake and people will often heap onto that one aspect using that a reason to discredit the whole thing. The good news for me is that I have several large, successful systems under my belt so I do not let it bother me as much as it used to.
Which brings me to the next aspect: know your material well. It is important not only to know the topic material well, but also many other aspects not in the presentation. Being a subject matter expert is hard, but essential. People will ask all sorts of questions from different angles. Fielding these, reacting and taking things in a different direction may be necessary. It depends on the audience. You just cannot predict everything ahead of time. Along those lines, it can also be necessary to bring things back on topic if someone in the audience is derailing the presentation.
In some ways it is really not a presentation, it is a performance. Heavy reliance on slides shows a lack of preparation and knowledge. There is nothing more boring than watching someone read slides. Showing real examples takes more preparation and time, but hypothetical talk is not as impactful as showing the real deal. Steve Jobs would spend 90 hours for a one hour presentation! That is a pretty high bar, but it shows that good presentations take a lot of preparation.
So how did Desert Code Camp go? I had a great time. Before the presentation started I asked everyone a little about their experience level, coding and language background, and database background. I spent lots of time preparing and showing real examples. I leveraged Git to quickly swap out branches of code to illustrate differences and points. I ran examples and pointed out important aspects of the design. We did not have a lot of time, but we were still able to bring all aspects together with a complete working example. Questions were good and everyone was pleasant. Most importantly, it was not about me, it was about the audience and their new understanding of Spring Data and MongoDB.