Regenerative software development

I have been under a lot of stress. Not just in work, also in my private life. I'm also very worried about the state of the world around us, the community we live in. And I am someone that tends to worry. I have a hard time with the mantra "grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference." I have always been feeling stress but lately it's been higher than ever.

Courage to change the things I can

As part of wanting to change the things I can, I have been actively protesting during Extinction Rebellion protests in The Netherlands. I've even taken on an active role (Arrestee Support, which an an awesome role to have). And more recently, I've helped start a local chapter of XR. If you're in the Utrechtse Heuvelrug or Woudenberg municipalities and you want to join, come join us!

Regenerate!

Last year, XR blocked a highway in The Netherlands for weeks on end to protest against fossil subsidies. At first everyone was very ready for it. While during the week the group was smaller, during weekends the group grew bigger. But as time went on, the group became smaller. This wasn't because people didn't want to protest anymore. On the contrary. This was because of one of the principles of XR: They are aiming to have a regenerative culture.

This does not just mean that the way we treat the earth should be in such a way that our planet can recover from the pressure we put onto our planet. This also means that we as humans beings should treat ourselves in such a way that we can recover from the pressure we put on ourselves.

Why? Because you can not be constantly sprinting. So we need to recognize when we run into our boundaries, preferably before we actually run into them, and recover enough so we can get back on our feet and again take action.

From Extinction Rebellion to software development

I see a similar thing happening in software development. Whether in open source development or in commercial services: We try to keep sprinting. We try to keep the high pace going, hoping we'll get to the finish as fast as possible, just so we can continue with the next race immediately.

For open source, that means constantly working on the next release. Through specifying what needs to be done, actually building it, testing it, putting the release out then moving on to the next feature on the list.

For commercial software development, that means going from sprint to sprint. Doing your demo, then moving on to the planning of your next sprint and immediately starting it. If you're lucky, you have a retrospective in between. But even the retrospective can be intense, since it is meant for honest feedback. As a software developer, most of your work is done with your head. A retrospective is also done with your head. There is no rest.

How can we do this?

With burnout being a major issue amongst developers we really need to take better care of ourselves. This includes taking care of our boundaries and making sure we don't cross them, at least not for longer periods of time, but also taking care of each other. And identifying where we can improve.

Is stress a bad thing?

We often talk about stress as a bad thing. This is because usually we don't start talking about stress until it actually becomes a problem. But by then, it might already be too late. We should realize that there is good stress and bad stress, and there is no single definition of what is good and bad. As Mira Miller writes in the linked article:

Two people can experience the exact same event—such as a new project with a tight deadline—but one of them might experience it as an opportunity to take on an interesting challenge while the other one might automatically predict that they’ll fail.

So first of all, we need to make sure that we recognize the bad stress in ourselves and each other early enough. If you recognize it early enough, you can prevent issues such as burn-out, but also lower efficiency due to prolonged stress.

Make sure you're not "always on"

First, we should all realize that being a software developer does not mean that you're writing code 100% of your working time. And with we should all, I mean, all of us. This includes developers, but also project managers, stakeholders and company management. Years ago I did a keynote at several conferences titled Developers are just like humans. Developers are not just a "human resource". They are first and foremost human.

This also means that we should not feel guilty for taking a break on a regular basis. It is OK to stand near the watercooler talking to someone. And that talking does not necessarily need to be about work. It could also be about what you did last weekend, or your plans for tonight. Or the fact that your kid just starting walking and how funny it was when they fell on their butt when they tried. Or how you won another round of Fortnite last night.

We should also not feel guilty for taking other measures to ensure you're not overloaded. When you're stuck on this annoying bug you can't replicate or how to implement that new architectural pattern you need for your new project, take a step back. Actually, take a lot of steps. Go outside and walk for 30 minutes. You'll feel fresh and there's a chance you'll even find the solution to your problem quickly after you get back. Your head sometimes needs the time to process what you're doing.

Full sprint?

To retain a sustainable pace in your software development, it could also be useful to not just schedule sprint after sprint. Sure, it's OK to do 2-3 sprints of 2 weeks each right after another. But every once in a while, schedule in a week without sprint. This does not mean you don't have to do work that week, but it's good to be clear of the pressure of a sprint every once in a while. Take the week to do that refactoring you've been postponing because the sprint work was more important. Or step back and (re)consider your current architecture. Does it still work? You could even use the time to thoroughly refine and prepare the stories for the upcoming sprint(s). Most importantly: Don't expect too much of this week. Work will get done, but don't schedule your whole week and expect everything to be fully done. We want to get away from the regular work stress, right?

