skoop.dev

Unobtrusive spam-protection with PHP

February 14, 2024

captcha, cloudflare, php, spam, turnstile
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?
The value of an external developer

February 13, 2024

consulting, contracting, external developers, freelancers, php

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.
Remembering Bob den Otter

January 22, 2024

bob den otter, bolt, festivals, music, php, pivot

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.
March 2024 conferences

January 19, 2024

conferences, DPC, Dutch PHP Conference, php, talks, webcampvenlo

I hope 2024 has started out good for you, and I certainly hope you are planning to attend some conferences. I’m happy to announce two awesome places where I’ll be doing talks

Web Camp Venlo

First I’ll head to the South of the Netherlands, to Venlo to be exact. There, Web Camp Venlo will take place from February 29 to March 2. They’ve got some interesting workshops on their first day, but I’ll be there on day 2 (March 1st) to deliver my Domain-Driven Design talk. If you missed that at SymfonyCon, this is a great opportunity to catch this talk. There’s very interesting talks on the schedule including on Keycloak (by Annemieke Staal), mental health and burn0out (by Jeroen Baten) and more. Tickets are available now. See you there?

Dutch PHP Conference

After several online-only editions due to you know what I am extremely happy that the Dutch PHP Conference is organizing a physical conference again this year. They’re teaming up with AppDevCon and WebDevCon, making this a must-attend event if you’re in the Netherlands. They have 2 training days, a tutorial day and a conference day with an amazing amount of talks. I’m excited to be doing my Sustainable open source contributions in your business talk there, next to interesting talks on sustainability (by Michelle Sanver), Git (by Juliette Reinders Folmer), agile architecture decisions (by Nic Wortel) and breaking production (by Sofia Lescano). Tickets are available now. I hope to see you in Amsterdam!
SymfonyCon follow-up: Doctrine entities vs Domain entities

December 9, 2023

ddd, doctrine, php, symfony, symfonycon
After doing my talk on Domain-Driven Design at SymfonyCon, I was talking to someone who was in the audience and who wondered about how to work with Doctrine entities vs Domain entities.

If you want to have a puristic approach to DDD (especially when you do the common combination with a hexagonal archicture), then your Domain entities should not leak infrastructure and they should be specific to your Domain and your Bounded Context. The domain entity should not care about how it is stored in the database (or wherever you store the data). So if you take the puristic approach, this means that you should have classes that constantly convert your Doctrine entities into domain objects and the other way around.

If I take the example I use in my talk of a Payment, then in the bounded context of the Checkout, the Payment only needs some basic information about the payment (amount and status, for instance). But in the Accounting context, we need a lot more information to correctly process that Payment into our books, so in that context the domain entity should have a lot more information such as payment method, perhaps even credit card or bank account details, etc. If you store that in a single database table, your Doctrine entity will have all that information available, but the Domain entities should only limit themselves to the information you actually need there.

And while the puristic approach is the best approach, I also understand that in a lot of projects you do not have the time to actually take this approach. And it actually is possible to keep using Doctrine entities and still do this relatively cleanly in your codebase. The trick? Interfaces.

In your Domain layer you define your interface, for instance:
```
namespace Webshop\Checkout\Domain;

interface CheckoutPayment 
{
    public function getStatus(): PaymentStatus;

    public function getAmount(): Money;
}
```
and in Accounting:
```
namespace Webshop\Accounting\Domain;

interface AccountingPayment 
{
    public function getStatus(): PaymentStatus;

    public function getAmount(): Money;

    public function getPaymentMethod(): PaymentMethod;
}
```
Now, your Doctrine entity implements these interfaces:
```
class Payment implements CheckoutPayment, AccountingPayment
{
    // here you just implement everything you need for your entity
}
```
In your application code, you just typehint the correct interface: In your Checkout context you typehint on the CheckoutPayment and in your Accounting context, you typehint the AccountingPayment. Yes, now the information from another context could potentially leak into the wrong context, but since we typehint on the interface we can now use a tool such as PHPStan to scan for places where we incorrectly use information that is not meant for that context.

My preference

