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.

Well begun is half the work. A good start is half the battle. Expressions like these may seem cliche but they are actually true, especially when talking about getting new developers on board. Better yet, in a market where there is more companies looking for developers than there are developers available, making sure that their first impression of your company is good makes it easier to retain those developers. But also from an efficiency point of view, or looking at it from "having fun working", making sure that developers can be easily on-boarded is important, for all parties involved.

And so, I want to talk a bit about on-boarding. Based on recent experiences, but also based on the Ingewikkeld Session we recently did about this topic.

Why should it be good?

Let's first talk a bit about why the on-boarding should be good.

The first impression

If you are able to hire a developer in the current market: Congratulations! Even with the recent big tech lay-offs, for many companies it is still not easy to hire developers, especially experienced developers. As such, you want those people to have a good first impression of your company and of their new job. Remember: There's a good chance that your new developer has said "no" to one or more other companies to be able to work for you. So you really want them to feel welcome and get the idea that their time at your company will be fun.

Get the most out of your new developer

Whether they are a freelancer, external contractor or a new in-house developer, you want them to be up-and-running as soon as possible. As long as they are not up-and-running yet, they mostly cost your company money. When working with external developers companies usually have the expectation that they are up-and-running quite quickly, and those developers are usually used to that. But you have a role in this as well, because if you are not prepared, it'll take them longer to be useful to your company.

Get that functionality out

Aside from the financial aspect there is also the functional aspect: You hire developers because you have a need to build functionality, and you want to get that functionality available to your customers, whether that is internal users or actual, paying customers. So it is in everyone's benefit to get that new functionality out the door as soon as possible. Getting new developers working on that functionality as soon as possible is essential to do just that.

How to make it good?

So, now that we've looked at reasons why we want a good on-boarding, let's look at ways to improve the on-boarding process.

Make a plan

With one recent customer I worked for, I've experienced one of the best on-boardings I've ever had. There was a plan. Not just a short list of things to do, but a full wiki page personalized for my on-boarding telling me which tools I needed, which people I needed to talk to and what other tasks are important for a good on-boarding. This sounds like a lot of work, but it pays off. I was up-and-running in very little time and I knew exactly which people in the organization I needed to introduce myself to and talk to. And since there was a wiki page with check boxes, I had a good overview of the things I still needed to do and my manager had a good idea of how far along I was with the tasks I had. Honestly, this was a great starting experience for me.

Get the right tooling

Your tooling matters. And modern tools give you a lot of options of making the on-boarding process very easy. If you have a good setup with Docker and possibly tools such as Make or Ant, setting up your local development environment will be a breeze. Last year I worked for a client where, when I came in on my first day, the only thing I had to do was cloning their Git repository and running make up. Sure, that initial setup took a while, but that gave me the opportunity to get a drink and talk to some developers to hear more about the project. By the time I came back to my laptop, my development environment was running. It really is worth the investment to not only create the correct Docker containers, but also make sure that that initial setup automatically loads a database with test fixtures, sets up anything that needs to be set up and already runs certain one-time tasks.

If this is not something you can or want to invest in, then at least make sure that the README.md file in the root of your project contains all commands you need to execute manually to get things set up.

Whether you automate everything or use the README approach, this is not a one-time investment. This requires regular maintenance as you project gets bigger. Worse than no documentation is incorrect documentation. So make a concious effort to keep the automated scripts and/or the README up-to-date.

Be available

A new joiner will have questions. Better yet: If a new joiner has little to no questions, I would worry about the new joiner. But of course, to be able to ask these questions and successfully and efficiently on-board in your project/company, they need to be able to get answers to those questions. So, especially in the first couple of days, make sure that someone is always available to answer questions. Always? Yes, in a perfect situation there would always be someone that can help. It does not have to be a single person (although something can be said about simply schedeling "on-boarding new developer" in for a single person so that others can focus on their regular work) but ideally it is always clear who will answer questions.

Low-hanging fruit