And I already hear the finance person, the project manager and the management: "But that week costs us a lot of money!". Yes, but as said, the work gets done. And regenerating is very useful to make sure that in the sprints that follow, the developers can again put in the sustainable pace that is expected of them. Besides, that refactoring or thinking about the architecture or writing of missing tests or whatever other thing that is done during that week, that's work that should also be done. By having that done during that one week "off" sprints, your application is better prepared for the future, and you'll save time in the long term.

Retrospect

In agile we learn that the retrospective is a moment to evaluate our process and discuss possible improvements. I would say that the process is not the only thing that needs evaluation. During the retrospective, also take some time to evaluate the impact work has on each team member. Make sure that everyone is still OK and ready to move on to the next sprint. And you don't even just have to do that during the retrospective. Your daily standup could start with a short check-in for each team member: How are you feeling today? Are you ready for the new day?

A developer is more than just that human resource

What I mean with this is that a developer is a developer during working hours. But outside of working hours, they also have a life. And things happening outside of working hours can also affect work. It is naive to think it won't, and it's unethical to expect it not to. Developers are not robots, they're human beings.

So, we need to make room for being able to deal with that. It's much more efficient to every once in a while give a developer one or two (paid) day(s) off to handle private matters well than to have a developer that is distracted for a longer period because they have to handle those private issues only after a long and possibly stressful workday. Sure, there are limits to this and if something needs more time then it is OK to see if they can take some days off from their vacation time (I realize this also really depends on the country and how much vacation days someone gets, but my main point is: this can be a conversation. As employer, do what you can but also communicate clearly when what you can do ends).

Know what the boundaries are

As a developer, it's good to find out what your boundaries are. From experience, I know that you'll cross your boundaries a couple of times because you figure out where they are. But be mindful of when and where you cross your boundaries, and communicate with your team and manager when you cross your boundaries. It is in the benefit of everyone involved to understand where they are and when to take a breath.

Likewise, just like you keep an eye on yourself, keep an eye on the rest of your team. There are signs of stress that you can recognize in yourself or others. The best way to prevent burn-out and other stress-related issues such as inefficient work but also physical issues such as carpal tunnel syndrome is to create a culture where it is OK to take a step back for a bit, to go outside for a walk during work hours, to regenerate.

Back to XR

And with that, we circle back to Extinction Rebellion. While I did my training for the A12 protests in The Netherlands, the trainer stressed in several ways that as an XR activist, you have a responsibility to yourself. You should clearly recognize when you need to step back. Regenerate. And it is OK to also talk to other about this.

As a business we can learn from XR. Not just about paying attention to our global footprint, but also to create a culture of regeneration for our team members. Because your team members are more than just people who do work. They're first and foremost human beings. And no one gains by completely burning them out, just like no one gains anything by burning out our planet.

Regenerative software development

So let's work towards a better, more healthy culture. A culture where there is room to regenerate, that is not focussed on burning people out and then replacing them with someone new. Remember: It is a lot cheaper to retain your existing developers than to hire new ones.


PHP and e-commerce

It had been years since I was in Cologne for anything development-related, so when the new Symfony User Group Cologne meetup was announced and it turned out it was a panel discussion in English about PHP and e-commerce, I decided to pay Cologne another visit. That was a good decision.

PHP and e-commerce: A match made in heaven?

It was interesting to hear from the representatives of Magento, Spryker, Sylius and Shopware about the differences and things in common between the different projects. I learned that Spryker and Magento are pretty strict in what they allow, Sylius is pretty loose and Shopware is somewhere in between. All have their own way of dealing with security as well as working with external plugins. Although Dennis from Spryker made a very good point:

You need to automate important things such as scanning for security issues. Those mistakes you feel no one will make because they are so easy are the mistakes that you will make yourself at some point

A very interesting discussion was about why these platforms had chosen PHP. While basically the answer for most projects was "because that was the language we were working with at that moment" the panelists were united in that they were still regularly deciding "PHP is still the right choice". One of the main reasons is because it is very easy to quickly implement new features using PHP. The projects do on a regular basis evaluate their choices, and still come to the conclusion that PHP is the right choice. That is good to hear. Then again, a good point was also made that a decision to rewrite the whole platform to another language in a week is not something you make.