While it is more work, I usually prefer to have separate classes for transforming Doctrine entities into Domain objects. Another reason for that is that sometimes you may need to want/do some additional transformations into Value Objects, or have an Anti-Corruption Layer between “outside” data sources (which could be other bounded contexts, but also the database could be seen as an outside data source). But this approach is certainly overkill for quite a few situations. In those situations, working with the interfaces in the Domain and your Doctrine entities directly in your code is a fine solution. It’s defintely sometimes recommended to be pragmatic in your code. What might be considered a shortcut in one project is a perfectly fine solution in another project. And especially if your dilemma is “I either work with this pragmatic DDD-ish approach” vs “No room for DDD in this project”, add that extra structure in a way that fits your project. It will help you out later.
SymfonyCon is coming up: 5 talks you shouldn’t miss

December 1, 2023

conferences, php, symfony, symfonycon

Next week it’s time for SymfonyCon! I am really looking forward to the conference. To meeting my old friends and make new friends. To the road trip I’m taking by car with a bunch of Dutch Symfony enthousiasts. In this blogpost I want to share with you the talks I really want to go and see.

1. Sofia Lescano – I did it! I broke production!

Everyone makes mistakes. And I love it when people own up on their mistakes, and share not just the mistake, but also the lessons learned. Because we learn best by our mistakes. So I’m really looking forward to hearing about the lessons Sofia learned.
Thursday December 7 at 11:10 in the SensioLabs room.

2. Ondřej Mirtes – Static Analysis Crash Course for Framework Developers

Static analysis is a very powerful tool, and I still see a lot of companies that don’t use the power of running tools like PHPStan automatically. A fresh course is therefore a good idea, and who better to give that course than the PHPStan maestro himself.
Thursday December 7 at 15:15 in the Symfony room.

3. Guillaume Loulier – Need to search through your data? Heard about Meilisearch?

Recently I have worked with Meilisearch for the first time in a project, and I really liked how it worked. As such, I’m looking forward tto hearing a bit more about what it is and how it works. Really looking forward to this one.
Friday December 8 at 10:05 i the SensioLabs room.

4. Ramona Schwering – It’s a (testing) trap!

Star Wars reference aside, this will be useful to everyone. Even if you’re already very experienced with writing tests (I’ve done this for quite some time now), I always find that hearing others speak about their experiences and tips and tricks is very useful. As such, I really want to see this talk to see how Ramona does testing.
Friday December 8 at 11:10 in the Symfony room.

5. Rick Kuipers – Symfony is RAD

There’s been a lot of talk about how Laravel is the best RAD framework at the moment and I do agree that Laravel is great for RAD. Then again, often I wonder if we couldn’t achieve a similar thing if we were using Symfony. Rick will hopefully proof me right. The funny thing is, Rick has been doing this talk at usergroups near me and somehow I’ve always missed them. So now that he’s doing this in Brussels while I’m there, I’ll definitely be able to watch it.
Friday December 8 at 14:30 in the SensioLabs room.

Of course your interests may differ form mine. Luckily, SymfonyCon has an excellent variation in the schedule. Will I see you there? Tickets are still available!
Step by step

October 23, 2023

php, session, small steps, usergroup

If you now think of New Kids On The Block when reading the title of this blogpost, you’re old, just like me.

But seriously, this week we’re doing something very cool. And “we” in this is my friend and former Ingewikkeld colleague Ewout and myself. We’ve developed a special session for the Ode aan de Code meetup in Apeldoorn. The session is about how taking small steps is better than taking a big leap.

Based on several situations related to either software development or the human side of software development we will go through examples of how it is easier to take small steps. And why you really would want to do that.

But we’re not just presenting information. It’s going to be an interactive session where the input of all attendees is going to be really important. Without wanting to give away too much, we’re actually going to make the attendees the center of attention for this session. Because why just limit ourselves to our own experiences when we can listen to everyone’s experiences?

Interested? RSVP-ing is the first small step to take and join us in Apeldoorn on Thursday for this session. Looking forward to seeing you there!

Note: Out of Ingewikkeld we can organize similar sessions focussed specifically on your company or team. We can use these sessions not just around a topic such as taking small steps, but also focussed on specific challenges your company or team has. If that sounds good, feel free to contact us to discuss the options.
Maybe this is not my customer

October 10, 2023

business, customer, php

As an entrepreneur you want to help your customers as well as you can. But sometimes you have to stop and think:

Am I really helping this person or company by taking them on as a client?

I was reminded of this when I had a meeting with a potential client earlier this week. They approached me with a question about a specific piece of technology I had worked with in the past, and what they were trying to do sounded like something I could help with. I was excited to talk to the to see if I could help them.

