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.

I've not used Github a lot anymore in recent times because we've switched to Gitlab some time ago. The main reason for using Github at this point is client work. But sometimes, I still need my account for open source reasons.

For one of the customers I do work for, however, I was asked to create a separate Github account. Now I was running into some issues because the private repositories are now shared with this new account, but by default I'm logged into my own account on the commandline (well, it picks my default key). Searching around I ended up on the site of freeCodeCamp, where Bivil M Jacob shared the solution that ended up working. The solution: Add a configuration file.

The first three steps are pretty standard and now that hard to understand, but the fourth step was new to me. I had no idea this was possible. So I followed the guidance of Bivil and ended up with my own .ssh/config file:

# Skoop, - the default config
Host github.com
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_rsa

# clientskoop
Host client.github.com    
   HostName github.com
   User git
   IdentityFile ~/.ssh/cf_ed25519

I've redacted this example to not include my actual client name. Now, if I want to clone a private repository from my client, all I need to do is:

git clone git@client.github.com:clientname/clientrepo.git

In the above command, note the client.github.com host name that is the same as the Host I defined in the config file. And lo and behold, when I clone in this way I can clone without a problem. It takes the correct key for this specific repository and I can do everything I want: push, pull, etc.

Sometimes the solution is simpler than you would've imagined.

Almost two years ago we moved to our current house. It was actually right at the start of the current pandemic, because we had some potential issues with moving because at the start it was unclear what the rules of the first lockdown were going to be. Luckily, moving was still an option.

In the old house we had set up our wifi network using a Ubiquity Amplify set with a base station and two mesh points. This worked really well because it was an old house so the wifi signal could pretty easily pass through floors and walls. The house was narrow but long, and we had a good wifi covering throughout the house.

The new house we moved into, however, had some challenges. It's a newly built house, very well isolated and with floor heating. It's great! However, having a set up with a mesh network that relies solely on a wifi signal being passed around quickly turned out to not be reliable. The signal was almost fully blocked by the heating and isolation material, causing great wifi on the ground floor but bad to now coverage on the first and second floor.

I contacted Ricardo Wijthoef of Tweeweg Internet, who was also the man responsible for the wifi on our WeCamp island. A great person very knowledgable of how to set up wifi and cabled networks. We got together and made a plan of how the network would work, what equipment we needed and how to set it all up. We started with the first floor (since the ground floor had pretty OK coverage with the Ubiquity gear) and getting the cables up to the second floor. Once the day was over we agreed to set a new date soon to finish the rest.

Unfortunately, Ricardo got quite ill and after some time in the hospital an email landed in my inbox some time later with the announcement that Ricardo had passed away. While this was sad for our home network, it was even more sad for the fantastic person that Ricardo was. Always willing to help people, friendly and a funny guy.

For quite some time after that, I could not be motivated to even think about doing the network without Ricardo, but last year I got to the point that I said to myself: Let's finish this thing.

The setup

Because getting a good wifi single up two floors is almost impossible, the only solution is is to pull cables up. Since we already had a cable going from the ground floor to the second floor and the first floor was already fully functional, that meant I just needed to get the correct access points for the ground floor and the second floor. Ricardo had recommended TP-Link Omada gear and since we already had installed an EAP235-Wall on our first floor, I ordered two more. Since these are powered by Power of Ethernet (PoE) I ordered a TL-SH1005P Switch. This would ensure all access points would have power. To have full control over the network and connect to the modem/router of my fiber provider, I got us a TL-R605 Router.

Now there were two more challenges to solve:

• I wanted most devices in our living room to be connected by cable
• I did not want to have to configure all devices seperately

Cabled connections

The EAP235-Wall has 3 ethernet ports, which is fantastic because it allows you to have good wifi as well as cabled connections. But our living room has more than 3 devices that I want to have cabled: Our TV, our settop box, our Playstation, our BlueSound and our AppleTV. So I got us an 8-port unmanaged TL-SG108 switch that I connected to the ground floor EAP235-Wall. Problem solved. Once I realised how easy this was, I got another TL-SG108 for the office on the second floor. While wifi is good there, having ethernet there for our computers is even better and those switches are not that expensive. Excellent!

Configure once

