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!

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.

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.

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.

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!

Yes, we're still in the middle of the summer vacation period (at least in the northern hemisphere) but I'm going to look ahead a bit towards september. A month where I have two conferences scheduled. Will I see you there?

API Platform Con

On September 21 and 22 you can find me in Lille where I'll be at API Platform Con. On September 22 I'll me doing my PHP Kitchen Nightmares talk, which promises to be fun! I'll draw a parallel between kitchens of restaurants and our work as developers.

Cakefest

A week later I'll travel to Los Angeles for CakeFest, which takes place on September 29 and September 30. I hear it's going to be an exciting conference. At that conference I'll introduce the concept of Domain-Driven Design to the attendees.

I hope to see you at one of these events!

About a month ago a discussion was triggered in the PHPNL Slack on the subject of what people are looking for in a vacancy. The trigger for this discussion was the fact that on a regular basis companies don't disclose a salary indication (an actual amount) in their jobs page. That got me to wonder: What else is good or bad? Perhaps we can learn from this. While probably not scientifically accurate or statistically sound, I did get a lot of responses from a lot of different developers. Let me try to give a summary of the things that were mentioned.

Salary

First of all, what triggered the discussion in the first place. Mention a salary range or indication. Not mentioning an actual number is for most developers that responded a reason to not even respond to a vacancy. And vague texts such as conform current market or competitive are even more off-putting than nothing at all. Too many companies use such terms to hide the fact that they simply don't offer a good salary. So be open and clear about what people can expect in terms of salary.

You should also be open about any bonus systems, 13th month systems or other financial compensations that are part of the job.

Other benefits

Other benefits can also be important. Do you offer a pension, what costs are reimbursed, do you pay for conferences and training, do you offer paid time for working on open source, etc. Not all developers are primarily focussed on salary, so any other benefits can be deciding factors. Make sure to clearly communicate what developers can and cannot expect at your company.

Location

Long before we had a global pandemic there were already developers that were mostly working remote, but the pandemic has (finally?) triggered more companies to open their eyes to remote working. Especially a job such as software developer is something that can easily be done remotely. On the other hand, there's a whole group of developers that prefer to work on-site. So make sure to clearly mention whether a developer can or must work on-site, or whether remote working is an option or even required.

Also, if you offer "hybrid" working (partially on-site, partially remote) be clear about how much time is remote, and how much is in-office.

Responsibilities

What are the responsibilities of the developer. Are you looking for a pure code monkey, or do you also need someone with other skills: ops, architecture, management, communication? Does this job also involve interviewing potential new developers? Does it involve talking directly to customers? Is it mostly about maintaining an existing application or will the developer also work on new features? Is it a legacy codebase or a greenfield project? Do your developers coach interns? Different developers have different interests, so it's good to manage expectations.

Working hours

Not everyone is a morning person just like not everyone is an evening person. Mention your work hours, or mention if those work hours are flexible. With the job market becoming more global and developers spanning multiple timezones this is especially important. If you have a daily standup or other meetings that are important that people need to attend, mention their times. That helps developers determine if this is something interesting for them.

Also: Are you looking for 40 hours/week? Or is 36, 32 or even 28 or 24 also an option?

Tech stack

What is the tech stack in your company? Also: Which part of that stack will the developer be working with on a regular basis? If you're looking for a backend developer it is not strange that you occassionally need to do some Javascript or CSS work, but if you expect a backend developer to work on the frontend as well on a regular basis, this is important to know.

Keep in mind that part of the tech stack is the development environment: Does a developer have free choice in what platform they develop on? Do you offer only a limited choice in what laptop and other hardware and software a developer can choose from? These things can be very important for the happiness of a developer, communicate it clearly!

Methodology

Does the team and/or company use scrum? Kanban? Waterfall? Is everything very structured or very ad-hoc? Some developers thrive in a chaotic environment, others really need structure. Some developers love the predictability of a waterfall approach, others prefer the more flexible scrum or kanban way of working. To make sure you get the right developers to respond to your vacancy, be clear about how you work.

Duration of the contract

Some companies initially offer a 6- or 12-month contract. Some companies immediately offer a permanent contract after that initial contract, others offer several temporary contracts before going to a permanent contract. Be clear about what a developer can expect.

What is the team like?

I'm grouping several different things under this header because they seem related. First of all, there is team composition. Is the team diverse in terms of gender, age, background? You don't have to specify all the details, but some people would rather work in a diverse team while others would prefer a team of similar people.

Then, culture. What is the culture like within the team and within the company? Is it a formal or informal organization? Is it an organization of individuals or is there a very strong team feeling? These are all things that can improve your chances of a developer responding to your job opening.

Language

