Last year at the SymfonyCon conference I did a talk about Domain-Driven Design in which I mostly focussed on the theory behind trying to understand what problem you're actually solving. I really enjoyed doing that talk, but I got some interesting questions afterwards about practical implementation of DDD when using Symfony. And I've also seen at several clients that people are always looking how they can actually implement a DDD approach when building software with Symfony.

That prompted me to consider what would be the best way to do this. There is so much to talk about and the answer to a lot of questions is "it depends". So I decided to develop a new full-day workshop about this. In this workshop, we take a Symfony project, and we start adding some functionality.

I am still developing the contents, but things that will come by are amongst other things:

• How to split up domains
• Implementing a hexagonal architecture
• Doctrine entities vs domain entities and how to make that split
• How to implement communication between bounded contexts and domains

The workshop will contain a theoretical part per subject, but also exercises for people to actually get some experience with doing this, as I realize that some people learn more from listening to the theory and others learn more by doing.

If you are interested to get this training for your team, shoot me an email. For those coming to Vienna for SymfonyCon, I do have some good news: On December 4, I'll be doing this workshop at SymfonyCon. You can already book your tickets.

Will I see you in Vienna?

Conferences are both fun and useful. Fun because you meet people and useful because you learn stuff. I have two conferences in the upcoming months, and I hope to see you there!

Cakefest

Last year was my first Cakefest. It was in Los Angeles, and a lot of fun. While I am not using CakePHP and have not used CakePHP in a while it was good to meet the community and share some information that might be useful.

I am honored that they think I did good enough a job to be invited back again this year. And even better: I don't have to fly out, I am actually driving to Esch-sur-Alzette in Luxembourg. The schedule is looking good! I will be doing my talk on sustainable open source contributions there.

Tickets are available for the in-person conference, or you could even get a free ticket for the online stream of the conference. But in-person is usually more fun, so if you have the opportunity, join us!

API Platform Conference

Another conference that I got invited back to is API Platform Conference. Again in driving distance for me, and I had a lot of fun last time, so I'm absolutely looking forward again to being there. The conference is in Lille, in the North of France.

In Lille, I will be doing my Domain-Driven Design basics talk, which focusses on what I think is the most important part of DDD: Understanding the problem. Lille is a beautiful city, the schedule is amazing... I'm really looking forward to it.

This conference also has both in-person and online tickets. If you have the opportunity, I'd love to see you there!

When you have an application built on top of an existing framework, then it is very tempting to just leave it be once the initial development is done. Never change a winning team, right? So once you delivered the project and it's running in production, the only thing you need to do is to add or change features and fix some bugs. Right?

Well, for a long time you can indeed do that and it won't hurt you. But in the long run, this will become a problem. Because while your application stands still, the world around you moves on. And that moving on includes new versions of your framework of choice. And as new versions come out, support of older versions will at some point be dropped. For big, popular frameworks there is usually a pretty clear release schedule of when new versions come out and how long old versions are being supported.

In most situations there is a phased end of life. First, active support for bugs will be dropped but security issues will be fixed. Eventually though, security issues will also not be fixed anymore.

If at that point, your application is still running on that old version, you are at risk of security issues which can lead to, amongst other things, damage to your public image or even legal action in case of security breaches. It is important to do regular maintenance and upgrades of any software you use. Whether that is the desktop software you use, frameworks and libraries and anything else.

However, because of a lot of different reasons, you can end up with an application that is years old and a lot of versions behind the current stable version. So what then?

Quite a few of the projects I've worked on in the past years have in some way or form included a situation like this (or I would see this coming in the future). There are two important approaches here, with different variations of those approaches.

Approach 1: Upgrade step by step

Let's take the example of an old Symfony project. It is stuck at version 3.4 of the framework. With Symfony 7.1 out now, one approach could be to do a step-by-step upgrade. This would mean going from 3.4 to 4, then 4.4, then 5, then 5.4, then 6, then 6.4 and then finally to 7 (either directly to 7.1 or via 7.0).

This may sound like a lot of work, and it is! So it's important to understand how to make the decision to go for this approach. What I've found is the most important factor to decide on to take this choice is the size or complexity of the project. This approach is mostly interesting for projects that are really big or very complex in terms of logic.

Requirements

Before you even start with such a massive project that is hard to estimate in terms of time and effort is to make sure that at least you can ensure your work was done correctly. So you need to have:

