Did you know: programmers convert coffe to code?

If you like my articles, support me with a small amount.

Buy me a coffee

Introduction to Systematic Program Design – Part 1 at Coursera.org

Although I am an experienced software developer, this course taught me a lot on how to design software (components).

First of all I have to tell you, this was the toughest course I’ve attended yet. So be warned: if you really want to take a successful run on the topic: separate time for studying.

The course is almost the same than other courses at Coursera: you get your weecly video lectures, some homework, a weekly quiz (based on the homework), some projects (graded through peer-review) and a final exam.  And why should this course be more difficult than others? Good question but here’s the answer: you only have one attempt on the quizzes. And they are time-limited (mostly 24 hours). The same goes for the final exam.

The course uses the DrRacket environment, starting with the Beginner Student Language and at the end of the 8 weeks (in the next version there will be 10 weeks) you’ll advance to the Intermediate Student Language (so this is again a good opportunity to delve into a new programming language).

You get week for week new design recipes which help you advance in the topics: first you learn how to design functions with atomic data types (numbers, strings and co), then you advance to data definitions, then go on to advanced topics (ok, conditionals are not really advanced but I did not want to list the entire course material in this post).

Program design

It is not just about how to get to the right components to end up with a working application. The course teaches you a good ol’ design (as I’ve taken from the Oxford Dictionary): “decide upon the look and functioning of (a building, garment, or other object), by making a detailed drawing of it”.

So yes, you not only learn the components but you write “beautiful” code: tests and good descriptions (signature, purpose) for your methods.

At the peer assignments the overall design (the look) of the code is more important than the functionality. There were questions about the test coverage (has each method an appropriate amount of tests and if they cover every possible case), method-signatures (does every method have a good purpose, signature and so) and if you use helper methods where possible instead of one big “almighty” function.


As I mentioned above every week has it’s own videos, own problem sets (programming exercises based on the week’s topic), homework and a quiz based on the homework.

After starting the quiz you have 24 hours to give your answers. The questions are related to the homework code (i.e. “What is the signature of the method so and so?” or “How many tests are the minimum for the method foo to cover all possibilities?”) or very general in the topic (“Which of the following purposes is right for the method bar?”).

Most of the time I only watched the lectures and tried the quiz without solving the homework (I know, bad-bad Gabor) and my points resemble this laziness for good. One quiz I attempted late again needed the homework design of an application which produces a Cantor-set and I had a bad feeling about the answers I gave without actually doing the work so I started my IDE, coded about an hour long and I realized that my answers were totally wrong. So I adapted the answers and vois la: I’ve got a maximum score. This is why I encourage too going through the homework exercises yourself.


This was a really great course. I’ve had some hard nights working through the course materials and homework of the week until the deadline of the quiz but the final exam showed me that I learned a bunch on designing. I can only encourage you to take this course even if you are an experienced software designer or developer. I think you can learn something from this course. Naturally you’ll have to adapt the material to the programming language you use but Racket does not have such methods or usable components which your language would not have (except you are a hardcore shell or mainframe developer — in this case my apologies).


Senior developer, consultant, author, mentor, apprentice. I love to share my knowledge and insights what I achieve through my daily work which is not trivial -- at least not for me.

Click Here to Leave a Comment Below 1 comments