I just bought a new iPad and of course I had to install a screen protector. Why wouldn’t I? A brand new iPad needs to be protected, right? The case for the Screen Protector I bought the best screen protector money can buy, Paperlike. Paperlike is excellent for when using the Apple Pencil; it gives a bit of friction to the pencil to feel (and sound) a bit like paper when drawing or writing on the screen. In addition, the Paperlike screen protector also gives a matte surface to the screen, making it more resistant to sunlight.

Why are we so afraid to show temporary or early drafts of plans to our teams, and why are we so obsessed with planning reveals at kick-offs? I don’t know, but it seems to be our ways-of-working when it comes to planning, road-mapping, or defining objectives. We have this idea that planning only involves the product owner/lead/manager and relevant stakeholders. We tend to have a non-transparent process of what the quarterly - or half-year plans will look like until we do the final unveil at the next “kick-off” with the rest of the team.

I have now come to the point, where I would like to add a bit more graphics to the prototype. Instead of having basic characters act as standins for the graphics, why not do the actual graphics themselves. To start with, I would like to render a lime instead of the “@” character. Before I can begin, I need to better understand the graphics capabilities of the ZX Spectrum and what options there are.

The time has come to look into cross compiling my code for the ZX Spectrum. As I alluded to in part 1 of the series, I intend to use ZXBASIC for cross compiling, which also means I can basically take (no pun intended) the prototype already writen in Sinclair BASIC and rewrite it in ZXBASIC. The advantage of ZXBASIC, besides compiling to assembler, is that it is also a modern take or dialect on BASIC (especially when compared to Sinclair BASIC), where it tries to keep some of the original Sinclair BASIC features, which definitely eases the transition from one language to the other, but it also offers features of a cross compiled language, such as data types and the possibility to do inline assembly code.

Now it is time to write some actual code. As I described in a previous post, I want to create an initial prototype directly in Sinclair BASIC, which will allow me to test out the gameplay of the Awakeman game on a ZX Spectrum. It has been a while since I coded in BASIC. My first job as a developer was to create small programs in Visual Basic for Applications (VBA), so building this prototype will also act as a refresher to BASIC.

With side-projects like this one, I tend to leave the project unchanged for weeks. Therefore, I have found it good practice to write down the explicit details about my development setup; it makes it a lot easier to return to a project set on pause for a while. As a general rule-of-thumb, my development setup has to be as platform-agnostic as possible. I think this is good practice. It allows a broader audience to follow-along when doing tutorials like this one, and it makes me independent from whether my next primary computer would be a Mac or a Windows PC. As a side note, I used to change jobs every 2-3 years, where my next computer was decided for me by the company “default” and not by my preferences.

For sentimental reasons, I recently bought a ZX Spectrum from a dear colleague, but what to do with it? I could play games from my childhood, but why not make my own?! The Speccy, after all, was what created a generation of bedroom coders. Because of the 8-bit hardware limitations, this would be an excellent opportunity to flex my programming muscle, something I do not get to do all that often.

In July 2013, I posted my workplace manifesto on a Tumblr blog I had back then. It was a list of five priorities I wanted for a current – or future workplace; some of them felt a bit far-fetched or maybe even utopian, so how do they stack up today? The Manifesto Without further ado here is the manifesto: Be able to work on projects that excite you! Be able to put in the hours to finish the project and NOT be bound by the project’s price-tag. Be able to work when and where you are motivated, even if this is at nine o’clock in the evening or in a café or at home. Be able to choose the right technology for the project, and not the other way around. Be able to work with the right set of tools on the job and not the workplace “default” that has been decided by IT or any other who have no idea of what works best for you. When I wrote this manifesto, I worked as a consultant and solution architect at Creuna, working on various enterprise solutions often limited by its contract. I was frustrated about the limitations to how many hours I could spend on a specific project, dictated with a fixed-price-contract, and the types of projects I had to work on; not all of them motivated me. I worked on predominantly CMS-solutions, so new projects were described as either a Sitecore – or Episerver project, not by the site’s actual goal. Also, I had not yet become a dad, so the restrictions of a traditional nine-to-five job felt very limiting.

A current trend in our industry is to formulate your goals as Objectives and Key Results (or OKR). However, there are a few challenges when implementing OKR, especially on a team level. This post is an overview of how we use (or misuse) OKR on a small development team. To give you a little context, our team consists of 3 developers and a product owner (that is I). We have a daily stand-up every day at noon and do refinement session once a week. Everyone (including myself) are attending all team meetings (including retrospectives). We use a Kanban board to support the prioritization of work and tracking progress. We do not use sprints or commit to work that we need to deliver within a specific deadline; instead, we communicate expected delivery dates based on our lead time.

When asked to do a presentation about something or the other, I struggle to find the motivation from time-to-time. Here are a few tips on what I do when preparing for a talk. To quickly summarize, these are the steps I go through: Somehow make the subject exciting Challenge myself Think about the presentation; can I make this entertaining to the participants Make the Subject Exciting Often I am asked to make a presentation about something I know by heart, which is great because this means that I probably have a presentation already on the subject tucked away somewhere that I can reuse. On the other hand, this means that I probably have talked about the subject so often that I might come off sounding a bit uninterested and unexcited when I give yet another talk.