I recently started to draw cheat sheets (in German) for our project Hack-the-Planet TV.
So, here is my very first attempt to illustrate the way Bubble Sort works.
Link: https://github.com/hack-the-planet-tv/cheatsheets/blob/master/cheatsheet_bubblesort_v10.pdf
Some weeks ago I started to live code using my Twitch project. I use this mainly to spend a few hours a week to get (again) familiar with .NET and C#. I stopped using it (in a professional way) when .NET was available as version 3.5. Indeed, my very last project was a migration project from 3.5 to 4.0.
While I was in the role of a dev/Sr. dev I used to code mostly in pair programming. Great experience. Not for everyone. I loved it. I learned a lot. Every time you stuck, you pair helped. EIther you thought and explained and he/she coded or the other way around. A major element of the secret is that you learn most when you explain.
The same seems to be true for live coding. Live coding is some kind of horror if you do new things. And it probably is utterly boring for all others seeing you looking up documentation and examples. However, there is quite a lot you learn while you are explaining – or at least while you try to explain. Probably, because you are trying to explain, i.e. you try to understand.
Said that I tried to implement an exercise from a recent programming course. I wanted to see, what the students face.
Part of the exercise was: Try to understand what the code does. In other words: reverse engineer. That’s some discipline not everybody is good in. Others are way better than me. I do need a lot of silence and time to understand what the intention of the author was when writing the code. Doing this live is quite q lot of stress. Remember, you try to talk at the same time. Anyway, I think it is a very bad example to give to students. I should try to avoid this in the future.
I never thought of this before about exercises. It was about implementing a Delegate and an Interface, an Indexer and o on. Implement a subclass and use the base constructor the same way. No words about what to achieve. I think it took me two hours just to get half of the exercise done. Would I have learned how the concepts work? Have I understood the new features of the language? No way.
I really think about what I have created. Some code. No added value. Meh.
Afterward, there was something I had on my todo list. As we started out podcast recently, I want to generate episode covers automatically. I am a big fan of letting things being done by the robotic overlord.
I thought about the requirements:
I did some research (aka Googling). I was looking for some articles about how to deal with image processing in .NET. I found an article from Scott. I had a look at the different frameworks mentioned by him and decided to check out the capabilities of ImageSharp. I checked out the examples and I wrote the piece of code.
I had to figure out how to do what I wanted to accomplish. I learned about at least three existing frameworks. I figured out how to use one of these frameworks. I had to figure out how to use NuGet to get the packages. I had to fiddle with some command line magic in Visual Studio projects. I learned about one new öanguage feature.
I have to go on with live coding because I want to become much better in it. It is quite challenging, especially if you haven’t written code for years. And it forces me to face challenges. So if you want to see me fail writing code, feel free to join the live stream in the future.
The more important fact is, that I have to re-think how we teach programming. Yes, you need to explain concepts. But one should not enforce them to be used. If doing it feels like pushing a developer in some direction. Do it with delegates and interfaces and so on. There are probably 100 different ways to accomplish your goal. Let them try out some of these ways. The might end up with the ideal solution – or not. If there is one at all.