Paul van den Dool

Development is changing

2026-07-26T00:00:00Z

In February 2026 I walked out of a five-hour-long meeting that my CTO had named “Why should we still write code”. We discussed what it would take for us to never write a single line of code anymore and what that would look like. I remember coming out of that meeting feeling like we were on the precipice of a major shift. That my work would be drastically different before the end of the year.

I was not mistaken.

At my company we’ve set up a workflow enabling “agentic development”, an environment of agents and skills that you only have to feed a ticket describing a bug, improvement or feature. The ticket is analysed and a plan is written. A human reviews the plan and either forces changes to the plan or gives the green light to start implementation. After implementation, the human tests the work and reviews the code.

It’s terrible.

Not because of the code quality—which is surprisingly decent, though it’s hard to measure across so many changes—but because of the process. Reviewing code has always been part of the job, but it’s rapidly becoming all of the job. You hear people say that the work is now shifting from implementation to further up the pipeline, where you bring your technical expertise to refining the briefing statement. For some developers, the work might shift that way, but this isn’t the case for everybody. If you have 60 developers working on the software, maybe only about a quarter of them are included in the discussions where the feature description takes shape. The others are merely implementers, either not senior enough or simply not the type of people who think about the product that way. Those are the developers who especially love writing code, wrangling zeros and ones into a working product—and they’re the ones who will start to hate their jobs. They’re turned into reverse centaurs.

Reverse centaurs

I like how Cory Doctorow describes what’s happening. He mentions centaurs and reverse centaurs. Centaurs are workers that are enhanced by AI. They’re in control and use AI to augment their abilities and make their tasks easier. Reverse centaurs are not in control, they are in service to the AI—though not in the dystopian kind of way, not really. If all you do is check the work AI has done, you’re a reverse centaur. And being a reverse centaur sucks the fun out of work.

I wholly believe that making reverse centaurs out of your employees will have a negative effect on the quality of the software and ultimately your company. It’s too soon to confidently predict the fallout and it will likely be a combination of things. AI can generate a lot of code and seem very productive, but the number of bugs being introduced to the software will increase as well. Developers are struggling to keep up with the amount of code that needs to be reviewed. They’ll get lax, or they’ll fail to understand the code. Critical thinking is being outsourced and no developer truly owns the code that is being written. But it’s where the perceived monetary gain is at. If you can get AI to do most of the thinking, you can “right-size” (how I loathe that word) your engineering department by 30–50%—assuming that same 30–50% hasn’t already quit out of sheer frustration.

Centaurs

I’m not saying developing with AI is bad and will lead to bad code. Leaving aside everything wrong with the power-hungry data centres and the money-hungry companies financing it all, AI as a technical achievement is mind-blowing and it is the most powerful tool in a developer’s tool belt ever, full stop. But it’s only positive if it’s used like that: a tool. Something that enhances the abilities of a developer—augments them—makes centaurs out of them.

When used responsibly it can give junior developers wings. They will be able to do a lot more than previously would be thought possible. But junior developers would be wise to make sure they understand and own the code that they generate. When used responsibly it can make senior developers super productive.

Still fun

I consider myself fortunate. As a lead front-end developer, my role still has plenty of texture. I lead a platform team, improving our software’s shared library and underlying architecture. I align cross-functional teams, and spend a good chunk of my time executing work myself. When I use AI, I use it as a sparring partner, do analysis, or automate tedious work. I’m still learning, and I still like what I do.

But if you’re reading this and feel like you’ve been relegated to a reverse centaur, don’t accept it as the new normal. Talk to your CTO or engineering manager. In many cases, leadership doesn’t set out to make your job miserable; they just want productivity gains and assume “agentic workflows” are the best way to get them. If you can demonstrate that you’re a sharper, more effective, and happier developer when you’re driving the AI rather than babysitting it, most reasonable managers will listen.

And if they don’t? Well, you might want to ask yourself how long you want to keep holding the leash.

Preferred Array Type Notation

2026-06-25T00:00:00Z

My preferred way of writing an Array type is Array<string> and not the shorthand string[] and there are two short, simple reasons: Readability and Consistency.

Readability

