Have you ever been requested to do a change to a system, but that change should not be visible until it is completed? Have you also been requested to launch fixes to the same system while you are changing it? Then you probably faced this problem.

Introduction

We have all been there: someone asked us to add some feature to an existing system, but that it should only be visible when it is completed. You go off and start coding. Sometime later, that same someone asks you to fix a bug, a high priority bug. But you have your code half done, and you can’t simply stash it. How will you handle this?

Context

In my quest to get back to coding, I decided to start building games again. The last time I wrote about this adventure, I summarized the latest changes I made to my version of the blocks puzzle. A few months have passed since then, and I have been busy thinking about what my next step should be.

Adding some color

Adding some color to the game is quite easy. Since our game pieces use sprites that are made of string, we can simply make a mapping between a letter and a specific color. With that mapping, each piece can have its own color, and our game bursts with color.

In the previous article, we made the game almost playable. It was almost playable because we could interact with it, but the logic to remove completed lines was not there. In this article, we are going to add several types of pieces to the game and the logic that detects full lines and removes them.

In the previous article, we developed the base model for our game. In this article, we will be creating the UI for the game. The UI will use the model previously developed to make a playable game. It will not be the complete game, but having something you can use and play with enables faster feedback. We need feedback to know if the model is easy to use (it should be, because we wrote it using Test Driven Development), but we also need feedback on what’s the next functionality that we should develop. I prefer to do development in small steps and collect feedback as I go, even when I am doing it alone.

Introduction

As part of my personal growth, I have decided to go back to what captivated my attention in computers when growing up. I was introduced to computers in the time of the ZX Spectrum at around eleven years old. I was sick at home, during the summer holidays, with nothing better to do then to read the computer’s manual and write a game. Have you ever tried to write a computer game using BASIC? Looking back, it doesn’t look as fun as it did back then 🙂 I wrote a game that was like whack-a-mole, but without a hammer to whack them: you would shoot them. Since then, I have never stopped programming and never lost the love for it.

Have you ever seen the great ones do some katas? See how the master works through the code and changes it so effortlessly? It seems like magic, doesn’t it? But they are just humans like us. Whether you follow Martin Fowler, Robert “Uncle Bob” Martin or Kent Beck, you’ve probably seen some of their katas. If fact, you can find videos of them trying new techniques like we do, like seeing Kent Beck doing some TCR (test && commit || revert). It is through deliberate practice and being humble that they, and also we, can become better at what we do. We never know everything. There is always something we can learn and something we can improve. If we stop practicing and we assume we know it all, that is a good recipe to let our Ego destroy our careers and our lives.