skoop.dev

  • About
  • @skoop@phpc.social
  • RabbitMQ in your Bitbucket pipeline

    August 15, 2024
    bitbucket, pipelines, rabbitmq, service

    Last week one of my tasks was getting our Behat tests to run successfully in the Bitbucket pipeline. Now, we have an interesting setup with several vhosts, exchanges and queues. Our full definition of our RabbitMQ setup is in a definitions-file. So that should be easy, right? Well, think again.

    Unfortunately, Bitbucket does not allow for volumes for services in your pipeline, so there is no way to actually get our definitions file into our RabbitMQ service. After searching for ways to solve this, with my express wish to not have to build my own RabbitMQ image, I ended up coming to the conclusion that the solution would be to… well, build my own image.

    Creating the image was very simple. As in, literally two lines of Dockerfile:

    FROM rabbitmq:3.12-management
    
    ADD rabbitmq_definitions.json /etc/rabbitmq_definitions.json

    I build the image and push it to our registry. So far so good. Now, I needed to alter our service definition in bitbucket-pipelines.yml. This was also not that hard:

    services:
        rabbitmq:
            image:
                name: <registry-url>/rabbitmq-pipeline:latest
                username: $AZURE_USERNAME
                password: $AZURE_PASSWORD
            environment:
                RABBITMQ_DEFAULT_USER: <rmq-user>
                RABBITMQ_DEFAULT_PASS: <rmq-pass>
                RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS: -rabbitmq_management load_definitions "/etc/rabbitmq_definitions.json"

    The trick in this definition is in that environment variable RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS. This basically tells RabbitMQ to load the definitions file we baked into the image in the first step. That will then set up our whole RabbitMQ, so that the code executed during the Behat tests will be able to connect as usual. RabbitMQ will be available in your pipeline on 127.0.0.1.

  • Creating a Bitbucket merge train

    August 14, 2024
    bitbucket, git

    Sometimes it happens: You have to work on a new feature, but that feature is depending on another feature that isn’t merged yet. Especially when trying to keep your branches small and you’re not doing trunk-based development, this may happen.

    Luckily, Bitbucket makes our life a lot easier. Say you create a new feature-branch-2 based off of feature-branch-1, when you create the pull request, instead of targetting main which will cause your diff to contain the changes of both branches, you can set the target of your PR to be feature-branch-1. Now your diff will only contain the changes in feature-branch-2, which makes it a lot easier to review.

    Now, when the feature-branch-1 PR is reviewed and ready to be merged, you don’t really have to do anything to the feature-branch-2 PR, as long as you keep this checkbox checked that is checked by default:

    On merging, Bitbucket will now automatically re-target the feature-branch-2 PR to the main branch.

  • Goodbye Sculpin, hello WordPress

    August 9, 2024
    sculpin, wordpress

    I really liked the idea of a static site generator. I still the idea of a static site generator, to be honest. However, writing purely in Markdown and having to go through some stuff to publish a new post became a bit of a hassle. So I wanted to go for a dynamic CMS again. My initial idea was to build the site in Bolt, as I love that CMS and the flexibility it offers. I even started on that, but ended up finding I did not enjoy myself while buildings. That made me decide that perhaps I should actually go for WordPress. It works, I have a hosting provider with an easy installer, it has tons of plugins if I want something specific, and… I’ve come to enjoy the new editor on one of my other sites.

    Migration

    Now, the migration was not easy. I started looking for ways to automatically import all my Markdown files. There was a plugin, I couldn’t figure it out. It became a chore. I quit. I gave up.

    I ended up doing a manual migration. I combined the migration with a bit of a clean-up. I removed some articles, added some additional tags to some articles, etc. It was also a nice moment of reflection. Over the years I did a lot of different things. I made some mistakes, or no, I grew. I understand now why some of the opinions I used to have might not have been the best.

    And now it’s up

    So far I’m happy. I have a CMS again. I can easily write and update posts from wherever I have access to my password manager. After all the different CMS’es I’ve had, I wonder how long WordPress will last me. Should be at least a couple of years, looking at my track record of Pivot, Textpattern, Octopress and Sculpin (and possible others) that I’ve used in the past,

    Welcome to the new skoop.dev!

  • Unsupported operand types string * int

    July 30, 2024
    error, php, tip

    Today I had a weirdly failing unit test. PHPUnit complained about the data provider being invalid, with a very vague error:

    Unsupported operand types: string * int

    This was weird, because I wasn’t doing any calculations in the dataprovider.

    That made debugging annoying as well. If I’m not doing any calculations, why this error?

    It turned out a typo was the cause. The weird thing though: There was no * in there. The typo was:

    $errorString -= 'Missing required data key: "%s".';

    See the -= there? That was the issue. It’s still unclear to me why I got the error I got, but if anyone runs into this error, be aware that the error may imply more than just *.

  • Symfony and DDD (and SymfonyCon)

    July 25, 2024
    conferences, ddd, php, symfony, symfonycon, talks

    Last year at the SymfonyCon conference I did a talk about Domain-Driven Design in which I mostly focussed on the theory behind trying to understand what problem you’re actually solving. I really enjoyed doing that talk, but I got some interesting questions afterwards about practical implementation of DDD when using Symfony. And I’ve also seen at several clients that people are always looking how they can actually implement a DDD approach when building software with Symfony.

    That prompted me to consider what would be the best way to do this. There is so much to talk about and the answer to a lot of questions is “it depends”. So I decided to develop a new full-day workshop about this. In this workshop, we take a Symfony project, and we start adding some functionality.

    I am still developing the contents, but things that will come by are amongst other things:

    • How to split up domains
    • Implementing a hexagonal architecture
    • Doctrine entities vs domain entities and how to make that split
    • How to implement communication between bounded contexts and domains

    The workshop will contain a theoretical part per subject, but also exercises for people to actually get some experience with doing this, as I realize that some people learn more from listening to the theory and others learn more by doing.

    If you are interested to get this training for your team, shoot me an email. For those coming to Vienna for SymfonyCon, I do have some good news: On December 4, I’ll be doing this workshop at SymfonyCon. You can already book your tickets.

    Will I see you in Vienna?

  • Upcoming conferences

    June 21, 2024
    apiplatformcon, cakefest, conferences, php, talks

    Conferences are both fun and useful. Fun because you meet people and useful because you learn stuff. I have two conferences in the upcoming months, and I hope to see you there!

    Cakefest

    Last year was my first Cakefest. It was in Los Angeles, and a lot of fun. While I am not using CakePHP and have not used CakePHP in a while it was good to meet the community and share some information that might be useful.

    I am honored that they think I did good enough a job to be invited back again this year. And even better: I don’t have to fly out, I am actually driving to Esch-sur-Alzette in Luxembourg. The schedule is looking good! I will be doing my talk on sustainable open source contributions there.

    Tickets are available for the in-person conference, or you could even get a free ticket for the online stream of the conference. But in-person is usually more fun, so if you have the opportunity, join us!

    API Platform Conference

    Another conference that I got invited back to is API Platform Conference. Again in driving distance for me, and I had a lot of fun last time, so I’m absolutely looking forward again to being there. The conference is in Lille, in the North of France.

    In Lille, I will be doing my Domain-Driven Design basics talk, which focusses on what I think is the most important part of DDD: Understanding the problem. Lille is a beautiful city, the schedule is amazing… I’m really looking forward to it.

    This conference also has both in-person and online tickets. If you have the opportunity, I’d love to see you there!

  • Upgrade or upgrade?

    June 7, 2024
    php, symfony, upgrade

    When you have an application built on top of an existing framework, then it is very tempting to just leave it be once the initial development is done. Never change a winning team, right? So once you delivered the project and it’s running in production, the only thing you need to do is to add or change features and fix some bugs. Right?

    Well, for a long time you can indeed do that and it won’t hurt you. But in the long run, this will become a problem. Because while your application stands still, the world around you moves on. And that moving on includes new versions of your framework of choice. And as new versions come out, support of older versions will at some point be dropped. For big, popular frameworks there is usually a pretty clear release schedule of when new versions come out and how long old versions are being supported.

    In most situations there is a phased end of life. First, active support for bugs will be dropped but security issues will be fixed. Eventually though, security issues will also not be fixed anymore.

    If at that point, your application is still running on that old version, you are at risk of security issues which can lead to, amongst other things, damage to your public image or even legal action in case of security breaches. It is important to do regular maintenance and upgrades of any software you use. Whether that is the desktop software you use, frameworks and libraries and anything else.

    However, because of a lot of different reasons, you can end up with an application that is years old and a lot of versions behind the current stable version. So what then?

    Quite a few of the projects I’ve worked on in the past years have in some way or form included a situation like this (or I would see this coming in the future). There are two important approaches here, with different variations of those approaches.

    Approach 1: Upgrade step by step

    Let’s take the example of an old Symfony project. It is stuck at version 3.4 of the framework. With Symfony 7.1 out now, one approach could be to do a step-by-step upgrade. This would mean going from 3.4 to 4, then 4.4, then 5, then 5.4, then 6, then 6.4 and then finally to 7 (either directly to 7.1 or via 7.0).

    This may sound like a lot of work, and it is! So it’s important to understand how to make the decision to go for this approach. What I’ve found is the most important factor to decide on to take this choice is the size or complexity of the project. This approach is mostly interesting for projects that are really big or very complex in terms of logic.

    Requirements

    Before you even start with such a massive project that is hard to estimate in terms of time and effort is to make sure that at least you can ensure your work was done correctly. So you need to have:

    • Good documentation of what the application does, preferably including developers with a lot of experience with this application
    • A good set of tests. Preferably a combination of unit tests and integration tests
    • Support of your organization and most importantly, your management

    If you don’t have one of the above, make sure to get it. Documentation can be obtained by talking to developers that have worked on the project, but also business stakeholders and most importantly: users. Make sure that you have a clear understanding of the expected behaviour. You can use this information not just to understand what happens, but also…

    To write tests! If you don’t have a comprehensive test suite of unit tests (especially for important business logic) and integration tests (at the minimum as smoke tests to quickly see where potential trouble is, but preferably that actually tests your user experience), before you even change a minor version of your framework, start writing tests. The lessons learned from requirement 1 can help you with this requirement.

    Last but not least: Management really needs to support the effort. It’s important that they understand why it is necessary to be running on a recent and supported version of the framework. Explain to them the risk of hacks but also the extra effort needed to build new features into such old versions. The new, modern features that may be available in newer versions, etc. Without solid support from management, at some point priorities will change and you’ll be stuck with a half-upgraded project.

    Go go go!

    Once your requirements are met it’s time to do the actual work. This will most probably take a big effort. Especially with the example I used where you go from Symfony 3.4 (which does not support PHP 8) to Symfony 7.1 (which requires PHP 8). This means that along the way, you’re not just making the jump from one Symfony version to the next, but also the jump from one PHP version to the next. And you don’t just do that for your framework, but also for any other libraries you’re using. Adn the dependencies of dependencies might start clashing.

    To make this as easy as possible, you need to really take smalls steps at a time. Usually inside a major version it’s relatively easy to upgrade, so for instance from Symfony 4.0 to Symfony 4.4 is relatively easy. Once you’re on the last version before a new major, it’s important to check for all deprecations: In case of Symfony, the next major is usually the same as the .4 version, but without the deprecations. So work on getting rid of all deprecations before going to the next major version.

    Whatever you do, use static analysis tools to help you! Running PHPStan will help you catch potential issues. Also, Rector is your friend. It can help you automate fixing issues in your code and upgrading to newer versions of your framework. There are a lot of preset rules to help you in the process of upgrading, and you can extend Rector with your own rules as well for changes specifically needed for your project.

    The result

    If you have the time, the result should be an application that is running on the latest stable version of the framework, including completely adhering to modern code structures etc. However, since this is usually a very big time investment, I see it happening a lot that the upgrade of the project is done, but also refactoring to modern structures and approaches is not done. Which may make economic sense, but may still make the codebase feel a bit clunky and old-fashioned, even if it works and it on the latest and greatest.

    Approach 2: The big bang upgrade

    This second approach is, in my experience, mostly useful when your project isn’t very big or complex. With this approach, you will have to touch most of the code in your project in one way or another. In this approach, instead of doing all the individual steps of the upgrade, you basically start over, but with the code you already have. So, let’s use the same example of a project built on top of Symfony 3.4. Instead of doing the whole flow of Symfony 4, 4.4, 5, 5.4 etc, you just create a fresh new project on Symfony 7.1, then start moving the code from the old project bit by bit into the new project.

    Requirements

    Not surprisingly, the list of requirements for this approach is similar as the previous approach:

    • Good documentation of what the application does, preferably including developers with a lot of experience with this application
    • A good set of tests. Integration tests are the most important in this approach
    • Support of your organization and most importantly, your management

    The good documentation is perhaps even more important in this approach, since the developers working on this upgrade will actually touch all the code in the project. In the first approach, they will mostly touch the integration between custom code and framework. Here, all the code will have to be touched.

    For tests, the most important one may be integration tests. When using this approach you usually not just copy over code, but actually also refactor it to modern code structures and apply newly learned patterns and architecture, unit tests may or may not be very useful. There’s a good chance that the changes in code structure require you to write new unit tests or highly alter existing unit tests. The integration tests, however, are there to test if the application still does what it is supposed to do. So those are the most important in this approach.

    Support from the organization and especially management is actually the same as in approach one, but it is worth mentioning since I’ve really seen projects like this fail because this support wasn’t obtained before starting the project.

    Here we go!

    So… now to get started. You start with a fresh Symfony 7.1 project. In my example, we started with Symfony 3.4 which still had a structure of bundles inside the application code. A good approach is to migrate the bundles to non-bundle src/ code. Be critical of code placement and naming. In Symfony 3.4 times a lot of developers had the inclination to use very technical terms when naming namespaces and classes, while these days even if you don’t do full Domain-Driven Design, it is still common to use domain-based names for namespaces and classes. You don’t have to make these changes but since you’re starting from scratch, it may be worth the little extra effort while you’re copying over code anyway.

    Just like in approach one, PHPStan is your friend. Rector maybe less so although it can still help you with your tasks, but PHPStan will be there to ensure the newly written/copied code is built on modern standards and methodologies.

    Think about what you do. Don’t mindlessly copy over code and adapt it to fit into Symfony 7.1. Focus on building things the way you’d do on a fresh new project. This will make your code a lot more future-proof.

    The result

    When taking this approach, the chances are a lot bigger that at completion of the project, the code is not just “working” but also built according to the latest best practices and standards and is ready for the future.

    Upgraded, and now what?

    So you’ve done the upgrade, whichever approach you took, and now what? The most important is to not get into this situation again. Make sure to stay up-to-date by doing regular upgrades. Make this part of your regular maintenance work. Because small steps are a lot easier than a big jump. And the smaller the step, the easier it is. Since the release schedule of a lot of frameworks and libraries is openly available, you can even schedule most of the work.

    Alternatives

    If you want to stick with the same framework (in this example: Symfony), the above two approaches can work well. But there are alternatives. You can for instance start a new project, run that parallel to your existing application and then carve out specific sets of functionality. This approach can be complex when code hooks into other part of the code. But it will allow you to spread out the effort of upgrading/rewriting over a longer period, which may make it easier for a business to deal with the cost of the project. There is a risk though: I’ve worked for companies that took this approach several times and ended up with 3 or 4 different codebases that each still handled part of the logic.

    Another approach could be… but this will sound scary, to literally throw away everything you’ve done so far and start from scratch. Be really careful when you’re considering this. While this approach will probably deliver the best, most high-quality product at the end of the project, there is a lot of risk involved. Hidden functionality that no-one knows about may be forgotten, and the project may end up being so big that management is not willing to invest any more money into it, resulting in having an even older codebase in production and a half-finished new codebase that will never be used.

    You mention Symfony, but…

    … I use Laravel, CakePHP, Drupal, or another foundation for my software. Well, good news, while I used Symfony as an example here, you can apply these approaches to basically any software project. You don’t even have to use PHP to apply the above.

  • Fun in Mannheim!

    April 5, 2024
    conferences, ddd, mannheim, open source, php, sylius, syliusdays, usergroup

    Mannheim is a great place to be. I’ve been there to keynote the unKonf, I’ve been there to speak at the usergroup, I’ve even been there to do merch for Amanda Palmer at the Maifeld Derby festival. I love going to Mannheim. It’s a beautiful, welcoming city with cool people.

    As such I am excited to be going there again this month. I’ll be there from April 17 to April 19, doing two presentations. First, on April 17th I’ll be speaking at the PHP User Group Metropolregion Rhein-Neckar. I’ll be doing my DDD talk there.

    Then, on Friday the 19th I’m really excited to be part of another Sylius event: Sylius Days. I love Sylius and I’m happy to do my talk about doing open source contributions as a business there. With people like Oliver Kossin (who is also speaking at the usergroup on Wednesday), Stephan Hochdoerfer and Łukasz Chruściel there it promises to be an amazing event.

    The great thing is: Both events are free to attend! So RSVP for the usergroup and Get your free ticket for SyliusDays. I’ll see you there!

  • Dutch PHP Conference ’24

    March 25, 2024
    conferences, DPC, dpc24, Dutch PHP Conference, php

    After several COVID-years of online conferencing and an earlier announcement that “Dutch PHP Conference” would remain online, some developments favorable to organizer Ibuildings meant doubling back on that decision. A lot of Dutch PHP developers, including myself, were really happy with that. And it was indeed glorious to meet again in a physical space with a big part of the Dutch PHP community.

    The fact that Dutch PHP Conference was now organized together with AppDevCon and WebDevCon also resulted in some great cross-pollination. It’s great talking to people from outside your “bubble”.

    Being invited to speak was another bonus for me. I was invited to speak at EndPointCon last year but had to cancel that last-minute because of a nasty stomach flu or something like that. So being to come back and speak was fantastic.

    The talks

    I watched quite a few talks from the DPC schedule, although I did make a little trip to one of the other tracks.

    Using Open Source for Fun and Profit

    We started with the opening keynote by Gary Hockin, a speaker that I know as very entertaining but also putting across a serious message. In this keynote, we walked through Gary’s life as a developer, but also learned about the role of open source in all that. Very relatable at times, and in my talk on Open Source I could even reference Gary. Great talk!

    Crafting a greener future with PHP

    Then it was onwards to Michelle Sanver. I try to make a change through my involvement in XR, but as a developer I also have a responsibility to make this world less worse, and as software developers we can also make a change. That is the important message I got from this talk. Michelle gave some great background on the how and why we should make a change. My biggest take-away was something I had never considered: We are used to running cronjobs at night. In some countries (such as Sweden) this is great from the perspective of green development, because there is less energy usage at night and the hydro-plants keep producing energy there. In The Netherlands, however, at night there is not a lot of renewable energy. Instead, at night the majority of electricity is generated using gas plants. So running heavy tasks at night is actually not good. Thinking about the location of your servers and how energy is generated there is therefore a good way of putting less stress on nature.

    We need to talk about sitting

    The next talk I saw, or should I say participated in, was the talk by Laura Broekstra on sitting. 2 minutes into the talk we heard we sit too much (the Dutch are apparently world champion in the amount of time they spend sitting) so we got told to stand up. We should for the remainder of the talk.

    Laura confronted us with some facts about sitting and how her team has made huge changes in the amount of time they spend doing things other than sitting, including all kinds of exercises. The talk ended in an actual exercise where everyone in the room had to join in on some squatting exercises for a couple of minutes.

    I really enjoyed this talk and need to really evaluate how I spend my working time. I also think more conferences should give this topic some attention.

    Offline first!

    After lunch I went to the talk by Rowdy Rabouw on offline first applications. I am far from a front-end developer but I feel it is my responsibility as a backend developer to at least try and stay up-to-date with developments in that area, and the way Rowdy showed you can use service workers in the browser to do a lot of local caching was really interesting. And to be fair, I also went to this talk because I really enjoy the style of presenting that Rowdy has.

    Evil Tech: How Devs Became Villains

    After my talk I stuck around in the room to see Sergès Goma explain how devs can become villains. This was a very entertaining talk (including some developers actually coming to the front to do evil villain laughs) on a very important and underrated topic: ethics. This talk gave a lot of food for thought. Sergès delivered this really well.

    Community, PHP and us: Growing up

    I ended up with the second time Michelle Sanver (I support the idea of a MichelleCon), this time with Michelle doing the closing keynote with her story. Her story of becoming a software developer is very different from the story we heard from Gary in the morning. Well, there were some similarities, but Michelle also shared some very negative experiences she encountered along the way. We should learn from stories like these, and make the community an even better, more welcoming place. For everyone.

    Next year!

    After the keynote it was announced that Dutch PHP Conference will be back again next year, and I’m already looking forward to it. Will I see you there?

  • Regenerative software development

    March 18, 2024
    php, regenerative, software, stress

    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 is 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.

Previous Page
1 2 3 4 … 60
Next Page

skoop.dev

  • Bandcamp
  • Mastodon
  • Bandcamp