The shorthand string[] is shorter than Array<string> and might in a codebase reduce visual noise.

const fruits: string[] = [ "Apples", "Oranges" ];
const vegetables: Array<string> = [ "Broccoli", "Brussels Sprouts" ];

A compiler reads them the same, but a developer reads them in two different ways: Array<string> is read from left to right, and string[] is read from right to left. "An Array of strings" versus "Strings in an Array". This difference is negligible for simple types, but becomes more noticeable on longer and more complex types.

const nerds: { id: number, name: string, hobbies: string[] }[] = [];
const geeks: Array<{ id: number, name: string, hobbies: Array<string> }> = [];

When reading the type for the nerds constant, you're reading an object and only at the end do you notice it's actually an Array.

When reading the type for the geeks constant, you immediately know the outer type is an Array.

We read code top down, from left to right; reading a type should be in the same cadence.

Consistency

Array is the only type that has a shorthand, other generic types don't. There's Map<T>, Set<T>, and Promise<T> amongst many others. Personally, I like things to be consistent.

Conclusion

It's a personal preference in the end. TypeScript's own documentation and frankly most examples I see only lean towards the shorthand. I find the Readability and Consistency arguments conclusive enough to go with the longhand form.

The choice starts to weigh more the larger the codebase gets and the more developers working on the project. Different people with different preferences on the same codebase gets messy fast. That's where it stops being about which form is "better" and becomes about picking one and enforcing it — the value is in the consistency, not the choice itself.

Dealing with new lines in HTML and CSS

2021-01-02T00:00:00Z

I've got 15 years of experience with CSS, but I've never really completely understood how the CSS property white-space works. This became apparent when working with new line characters that originated from a textarea. In my case it was a string returned from the database that had come from a textarea. The string looked like this: test↵with new line. The arrow represents a new line character. I had to display that string in a simple paragraph tag. But it displayed as a single line where the new line character is treated as a simple (white) space: "test with new line". I tried detecting the new line with JavaScript and replace it with a <br>, but I couldn't detect the new line properly. It took me a little while, but I eventually came across a small comment on StackOverflow that said "Just use white-space: pre-wrap".

Break on new lines

To break on new lines you have several options.

white-space: pre;

It breaks on new lines, but has some other behaviour you need to be aware of. It preserves spaces and tabs. You know how HTML normally collapses two spaces into one? This will preserve those. It also doesn't wrap. Like white-space: no-wrap. So when the line becomes wider than the parent element it is in, it just keeps on going.

See the Pen JjRLEpx by Paul van den Dool (@paulvddool) on CodePen.

white-space: pre-wrap;

This will also break on new lines, but unlike pre it will wrap within the parent element. And like pre, it will also preserve spaces and tabs, but will "hang" any spaces at the end of the line. See break-spaces next for more information.

See the Pen white-space: pre-wrap by Paul van den Dool (@paulvddool) on CodePen.

white-space: break-spaces;

This one is a lot like white-space: pre-wrap. It will break on new lines, it will wrap and it will preserve spaces and tabs. The only difference is with "end-of-line spaces". Spaces at the end of the sentence. With white-space: pre-wrap those spaces will "hang". This means that the space is preserved but if it causes the sentence to be wider than the width of the parent element, it will not wrap to a new line. It will "hang" over the side. With white-space: break-spaces it will wrap to a new line.

See the Pen white-space: break-spaces by Paul van den Dool (@paulvddool) on CodePen.

white-space: pre-line;

This one behaves the most like the default behaviour: white-space: normal. It will collapse spaces and tabs, it will wrap correctly and it removes end-of-line spaces. But unlike white-space: normal it will break on new lines.

See the Pen white-space: pre-line by Paul van den Dool (@paulvddool) on CodePen.

This last option is what I chose because of its default behaviour.

The other values

The white-space property takes five more values. Only two of those are what they call "keyword values" like the ones described above. The other three are "global values".

white-space: normal;

The default behaviour. It collapses new lines, so probably not the value you want if you are reading this. It also collapses any spaces and tabs into just a single space. It wraps so text stays within the parent container and any spaces at the end are removed.

See the Pen white-space: normal by Paul van den Dool (@paulvddool) on CodePen.