No, I'm not talking about programming language (although, really, do mention which programming language(s) you use) but I'm talking about spoken language. I've come across so many organizations that only want people that speak Dutch, for instance. Mention that! It saves you and the non-Dutch-speaking developers a lot of time (and therefore, money).

What type of clients do you work for?

Developers have their own principles and therefore don't always want to work for certain types of companies. Or they have a strong interest in specific domains (care, education, industry), so they would apply to a job where the chance of working in that domain is higher. You don't always have to use names (although using names can be a bonus) but at least say what kind of clients you work for.

Sustainability and responsible entrepreneurship

Several developers mentioned that they like to know how a company handles things like sustainability and social responsibility. Does your company invest in making sure your ecological footprint is smaller? Do you invest in the (local? worldwide?) community and support NGOs that try to create a better world?

Similarly, do you offer internships or traineeships? Or do you invest in another way in sharing knowledge and experience? Does your company contribute directly or indirectly to open source?

What NOT to do?

Aside from all these things that are good to mention, there's also some things you really don't want to do.

For instance, do not use terms such as heroes, superstars, rockstars to refer to developers. Most developers are normal humans (yes, really!).

Don't use things like "we don't have a 9 to 5 mentality". This is a red flag for many developers that signifies that you expect regular unpaid overtime. Even if you mean well, this is a red flag that stops many developers from responding to job openings. As said earlier, specify expectations as to work hours and list the times of important meetings so developers understand whether you are very flexible when it comes to work hours, or whether you're looking for unpaid overtime.

Don't communicate a salary that is unrealistically low or high. Also: Don't offer a salary below the range you communicated once you interviewed a developer. Be honest. And that isn't limited to salary.

Do not overestimate yourself. Do not talk about "what an honor it would be to work for us" or "how lucky you are when we pick you".

Similarly, don't use buzzword bingo terms. Don't talk about "energetic", "kick-ass" or such terms. This makes your text sound untrustworthy. You're trying too hard to make it sound appealing. Instead, be clear and honest. As the saying goes, honesty goes a long way.

Good luck in your search for developers! I hope this helps!

In the past year several version of PHP and frameworks within the PHP world have been going into end-of-life status. Either there are only security updates left (PHP 8.0 is not supported anymore since November 26, 2022, but there are still security updates) or they are completely unsupported now (PHP 7.4 does not even get security updates anymore since November 28, 2022). Similar things are happening for older versions of for instance the Symfony framework.

Whether there is a relation with those changes or not, in recent months at Ingewikkeld we've taken on several projects that consisted mostly of upgrading projects. In all situations it is a combination of upgrading PHP (most of the times from PHP 7.4 to PHP 8.1 or PHP 8.2) and upgrading Symfony (from several versions within Symfony 4 to the most recent Symfony versions).

These are not easy projects. They are quite complex because of everything that is involved. It's not simply "switching to a new PHP version" and then running composer update. Depending on your project, there will be different dependencies and dependencies of dependencies to take into account. Your code may contain deprecated features of either PHP or the framework and other libraries that you use.

Of course, there are many tools that can be used to make this process easier. Rector is a huge help, and so is PHPStan. Ingewikkeld's Muhammad, who has worked on two of the big upgrade projects we've been doing, recently even did a talk on Rector. But even with these tools it is not an easy process, and it takes a lot of time. And therefore, also a lot of money.

Continuous upgrades

One of the main reasons why it is so hard is because we're making a huge leap. A combined leap as well, because we have to upgrade both PHP and the framework and libraries. This makes it extremely complex. So what can we do to solve that?

Well, what is a lot easier than a big leap forward? Indeed, small steps. So instead of upgrading once every couple of years and doing a huge upgrade that is time consuming and therefore very expensive, make upgrading part of your regular maintenance process. Bugfix-releases and minor releases are usually backwards compatible so doing those upgrades are relatively painless. With major version releases this is a big different. You usually have to schedule some time to do those. But luckily most of the big projects in the PHP world these days have a very transparent release schedule. Check the roadmap page that Symfony has, for instance. There is also endoflife.date that gives an overview of a lot of languages and frameworks. I linked the PHP page as an example. This release information allows you to schedule your upgrade work months in advance.

So I always have to immediately upgrade?

No. First of all, it depends on your situation. There is not one specific way to handle this. And if you are still in your initial development phase of a project, I would actually recommend not to upgrade yet. When you're still in that phase, I would recommend first focussing on building the features that you need. Yes, you can do bugfix upgrades and minor release upgrades, but don't immediately switch to new major versions. Unless, of course, there are specific new features in that new version that will save you time in your development.

My point is mainly: You apply the "continuous upgrade" mentality mostly to your project when it is already fully in production and you're doing either maintenance or maintenance and development of new features. Schedule the upgrade work as maintenance work.