Now the other thing: I wanted an easy way to manage all these TP-Link devices. Luckily, TP-Link has an easy solution for that in the form of the OC200 Hardware Controller, a small device powered by PoE that allows a central place to configure all devices using the Omada Cloud environment. Configure once then simply roll out the configuration changes to all devices in your network.

Well, that was easy

After connecting everything the setup was a breeze. It was very easy to connect everything together and get the controller to recognize all the devices. I was a bit shocked at first that the default username/password combination for all devices was admin/admin, but when you log in to the devices you're forced to change that. Also, the controller will take over the control of all the devices anyway. So that was easily settled.

Ka-ching

Now, what did all of this cost? A quick overview:

• 3 TP-Link EAP235-Wall access points: 70 euro each
• 1 TP-Link TL-R605 router: 60 euro
• 1 TP-Link OC200 hardware controller: 75 euro
• 2 TP-Link TL-SG108 8-port switches: 30 euro each
• 1 TP-Link TL-SG1005P 5-port PoE switch: 45 euro

That makes a total investment of 450 euro, plus the cables (but Ricardo was nice enough to just give those to us).

Concluding

I am extremely happy with this setup. The Omada Cloud web interface and the Omada app are really easy to use and gives a lot of control over your network. The wifi connection throughout the house is now fantastic and having the devices that use a lot of data such as the TV, settop box, Playstation, BlueSound and AppleTV on a cabled connection has greatly improved the audio and video quality of those devices. The investment was really worth it. Plus, it was a nice hobby project over the holidays.

Last year, as the global pandemic caused us to have to cancel WeCamp, we felt compelled to do something else. That something else became Comference, an online conference from the comfort of your own chair, couch, bed, or wherever you want to comfortable see a nice set of interesting talks. In terms of content we wanted to stay close to WeCamp in that we felt tech was important, but there's many topics related to the tech world that are equally important and maybe not getting as much attention at tech conferences.

Our go/no-go moment for WeCamp is at the end of December or early January. This is because we have to reserve the WeCamp island and make a down payment on the reservation, but also because we start our search for both sponsors and coaches in January. So early this year we had to make the sad decision that 2021 was simply too early to start planning a new WeCamp. The result of that was, obviously, that we wanted to organize a new Comference.

Tomorrow we kick off that second edition of Comference, and I'm really looking forward to it. We have some amazing talks that I want to highlight here.

Documentation

As much as developers don't want to hear this, documentation is important. I'm really looking forward to hearing Milana Cap speak about documentation based on the documentation of one of the most important open source projects in the world: WordPress.

Get rid of management

With our company Ingewikkeld we've been working a lot for and with Enrise over the years. It is fair to say that Ingewikkeld wouldn't be where we are today without Enrise. We've worked on some amazing projects with them. Some years ago they switched their whole business to completely self-managing teams and it's been interesting to follow that journey. Now we'll have some people from Enrise telling us about that switch and the new model.

Change

Change can be hard. If you're convinced a change is necessary, but the rest of your team or organization isn't convinced, it'll take a lot of hard work. Jeremy Cook will tell us more about what you can do to get adoption for change without having to become some kind of dictator that pushes change down people's throats.

No More Scrum?

Most companies I come into as a developer or consultant have adopted some form of scrum. Jeroen de Jong is at Comference to tell people to stop doing scrum. What? Yes, he'll share the story of how he told a team to stop down scrum and how that helped them to improve collaboration.

Do you see the light?

Due to the pandemic a lot of people have started working from home more. And as the pandemic (hopefully) leaves this world, remote working seems to have gotten a stronger grip on the workplace. This is a great development, but it also introduces some challenges: How to get a good home office set up. Camilo Sperberg talks about a topic often forgotten: Lighting.

Diversity

Diversity is a diverse (see what I did there?) topic. Last year we have Lineke talking about diversity from a completely different point of view, and this year Andreas Heigl takes a completely different view on diversity again: How do we scale diversity on a global level?

Don't believe the hype

APIs are here to stay, but we can certainly improve on how we create our APIs. Tim Lytle will be sharing information on how to make an API easy to traverse and ensure less problems with implementing APIs by introducing hypermedia.

The fellowship

