An insightful conversation with our Tech Lead, Harmen Janssen

When I began working at GRRR in 2008, it was already a highly passionate and informal environment. I would describe GRRR back then as the ‘wild west of design.’

As I gained a lot of experience, I found joy in being a sort of mentor, helping junior developers when they needed it. The biggest difference between me and a junior isn’t that I type faster but that I have made more mistakes, giving me a broader perspective.

Originally, I wanted to be a comic book artist. However, that dream gradually evolved into a more practical career plan, leading me to pursue multimedia design at the Graphic Lyceum in Eindhoven. I quickly discovered that design wasn’t my forte, but code seemed dull at first— black screens with white text. That perception changed when I encountered Flash during my first year of school. I discovered its interactive potential and how code could influence design.

Flash doesn’t exist anymore, but it sparked my interest in coding. I realized coding is another form of design. I started with Dreamweaver at school, a visual website building tool, but typing coding by hand attracted me more. Once that interest was piqued, I read a lot of books about coding on the train to school.

During my final year of school, we had a week of workshops. I was assigned to a group led by Rolf, GRRR’s Creative Director.Our task was to develop a Flash application controlled by a dance mat. At the end of the week, Rolf said, ‘Once you’ve completed your education, reach out to us.’ And so, that’s how it all began.

When I began at GRRR in 2008, it was like stepping into an incredibly passionate yet informal environment—a place I’d describe as ’the wild west of design.’ It was an incredible experience. Everyone was deeply passionate about the projects and the company.

Due to limited experience and no project management, there were times, like on Mysteryland, when we worked until 3 AM just to get everything done. The motivation was sky-high, and the atmosphere was vibrant, so the late hours didn’t bother us. Gradually, we started to plan projects more effectively and optimize our workflow.

There have been substantial positive developments. The rise of mobile phones brought significant changes, especially in making websites responsive. Developing responsive sites that adapt to various screen sizes, from mobile to widescreen desktops, became a game-changer. It is the most common thing nowadays.

Museumnacht was one of the first websites we made responsive—a pioneer in the Netherlands. This innovation opened new possibilities, allowing visitors to use the website on their phones while out in the city.

Another major change was our focus on static websites. In the past, everyone built monoliths—single large applications where the website, CMS, and all related services were in one codebase. Now, we decouple that. The CMS becomes ‘headless,’ and the website becomes static. This results in faster, safer websites with lower hosting costs. Front-end developers can work independently of the CMS, thanks to API separation. It’s more efficient because you can iterate easily on the specific part you’re working on.

I’m currently working on Schoolwijzer, a project that’s been ongoing for about 10 years, and I’m still thoroughly enjoying it. We started by digitizing a physical school guide and transformed it into a website with an Open Data API and many integrations with government systems. Right now, we’re developing version 2 of the website, using a completely new stack and design.

Working with microservices is one of those insights. When we worked on the first version of Schoolwijzer, ten years ago, we realized it would be an ongoing project with numerous future updates. To prepare for this, we started decoupling interactive elements from the website so that we could adjust them separately in the future. We still use this strategy. By treating various website components as microservices, we can optimize specific elements and manage and adjust the whole more effectively, providing greater flexibility and optimization possibilities.

Absolutely! Take lots of notes—that’s number one. Invest in a system to document everything so your brain doesn’t have to store it all. Secondly, continuously learn and expand your skills, but also understand that many passing trends are just that—trends. A strong foundation in HTML, CSS, and JavaScript, along with a solid understanding of software design principles like Domain Driven Design, will take you further than testing the latest JavaScript framework every month.

Another valuable tip is to contribute to open-source projects. When your work is visible to everyone, it forces you to be critical of your code and consider more scenarios: what if someone wants to use your tool differently? What adjustments can you make to help others integrate your work into their projects?”

A mistake that’s both frustrating and enlightening is sharing something on production (live websites). I was once in a rush to fix something for a client, I logged into a production server and typed a message for myself, like ’test,’ to check if it worked. That’s not a big deal during development, but on a production server, it’s a big no-no because it immediately goes live. And that’s precisely what happened. A silly message, as I usually write, but on a live site. I’ll never make that mistake again, but it taught me a lot in my younger years.

I once accidentally deleted a production disk due to rushing. Fortunately, there was a backup. However, the most crucial lesson I’ve learned, and one I believe everyone can benefit from, is to take your time, avoid rushing, and prioritize attention to detail.

I’d like to support junior developers. I enjoy being some sort of mentor, letting them know they can come to me whenever they need help. With my experience, I find it rewarding to tackle problems together with juniors. The biggest difference between me and a junior isn’t that I type faster, but that I’ve made more mistakes, giving me a broader perspective. I can look at a small piece of code and offer input from a larger perspective, which I find gratifying to share with juniors.

PHP is quite stable. A few years ago, I was critical of PHP for lacking features I needed. I’m highly interested in Functional Programming. Languages like Haskell have features like type classes and currying, which are great to work with. PHP was lacking those, but it’s been developing well, and frameworks like Laravel make it one of the most productive languages to work with.

The rise of TypeScript is fascinating, bringing type checking to JavaScript, ensuring code integrity before publishing it. Lastly, I’m very intrigued by the Svelte framework. We currently use React, but Svelte impresses me with its performance and developer-friendliness.

Twitter is a hub for developers, but it can also be distracting and sometimes negative.

So, find a good RSS reader and subscribe to blogs that regularly publish quality content. Also, check out our tech blog! We maintain a list of inspiring blogs there.

I also enjoy listening to podcasts like ShopTalk Show, Syntax.fm, and The Bike Shed.