Especially when you work on complex software, you can not expect a new developer to immediately work with the rest of the developers on implementing big new features. It takes a while to get going and understand what a codebase is about. To get people up-and-running soon and digging into the codebase, it is good to have some simple tasks available to pick up in the first few days. Things that may be interesting: Simple changes to existing functionality, writing (unit) tests for currently untested code, simple refactoring tasks. This has multiple advantages: the developer has an easy way of digging into the code to learn how it works, the low-hanging fruit is often things that get overlooked quickly by experienced developers because those focus on the bigger tasks, and it gives a very rewarding feeling to be able to make your first pull request in the first day or first couple of days.

The session

If this all sounds interesting to you, I would recommend checking out the Ingewikkeld Session we recently did on this subject. You can watch the Youtube video below, or look for Ingewikkeld Sessions in your favorite podcast app to listen to this session.

Having said that, if you like learning about development-related subjects, it's a good idea to have a regular look at the planning for our Ingewikkeld Sessions. And if you really like what we're doing, you can also support us at Patreon. If you support us, you get access to the full back catalogue of our live stream recordings.

We can help

If you have more questions about on-boarding or you need help setting it up, do get in touch with us at Ingewikkeld. We can help by looking at your current on-boarding process and advising on how to improve it, and we can even help you improve it.

If you're like me and you enjoy Disney movies and Disney shows, you'll most likely have thought at some point while watching a movie:

Gosh, this reminds me of the time at work when...

All the stuff Disney makes, whether that is Disney itself or Disney Pixar or any of their other ventures, it all contains a lot of lessons and emotions. And that translates well into real life.

Recently, I did this talk at SymfonyCon 2022, in which I shared 7 lessons you can learn from Disney movies, and I'd like to also share those lessons here. Because I know that you can probably relate, at least to some.

Who are you?

When you start out as a developer you may have an idea of what you want to do or who you are. But along the way you'll have experiences and learn even more about who you are. Or perhaps who you are changes. Your interests may shift, your views on software development may shift, you'll learn new stuff.

During your whole career as a developer, it is important to communicate who you are and what you want. To your colleagues, to your superiors, to the people around you. What's your ambitions? Where do you want to go? What are your talents and what work do you find enjoyable.

I've seen so many developers that got stuck in their jobs and didn't really know how to show it. They tried to hide their true interests and talents because those didn't fit with their current job.

In Frozen, I see a similar thing happening with Elsa, who hides her uniqueness. Why? Because of an accident she gets scared. She hides herself and instead of focussing on learning what she can do with her skills, she gets stuck. It is not until she comes to the realization that she can solve this problem herself that she learns to fully use her skills, her talents in the right way.

And this also goes for you. During your career, mistakes will happen, you may feel out of place. But instead of sucking it up and just continue the way you are going, you can also embrace who you are and what you like, and try to use that as a superpower. So find out who you are and what your superpowers are, and try to make them work for you instead of against you.

You are not alone

I already mentioned before that talking to people is a good idea, so let's zoom in on that a bit. Because the communication with people around you makes you realize that you are not alone. There are quite a few support structures around you. Whether that is family, friends, colleagues, your manager, the HR department in your company, the company itself. You don't even have to have all of those available to you. Just one is enough.

And really, sometimes your support structure may disappear. You may lose your job. I hope it doesn't happen, but you may lose your family. Speaking of which, can you remember what happened in the Lion King. Simba losing his father in a quite dramatic way, then leaving. Thinking he is all alone. But he finds support. Rafiki mentors him. And of course his friends Timon and Pumbaa have his back. Of course he has to work hard to try and understand who he is and what he wants, but with a mentor and with the support of his friends, he can make great things happen.

And the same goes for you. Everyone needs a mentor. If I think back, I had a lot of mentors over the years. Not all of them were officially my mentor, but I've learned so much from family, friends and colleagues such as Marjolein, Tomas, Alex, Petra, Ivo, Mike and countless others. Sometimes you have to seek out help, and sometimes it just happens. But the most important message of all is: You are not alone. You are Simba and destined for greatness.

What is your goal?

When you have the help of a mentor or the support of a friend, use it to set some goals. Because really, without goals, aren't you just going in a random direction? Why don't you just aim for infinity, and beyond? Oh wait, I think there was a Disney movie where that line was used. But that's not really the storyline I wanted to use.