Do I get anything out of this?

Yes. Aside from having recent versions of the tools you're working with, PHP upgrades usually bring performance upgrades, which makes your site or application faster, and can also reduce your hosting costs. Frameworks sometimes also get a performance boost. And there's usually bugfixes and sometimes also security fixes in new versions that can help you keep your website or application more secure/less vulnerable.

I did not continuously upgrade. Now what?

In that case, you'll have to make the big leap first. And while doing that, plan your new continuous upgrade process. If you need help with the big leap, Ingewikkeld can help! Feel free to contact us to discuss options.

Conferences are happening again and I'm really happy about that. And while it gives me quite a bit of FOMO to see the messages about PHP[tek] and PHPDay, and especially for EndPointCon (as I was supposed to speak there but had to cancel due to a nasty stomach flu) I'm happy to announce some new conferences where I'll be speaking.

DrupalJam Utrecht

First off, on June 1 I'm heading to Utrecht for DrupalJam, where I'll be joining the ranks of speakers amongst such names as Arnoud Engelfriet, Rick Kuipers and many more. I'll be delivering my Domain-Driven Design: The Basics talk there.

TechTuesday XXL

Then on Tuesday June 13th I'll be doing that same talk a bit more in the south of the Netherlands in Tilburg during the TechTuesday XXL. The regular TechTuesday meetups are always fun, and this XXL edition will be even more fun with, among other people, Pauline Vos also be there.

API Platform Con

Then I'll be meeting Pauline again in Lille in september, as we're both joining the ranks of speaking at API Platform Con. There I'll be doing my PHP's Kitchen Nightmares talk. Lots of fun will be had in Lille, I'm sure.

See you there?

I'm really looking forward to speaking at these events. Will I see you there?

I will be the last one to tell you not to write unit tests. I will be the last one to tell you not to test your own work (or work done by your team) manually. However, I was today reminded of another form of testing that is possibly equally important or perhaps even more important: Sitting down with your customer to test.

A full day. We scheduled a full day to sit down with a customer. The application we're working on is quite extensive and the project so far has not been very iterative. Yes, there has been feedback along the way, but really sitting down and testing is something that has not been done that often so far.

So today was the day: We sat down with three employees of the customer and 4 developers. Our goals:

• Being able to show the customer all the cool stuff we've done
• Being able to see how the customer would use our application
• Understanding what the customer expects to happen on certain key actions

If you're working in an iterative way, for instance when using scrum, you're used to being able to show the customer all the cool stuff you've made. But in some projects, that doesn't really happen. The project for which we gathered today is one of those, and so it was really great to be able to show the customer how we'd build certain things. Seeing and hearing the response of a customer is really useful: Their response, whether with what they say or even with their facial expression, really tells you whether you did a good job, and which parts of the application you may need to improve on.

Another very useful piece of feedback is to actually see your customer navigate the software you built. It gives a lot of insight into whether you made the right choices, and gives good pointers on where you can improve the usability or the functionality. Today, we had someone always connected to a big screen so we could see exactly what they were doing on the screen. Combine what happens on the screen with the body language of the person controlling the computer at that point and you'll get a ton of very useful feedback.

At some points during the day, there may be confusion. The user will do something and will look surprised, confused, or perhaps both. This is where you really have to pay attention. This is where you can learn how you perhaps interpreted the wishes of your customer different from how the customer actually wanted it. There's a good chance they didn't even know yet how they wanted it. Whichever it is, now is the time to learn how you can truly improve the application to better fit how your customer works.

4 developers

We were there with 4 developers for a reason: While the customer was testing, the developers were also simultaneously fixing issues that had arisen. By making this feedback cycle very small we made it a lot easier for the customer to get exactly what they needed. Another important goal of this was also to give developers a morale boost: To see a customer really happy with the stuff that was built is a very rewarding experience.

Shorten the feedback cycle

In this project, while there were regular meetings, the feedback cycle was sometimes very long. During today's meeting, the cycle was extremely short. Today was a day of constantly running. This is not something you can do on the long term. But there is also no need to constantly walk very slowly. You have to find what works for you and for your customer. In my experience, 2-4 week cycles give you a good sustainable pace: There is enough room for the customer to give feedback and improve what you are building, but you also have enough time as developers to focus on building the coolest features. So don't do 6-month+ projects with little to no feedback moments. Shorten that cycle to something that works for everyone.

We can help

Are you a development company or team and you have no idea where to start to improve this? Are you a customer of a development company and are you unhappy with how things are working out? Get in touch with us at Ingewikkeld. We'd be happy to help you improve the development process to make it work for everyone involved.