As the meeting progressed I got the feeling more and more that what they wanted was indeed a potential solution to their issue, but the way they wanted it was something I had no experience with and it was so far out of my comfort zone that while I could probably do it, it would cost me way too much time and because of that it would cost them way more money. Especially considering there was a pretty hard deadline, and I was unsure if I would be able to make that deadline.

No. I was not the right person to solve this issue.

So what is the next best thing I could do? Help them find a knowledgeable person in this area, and get them in touch with those people. So that is what I did. I simply told them “I’m not the right person for this, but I know someone who can help you”. And that was appreciated.

I see too many examples out there of people using tool x to solve issue y even if tool x is not the right solution to that issue. A CMS, an e-commerce solution and a CRM all do some form of content management, but that doesn’t mean they’re interchangeable. I also see too many examples out there of people thinking as long as I can sell myself to this customer, I can probably learn along the way. And while that is not necessarily a bad thing, if the customer has a strict deadline or explains that there is no room for mistakes on this project, they still take that project on.

Build a network around you of experts. If you can’t do it, pass the project on to someone who can. They will do the same with projects they can’t do, but you can do. The customer should be the most important, at all times. Their issue needs to be solved. Whether you do it, or someone else, that is the most important.

So next time you sit with a potential customer, and you get the feeling that this might not be a good fit, be honest about it. See if there’s room for you to learn. If not, find someone in your network that can do the job. Your not-costumer will thank you for it.
Decentralized DTO and speedy FrankenPHP: API Platform Con 2023

September 23, 2023

apiplatform, apiplatformcon, conference, conferences, decentralized web, frankenphp, lille, php

As it can not surprise people that know me: I love conferences. I love learning about new things and I love meeting people. It might be friends I’ve known for years in the PHP community, it might be new friends. And this was what API Platform Con was all about: Learninng about new things and meeting people. All that in the beautiful city of Lille, in France.

FrankenPHP

When FrankenPHP was announced some time ago I was quite interested. But since it was still in development I didn’t really pay much attention to it yet. During the very first talk of the very first day, Kevin Dunglas announced in his opening keynote that FrankenPHP is now in beta and that it is considered stable enough to use in production. With all the information he shared about Docker setups becoming less complex but more importantly: FrankenPHP being a lot faster than a standard Nginx+PHP-FPM setup, I was intrigued. So I sat down during the talk after and the morning break to try it on a local development environment for one of my projects. I had my local environment up and running very quickly. As in: It was almost as easy as removing the Nginx and PHP containers I had, and adding FrankenPHP. Nice! I’ve also done the preparation work for pushing this into production as well but did not dare merge the merge request for it yet, since I was at a conference and didn’t want production to go down in case I had made a mistake. But this is to be continued, because so far, so good.

The Need For Speed

The most popular sponsor stand by far was the stand of Commerce Weavers. They had brought a remote control race car track, which was a lot of fun. But that wasn’t the only thing with speed. Had I talked already earlier about that FrankenPHP is a lot faster than Nginx and PHP-FPM, Lukasz Chrusciel of Commerce Weavers also did a talk about speed optimizations in API Platform, which contained a lot of useful tips and tricks to improve the speed of your API Platform project. Now, I must admit that I’ve not really worked on a lot of projects yet that do API Platform so I have not encountered speed issues yet, but next time I do run into issues, I must find the recordings of this talk because there’s a good chance Lukasz has given the solution already.

DTO

I started off day 2 with the keynote by Ryan Weaver, who presented some new options to make working with DTO’s in API Platform a breeze. I must admit… at some point Ryan had completely lost me and I did not understand why you would do it like that. But he knew it didn’t make sense, as he then moved on to explain why it didn’t make sense to do it like that, and what the proper way was to actually make it work well. I must say, these new features to work with DTO’s make working with them a breeze, and the way Ryan used a very simple mapper to create a generic provider and processor… how little code do you need to create a fully functional API these days? Wow!

Decentralized web

All of the above talks really inspired me to sit down at a computer and try out things, but the talk that inspired me the most was Pauline Vos and her talk about the decentralized web. After a depressing introduction of the past and the present of the web (the web currently is in a horrible state and definitely nowhere near what Tim Berners-Lee originally wanted), Pauline showed us what the options are for the future and how The bright and exciting future of the decentralized web is indeed bright and exciting. I registered for an account on Mastodon years ago but it wasn’t really until earlier this year that I started digging a bit more into the fediverse and all the options it has available and that excited me a lot. It’s inspired me to not really use Twitter/X anymore, to use Facebook a lot less, to use Instagram a lot less. Instead, I am now on Mastodon and Pixelfed, and I really want to dig into the various other federated replacements it has for big, corporate, centralized platforms that I still use such as Goodreads.

