In the previous article on the Block Puzzle game, I showed how I intended to separate the game logic from its UI. The goal behind this separation is to make it easier to develop and test the game logic without having to do it manually via the UI. In this article, I will show how I am doing the unit tests without writing any UI or even having any dependency on UI code. Although the work was done in small steps, in this article I will explain the reasoning behind them in the hope that I can explain my reasoning behind doing it the way I did it.

The first game idea that came to me was inspired by an YouTube video I saw of Mitch Koko programming a game in Flutter from scratch. The game was a Tetris, programmed in bulk without a lot of care for structure and tests. But that goes against most of the lessons I have collected over the years. I like structure and tests. I believe they allow me to go faster, but before that a small detour.

How to sharpen your skills while having fun!

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.

We have all heard the saying, Practice Makes Perfect. But does it apply to programming? To write tests? To software design? I believe so and I hope this articles makes you think about doing some Katas, some experiments, writing some side projects, and, if you’re brave, publishing them!

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.

How a simple idea changed software design forever

It was the dawn of computers and software. Operating systems were being developed, and there were still no agreed-upon abstractions. Then came a simple abstraction: the device driver. The device driver enabled the development of software that was not locked to a specific hardware; it allowed developers to write code that worked with any hardware. This seemingly simple change made software development a lot simpler. It is something we take for granted today, but that we forget when we develop software. Why do we keep on forgetting this simple idea? In this article, I’ll explain what the driver abstraction is, how it came to be, and the problems it tried to solve. I will also show why we keep forgetting about it, and the costs we pay every day for not learning from our past.

A View Of Many Years In The Trenches

Have you thought about how to grow a Software Development Team? How do you get juniors into seniors? How do you keep seniors motivated and engaged, not feeling the need to look for jobs elsewhere or afraid of becoming obsolete? This is not an easy subject, but a question on my last day of work at my last company got me thinking about it, and I will add my two cents to the discussion. Take this with a grain of salt; after all, I am no expert, and I am most likely wrong. Sorry!