skoop.dev

Remembering Bob den Otter

January 22, 2024

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

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

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

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

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

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

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

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

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

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

January 19, 2024

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

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

Web Camp Venlo

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

Dutch PHP Conference

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

December 9, 2023

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

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

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

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

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

interface CheckoutPayment 
{
    public function getStatus(): PaymentStatus;

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

interface AccountingPayment 
{
    public function getStatus(): PaymentStatus;

    public function getAmount(): Money;

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

My preference

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

December 1, 2023

conferences, php, symfony, symfonycon

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

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

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

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

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

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

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

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

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

5. Rick Kuipers – Symfony is RAD

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

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

October 23, 2023

php, session, small steps, usergroup

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

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

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

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

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

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

October 10, 2023

business, customer, php

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

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

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

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

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

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

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

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

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

September 23, 2023

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

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

FrankenPHP

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

The Need For Speed

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

DTO

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

Decentralized web

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

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

Inspiration

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

September 14, 2023

debugging, performance, php, problem solving

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

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

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

Take a step back

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

Get help

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

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

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

No really, step away

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

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

Good luck!

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

August 4, 2023

apiplatformcon, cakefest, conferences, php, talks

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!
What developers look for when reading a job opening

August 2, 2023

developers, jobs, opening, php, vacancy

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!

Web Camp Venlo

Dutch PHP Conference

My preference

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

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

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

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

5. Rick Kuipers – Symfony is RAD

FrankenPHP

The Need For Speed

DTO

Decentralized web

Inspiration

Take a step back

Get help

No really, step away

Good luck!

API Platform Con

Cakefest

Salary

Other benefits

Location

Responsibilities

Working hours

Tech stack

Methodology

Duration of the contract

What is the team like?

Language

What type of clients do you work for?

Sustainability and responsible entrepreneurship

What NOT to do?