But Pauline showed me that aside from the Fediverse there is a lot more out there that focusses on decentralizing the web, including an initiative by Tim Berners-Lee himself called the Solid Project that aims to give everyone their own “pod” that controls their private data and that allows finegrained control over what data you share with other sites. I LOVE this idea.

Inspiration

So now I want to look more deeply into FrankenPHP, and I really want to start looking more into all those decentralized options that are available. And for my next API Platform project, I really want to try out the new DTO stuff and I know where to look if I run into any performance issues. I can not remember the last time a conference left me so incredibly inspired. A big thank you to Kevin, Lukasz, Ryan and Pauline and the other speakers for sharing all this information. And of course a lot of love to the organizers of the conference for doing this all in the beautiful city of Lille.
What is the problem?

September 14, 2023

debugging, performance, php, problem solving

When you run into a problem with your code, either you’re stuck in trying to implement a feature or a bug occurs and you can’t quickly find what the cause of that bug is, it is very tempting to really dive into the code. It makes sense to do that, because you’re working on that code and it isn’t doing what you want it to. We also have great tools such as Xdebug that can help us trace the path of the code. Or if the problem is performance, there’s tools such as Blackfire that can give you a lot of information about the when, where and why an issue occurs. So please, use tools like these to give you a lot of information.

But sometimes this is not enough to immediately spot the cause.

In that situation, please don’t dive deeper into the code. There is a risk that you’ll drown in the code, have no idea anymore what is happening where and eventually you’ll be frustrated, tired and completely lost.

Take a step back

Instead of digging into the code, take a step back. Gather as much data as you can about what is happening using all the tools that you can think of, and then step back from the code. Make an overview for yourself of what you expect to happen. Use pencil and paper or a whiteboard to make a map of the flow. Then, compare that to the data you’ve gotten from Xdebug, Blackfire and other tools. See if you can spot the flaw. See where your idea of what is supposed to happen diverges from what is actually happening.

Get help

If you’re still stuck, don’t hesitate to get help. You can first start rubberducking by trying to explain it to a rubberduck or an elePHPant. Sometimes this already helps: By thinking about how to explain the situation, your brain will look at the problem from a different angle (“how do I describe this so someone else explains what I already know?”), and this sometimes explains to you “ah, this is why it’s not working as I want it to”.

If that doesn’t work, get a second pair of human eyes on all the information you have. A fresh pair of eyes will have a different look on all the data and might help. Especially when you’ve been stuck on something for a while you may have become blind to the actual cause. Having someone else have a look may just bring that fresh set of eyes that is needed to quickly spot the cause of the issue.

And don’t feel bad if your colleague spots the cause of the issue quickly. This is very normal. As mentioned before, when you’ve been stuck on something for a while you may have become blind. They have not been staring at this for a long time already, so they may quickly see what’s going on.

No really, step away

Another way to prevent becoming blind to the issue is to really step away from your computer for a while. Take a 15 minute walk, or perhaps even a 30 minute walk, to clear your head. Don’t keep thinking about the bug, but instead think of anything else. Truly anything else: That concert you’re going to next week, which laundry is next on your list, what’s for dinner tonight. As long as it is NOT your code, you’re good. Once you come back, you’ll be the fresh pair of eyes, and you might spot the issue soon after returning to your computer.

Being a developer is not just about writing code, so don’t feel guilty for taking 15-30 minutes for a walk. This is part of your work. As someone who works with their brain, you need to give that head some rest every once in a while. Nobody can do full focus work for hours on end without needing a break every once in a while.

Good luck!

I hope you won’t run into many issues like these, but if you do: Good luck! I’m hoping you’ll find the solution soon!

A fresh look

Temporary help or ramping up to your new developer

The amount of experience

Get it documented

Smells like team spirit

Get rid of your bias

So challenge yourself

Web Camp Venlo

Dutch PHP Conference

My preference

1. Sofia Lescano – I did it! I broke production!

2. Ondřej Mirtes – Static Analysis Crash Course for Framework Developers

3. Guillaume Loulier – Need to search through your data? Heard about Meilisearch?

4. Ramona Schwering – It’s a (testing) trap!

5. Rick Kuipers – Symfony is RAD

FrankenPHP

The Need For Speed

DTO

Decentralized web

Inspiration

Take a step back

Get help

No really, step away

Good luck!