The other day, I stumbled upon the following tweet.
It's easy to explain "things" to people that are eager to learn. But how do you explain "things" to people that are not?11:13 AM - 11 Jun 2018
0
2
It really was thought provoking for me. And I compiled the following answer, taking full 12 minutes, rewriting the tweet over and over.
@simas_ch You just don't. You have to convince them that "things" are worth learning. After you convinced them, you can explain "things" to them. Typically, the convincing part is the real challenge.11:25 AM - 11 Jun 2018
But still, the topic didn’t let my mind free. It struck me, that there’s something really really important in there. So I try to break free by writing my thoughts down in this blog post. Enjoy!
I used to teach a lot at University. The two courses I co-taught, Advanced Java Programming and Programming Complex and Interactive Systems were known to be really time-intensive and not mandatory. Hence, the vast majority of the students who ended up in these courses were really motivated to learn and they accepted the large amount of work they needed to do — despite a lot of easier courses available as alternatives! For that experience, I feel privileged. Teaching those courses typically fell into the category of “it’s easy to explain “things” to people that are eager to learn”. They were already convinced that these courses are really important for themselves and didn’t need convincing.
But that’s not the whole truth. Apart from the technology part, we put a large focus on teaching clean code through code reviews in class, of their homework assignments, and even in the oral exam. Not every student shared our enthusiasm for clean code as we lecturers did. These students were already struggling with the course workload and simply wanted their code to run correctly and get good grades. That’s fine. Nothing wrong with that attitude, however, we ended up in the other category: “explaining “things” to people who aren’t eager to learn”. We, as idealistic teachers, wanted to teach and reach every student. So we talked a lot about why some code is hard to read and what consequences this will cause. Each semester, we put more and more emphasis on why a particular code is hard to read. It payed off. We could see this quite well in the feedback we’ve written as part of the grading of the student homework over the years. It changed from talking only about the solution at first to talking about the problem and the solution in a 50:50 split, giving the problem the same amount of space as the solution. I don’t have hard data to support my argument, but students stopped complaining about clean code advice after we switched to the 50:50 explanation. I assume it was convincing enough for the students to walk that extra mile despite the extra work.
We took that experience further and wrote our book Java by Comparison according to that 50:50 share between problem and solution. For each comparison in our book, we dedicate the left-hand page to the problem alone and the right-hand page to the solution. There are a lot of books on clean code that focus on solutions, but none of them spends so much space on the problem alone as far as I know. I think this really sets our book apart and makes it so appealing to beginners and experts alike. Have a look to see it for yourselves.
Let me generalise the point here. Talking about solutions is natural to us developers who like to share what we know. We want to share that cool new framework, programming language, IDE, CLI tool, or library. We want to show how it works and how cool it feels. But we often don’t spend enough time on why we should switch from the currently used framework, programming language, IDE, CLI tool, or library. We are already convinced, often strongly convinced, that the new is simply better. But we tend to forget that others haven’t thought our thoughts, haven’t gained our experience, and may reach totally different conclusions because of their current needs.
When you read the next article, listen to the next talk, or simply attend your next meeting, think about the ratio of time spent about the problem and the solution. Do you think the article/talk/meeting would’ve been better by talking more about the problem and less about the solution? Please let me know in the comments.
Top comments (0)