The conclusion for now though is that PHP and e-commerce are still a match made in heaven. Being able to quickly make changes and deploy without having to compile things, the fact that PHP is good at Rapid Application Development and that the language has greatly evolved and has a clear release schedule all make for good reasons to use PHP for e-commerce solutions.

So what about the next e-commerce project?

It's interesting to have seen the options of the represented projects. I've worked with Magento before (that was not a good experience for me personally, but that was Magento 1 and I hear the newer versions are better) and Sylius (multiple times, and that has been an amazing experience so far). I've not yet worked with Spryker or Shopware so far. I surely hope to do an e-commerce project in the future where I can either use Sylius again or, depending on the requirements, try a different platform. Surely, there are a lot of mature options in the PHP world when it comes to e-commerce, that much is clear.

Big thanks

Big thanks to Qossmic for organizing this panel discussion. I had a great time speaking to several attendees, both people I knew before and some people I met during the meetup. And the panel discussion itself was really interesting.


Unobtrusive spam-protection with PHP

If you are like me and absolutely hate solving weird visual captcha's with sometimes really impossible questions (is that small corner part of the bike/zebra crossing/bridge or not?) then you must've wondered about how to prevent forms (such as contact forms or comment forms) against spam. Of course, a 100% protection does not exist, but it would be good to have at least some protection.

When I recently updated the Ingewikkeld website with a contact form I quickly got swamped with spam messages. The first thought for many people will be "just add a CAPTCHA". But I do not want to scare away potential customers. I want to make it as easy as possible for them to contact me.

So I set out to search for an unobtrusive alternative. After searching for a bit and not really finding something, I saw the name Cloudflare. Now, I know them, we use their DNS services as well. But I had not yet heard of their Cloudflare Turnstile product. I checked it out and it seemed to do exactly what I wanted. A check, without required interaction. Nice!

I configured it for the ingewikkeld.dev domain and opened my IDE to implement it. There is great documentation and the frontend part was implemented in a matter of seconds. But Turnstile also relies on a backend part: The frontend does a call to Turnstile to obtain a token and "clear" the user. The backend then has to verify that token to confirm that Turnstile indeed cleared the user. It's a relatively simple HTTP request that I could build myself using an HTTP client class, but I decided to check https://packagist.org to see if there was a library that already implemented this functionality. It turns out there are already quite a few.

After a bit of checking I decided to try and implement usarise/turnstile. It seemed simple, supports Symfony's PSR-18 HTTP client out of the box and since the Ingewikkeld website is built with Symfony, that's good. And indeed, it was exactly as easy as I had hoped. Make sure the Turnstile\Turnstile class is injectable via the container, and the actual logic is easy:

$turnstileResponse = $turnstile->verify($request->request->get('cf-turnstile-response'));

if ($turnstileResponse->success === true) {
  // logic
} else {
  // set a flash message and redirect back to the form
}

It's as easy as that! Why would anyone still use a CAPTCHA if this is also an option?


The value of the external developer

Full disclosure: As owner of a company that supplies external developers and as an external developer myself, I have a lot of experience and I also obviously earn my money this way. Keep that in mind when reading this. Also: I speak from my own experience in this blogpost, but there are a lot of freelancers and consulting agencies. You don't have to hire me or one of the Ingewikkeld people (of course you can!). The same goes for a lot of other external developers that you can hire.


Over the years I have worked for a variety of different companies as an external developer both as a part of existing teams or the builder of new ones. Sometimes to help just with the software development, but often to be what I call a "developer++": Aside from helping with software development I am involved with all aspects of development, from architecture to coaching individual developers or even the organization. In some cases I was there for a year or even longer, in other cases it was just a few weeks, in some situations it was simply an hour to brainstorm.

There is not one single thing that is the value of the external developer, so in this blogpost I want to go through several different advantages you as a hiring organization can get out of using external developers in your organization.

A fresh look

This is one of the most underrated advantages of getting in external developers: They bring in a fresh look at the things you are doing and the way you are doing it. If you're fully immersed in a certain way of doing things then it can really help to get someone from the outside to give you feedback on that. From the inside, you might not see everything clearly anymore.