• Good documentation of what the application does, preferably including developers with a lot of experience with this application
• A good set of tests. Preferably a combination of unit tests and integration tests
• Support of your organization and most importantly, your management

If you don't have one of the above, make sure to get it. Documentation can be obtained by talking to developers that have worked on the project, but also business stakeholders and most importantly: users. Make sure that you have a clear understanding of the expected behaviour. You can use this information not just to understand what happens, but also...

To write tests! If you don't have a comprehensive test suite of unit tests (especially for important business logic) and integration tests (at the minimum as smoke tests to quickly see where potential trouble is, but preferably that actually tests your user experience), before you even change a minor version of your framework, start writing tests. The lessons learned from requirement 1 can help you with this requirement.

Last but not least: Management really needs to support the effort. It's important that they understand why it is necessary to be running on a recent and supported version of the framework. Explain to them the risk of hacks but also the extra effort needed to build new features into such old versions. The new, modern features that may be available in newer versions, etc. Without solid support from management, at some point priorities will change and you'll be stuck with a half-upgraded project.

Go go go!

Once your requirements are met it's time to do the actual work. This will most probably take a big effort. Especially with the example I used where you go from Symfony 3.4 (which does not support PHP 8) to Symfony 7.1 (which requires PHP 8). This means that along the way, you're not just making the jump from one Symfony version to the next, but also the jump from one PHP version to the next. And you don't just do that for your framework, but also for any other libraries you're using. Adn the dependencies of dependencies might start clashing.

To make this as easy as possible, you need to really take smalls steps at a time. Usually inside a major version it's relatively easy to upgrade, so for instance from Symfony 4.0 to Symfony 4.4 is relatively easy. Once you're on the last version before a new major, it's important to check for all deprecations: In case of Symfony, the next major is usually the same as the .4 version, but without the deprecations. So work on getting rid of all deprecations before going to the next major version.

Whatever you do, use static analysis tools to help you! Running PHPStan will help you catch potential issues. Also, Rector is your friend. It can help you automate fixing issues in your code and upgrading to newer versions of your framework. There are a lot of preset rules to help you in the process of upgrading, and you can extend Rector with your own rules as well for changes specifically needed for your project.

The result

If you have the time, the result should be an application that is running on the latest stable version of the framework, including completely adhering to modern code structures etc. However, since this is usually a very big time investment, I see it happening a lot that the upgrade of the project is done, but also refactoring to modern structures and approaches is not done. Which may make economic sense, but may still make the codebase feel a bit clunky and old-fashioned, even if it works and it on the latest and greatest.

Approach 2: The big bang upgrade

This second approach is, in my experience, mostly useful when your project isn't very big or complex. With this approach, you will have to touch most of the code in your project in one way or another. In this approach, instead of doing all the individual steps of the upgrade, you basically start over, but with the code you already have. So, let's use the same example of a project built on top of Symfony 3.4. Instead of doing the whole flow of Symfony 4, 4.4, 5, 5.4 etc, you just create a fresh new project on Symfony 7.1, then start moving the code from the old project bit by bit into the new project.

Requirements

Not surprisingly, the list of requirements for this approach is similar as the previous approach:

• Good documentation of what the application does, preferably including developers with a lot of experience with this application
• A good set of tests. Integration tests are the most important in this approach
• Support of your organization and most importantly, your management

The good documentation is perhaps even more important in this approach, since the developers working on this upgrade will actually touch all the code in the project. In the first approach, they will mostly touch the integration between custom code and framework. Here, all the code will have to be touched.

For tests, the most important one may be integration tests. When using this approach you usually not just copy over code, but actually also refactor it to modern code structures and apply newly learned patterns and architecture, unit tests may or may not be very useful. There's a good chance that the changes in code structure require you to write new unit tests or highly alter existing unit tests. The integration tests, however, are there to test if the application still does what it is supposed to do. So those are the most important in this approach.

Support from the organization and especially management is actually the same as in approach one, but it is worth mentioning since I've really seen projects like this fail because this support wasn't obtained before starting the project.

Here we go!

So... now to get started. You start with a fresh Symfony 7.1 project. In my example, we started with Symfony 3.4 which still had a structure of bundles inside the application code. A good approach is to migrate the bundles to non-bundle src/ code. Be critical of code placement and naming. In Symfony 3.4 times a lot of developers had the inclination to use very technical terms when naming namespaces and classes, while these days even if you don't do full Domain-Driven Design, it is still common to use domain-based names for namespaces and classes. You don't have to make these changes but since you're starting from scratch, it may be worth the little extra effort while you're copying over code anyway.