white-space: nowrap;

It behaves much the same as white-space: normal but doesn't wrap the text.

See the Pen white-space: nowrap by Paul van den Dool (@paulvddool) on CodePen.

white-space: inherit;

This will go searching up the DOM tree to the first parent element it can find that also has the white-space property declared.

white-space: initial;

This will set the value back to the default value. For the white-space property this is white-space: normal. You can use this in case you don't remember what the default value is.

white-space: unset;

The unset value in CSS resets a property to it's inherited value. If it doesn't have an inherited value, it will reset to it's initial value. For the white-space property this means that when you already have a block of CSS defining the white-space on an element but you don't want it to apply to that specific element while still maintaining any other styling, you can set the white-space to unset. It will then take any white-space styling from a parent element (inherit), or revert to white-space: normal (initial).

Here's a CodePen with all the examples in one place.

See the Pen The white-space property by Paul van den Dool (@paulvddool) on CodePen.

I liked writing this post, and I'm thinking of doing more of this kind of posts. Got a suggestion for a next deep dive? @ me on Twitter or send a pigeon.

Clean Slate

2020-05-02T00:00:00Z

I've learned something about myself recently. I work best on a clean slate.

I've always loved to format my computer and start fresh with a reinstall. I never ever put back any backups. I feel there is no need. Before I format I do of course check if I have any documents or pictures on the machine locally that are not synced to the cloud. But after the format I download some of the applications I'd like to continue using and I'll tweak my settings a bit so they're back to how I like them, but that's it. I feel like it gets rid of all the junk and unnecessary stuff that piles up after using it for so long. You can spend a lot of time searching for old stuff and deciding if it can be removed. Or you can reformat the computer and only put back what you need.
This also applies to reformatting my phone. I only download back whatever apps I'm truly using. It gets rid of those apps I download once and never use after a while.
It turns out this same principle, the same metaphor, can be applied to developing.

Refactor

At Maxxton we've reached a point in our software where we noticed the code wasn't that maintainable any more. Two or three years ago some foundational choices were made without knowing where we would stand two or three years later. The software has grown bigger than we anticipated and as a result the code is starting to form cracks.
In my team, several developers have been working on the same parts of the software for quite some time, adding or removing stuff as time went on. New clients came in with a different way of working that we wanted to support or we changed stuff based on new found information. The code slowly grew into a Frankenstein's monster and could be used as a school example of "spaghetti code". Bugs were common and it was easy to break stuff while working on a different thing.
So a bunch of weeks ago we decided to do a big refactor of one of the most error prone areas of our software. Use proper State Management and building the code while knowing what we know now.
Me and my teammates each got our own part to refactor and went ahead with this pretty massive job.
It turns out though that my teammates have a very different approach than me though.

Slow down and focus

I love doing the refactor. I get to revisit code that has been written a few years ago, possibly even by me, and make it better. Do you ever have that, when in hindsight you think of better ways to develop a particular feature? Well, I do. And normally I don't really get to revisit it, but now I do! And there's at least a year of extra knowledge in my head on how to do it better. It is very satisfying.
But it is difficult. Before tackling a certain page or component, I spend quite some time analysing it. How does it work? Is it supposed to work like that? What happens at every step? What stuff is still needed and what can be thrown out? Think of it as Marie Kondo for your code.
Do you know the proverb "not being able to see the wood for the trees"? The Dutch equivalent for that proverb would translate to "not being able to see the forest through the trees", which works slightly better in my opinion. This is often the same thing when looking at a large codebase. The amount of code can be so overwhelming that it's hard to figure out what it all is doing. It's more difficult to understand what all of it is doing if you're trying to take it in as a whole. For me, parts of the code I don't really have to look at at that moment are creating noise which hinders me from truly understanding the parts of the code I am trying to focus on. Isolating parts of the code helps me to focus on it. Therefore I always like to create an empty component or page next to the original and start fresh. I find it simpler to write everything again from scratch having the old code as a reference from which I can copy and paste if necessary. I can take pieces of the code and isolate them in this new component. I can start with improvements to the overall layout if necessary—which is easier if there isn't a ton of code inside them— and add pieces of the component or page back one at a time. And by checking every parameter while I type them in allows me to follow it and see if it's still necessary. Starting fresh on a clean slate forces me to slow down and helps me focus on one thing at a time. My head is much calmer than when it's filled with the noise of a whole lot of other person's code. Eventually the code in the new component will grow and grow but the code already there won't be as noisy as before as I already understand what it does and what its purpose is.

