I’m convinced that the best way to grow as a developer is to practice. In particular, intentionally practicing things you aren’t good at or haven’t tried. In that vein, I started a weekly meeting at work in the spirit of a software kata.
I am encouraging my teammates to solve these problems by practicing something they’re not great at. For some people, solving the challenge in python is enough. For others, introducing tests or trying a functional programming style is their focus.
With intentions like this, puzzles you have solved many times before take on a new life. Settling into a familiar problem enables you to write more elegant code, or experiment with an unfamiliar technique.
In our last meeting, we had the familiar “fizz buzz” challenge.
For those unfamiliar with “fizz buzz”, the challenge is to print out the numbers from 1 to 100, but if the number is divisible by three, don’t print the number. Instead, print “fizz”. If a number is divisible by five, print “buzz” and if the number is divisible by both, print “fizzbuzz”.
It was a great challenge for those new to python to see some different ways to solve it.
While reading about the Open-Closed principle, I was particularly interested in the thought that one could write code in a way that adding new behavior would ideally require editing zero lines of the code already writtenThere’s more to the Open-Closed Principle, especially when you move to the module level, but I wanted to practice thinking about building something to satisfy this requirement without “overengineering” the solution. .
Fizz buzz is a great problem to practice this with. One can build up the solution for “fizz” and then add the “buzz” behavior without editing the “fizz” code.
At this point, I was going to show my solution, but I think it would be a great problem for you to try. I’ll post my solution in another post soon.
Don’t worry about having code that isn’t good enough. This is an exercise. Let’s learn and grow together.