Just like in approach one, PHPStan is your friend. Rector maybe less so although it can still help you with your tasks, but PHPStan will be there to ensure the newly written/copied code is built on modern standards and methodologies.

Think about what you do. Don't mindlessly copy over code and adapt it to fit into Symfony 7.1. Focus on building things the way you'd do on a fresh new project. This will make your code a lot more future-proof.

The result

When taking this approach, the chances are a lot bigger that at completion of the project, the code is not just "working" but also built according to the latest best practices and standards and is ready for the future.

Upgraded, and now what?

So you've done the upgrade, whichever approach you took, and now what? The most important is to not get into this situation again. Make sure to stay up-to-date by doing regular upgrades. Make this part of your regular maintenance work. Because small steps are a lot easier than a big jump. And the smaller the step, the easier it is. Since the release schedule of a lot of frameworks and libraries is openly available, you can even schedule most of the work.

Alternatives

If you want to stick with the same framework (in this example: Symfony), the above two approaches can work well. But there are alternatives. You can for instance start a new project, run that parallel to your existing application and then carve out specific sets of functionality. This approach can be complex when code hooks into other part of the code. But it will allow you to spread out the effort of upgrading/rewriting over a longer period, which may make it easier for a business to deal with the cost of the project. There is a risk though: I've worked for companies that took this approach several times and ended up with 3 or 4 different codebases that each still handled part of the logic.

Another approach could be... but this will sound scary, to literally throw away everything you've done so far and start from scratch. Be really careful when you're considering this. While this approach will probably deliver the best, most high-quality product at the end of the project, there is a lot of risk involved. Hidden functionality that no-one knows about may be forgotten, and the project may end up being so big that management is not willing to invest any more money into it, resulting in having an even older codebase in production and a half-finished new codebase that will never be used.

You mention Symfony, but...

... I use Laravel, CakePHP, Drupal, or another foundation for my software. Well, good news, while I used Symfony as an example here, you can apply these approaches to basically any software project. You don't even have to use PHP to apply the above.

Mannheim is a great place to be. I've been there to keynote the unKonf, I've been there to speak at the usergroup, I've even been there to do merch for Amanda Palmer at the Maifeld Derby festival. I love going to Mannheim. It's a beautiful, welcoming city with cool people.

As such I am excited to be going there again this month. I'll be there from April 17 to April 19, doing two presentations. First, on April 17th I'll be speaking at the PHP User Group Metropolregion Rhein-Neckar. I'll be doing my DDD talk there.

Then, on Friday the 19th I'm really excited to be part of another Sylius event: Sylius Days. I love Sylius and I'm happy to do my talk about doing open source contributions as a business there. With people like Oliver Kossin (who is also speaking at the usergroup on Wednesday), Stephan Hochdoerfer and Łukasz Chruściel there it promises to be an amazing event.

The great thing is: Both events are free to attend! So RSVP for the usergroup and Get your free ticket for SyliusDays. I'll see you there!

After several COVID-years of online conferencing and an earlier announcement that "Dutch PHP Conference" would remain online, some developments favorable to organizer Ibuildings meant doubling back on that decision. A lot of Dutch PHP developers, including myself, were really happy with that. And it was indeed glorious to meet again in a physical space with a big part of the Dutch PHP community.

The fact that Dutch PHP Conference was now organized together with AppDevCon and WebDevCon also resulted in some great cross-pollination. It's great talking to people from outside your "bubble".

Being invited to speak was another bonus for me. I was invited to speak at EndPointCon last year but had to cancel that last-minute because of a nasty stomach flu or something like that. So being to come back and speak was fantastic.

The talks

I watched quite a few talks from the DPC schedule, although I did make a little trip to one of the other tracks.

Using Open Source for Fun and Profit

We started with the opening keynote by Gary Hockin, a speaker that I know as very entertaining but also putting across a serious message. In this keynote, we walked through Gary's life as a developer, but also learned about the role of open source in all that. Very relatable at times, and in my talk on Open Source I could even reference Gary. Great talk!

Crafting a greener future with PHP