If you've been following me for some time you know that I simply love the PHP community, and the concept of community in general. I'm really happy that one of the greats of our community, Wasseem Khayrattee, has agreed to do a talk about the community and what community can do for you as well as what you can do for the community.

Isolation on an island?

Last but certainly not least, we dive into the world of open source. Tonya Mork and Juliette Reinders Folmer are going to have a conversation about open source, and about how open source projects are not isolated islands, but together they are a constantly changing ecosystem of related projects.

See you there?

The whole of Comference is free to stream on YouTube (we'll also add the video's to our website). If you have any questions or want to discuss the subjects of the talks with fellow attendees, feel free to join the Comference Discord. That same Discord is also used during the game night to discuss what games we're going to play. See you there?

OK, so this might be a situation you may get into, but I'm blogging this as much for myself as for others because I know this is a situation that I might also head into:

You start working on a new project for a new customer, and you forget to set up PGP signing of your commits in your Git configuration. Now you've pushed your branch, made a pull request but the pull request can not be merged because your commits are not signed. OH NO! Now what?

The one-liner

Luckily, I'm not the only one to do this and a quick search around the web resulted in this post on superuser.com and look, it is actually quite easy. First of all, you configure git to use your PGP key and set the correct email address. Then you use git log to find out the commit hash of the commit before your first commit. Then you use the command:

git rebase --exec 'git commit --amend --no-edit -n -S' -i <commit hash>

Where, obviously, you replace <commit hash> with the actual commit hash.

Simply write and quit the editor coming up describing what the rebase is going to do, and... TADA! All your commits are now signed.

Force push

Yes, you will have to force push your changes to your branch. But since the merging of the pull request was blocked anyway, no one will have pulled your changes. Right? RIGHT?

If anyone pulled your changes before you force pushed, you'll have to warn them and prepare them for a bit of extra work.

Done!

And that's it. That's all you need to do to sign your commits after the fact. And next time you start working on a new project, don't forget to configure Git to use your key and sign your commits from the start.

I am very happy to announce a new initiative from Ingewikkeld: Comference Summer Sessions. In three interactive panel discussions we'll be talking about three topics we feel are very important in development:

• Open Source in your company
• Facilitating company cultural change
• The role of the Product Owner in a development team

Each session will last about 1.5 hours, in which the panel will discuss the subject at hand. Through our Comference Discord, you can also ask questions and remarks that the panel can talk about.

After each session, the panelists will also record a 30-minute podcast in which the panel summarizes the most important lessons from the interactive session. So if you miss the stream or if you want to be reminded of what was talked about, the podcast is there to help you out.

For the first session, on Open Source in your company, the panel is already known:

• Host: Jaap van Otterdijk (Ingewikkeld)
• Sebastian Bergmann (PHPUnit, ThePHP.cc)
• Stefan Koopmanschap (Ingewikkeld)
• Erik Baars (ProActive)

