Introduction
Hi, I’m a software developer with over 10 years of professional experience, currently focused on Unity3D and .Net ecosystems. My favorite part of the job is tackling those hard to solve problems and creating the right abstractions and tools for other developers to use.
My experience in Unity3D ranges from (serious) games to simulations and business apps, to XR and VR targeting different industries like healthcare, automotive, industrial, aerospace and defense. I’m also a big proposer of extending the Unity3D editor in order to allow for better integrations with custom tooling. So I have great understanding of Unity3D editor plugins and extensibility.
Additionally, as with any modern applications; many Unity3D apps come with back-end web-services. I don’t shy away from back-end tasks or even CI/CD work as I want to see my task through and deliver something that closes the loop of the Unity3D tech-stack.
When I’m not coding, I’m probably spending time with my family, working out, reading, blogging, podcasting or doing more coding.
Background
I currently work as a software engineer at TomTom in The Netherlands which is an international company mostly known for it’s handheld SatNav’s in cars. Currently they focus on many different markets. I work in a team called the Map Visualization Unit where we build API’s that other teams consume to build apps and other great software.
The content and opinions of this blog are my own!
I blog about programming, software quality, software development processes, programming language design, culture & ethics and general technology. My field of expertise is in the .NET space, mostly C# with Unity3D. A bit of C++ and of course bash and python for anything CI/CD. I also do some hobby projects in Clojure(Script) F#, Lua, Kotlin and Java. I am a strong believer that code is written to be read by other programmers, so I focus on code quality, readability and maintainability while making sure software is built according to it’s requirements.
I have been using Unity3D ever since version 2.5, and that is over 13 years already… time flies… and I have built many 3D simulations, games, libraries and editor plugins for Unity ever since.
Previously I worked as a (team) lead Unity3D developer at a company called Dephion where I was part of the front-end (Unity3D) team. We built a lot of cool technology but I will refer you to this page for further details. My job before Dephion was at a company that made 3D simulations and serious games. There I started as ‘full-stack’ developer, meaning I did some back-end work in PHP (Symfony) and front-end work in Unity3D. However, as the company grew my work shifted more towards Unity3D.
Education
After high school I started studying game development in Eindhoven, The Netherlands. Here we mostly did C# and XNA game studio, but we also used Adobe Flash + ActionScript 2.0 and 3.0 (yuck). I first started to use Unity for my graduation project. After I graduated I started to study for a bachelor’s degree in software development. This was mostly C# with some JS, C or C++ here and there. Then I wrapped up my studies with a Master’s degree in software development. I have learned a great deal from my master’s and I graduated with a thesis on protocol languages (which are special purpose languages to express multi-threading protocols, but that’s probably a topic for a blog).
Interests
As I hinted at before, my interests lie in software and code quality. I strongly believe that code must be readable and able to communicate it’s intent in order to provide good quality software. The main subject of the blog will probably be very closely related to this matter. I like to build frameworks and tools that solve difficult problems for other programmers to use in order to make their life easier, all in the name of improving the quality of the system. This does not have to be in C# + Unity3D, I also like other languages like C++, Bash, Python, HLSL/LLSL, Clojure and ClojureScript, Kotlin, Java and lately also F#.
I also like to read books about software development, architecture, processes, evolution and life-cycle, programming languages and language design. There are so many great books written, and still being written, about software. It is hard to keep up since there also is an endless stream of research papers being released.
I also enjoy watching conference talks on software engineering in my free time and I listen to podcasts mostly during sports or commute to work.
Things I’m good at:
Leading
Taking an idea and making it come to fruition, batteries included. Transferring my knowledge through coaching, mentoring and teaching.
A strong team needs strong leadership, however “flat” the organization might be. There is often a need for someone to keep things together and steer towards the targets on the horizon. Over the years, people have described me as a calm person who’s able to uplift the team through good communication and broad technical knowledge. My style of leadership leans heavily on three aspects: integrity, trustworthiness and empathy. Why empathy in a business setting, you might ask? Well, I’m a developer too and I know some requirements are a b*tch to estimate let alone be implemented. Furthermore, integrity and trustworthiness are at the core of good leadership. Communication cannot go smoothly if any are off-center.
Also, being from the generation who’s lucky enough never to have worked with the waterfall method in a professional context, agile methods are second nature. I like the iterative style of working and organize both my work and the team’s work around the agile practices. A big part of agile is also coaching and/or mentoring which I’m a big fan of. I think this lowers the bar for juniors to ask questions. If coaching and/or mentoring is not part of the flow in the team, juniors might be scared to ask questions.
Team Play
Augmenting a team as a developer, upping the standard and accomplishing great things.
Depending on the project or context, I may or may not take lead. I’m perfectly fine with either a lead role or augmenting the team as a developer, as long as opinions of team members are heard. We don’t want the “ivory tower” architect to rule us all. I’ve worked in many teams of different sizes and structure, on-site, remote or hybrid. My intrinsic interest into software development best-practices and processes helps me being a good team-player (or leader).
Additionally I enjoy picking up the hard to solve problems. I like writing abstractions in the form of libraries, frameworks or tools to make the life of other developers easier. I’m also a big proposer of continuous delivery through proper CI/CD pipelines. These speed up development, big time. Although this is very challenging in a Unity3D context because, it’s not just code that can totally wreck your game/app. A simple change in colliders, lighting, world-design can break “everything”. So a pipeline will most of the time still involve exploratory testing by QA folks (which is a good thing).
Architecture
What is the best architecture for your application depending on the type of app, team structure and topology, experience level and company culture?
Architecture and Unity3D applications often don’t mix very well. That’s why I’ve taken a very strong stance towards having proper software architecture in Unity3D apps. Software architecture is a very important topic, both in “traditional” business software and also in games. But choosing an architecture is not always as easy as it sounds. Depending on the application, team structure or topology or even seniority and company culture you might choose one architecture over the other.
Having worked in different teams and setups I’ve come to recognize which architectures might fit well in certain situations. If you have somewhat of distributed teams a component based approach might be best since everyone is able to work in an isolated manner. If the team has a higher ratio of designers and artists than developers, a ScriptableObject (SO) architecture often fits nicely since designers are able to play around with SO’s easily, and thus do not have to edit code. On the other hand, if the ratio’s were inverted, a code-first solution is often more suitable.
Then, depending on the app we might choose an architecture that orients around performance or predictability/stability. For example; if the app is fast-pased with real-time interactions or leans heavily on physics, a reactive architecture is often a very good choice. But if it’s a simple slow-pased 2D puzzle game, a more traditional architecture like MVC/MVP might be perfectly fine.
Custom Tooling
Developer productivity is all the rage these days, and will increasingly take a more prominent role for developers. Custom, fine-grained tooling will offer solutions and open up new possibilities.
A topic I hear being mentioned very often lately in podcasts, conference talks, videos or blogs is developer productivity or “developer excellence”. This really got it’s foot on the ground since “things” happened in 2019-2022. Developer productivity has taken a prominent role and will grow even more in the near future.
Now, being in game-dev for quite a while we’ve recognized this a long time ago. A big part of game-dev is writing custom tooling to support designers or artists in their work. Think about the tools designers are able to use like the Unity3D animator, terrain tool and the little things like the custom import settings for assets and most importantly, the scene editor and inspector.
As a developer I’ve taken this a step further and honed in on the skill of writing custom technical tooling. I really like the ability to extend the Unity3D editor any way we see fit. I’ve written my fair share of plugins/add-ons for the editor and I think this is a great skill to have for any (Unity3D) dev.