Then it was onwards to Michelle Sanver. I try to make a change through my involvement in XR, but as a developer I also have a responsibility to make this world less worse, and as software developers we can also make a change. That is the important message I got from this talk. Michelle gave some great background on the how and why we should make a change. My biggest take-away was something I had never considered: We are used to running cronjobs at night. In some countries (such as Sweden) this is great from the perspective of green development, because there is less energy usage at night and the hydro-plants keep producing energy there. In The Netherlands, however, at night there is not a lot of renewable energy. Instead, at night the majority of electricity is generated using gas plants. So running heavy tasks at night is actually not good. Thinking about the location of your servers and how energy is generated there is therefore a good way of putting less stress on nature.

We need to talk about sitting

The next talk I saw, or should I say participated in, was the talk by Laura Broekstra on sitting. 2 minutes into the talk we heard we sit too much (the Dutch are apparently world champion in the amount of time they spend sitting) so we got told to stand up. We should for the remainder of the talk.

Laura confronted us with some facts about sitting and how her team has made huge changes in the amount of time they spend doing things other than sitting, including all kinds of exercises. The talk ended in an actual exercise where everyone in the room had to join in on some squatting exercises for a couple of minutes.

I really enjoyed this talk and need to really evaluate how I spend my working time. I also think more conferences should give this topic some attention.

Offline first!

After lunch I went to the talk by Rowdy Rabouw on offline first applications. I am far from a front-end developer but I feel it is my responsibility as a backend developer to at least try and stay up-to-date with developments in that area, and the way Rowdy showed you can use service workers in the browser to do a lot of local caching was really interesting. And to be fair, I also went to this talk because I really enjoy the style of presenting that Rowdy has.

Evil Tech: How Devs Became Villains

After my talk I stuck around in the room to see Sergès Goma explain how devs can become villains. This was a very entertaining talk (including some developers actually coming to the front to do evil villain laughs) on a very important and underrated topic: ethics. This talk gave a lot of food for thought. Sergès delivered this really well.

Community, PHP and us: Growing up

I ended up with the second time Michelle Sanver (I support the idea of a MichelleCon), this time with Michelle doing the closing keynote with her story. Her story of becoming a software developer is very different from the story we heard from Gary in the morning. Well, there were some similarities, but Michelle also shared some very negative experiences she encountered along the way. We should learn from stories like these, and make the community an even better, more welcoming place. For everyone.

Next year!

After the keynote it was announced that Dutch PHP Conference will be back again next year, and I'm already looking forward to it. Will I see you there?

I have been under a lot of stress. Not just in work, also in my private life. I'm also very worried about the state of the world around us, the community we live in. And I am someone that tends to worry. I have a hard time with the mantra "grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference." I have always been feeling stress but lately it's been higher than ever.

Courage to change the things I can

As part of wanting to change the things I can, I have been actively protesting during Extinction Rebellion protests in The Netherlands. I've even taken on an active role (Arrestee Support, which is an awesome role to have). And more recently, I've helped start a local chapter of XR. If you're in the Utrechtse Heuvelrug or Woudenberg municipalities and you want to join, come join us!

Regenerate!

Last year, XR blocked a highway in The Netherlands for weeks on end to protest against fossil subsidies. At first everyone was very ready for it. While during the week the group was smaller, during weekends the group grew bigger. But as time went on, the group became smaller. This wasn't because people didn't want to protest anymore. On the contrary. This was because of one of the principles of XR: They are aiming to have a regenerative culture.

This does not just mean that the way we treat the earth should be in such a way that our planet can recover from the pressure we put onto our planet. This also means that we as humans beings should treat ourselves in such a way that we can recover from the pressure we put on ourselves.

Why? Because you can not be constantly sprinting. So we need to recognize when we run into our boundaries, preferably before we actually run into them, and recover enough so we can get back on our feet and again take action.

From Extinction Rebellion to software development

I see a similar thing happening in software development. Whether in open source development or in commercial services: We try to keep sprinting. We try to keep the high pace going, hoping we'll get to the finish as fast as possible, just so we can continue with the next race immediately.

For open source, that means constantly working on the next release. Through specifying what needs to be done, actually building it, testing it, putting the release out then moving on to the next feature on the list.

For commercial software development, that means going from sprint to sprint. Doing your demo, then moving on to the planning of your next sprint and immediately starting it. If you're lucky, you have a retrospective in between. But even the retrospective can be intense, since it is meant for honest feedback. As a software developer, most of your work is done with your head. A retrospective is also done with your head. There is no rest.

How can we do this?

