Why I give lectures in software engineering

September 13, 2010

<a href="http://de.fotolia.com/id/21746212" mce_href="http://de.fotolia.com/id/21746212" title="" alt="">falcn</a> - Fotolia.com

For more than eight years, I give lectures in software engineering, object oriented programming and software development “best practices”. I have to spend nearly a day every week for six months in the year to prepare and hold the classes. My normal work schedule is always very stuffed with tasks, I have to affront my other duties sometimes in order to show up in front of the students. On many occassions, I’ve been asked why I keep giving lectures despite pressing liabilities, inferior payment and generally better alternatives elsewhere.

Here is a list with answers I’ve given to this questions over and over again. I do not want to convince you that giving lectures is the best thing right after sliced bread or that you will experience any of these if you manage to get in the same position. It’s just a rational explanation why the question still strikes me as odd.

  • It’s pure fun – This surely doesn’t count for everyone, but for me, speaking (ranting, raving, arguing) about software development counts as fun times. Being “on stage” in front of the students helps me to free my thoughts from dead freight and completely concentrate on the topics.
  • I’m being paid to recapitulate the basics – This are two advantages in one: being paid cannot be bad (albeit payment can always improve) and to repeat the basics of my craft on a regular schedule can be seen in the tradition of katas. I’m very bulletproof in discussions about fundamental topics of software engineering because I’ve heard most questions and had to answer them multiple times already.
  • I’m constantly learning new facets about well-known topics – My students always bring in unique and original thoughts about topics that I thought to have mastered. And then, a new way to access things emerges, at least for me. I feel very certain that I’m still learning more during the lectures than my students do. And feedback suggests that they learn a lot.
  • I’m honing my verbal abilities – Giving a lecture is all about speaking without script and responding to the audience. You have to make your points, but you cannot force them. Sometimes I feel like a stand-up comedian for technical knowledge. Having the ability to speak fluently while preparing the next topic in the back of your head is a great advantage in every situation including verbal communication.
  • Roughly 100 aspiring developers remember me every year – What they will remember me for can be debated about, but they will remember. This is all about “networking”, but focussed on members of my own profession. The reach of this network amazes me every time when it loops back.
  • I can contact every local company with job training – Due to the nature of the Cooperative State University where I’m giving my lectures, I can also establish contact to every software company in the vicinity. Many contacts would never happen without my function as lecturer.
  • I keep in touch with hypes – Students are easy prey for IT hypes. Their experience with different technologies isn’t embittered by analogies from the past. All I have to do is to listen to them when they tell me about their work and hobby projects. And then I can draw my own conclusions based on their first-hand experience.

All these reasons and some more are enough for me to stick with the job. You can see a lot of short term benefits and some aspects that might pay off at medium term. On the long run, I’m convinced that my personal advantages from this job will outweight the (sometimes serious) drawbacks. And then, I haven’t yet included the advantages that my students took along from my lectures, hopefully.

If you happen to give lectures too, I would be pleased if you blog about your reasons for doing so, and announce your post here. Or just use the comment section.


On teaching software engineering

February 18, 2009

overheadIn my rare spare time, I hold lectures on software engineering at the University of Cooperative Education in Karlsruhe. The topics range from evergreens like UML to modern subjects like aspect oriented programming (AOP) or Test Driven Development (TDD).

One thing I observe is that students don’t have difficulty separating the old topics from the current ones, even if they hear both of them for the first time. It seems that subject matter ages by itself, just like source code does. So, I’m constantly searching for new topics to include in the lectures, replacing the oldest ones.

Three things to include in your lectures

Some months ago, I read a very good blog post written by Alan Skorkin, titled “3 Things They Should Have Taught In My Computer Science Degree”. Alan covers three points:

  1. Open Source Development
  2. An Agile Process (e.g. XP, Scrum)
  3. Corporate Politics/Building Relationships

The idea of missed opportunities to tell some fundamentals to my students struck me. I compared my presentations to the list, finding the leading two topics covered to a great extent. The last one, corporate politics, is a bit off-topic for a technical lecture. But nevertheless, it’s too important to omit completely, so I already had included some Tom DeMarco lessons in my presentations. Perhaps I can build this part up a bit in the future.

What they should have taught me

Soon afterwards, I though about things my lecturers missed during my study. Here’s the list with only two points in addition to Alan’s list:

  • Age and “maturity” of topic: When I was a student, I quickly identified old topics, like my students do nowadays. What I couldn’t tell was if a topic was mature (a classic) or just deprecated. It would have helped to announce that a topic was necessary, but of little actual relevance in modern software development craftmanship. Or that a topic is academical news, but yet unheard of in the industry and lacking wide-spread acceptance. Both extremes were blended together in the presentations, creating an unique mixture of antiquated and futuristic approaches. This is a common problem of Advanced Beginners in the Dreyfus model.
  • Ergonomics and Effectiveness: I still can’t believe I didn’t hear a word about proper workplace setup from my teachers. I had courses teaching me how to learn, but not a single presentation that taught me how to work. This topic ranges from the right chair over lighting to screen size and quantity and could be skimmed over in less than an hour. But it doesn’t stop with the hardware. Entire books like Neal Ford’s “The Productive Programmer” cover the software side of effective workplace setup. And even further, the minimal set of tools a software developer should use (e.g. IDE, SCM, CI, issue tracker, Wiki) wasn’t even mentioned.

I hope to provide all these topics and information to my students in a recognizable (and rememberable) manner. They deserve to learn about the latest achievements in software engineering. Otherwise you aren’t prepared to work in an industry changing fundamentally every five to ten years. Of course, hearing about the classic stuff is necessary, too.

Give me feedback. What are your missed topics during apprenticeship, study or even work?

Update: In case you can’t visit my lectures but want to know a bit about ergonomics, I’ve written two blog articles on this topic:


Follow

Get every new post delivered to your Inbox.

Join 64 other followers