Lately, we had a talk with one of our former interns who now happens to study informatics at university. He presented some code he had written for his programming course and we did a team code review. The review itself was a lot of fun and sparked quite a few discussions. At one point, we assessed the different implementation styles of a method, changing the rather complex single return code into an early return method. Our former intern (now student) listened to the solution and stated: “I am not allowed to do that.”
There was a sudden silence, as everyone tried to comprehend what that means.
The student explained: “my course instructor prefers the single return approach over the early return style”. Well, that’s one thing, we can handle different opinions. “And”, he continued, “he announced there will be a painful deduction of points if we don’t comply to this style.” When the course tried to discuss this point, the explanation given was: “the single return style is superior because the other style is frowned upon.”
We couldn’t believe it. But, as it turns out, there are many rules like the one above in this programming course. And nearly every rule is highly debatable if not plain wrong (in our perception).
There is no problem with the presentation of certain rules in a beginner’s programming course. Novices need clear and precise rules to learn, according to the Dreyfus Model of Skill Acquisition. The concept just doesn’t work for students that aren’t on the Novices level anymore. These students are explicitely forbidden to create more advanced solutions. They are discouraged to look into different programming styles because it will only harm their grades.
We can think of a possible explanation for this scenario: The assignments have to be evaluated by the course instructors. It takes a lot of hard work (and time) to evaluate hundreds of totally different solutions for the same problem. If the solutions are mostly similar in style and concepts, the evaluation is a lot easier and can be done without full understanding of the code.
This is a rather poor explanation. It says “don’t be too advanced in your field of study or you will be too troublesome to attend to”. This is essentially an anesthetization by decree. But the real problem arises when you realize that there won’t be any continuative programming courses. They will never teach you all the more advanced concepts or rectify the silly rules that should get you along as a beginner. After you’ve successfully mastered this course, the studying focusses on the more academic topics of our field. The next possibility to develop your programming skills in a professional setting is your first software development job.
We don’t have a practical solution to this problem. One obvious solution would be to have more instructors evaluate less assignment solutions in the same time, enabling them to dive deeper in the code and give better personalized feedback. This scenario lacks at least enough capable instructors. The reality shows that Novices level students (in the sense of the Dreyfus Model) are often taught by Advanced Beginner level instructors (called a “tutor”).
But we have a word of encouragement for all you students out there, feeling dumbed down by your instructors: It’s not your fault! Take your programming course rules with a (big) grain of salt and talk to other developers. If you don’t know anybody already in the industry, try to make contact with some fellow open source developer on the web. It’s really just the advice “Find a Mentor” from the book Apprenticeship Patterns (highly recommended for aspiring software developers) applied in real life.
Because if you don’t actively unlearn all these arbitrary rules or at least put them into perspective, you’ll start your professional developer career with the burden of some really antic code quirks.
Good luck and tell us your story, if you want.
6 thoughts on “Take your programming course with a grain of salt, please”
This posting explains the origin of the “Single Entry, Single Exit” (SESE) concept: http://programmers.stackexchange.com/a/118717
In C it has its place, in most other languages it’s unnecessary. He should tell his instructor.
thank you for the link. I’m afraid the student already tried to explain it and was rejected.
The instructor sounds like a “Angry Monkey” as desribed in The Productive Programmer.
But now I’m actually curious what the average method length of the instructor is. My personal experience is that people who argue for “Single Entry Single Exit” write methods with 2-3 digit line count.
Hi zillus, you guessed right. The sample solution was riddled with high complexity methods and nested blocks. The two hundred line switch was very readable, though 🙂
Thank you for the hint to “Angry Monkey”. Makes it very clear what’s happening.
Hmmm that is a worrying tale! Thankfully my experience of being taught programming was not quite this bad. There were definitely hints given out such as the popular ‘goto is bad’ but on the whole we were left to experiment, make mistakes and explore the complexities of the language. It sounds like this poor chap is being taught how to pass his course rather than how to become an accomplished programmer.
Being taught that something is bad without a rationale may well help people write better code in the short term but ultimately they need to develop an inquiring mind and have the courage to try new things and make mistakes. Lessons learned from getting your fingers burned are the most valuable! 🙂
I am not a programmer but I have this C language subject this session and have to prepare for it. What all topics should be covered in it?
And has anyone studied from this course http://www.wiziq.com/course/2118-learn-how-to-program-in-c-language of C tutorial online?? or tell me any other guidance…
would really appreciate help