With burnout being a major issue amongst developers we really need to take better care of ourselves. This includes taking care of our boundaries and making sure we don't cross them, at least not for longer periods of time, but also taking care of each other. And identifying where we can improve.

Is stress a bad thing?

We often talk about stress as a bad thing. This is because usually we don't start talking about stress until it actually becomes a problem. But by then, it might already be too late. We should realize that there is good stress and bad stress, and there is no single definition of what is good and bad. As Mira Miller writes in the linked article:

Two people can experience the exact same event—such as a new project with a tight deadline—but one of them might experience it as an opportunity to take on an interesting challenge while the other one might automatically predict that they’ll fail.

So first of all, we need to make sure that we recognize the bad stress in ourselves and each other early enough. If you recognize it early enough, you can prevent issues such as burn-out, but also lower efficiency due to prolonged stress.

Make sure you're not "always on"

First, we should all realize that being a software developer does not mean that you're writing code 100% of your working time. And with we should all, I mean, all of us. This includes developers, but also project managers, stakeholders and company management. Years ago I did a keynote at several conferences titled Developers are just like humans. Developers are not just a "human resource". They are first and foremost human.

This also means that we should not feel guilty for taking a break on a regular basis. It is OK to stand near the watercooler talking to someone. And that talking does not necessarily need to be about work. It could also be about what you did last weekend, or your plans for tonight. Or the fact that your kid just starting walking and how funny it was when they fell on their butt when they tried. Or how you won another round of Fortnite last night.

We should also not feel guilty for taking other measures to ensure you're not overloaded. When you're stuck on this annoying bug you can't replicate or how to implement that new architectural pattern you need for your new project, take a step back. Actually, take a lot of steps. Go outside and walk for 30 minutes. You'll feel fresh and there's a chance you'll even find the solution to your problem quickly after you get back. Your head sometimes needs the time to process what you're doing.

Full sprint?

To retain a sustainable pace in your software development, it could also be useful to not just schedule sprint after sprint. Sure, it's OK to do 2-3 sprints of 2 weeks each right after another. But every once in a while, schedule in a week without sprint. This does not mean you don't have to do work that week, but it's good to be clear of the pressure of a sprint every once in a while. Take the week to do that refactoring you've been postponing because the sprint work was more important. Or step back and (re)consider your current architecture. Does it still work? You could even use the time to thoroughly refine and prepare the stories for the upcoming sprint(s). Most importantly: Don't expect too much of this week. Work will get done, but don't schedule your whole week and expect everything to be fully done. We want to get away from the regular work stress, right?

And I already hear the finance person, the project manager and the management: "But that week costs us a lot of money!". Yes, but as said, the work gets done. And regenerating is very useful to make sure that in the sprints that follow, the developers can again put in the sustainable pace that is expected of them. Besides, that refactoring or thinking about the architecture or writing of missing tests or whatever other thing that is done during that week, that's work that should also be done. By having that done during that one week "off" sprints, your application is better prepared for the future, and you'll save time in the long term.

Retrospect

In agile we learn that the retrospective is a moment to evaluate our process and discuss possible improvements. I would say that the process is not the only thing that needs evaluation. During the retrospective, also take some time to evaluate the impact work has on each team member. Make sure that everyone is still OK and ready to move on to the next sprint. And you don't even just have to do that during the retrospective. Your daily standup could start with a short check-in for each team member: How are you feeling today? Are you ready for the new day?

A developer is more than just that human resource

What I mean with this is that a developer is a developer during working hours. But outside of working hours, they also have a life. And things happening outside of working hours can also affect work. It is naive to think it won't, and it's unethical to expect it not to. Developers are not robots, they're human beings.

So, we need to make room for being able to deal with that. It's much more efficient to every once in a while give a developer one or two (paid) day(s) off to handle private matters well than to have a developer that is distracted for a longer period because they have to handle those private issues only after a long and possibly stressful workday. Sure, there are limits to this and if something needs more time then it is OK to see if they can take some days off from their vacation time (I realize this also really depends on the country and how much vacation days someone gets, but my main point is: this can be a conversation. As employer, do what you can but also communicate clearly when what you can do ends).

Know what the boundaries are

As a developer, it's good to find out what your boundaries are. From experience, I know that you'll cross your boundaries a couple of times because you figure out where they are. But be mindful of when and where you cross your boundaries, and communicate with your team and manager when you cross your boundaries. It is in the benefit of everyone involved to understand where they are and when to take a breath.

