Part 0 – Intro

There is a legend about an ancient riddle that have failed many a programmers. It is called the riddle of Fizzbuzz and it goes like this:

“Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.”

Read more about that here.

The thing about FizzBuzz is that it is a really simple task. Perhaps many fail it because of the psychological stress of a test.

For the uninitiated I would first suggest going through the trivial solution outlined by Real Tough Candy.

Now we could have stopped there, be settled, maybe even pass the interview and get the job. But if you strive to become a better developer, then you should push your coding abilities further.

Usually there are many ways to write a program which delivers the desired output. You can look at it as a range of expression. The more you can come up with – the better programmer you are.

Sure the trivial solution gets the job done. It’s even efficient and fast. But trivial solutions make for trivial developers.

In this series we’ll explore changing the code from different perspectives, exploring different syntaxes and paradigms. The end result will look nothing like trivial solution. I guarantee that the more you follow along – the more flexible and robust you’ll become as a coder.

Let’s review the task for a minute.

Let’s stop for a second to ponder on this solution.

A newbie might try to tackle the problem in the same order as she reads it. She’ll test for 3 and then for 5 and then for both.

But wait a minute, testing for 3 does not negate 5, so they’re not mutually exclusive cases! This is probably the most common mistake. This will never output “FizzBuzz”.

So one might be tempted to exclude 5 from the first case, then 3 from the second. Indeed it will get the job done alright, but at a high price.

The code is less readable. Even worse, imagine what would happen if there were other cases to test! (if a && not b && not c etc…)

So the idea behind the favorable solution is testing for the most specific case first and then for the more general ones.

Now it’s time to look at our code in a more critical way and explore the many things we can do with it. It’s going to make it much better. It’s going to make YOU much better.

We’ll explore the first step in the next article in this series.