As an example, at one of my previous customers they had made the decision to build on top of an e-commerce framework for their headless e-commerce solution. Their software development was grinding to a halt, but they did not understand why. As I came in, I noticed that the e-commerce framework they had chosen was holding them back more than it was helping them. It would be a bad choice to throw away what they had built, but going forward for the new functionality it would be more productive to leave the framework where it was, and focus on pure Laravel development instead. After we made that decision, development became much more efficient and the rest of the functionality was implemented quickly.

Temporary help or ramping up to your new developer

A big percentage of the projects we do, we simply provide extra development help. Now it isn't always productive to add extra developers to a project that is already late and in the acquisition process I am often critical about this, but there are definitely situations where the temporary extra help can be a benefit to your project. I've found that many external developers are very used to quickly being up-and-running and understanding the problem at hand.

Additionally, if you have a vacancy open, it can sometimes help to get in an external developer for the period until you've found someone to fill the vacancy on a permanent basis. The external developer can ensure there is already some clarity about the exact role of the new hire, and also can make sure that the new developer can hit the ground running because a lot of the setup work has already been done for the new position.

The amount of experience

External developers switch companies and projects on a regular basis. This results in an incredible amount of experience with different situations and different people. The result of that is that there's a lot of different situations and technical challenges that they have already encountered. They bring that combination of experiences to the table on any new project, resulting in one or even more possible great solutions for any challenge you run into.

Dealing with all kinds of different people also really helps with the communication skills. This is why on average external developers are more skilled at identifying and bringing to light possible communication issues in a team.

Get it documented

Based on our experiences, internal developers are less likely to correctly document decisions and technical setup. This causes issues for instance with on-boarding new developers or figuring out the reasoning behind certain technical decisions after a few months or years.

External developers know that they're temporary, that they will leave at some point. The result of that is that they're more focussed on making sure decisions and knowledge about the codebase is documented so that those who come after them can continue the work. This rubs off on the internal team as well usually, triggering them to be better at documenting. The result is code that is better documented, developer on-boarding that can be done much more efficiently and overall more knowledge among team members about the codebase and the problems that are being solved.

Smells like team spirit

Building software is one thing, but building a team is another. That's not easy. And it's really important to have a good team. A good team is able to act on changes faster and is more predictable in the quality of the work they deliver. A good team needs a good leader to keep the team together and make sure it works well together. Often when teams don't work together well there is no leader, or the leader is not able to really keep the team together. External developers can be that glue for the team, and can coach one of the permanent team members to take that role.

Talking from my own experience a lot of places where I've worked in the past decade did not have a team. They had a group of individual developers. And while the individual developers can get a lot of work done, making them a team, where the total is more than the sum of its parts, is something that needs attention. Because of external developers working for a lot of different companies, projects and teams, they usually have a good overview of what needs to be done to truly have a team. They can have that leadership role, or do the coaching of the leader to take on that role.

Get rid of your bias

OK, story time. Some years ago I started at a new customer. The small team of internal developers were reporting to their boss, a former software developer turned entrepreneur. He had built the company himself on top of his own software, but he had not been developing for years as the company took off.

The team came up with several suggestions to improve the software. But they were rejected by the boss because it was unnecessary, or too much work, or there was another reason why it was not a good idea. When I came in, I started talking to the internal developers and I actually quite liked their ideas. They were ideas based on current knowledge of good software development practices. They were definitely improvements. So I started proposing the exact same ideas to the manager. And with the proposals coming from me, the manager said "oh, that sounds like a good idea, let's do that!"

While it is not good that there was somehow no trust in the internal developers, that situation sometimes happens after years and years of being stuck in a certain flow. Sometimes it's good to have external developers challenge your bias against your own people. Especially when you were a developer before so you think you have good knowledge of the matter at hand.

So challenge yourself

So, challenge yourself and your team and get an external developer on board. You don't have to permanently have an external developer in your team, but having one in your team for a few months on a regular basis will already help you and your whole team improve and challenge you to think about the way you do things and your focus on both the technical and the human level. And as I said at the start, you can surely hire one of the experts of Ingewikkeld, but there's a lot more talent out there on freelance, contract or consultancy basis. Need help selecting the right developer? Feel free to get in touch with me. Even if you don't choose an Ingewikkeld developer, I'm happy to help you with your selection process.


Remembering Bob den Otter

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

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

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

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

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?

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.