Likewise, just like you keep an eye on yourself, keep an eye on the rest of your team. There are signs of stress that you can recognize in yourself or others. The best way to prevent burn-out and other stress-related issues such as inefficient work but also physical issues such as carpal tunnel syndrome is to create a culture where it is OK to take a step back for a bit, to go outside for a walk during work hours, to regenerate.

Back to XR

And with that, we circle back to Extinction Rebellion. While I did my training for the A12 protests in The Netherlands, the trainer stressed in several ways that as an XR activist, you have a responsibility to yourself. You should clearly recognize when you need to step back. Regenerate. And it is OK to also talk to other about this.

As a business we can learn from XR. Not just about paying attention to our global footprint, but also to create a culture of regeneration for our team members. Because your team members are more than just people who do work. They're first and foremost human beings. And no one gains by completely burning them out, just like no one gains anything by burning out our planet.

Regenerative software development

So let's work towards a better, more healthy culture. A culture where there is room to regenerate, that is not focussed on burning people out and then replacing them with someone new. Remember: It is a lot cheaper to retain your existing developers than to hire new ones.

It had been years since I was in Cologne for anything development-related, so when the new Symfony User Group Cologne meetup was announced and it turned out it was a panel discussion in English about PHP and e-commerce, I decided to pay Cologne another visit. That was a good decision.

PHP and e-commerce: A match made in heaven?

It was interesting to hear from the representatives of Magento, Spryker, Sylius and Shopware about the differences and things in common between the different projects. I learned that Spryker and Magento are pretty strict in what they allow, Sylius is pretty loose and Shopware is somewhere in between. All have their own way of dealing with security as well as working with external plugins. Although Dennis from Spryker made a very good point:

You need to automate important things such as scanning for security issues. Those mistakes you feel no one will make because they are so easy are the mistakes that you will make yourself at some point

A very interesting discussion was about why these platforms had chosen PHP. While basically the answer for most projects was "because that was the language we were working with at that moment" the panelists were united in that they were still regularly deciding "PHP is still the right choice". One of the main reasons is because it is very easy to quickly implement new features using PHP. The projects do on a regular basis evaluate their choices, and still come to the conclusion that PHP is the right choice. That is good to hear. Then again, a good point was also made that a decision to rewrite the whole platform to another language in a week is not something you make.

The conclusion for now though is that PHP and e-commerce are still a match made in heaven. Being able to quickly make changes and deploy without having to compile things, the fact that PHP is good at Rapid Application Development and that the language has greatly evolved and has a clear release schedule all make for good reasons to use PHP for e-commerce solutions.

So what about the next e-commerce project?

It's interesting to have seen the options of the represented projects. I've worked with Magento before (that was not a good experience for me personally, but that was Magento 1 and I hear the newer versions are better) and Sylius (multiple times, and that has been an amazing experience so far). I've not yet worked with Spryker or Shopware so far. I surely hope to do an e-commerce project in the future where I can either use Sylius again or, depending on the requirements, try a different platform. Surely, there are a lot of mature options in the PHP world when it comes to e-commerce, that much is clear.

Big thanks

Big thanks to Qossmic for organizing this panel discussion. I had a great time speaking to several attendees, both people I knew before and some people I met during the meetup. And the panel discussion itself was really interesting.

If you are like me and absolutely hate solving weird visual captcha's with sometimes really impossible questions (is that small corner part of the bike/zebra crossing/bridge or not?) then you must've wondered about how to prevent forms (such as contact forms or comment forms) against spam. Of course, a 100% protection does not exist, but it would be good to have at least some protection.

When I recently updated the Ingewikkeld website with a contact form I quickly got swamped with spam messages. The first thought for many people will be "just add a CAPTCHA". But I do not want to scare away potential customers. I want to make it as easy as possible for them to contact me.

So I set out to search for an unobtrusive alternative. After searching for a bit and not really finding something, I saw the name Cloudflare. Now, I know them, we use their DNS services as well. But I had not yet heard of their Cloudflare Turnstile product. I checked it out and it seemed to do exactly what I wanted. A check, without required interaction. Nice!

I configured it for the ingewikkeld.dev domain and opened my IDE to implement it. There is great documentation and the frontend part was implemented in a matter of seconds. But Turnstile also relies on a backend part: The frontend does a call to Turnstile to obtain a token and "clear" the user. The backend then has to verify that token to confirm that Turnstile indeed cleared the user. It's a relatively simple HTTP request that I could build myself using an HTTP client class, but I decided to check https://packagist.org to see if there was a library that already implemented this functionality. It turns out there are already quite a few.