It might seem tedious

It turns out though that in my team I'm the only one that prefers to work like that. My coworkers seem to prefer converting components as they are. Rewriting bits and pieces to work with the State Management that we are implementing. That can work just fine, but in my experience you end up with a lot of old code that if you were to look closer, could actually be removed. In my experience it's also very hard to wrap your mind around all of the code to understand what it is all doing and what parts are needed and what parts could be further optimised or even dropped. So you end up with refactored code that you don't really know as well as you should.
In my experience it takes a fair bit of domain knowledge in order to successfully refactor code in this manner; Knowing what the code does and what it is supposed to do. But on large codebases or old codebases this domain knowledge is either lacking for new developers or everything is fuzzy for developers who are around longer at the company. In my case there could be parts I haven't worked on, or parts I did work on but have been tweaked and changed by others over time, or parts I simply forgot how they were constructed or should work because it has been a while since I worked on it. It happens more than I would like to, that I wonder who wrote that subpar piece of code only to find out it was me a year and a half ago. But hey, we all grow, we all learn, and we all get smarter over time. It's only in retrospect that we often know the full scope of the problem we are solving and how the solution we just build lacks or could have been built better. But it's a luxury if you get to revisit and improve on it. Most teams work with deadlines and customer expectations. Those working in agencies even more than we do at Maxxton with our enterprise B2B software. You sometimes have to make due with something that you could perhaps do a better job on if you got to revisit it.
In that aspect, even refactors can be constrained by time. Developers are expected to refactor a portion off the application within a certain timeframe. In our case at Maxxton we've already extended that deadline by a month and we're still not gonna make it.
My method might seem tedious and more likely to take up more time since I'm basically starting from scratch instead of modifying what is already there. But I beg to differ. The clean working area gives me the focus I need to fix the HTML groundworks. Things might have been added over time that I can now take into account when creating a better scaffolding. I get to revisit every feature and method one by one, figuring out how they work and how they're supposed to work without any other features interfering. I would say that that increase in focus and decrease in noise actually increases my productivity and efficiency. I can often copy paste decent chunks of code and in other cases I can type referencing the old code.
This new intricate knowledge of the code also helps me on the long run. I own the code more and if I were ever have to revisit again due to a bug or a new feature I would be better able to solve the bug or implement the new feature. I've already been noticing that in the short timespan that we've been doing the refactor. I've been able to quickly and accurately answer questions about how certain parts of the code work to other coworkers.

Give it a try

I'm not yet sure if this working method works best for all or just for me. Why else would I be the only in my team working like this, no? It could very well be a lack of domain knowledge on how it all is supposed to work that refrains my coworkers from also working from a clean slate. They might think all bits and pieces are vital. I don't know. I might bring it up during the next retrospective. If you yourself have been in similar situations, or still are, and you have any input on this I'll be extremely curious to hear. Or be sure to try it out next time and let me know then.

How I got into web development

2019-07-01T00:00:00Z

I always like other people’s story on how they started with webdevelopment. I’ve recounted mine often enough, so I thought, let’s jot it down.

I first came into contact with HTML in 2000, when CU2 became popular in the Netherlands. I was still in primary school. It gave you a personal landing page and a lot of control over the look of the page and what displayed on it. It was the wild west of HTML customisation, with GIF counters showing you how many people visited your page and all that 90’s goodness. I got good at styling the pages and was asked to help classmates with their pages.

The interest stayed, and eventually I was making websites from scratch. I can’t remember how exactly I managed, but there was a way for me to host one website on a free .dk domain. In the early zeros, I made quite a few websites on this domain. Mainly websites for MapleStory — the mmorpg I was playing at the time. It was still the time of tables and inline CSS, and I wrote it all in Notepad. I loved how HTML and CSS enabled me to build something. I kept self-learning by finding resources online.