I am very excited about this new series of events. The sessions are free to attend (we're streaming them live on YouTube). SO block your calendars for the three dates:

• Tuesday, June 29
• Tuesday, July 27
• Tuesday, August 24

I hope to see you there!

Dear recruiter,

This is an open letter to you, the recruiter who focusses on the tech industry. I've had many interesting experiences with recruiters, and I want to share some, to tell you about my positive and negative experiences, in the hopes that you might learn something.

In my social bubble, both online and offline, many developers are not happy with you. Perhaps not you specifically, but recruiters are often seen as annoying, rude, lying people. It is therefore especially important for you to make a good first impression when you contact someone. Hopefully, the things I'm going to talk about will help you do that.

Be clear and honest from the start

I have had many interactions with recruiters that were either very unclear or dishonest, or conveniently left out some information in the early communication about a project.

One example was an email I got about a very interesting project. I showed interest, sent a CV and had an interview. This means that from my side, I've invested several hours already, hours that for me as a freelancer, are unpaid. Because I see potential in the project.

The customer was interested and I was interested as well. And then the paperwork came about, which included a 90 day payment period. 90 days. That is three months. When I responded to that, I got told "This is standard for this customer". That might be true, but you know that and I don't. And I don't know a lot of freelancers that are OK with or even capable of handling a 90 day payment period. It could've saved me (and you!) hours of work and a disappointment in the final stages of the process. And if this is standard, you knew about it and could've communicated this in your initial email (or quickly thereafter).

More recently, I got an email about an interesting full-remote project. I specifically communicated in our initial communication that the full-remote was an important requirement, and you went ahead and introduced my developer to the customer. When that developer interviewed with the customer, it turned out that because they were recruiting for a new team, there was a 2-day on-site requirement. When I asked about this, you told me you had heard about this already. Why had you not already communicated this to me? This could've saved me, my developer and you a lot of time and frustration.

Send the right projects

The amount of messages on LinkedIn and email in my inbox from recruiters is pretty big. Which I can accept, because that should mean that we do our work well and you as a recruiter think we could be good potential candidates for the roles your customers have.

Unfortunately, when I wade through the emails, I can delete about 75% of the emails immediately. With my company we focus on PHP development, architecture, consulting and training (and you know about that!), so why do I get so many emails for Python positions, Java positions etc? You are wasting a lot of my time, because yes, I go through all of these because there might be a super cool project in there that we want to work on.

If you send out emails or LinkedIn messages, please make sure you only send messages that actually apply to me. If it's sort of related (like a product owner or scrum master role) that's fine as well, but things that are totally unrelated to our specialty can better be sent to the people that specialize in that.

Rates

I only rarely receive emails about projects where the rates are communicated in the first email. Most of the emails contain useless wording such as good rates or competitive rates. Just tell me what you're willing to pay me. I'm happy to discuss my rate and in specific situations adapt my rate to fit with your client's wishes. But, here we go again, it would save you and me a lot of time if you communicate this upfront. Because if your maximum rate is 80% of my minimum rate, we're never going to be able to make a deal.

Ask before sending my CV

Unfortunately, I've been in situations where I was contacted by you and I sent you my CV, and while we're still discussing specifics it turns out you've already sent my CV to your client. Later in our discussion it then turns out that we can't agree on specifics, and then I get the but I've already sent your CV to the client and they're really interested, can't we agree on this because this looks bad on me. Listen, if you've already sent my CV while we are still discussing specifics, that is not my problem. Also, please consider the damage it does to my image. Because I'm pretty sure you're not going to tell your client that you f*cked up. Which means that this specific client, which I may or may not encounter in the future, may have a negative experience with me, even if they haven't even ever spoken to me.

That first impression

The above are only a few examples. I have many more where these came from. So let's talk about making a good first impression. And that really already starts with your initial contact:

• Send an email first, with as much information you have on the project: A good description of what the project is, what your client is looking for and why you think I would be/have a good candidate, a maximum rate (possibly accompanied by a preferred rate), a description of the process and any special requirements or other agreements that are important such as payment method, hours per week/month, specific work days, required insurances and anything special that is expected to be included in the rate such as specific hardware or software, background checks, etc)
• Feel free to call me after a couple of days if I haven't responded yet, but give me some time to consider if I am or have a good candidate for the project and whether I can agree with the wishes and requirements
• If any new information comes to light between your email or other contact we have, inform me of that. Don't leave it out for me to find out later. Because I will (have to) find out.

This is just for that good first impression. If my first impression of you is not good, given the amount of bad apples in the recruitment business, it is very likely that you'll quickly make it to my mental blacklist and I'll ignore you in the future.

After a good first impression, make sure to show that you want to continue a good business relationship. I try to do that as well by contacting you if I feel there might be a good opportunity. Don't spoil it by spamming me with projects that you know I'm not a good fit for. If we agree to work together, ensure that you agree to your end of the deal in terms of payments etc. That ensures we might be able to work together for a long time.

Stand out

In a recruitment world that is dominated by spammers, lying people, frustrating communications and an overall negative attitude, it is quite easy to stand out, it is easy to show that you're serious about doing business with me by showing you don't just care about your own profit margin, but you care about a long-term business relationship. I care deeply about delivering high quality services to my customers and, if we work together, to your customers. Please show me that you also care about that. If you do, I will not only be happy to work with you for a long time, but I'll also be happy to help you find other possible candidates, which may lead to more money and a better network for you. I'd call that a win/win situation. Please care. I do.