After a bit of checking I decided to try and implement usarise/turnstile. It seemed simple, supports Symfony's PSR-18 HTTP client out of the box and since the Ingewikkeld website is built with Symfony, that's good. And indeed, it was exactly as easy as I had hoped. Make sure the Turnstile\Turnstile class is injectable via the container, and the actual logic is easy:

$turnstileResponse = $turnstile->verify($request->request->get('cf-turnstile-response'));

if ($turnstileResponse->success === true) {
  // logic
} else {
  // set a flash message and redirect back to the form
}

It's as easy as that! Why would anyone still use a CAPTCHA if this is also an option?

Full disclosure: As owner of a company that supplies external developers and as an external developer myself, I have a lot of experience and I also obviously earn my money this way. Keep that in mind when reading this. Also: I speak from my own experience in this blogpost, but there are a lot of freelancers and consulting agencies. You don't have to hire me or one of the Ingewikkeld people (of course you can!). The same goes for a lot of other external developers that you can hire.

Over the years I have worked for a variety of different companies as an external developer both as a part of existing teams or the builder of new ones. Sometimes to help just with the software development, but often to be what I call a "developer++": Aside from helping with software development I am involved with all aspects of development, from architecture to coaching individual developers or even the organization. In some cases I was there for a year or even longer, in other cases it was just a few weeks, in some situations it was simply an hour to brainstorm.

There is not one single thing that is the value of the external developer, so in this blogpost I want to go through several different advantages you as a hiring organization can get out of using external developers in your organization.

A fresh look

This is one of the most underrated advantages of getting in external developers: They bring in a fresh look at the things you are doing and the way you are doing it. If you're fully immersed in a certain way of doing things then it can really help to get someone from the outside to give you feedback on that. From the inside, you might not see everything clearly anymore.

As an example, at one of my previous customers they had made the decision to build on top of an e-commerce framework for their headless e-commerce solution. Their software development was grinding to a halt, but they did not understand why. As I came in, I noticed that the e-commerce framework they had chosen was holding them back more than it was helping them. It would be a bad choice to throw away what they had built, but going forward for the new functionality it would be more productive to leave the framework where it was, and focus on pure Laravel development instead. After we made that decision, development became much more efficient and the rest of the functionality was implemented quickly.

Temporary help or ramping up to your new developer

A big percentage of the projects we do, we simply provide extra development help. Now it isn't always productive to add extra developers to a project that is already late and in the acquisition process I am often critical about this, but there are definitely situations where the temporary extra help can be a benefit to your project. I've found that many external developers are very used to quickly being up-and-running and understanding the problem at hand.

Additionally, if you have a vacancy open, it can sometimes help to get in an external developer for the period until you've found someone to fill the vacancy on a permanent basis. The external developer can ensure there is already some clarity about the exact role of the new hire, and also can make sure that the new developer can hit the ground running because a lot of the setup work has already been done for the new position.

The amount of experience

External developers switch companies and projects on a regular basis. This results in an incredible amount of experience with different situations and different people. The result of that is that there's a lot of different situations and technical challenges that they have already encountered. They bring that combination of experiences to the table on any new project, resulting in one or even more possible great solutions for any challenge you run into.

Dealing with all kinds of different people also really helps with the communication skills. This is why on average external developers are more skilled at identifying and bringing to light possible communication issues in a team.

Get it documented

Based on our experiences, internal developers are less likely to correctly document decisions and technical setup. This causes issues for instance with on-boarding new developers or figuring out the reasoning behind certain technical decisions after a few months or years.

External developers know that they're temporary, that they will leave at some point. The result of that is that they're more focussed on making sure decisions and knowledge about the codebase is documented so that those who come after them can continue the work. This rubs off on the internal team as well usually, triggering them to be better at documenting. The result is code that is better documented, developer on-boarding that can be done much more efficiently and overall more knowledge among team members about the codebase and the problems that are being solved.

Smells like team spirit

Building software is one thing, but building a team is another. That's not easy. And it's really important to have a good team. A good team is able to act on changes faster and is more predictable in the quality of the work they deliver. A good team needs a good leader to keep the team together and make sure it works well together. Often when teams don't work together well there is no leader, or the leader is not able to really keep the team together. External developers can be that glue for the team, and can coach one of the permanent team members to take that role.