The interest blossomed in secondary school with IT classes. At that time, Macromedia Flash (later Adobe Flash) was hot and happening. I must have designed 20 different versions of a personal website in Flash, but none ever saw the light of day.

I was 15 when I knew what school I wanted to go to next. I had found an education in line with my interests. With the level I did in secondary school, I could go to Research University, where they offered IT courses, but those were very technical, teaching back-end related programming languages. It was too technical for me. I loved the creative part — what I didn’t know was called “front-end”. So I wound up going to a University of Applied Sciences at age 18, where I studied Communication and Multimedia Design. I got programming classes and learned to work with Adobe’s software. I had drawing classes, and I did a minor in art history and another in 3D modelling. But they also had classes in what they called “Interaction Design”, but what I would have called “User Experience Design”. That particular direction definitely piqued my interest, and I started learning about more than what they could teach me at school by reading a lot of articles and blog posts.

My first real job after school was heavily UX related, but lasted less than 4 weeks due to a terrible boss creating a toxic work atmosphere. I ran screaming. But it turned out to be a great choice. I ended up working at this awesome little studio, where I could work on websites for a few restaurants, a major Michelin star chef, and other interesting projects. It was a fun small team that gave me a lot of responsibilities and valued my input. I eventually went on to a different company, my current company, where the role is a lot more technical. I wouldn’t call it webdevelopment anymore, even though I’m building in the browser — I’m now doing proper front-end development. But still, at its core, it feels the same as when I was tweaking CU2 pages in Notepad: shaping something out of nothing and watching it come to life.

Intuitive Design Is Hard

2019-05-04T00:00:00Z

There is a video going around on Twitter recently about two teenage boys who are asked to make a phone call on an old rotary phone. TLDR; they fail miserably.

*{padding:0;margin:0;overflow:hidden}html,body{height:100%}img,span{position:absolute;width:100%;top:0;bottom:0;margin:auto}span{height:1.5em;text-align:center;font:48px/1.5 sans-serif;color:white;text-shadow:0 0 0.5em black}▶" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen title="17 year olds dial a rotary phone" loading="lazy">

The video is a prime example of how difficult it is to create intuitive design. There is no one real answer to what actually makes design intuitive. That all depends on your user and what they would consider as intuitive. And like in the video, the intuitiveness of a design can become outdated with time.

Let's first look at what the definition is of intuitive design. I like the explanation Jared Spool gives. It's when the target knowledge, the knowledge needed to use the design, overlaps with the current knowledge of the user. Or when the design has enough signifiers to bridge that gap without any significant mental effort by the user.

Take for instance a door handle. You've probably learned how to use a door handle long before you could even reach it. You've seen your parents or older siblings do it a million times but you're just not tall enough to reach yet. Once you're tall enough though, your current knowledge is enough to perform the task of opening the door.

Recently I had to turn the door handles of some of the doors in my house upwards because my youngest was able to reach them and we don't want him wandering onto the street in an unguarded moment where we didn't lock the front door. Suddenly there was this gap between my current knowledge and target knowledge, however small. I suddenly had to keep my hand in a different angle and the vertical motion to pull the handle down suddenly turned into a horizontal motion. But luckily there were enough signifiers. The handle still looked the same, it was just at a different angle. I knew that it would rotate the same direction. And I still had the knowledge of how the mechanism inside a door works that helped me in understanding how the angled door handle would work. My eldest boy had some more difficulty in bridging that knowledge gap.

But not all things are as common as a door knob. Especially digital products. Where door handles or door knobs haven't changed much since the 1800s, computers and the internet have only been around a few decades and have changed a lot. Digital products have often only been around for a few years and have already changed even more so. In this area the knowledge gap can be enormous. To make this gap smaller, digital products relied on metaphors; a resemblance to a physical object with similar traits. Only up until a few years ago skeuomorphic design helped in this. Apple did this like no other. Take their note app for example. It had a lot of visual cues it borrowed from an actual note pad. It even had this edge of torn paper at the top as if there were already some sheets of paper used and torn off. Buttons needed to look like buttons, like they afforded to be pushed down. Since a few years we've stepped away from skeuomorphic design in favour of flat design. I'm not going into the pros and cons of flat design, but the reason we could make that step from skeuomorphic to flat was partially because the knowledge gap was small enough. A flat button doesn't look anything like a real button, but it has enough of the traits of the skeuomorphic button that people can make the association quite easily. We're so accustomed to digital interfaces that nowadays we don't have to make the association with physical objects anymore. It's more about convention, how familiar users already are with certain patterns and their mental model, how they expect it to behave based on prior knowledge of similar products.

