1. Getting rid of Monoliths

    Reading time: 6 minutes
    Posted 2 years ago

    I am working for Jumbo Supermarkten, which is a large grocery chain in the Netherlands. This family owned business started to venture into e-commerce at about 10 years ago with a very small team of developers. Currently, we've grown into an IT department that consists of over 450 developers working on all digital solutions. We've made some changes over time on how we manage our software. I gave a talk together with my colleague on this topic, so let's share the write up here.

    So, if we rewind the clock the the founding of the Jumbo Tech Campus (JTC), where in the beginning the main purpose was to get started with e-commerce. What happened was that the team at the time did the thing that is most obvious with limited resources and a generic goal: they grabbed an off the shelf solution and started to implement it. This meant connecting to the existing brick and mortar stores, the delivery and storage APIs and whatnot.

  2. Conference with confidence

    Reading time: 6 minutes
    Posted 2 years ago

    Last week I had the opportunity to speak at VueJS Amsterdam ❤️ together with a colleague of mine. It was my first time doing a talk at such a big event and thought to share my journey, and give you considerations for when you will be giving a first talk!

    Small disclaimer: I am by no means an expert in speaking, but that’s exactly why I think this post gives you insights for starting out. Also, the talk we gave was about a certain technology, but I think this article is generic enough to apply for any topic.

  3. Broken windows

    Reading time: 3 minutes
    Posted 2 years ago

    In software engineering, we can apply a lot of the psychology findings to their digital counter part. If we consider the broken window theory, it doesn't apply to the operating system, but to the state of code.

    Let's go back to the source. From an article originating from 1982 ("Broken Windows") in The Atlantic by James Wilson and George Kelling.

  4. Interviews done right

    Reading time: 3 minutes
    Posted 3 years ago

    Tech job interviews. They are a very important part of the continuity of an organisation and the trajectory can wildly vary per company. I want to highlight a couple of tips for both interviewer as interviewee, from my perspective as having done both on several occasions.

    Let's take a look at the companies' perspective. I think this perspective hold most value for both parties. Usually we can break down the interview process in a couple of steps, which boils down to the following phases:

  5. Released NPM package for OhMyPrints & Werk aan de Muur

    Reading time: 1 minute
    Posted 3 years ago

    As a hobby photographer, I upload some of my photos to a selling service called "Werk aan de Muur". It allows consumers to order prints while offloading the logistics to the service in exchange for a commission per print.

    As software developer, I believe you should be able to own your own content. Which is one of the reasons I also launched this website.

  6. Challenge yourself with a Coding Challenge

    Reading time: 2 minutes
    Posted 5 years ago

    As a mentor via CodingCoach.io I'm currently working my way through the 21 Days of Code coding challenge by Lighthouse Labs with my mentees. I thought to share our findings and resolutions here, as well as offer some perspective on these events.

    Firstly, I kind of like this iteration (we've previously did a similar coding challenge side by side). We're following a storyline involving the Mayor of Codeville and face different kinds of challenges. It's nice to have some context and not simply solving problems. I think this is a really engaging way of keeping interest and motivation.

  7. Optimised team work

    Reading time: 4 minutes
    Posted 6 years ago

    With the right processes and tooling, it becomes a lot easier to share code between developers. With the right amount of documentation in the right place, you also flatten the learning curve for onboarding developers to get up to speed. This reduces the risk that responsibility lies with a single developer (read: a single point of failure) and encourages developers to share, contribute, review and refactor code. Just make sure you have ample coverage so that you confidently can refactor, with minimal impact on existing features.

    Any software project tends to grow in complexity over time. Without a good development strategy, sooner of later the quality of projects can erode.