Talking from my own experience a lot of places where I've worked in the past decade did not have a team. They had a group of individual developers. And while the individual developers can get a lot of work done, making them a team, where the total is more than the sum of its parts, is something that needs attention. Because of external developers working for a lot of different companies, projects and teams, they usually have a good overview of what needs to be done to truly have a team. They can have that leadership role, or do the coaching of the leader to take on that role.

Get rid of your bias

OK, story time. Some years ago I started at a new customer. The small team of internal developers were reporting to their boss, a former software developer turned entrepreneur. He had built the company himself on top of his own software, but he had not been developing for years as the company took off.

The team came up with several suggestions to improve the software. But they were rejected by the boss because it was unnecessary, or too much work, or there was another reason why it was not a good idea. When I came in, I started talking to the internal developers and I actually quite liked their ideas. They were ideas based on current knowledge of good software development practices. They were definitely improvements. So I started proposing the exact same ideas to the manager. And with the proposals coming from me, the manager said "oh, that sounds like a good idea, let's do that!"

While it is not good that there was somehow no trust in the internal developers, that situation sometimes happens after years and years of being stuck in a certain flow. Sometimes it's good to have external developers challenge your bias against your own people. Especially when you were a developer before so you think you have good knowledge of the matter at hand.

So challenge yourself

So, challenge yourself and your team and get an external developer on board. You don't have to permanently have an external developer in your team, but having one in your team for a few months on a regular basis will already help you and your whole team improve and challenge you to think about the way you do things and your focus on both the technical and the human level. And as I said at the start, you can surely hire one of the experts of Ingewikkeld, but there's a lot more talent out there on freelance, contract or consultancy basis. Need help selecting the right developer? Feel free to get in touch with me. Even if you don't choose an Ingewikkeld developer, I'm happy to help you with your selection process.

It was the age before Twitter (can you remember that?) that I started reading blogs (and eventually, writing blogs). One of my favorite Dutch blogs was Mijn Kop Thee. That blog was the blog of Bob den Otter.

Bob also developed Pivot (and later PivotX), blogging software that a big part of the Dutch blogging community (including myself for quite some time) used. And perhaps also internationally, I have no idea. What I did know is that even in Pivot, while it was fully file-based and no databases were harmed yet, the most important thing was that it was so well-developed. Usable. Intuitive. I loved it.

The first time I can remember meeting Bob was at a meetup I helped organize out of the Dutch PHP usergroup. It was in The Hague, Bob's hometown, and it was on frontend technologies. I have a habit of putting people that I look up to on pedestals and being "afraid" of meeting them, but Bob was so approachable, open and friendly. It felt like there was an immediate connection.

Since then we have been in contact on a regular basis. I worked for his company Two Kings on a project once and learned a lot from him. About software development, but also about running a business. Bob hated "payment terms". So when you sent him an invoice, he would just pay it immediately. It's something I started doing since then as well. Because it makes absolutely no sense to wait for 30 days to make a payment.

Another fond memory of Bob is the time when we sat down on Vlieland to work on the website of Into The Great Wide Open. Two Kings builds the website of this festival and I volunteered to help with the site. Sitting there with the Two Kings crew working on building the new site was a fantastic experience. Bob built an amazing team, and with that team also built amazing websites.

I mentioned Pivot(X) before, but more recently Bob built and open sourced Bolt CMS. As before, I love it because it's so intuitive and easy to easy. Defining new data types simply in a configuration file and the system will automatically just use that, that's amazing. With it being based on Symfony, it's also quite easy to extend or alter it's behaviour. I'm really going to miss Bob's vision on software development. He made things easier for everyone, disliked unneeded complexity and just wanted to get the job done well.

What I'm going to miss most though is Bob's passion. It didn't matter what subject. Festivals, music, artisinal web development, climate change, you name it. Every year we would find each other on Vlieland for the Into The Great Wide Open festival. We'd compare our planning (as you can see in the picture above), talk to each other about great new bands, or share a beer in the special beer bar on the festival site.

Bob passed away on January 18, and I still can't believe it. I've re-read the message notifying me of his passing multiple times just to get that confirmation that indeed, it is true. I don't want to believe it. Without exaggerating, Bob was one of my favourite people on this planet. My heart goes out to his partner and family, to the team at Two Kings, and to all who knew him.

Bob, wherever you are, thank you for all you did. You inspired me, and I will carry your lessons with me forever.