Before designing anything you should have an intricate knowledge of your user. What are these conventions your users are familiar with?

In case of the teenagers in the video clip, it's easy to say they have never seen a rotary phone before. At least one of the two does seem to recognise the horn for what it is.

It's also a fine example that even something as common and institutionalised as a phone can be unintuitive. At least, dialing a number on one can be. Designers should never assume their current knowledge is the same as the users' current knowledge. The thing you're designing may very well be less intuitive than you think. Creating something intuitive requires careful thought and plenty of research. Creating something intuitive is hard.

Reaction To CSS Tricks Newsletter on Using Data

2019-04-25T00:00:00Z

Robin, who writes the CSS Tricks' newsletter each week, talks about data (analytics) in the intro of the newsletter (issue 142) and shares his take on it. In his opinion, we collect too much data. He wonders why we even need analytics. Why we need to know the users' viewport sizes. Why we need to A/B test the colour of a button. In his experience, it's often used to justify not supporting certain browsers or browser versions because only a small percentage of users is using it.

I acknowledge that there will always be some executive that will only think about the bottom line and will make the trade-off for not spending resources on something that will have very little immediate return on investment. I agree this is the wrong use of analytics and that it's bad for the user and bad for the company in the long run. I also agree that a lot of the data that is collected is unnecessary. But what I certainly don't agree on is what Robin says next.

If anything, it prevents us from iterating and confidently making changes. It makes us think twice before we do things and it slows us down immensely from improving an interface. Data alone won’t make better websites.

How would you make changes confidently that will improve an interface if not backed by some data? How would you even know what needs improving and how it can be improved, if not for data. I would say yes, think twice before you do things. It's said by people smarter than me that it is more costly to rectify a mistake than to properly research the correct solution. Data alone won't make better websites, but it can point you to areas that need addressing. Some people use an obscure browser and you want to include them as well in the experience. A growing number of users is using a large viewport you never tested the website on. Your layout might break on those sizes or you could do so much more with the extra space.

See what I did there? I basically reversed what Robin said. It's not about the data, it's about what you do with the data. The bit by Robin feels as if he is throwing the towel into the ring. Why even bother if the data is only going to be used in the wrong way? I say you need the data, collected in a responsible way, in order to make sensible decisions on how to improve a website or application. But data alone will not help you do that. It also requires the intention to actually do something useful with the data and the right people to interpret it.

Sliders Are Bad Practice

2015-08-15T00:00:00Z

This post is my reaction to seeing more and more numeric or range sliders in web- or mobile design used for the wrong reasons.

A slider is a good choice when you know that users think of the value as a relative quantity, not a numeric value. For example, users think about setting their audio volume to low or medium—not about setting the value to 2 or 5. — Microsoft

I hate saying this, but listen to Mr. Microsoft. Using a slider to select a specific number is horrible, on touch devices even more so. The larger the value range on a slider, the easier it is to select the wrong number. Like Mr. Microsoft says, using it to select a relative quantity is OK. Only people with certain compulsions will want to set the volume to an exact number. Or maybe people who know eighty is the perfect volume on their TV when watching their favorite show on Netflix. When I’m ordering beer at the bar I’m not like “Five to ten beers please”. I want six for me and my buddies and I don’t want it to order like “Five beers, no eight, wait, seven, no six beers please”.
So please, only use sliders when users have direct feedback on the change. Like the changing of the volume or the changing of the brightness.

What should I use then?

When deciding on your input method consider the value that needs to be entered. If you want to restrict the user you could use radio buttons if the restriction is up to four values. For anything more than four values I recommend using select boxes (or custom drop down list for more creative freedom). If you don’t want to restrict your user, just use a input box. HTML5 has a special numeric input type which even gives you the option to set a minimum and maximum value.