What I wanted to look at though was Hercules. Do you know that movie? As a kid Hercules, son of gods Hera and Zeus, is stripped of his immortality. To get that back, he must become a true hero. And that makes him set out to reach that goal.

Now I'm not saying you need to become a PHP hero, but what I want to point out was what setting this goal brought him: It gave him purpose, gave him something to reach for, something to fight for. And that also goes for us. In a world of constantly evolving technology, if we don't learn, don't struggle, don't make mistakes while reaching for the goals we set for ourselves, we fall behind. So on a regular basis, set some goals, evaluate your previous goals, don't worry about sometimes not reaching one goal. The journey towards that goal has brought you to where you are now, and where you are now you may be able to set new goals, so it hasn't been for nought.

Learn and persevere

And that's one thing to learn anyway. Nothing you do is for nought. Even if it doesn't bring you what you wanted, it may bring you unexpected other lessons. Remember Lightning McQueen from Cars? He makes a mistake that eventually makes him end up in Radiator Springs, where he has to appear in front of a judge and gets sentenced to community service. McQueen is desperate, because he has to make the final race of the Piston Cup in time, but as his time in Radiator Springs progresses he learns to appreciate the town as well as the people in it. He still wants to win the Piston Cup, however, so he practices for that outside of his community service hours. Eventually, he makes sure his community service tasks are done before going to the Piston Cup final. He doesn't win, but the only reason why is because of the sportsmanship he shows in helping one of the other competitors, because of his lessons in Radiator Springs.

For us as developers there's a similar story. Sometimes we make mistakes, sometimes we have to make detours. Sometimes we don't like where we are or where we are going, and we feel pressure or maybe even put pressure on ourselves to get something done. But if we learn to appreciate where we are, the people we inadvertently have around us, and if we keep practicing for where we want to go, we can do a lot and we can learn a lot. And even if something seems impossible, sometimes we need to persevere. We need to keep going, find creative solutions to "impossible" problems, we have to keep trying to get there. And we should not forget to think about the people around us.

And one thing Lightning McQueen learned was that competition is not all there is.

Is it a competition?

Do you remember Monsters, Inc? A world of monsters that generate energy using the scared screams of human children. The monsters keep track of how much scream they catch and thereby energy they create, as a sort of competition. Sulley is at the top of the list constantly, but Randall wants to go beyond all boundaries to be the top monster. Which triggers all kinds of unwanted situations. Of course, everything is well at the end, but we can learn a big lesson here. In a company, you're a team and together you work towards goals.

Unfortunately I have experienced several times that developers were very competitive within their own company or even their own team, going as far as hindering other developers in their work so that they could be regarded as the best developer. Well, let me tell you something: If you're not acting in the best interest of the project you're working on, you're not the best developer. The best developer is always the developer that helps their team, and helps the project move forward.

Take a chance

Earlier on I mentioned having a goal. And when you've set a goal, sometimes you come to the conclusion that it will not be easy to reach that goal. That you might have to take your chances, take some risk to get to that point. You have to be brave and maybe... bend the rules a bit?

Remember Mulan? The woman who was adventurous and brave, much to the dismay of her very traditional family. She risks a lot by cutting her hair, pretending to be a man and signing up for the army which eventually leads her into battle. She's wounded and that triggers the outing of her secret. She's kicked out of the army but does not give up and eventually plays an essential role in saving the emperor.

Mulan took enormous risks and I can't really advice you to take risks as big as these, but our work sometimes does involve taking risks. For instance when using a new piece of technology that you don't have experience with yet, but you need something like that for the project you work on. And also in our careers sometimes you just have to give up one job for a chance of a better job. Sometimes you will fail, but failure is OK. Because failure teaches you, and you'll take that experience with you for the next time you face something risky. So, next time you're faced with a big risk, when you have to decide what to do, think of Mulan. Consider your options, and perhaps take a chance.

Perhaps you need a different perspective

OK, one more lesson to finalize the 7 lessons I wanted to talk about, and for that there's actually 2 movies that I want to talk about.

Let's start with the oldest one so far: Lady and the Tramp. Lady grows up in a very protected and luxurious environment until an incident triggers her to run away and she befriends Tramp, a street dog. The difference between the two could not be bigger. Eventually Lady still believes that they are two different to be friends or even partners, but as the story progresses she learns that while Tramp has a completely different background, they indeed can be friends... and more.

And the other movie that I want to talk about is Up. Remember that one? Carl and Ellie dream of Paradise Falls and save money, but they end up having to spend that money they whole time. As Ellie falls ill and dies, Carl feels he failed on their quest to get to Paradise Falls. The epic scenes of his house flying away carried by balloons is epic, but it isn't until he finds Ellie's scrapbook with photos of their marriage and a note thanking Carl for the adventures they had that Carl realizes that he can have adventures still. He just needed to take a different look at his own situation, to understand that while they didn't make it to Paradise Falls, they still had some beautiful adventures together, and that adventures were still there for the taking.

Both movies teach us an important lesson of perspective. Sometimes, based on your experiences so far, based on the things that you've learned or seen or done, you feel a certain way about a situation or a piece of code. And while moving forward based on that experience and those lessons you've learned is certainly not a bad thing (it's actually a big part of your work), it can be good to sometimes take a step back and try to look at it from a different point of view. Talk to your colleague. If you're a senior developer: talk to a junior developer. If you're a junior developer, talk to a senior developer. But talk to someone who will look at it from a different perspective. And then (re)consider if you're still on the right path, taking the right approach.

And it doesn't have to be made very big. Remember the rubberducking method? Where you explain a problem to a rubber duck as if the rubber duck would be able to help you with the problem. By having to think about how to explain the problem, you already think in a different way, or that can already help you solve the problem you're facing. By the way, that also works really well with an elePHPant.

I like this!

That's great! I delivered the above information (plus a bit more) at SymfonyCon 2022 in the Marvel New York hotel in Disneyland Paris recently. If you missed it there, you'll have another opportunity, because I'll also deliver the talk as part of the Ingewikkeld Sessions on December 6th. Attending the live stream is free, but of course you can support us on Patreon.

Over 2 years of no conferences was nice when it started, but eventually started to wear on me. I had the luck of being invited to speak at the PHP Ruhr conference in November of last year, which was still awkward because clearly the pandemic was not over yet and there were quite some measures still active. I'm not complaining, they were definitely necessary, but that made the conference quite awkward. The awesome location (the Dortmund stadium) made up for much though. Wow!

Then, May 2022, finally a PHPDay in-person event again. It reminded me why PHPDay is currently my favorite conference: An excellent location in a beautiful city with nice people and a stellar line-up. OK, and me as well. There were still some active measures but already less, and it felt more normal. And I found out I sorely missed the gathering of peers, talking to old friends and making new friends.

But just one conference in the first half year still felt weird.

Luckily, I'm going to be making up for that by speaking at two great conferences in the next month. There'll be a bit of overlap in which old friends will be there, but I also look forward to meeting new friends.

SyliusCon 2022

Over the years I've been involved in a couple of e-commerce projects using Sylius and it has been a blast. I can not generalize because there's enough pieces of e-commerce software that I have not used yet, but out of all the software I have worked with, Sylius is definitely my favorite. As such, I'm really happy that I got invited to Poland to speak at SyliusCon. My talk will not be about Sylius. Instead, I'll be looking at development and comparing it to situations from Gordon Ramsay's Kitchen Nightmares. Because believe it or not, developers can learn a lot from chef Ramsay.

SyliusCon is next week, October 27. There are still tickets!

SymfonyCon 2022

Then in November, it's off to Disneyland Paris for SymfonyCon. While I work with many frameworks in my job, Symfony has been my favorite for years now and I don't foresee that changing any time soon. As such, I am quite happy to be accepted again to speak at SymfonyCon, especially now that it takes place in one of my favorite locations: Disneyland Paris. It is going to be awesome.

At SymfonyCon I'm going a brand new talk, but similar to the one I do at SyliusCon. Instead of looking at chef Ramsay, I'm talking a deep look at Disney movies to see what we as developers can learn from those. I will share 7 lessons I learned from watching Disney movies. See you there?

For SymfonyCon, get your ticket here.