Forem: Carlo Palinckx

Adapting to an ever-changing environment

Carlo Palinckx — Tue, 21 Jul 2020 06:32:21 +0000

600 million years ago, the planet was inhabited by simple organisms. There was no predatory behavior and life was peaceful. Then over time, our nervous systems got more and more complex and interactions increased exponentially. All of a sudden, we needed to be able to sense our environment and the beings around us in order to stay alive. We started to evolve, along the way we developed tools like eyes and ears that helped us get a better understanding of what was happening around us.

We learned to interact with each other and our environment.

This metaphor holds up very well when held against the current state of web development. Users are coming at us from more directions than they ever have and (either through user-expectations and technological advances) the environment is ever-changing. There is an opportunity here for us to evolve.

Evolving our nervous systems

The environment around us is changing. Perhaps we should too, but how should we be changing? In evolution theory, a species branches off from its current form because of a change in the environment around it and in turn forms a new "subspecies". This new species is better at solving a small set of specific problems that endanger its survival. They become "specialists". Perhaps we can apply something similar to web development. Let's look at how we as developers can work towards becoming a group of "specialists".

For reference: We currently house 2 product teams with each: 2 frontenders, 2-3 backenders, 1 designer and 1 product-owner.

The goal here is to develop a framework that helps you communicate and improves expertise. The boundaries you set as a group of specialists indicate the points of contact you have with the outside world, be it other teams, or be it your users.

Gaining eyes and ears

After defining what kind of specialism we could benefit from, we should start working towards a better understanding of our environment. A big part of this is knowing where you need to go and what is happening around us. We need eyes and ears.

A pair of eyes

We are trying to change our behavior in order to become better adapted to our environment. With evolution by natural selection, there is a clear indicator of whether or not we are heading in the right way, survival. However, it is probably for the better to look at a less radical approach when applying this metaphor.

As a group of specialists, it is very useful to know if our change is having the desired effect. We should try to measure our progress.

You have probably come up with a few themes or goals that you want to achieve while defining your specialism. It is important that you really tailor these to your team. There is no set of themes that will work for every team. For instance, a few of the themes that worked for us when we started moving towards a more separated existence:

Developer experience

Most of the code at MyOnlineStore (although this is decreasing at a pretty fast rate) lives in a monolithic application, which is a giant Symfony application. Symfony isn't really built for having a wide array of frontend tooling that can help us build features faster. We wanted to have independent tooling that would not interfere with Symfony. You could keep track of your developer satisfaction as well as to measure how fast your javascript builds are compared to before.

Deliver faster

Getting things done was hard at the time and often required one or more handoffs with backenders. This often clogged up the delivery of a feature. Backenders wrote controllers in PHP (in a traditional MVC architecture) that would directly affect user interaction. We would be a lot faster if we could deliver the entirety of a feature with just the UX designers and frontenders. Backend would still supply us with the data, but we would be able to freely interpret this. To keep an eye on how much faster you can deliver, you could start looking at the number of handoffs you are skipping. Or how your estimations for user-stories change (or the amount you deliver within the same estimations).

Deliver better

The complexity of our client applications would suddenly increase. We wanted to at least try to make this as sound as possible by writing tests and documentation. Our frontend stack at the time didn't lend itself for this, however. We decided that we should start migrating to a javascript framework in favor of a template language like Twig. The progress here could be measured by the amount of test coverage you can gather or a percentual decrease in bugs.

Themes like this can help you stay on track of the change you are trying to apply to your teams. Once you are starting to become more comfortable with your newfound specialism, you could start turning these into metrics to track your performance. "Delivering better" could be redefined as % of bugs that occur compared to before. "Developer experience" could be tracked by taking internal surveys or by measuring the time spent waiting for code to build or tests to run. Note that these themes or metrics are never set in stone and you might be required to change directions once your environment changes again (which it certainly will).

A set of ears

Now that we know what we need to look for when starting this process, we need to talk about the things that we cannot visually perceive. Instead of only looking at our progress we should also start listening to our environment.

Implicit knowledge

Like I mentioned earlier, handoffs are horrible (for us). The team alignment required to get things done is a pretty hard topic to get right. However, one thing that is great about handoffs is the fact that you are required to share knowledge formally. Almost every application and every feature of that application has undocumented knowledge that could turn out to be important somewhere along the road. Something that works great for us is refining user-stories together with other specialisms and working our way towards the implementation from a user perspective. This makes sure that you can still rely on all specialisms involved when solving a problem that a user faces, instead of letting team members like UX designers or frontend developers be the only ones responsible for user experience.

Traceability of bugs

Another thing that you could lose track of is the traceability of bugs. A lot of teams that migrate towards a more headless approach may come from an application that renders server-sided documents and fetches data synchronously with something like PHP or Ruby on Rails. This is a pretty big contrast compared to modern javascript frameworks that tend to heavily focus on asynchronous data-fetching. Because of this, bugs can have several surface points. It is important that you can follow errors all the way down to the origin, wherever it may be. There are several tools (we use Rollbar for this) that let you log errors across multiple applications or services by providing some form of a shared identifier everywhere in your stack. That way you can easily follow the bug on its path of wreckage and plug the hole it came through.

Walking on land

I hope our story has prepared you a bit for what will come when changing your team or organization. This story is by far a conclusive approach but it helped us get where we are today. At the time of writing, we are in a happy symbiotic relationship with our environment and our investments are starting to pay their dividends. Our developer experience has drastically improved, we are delivering a lot faster and are delivering more robust client applications than we ever have. We are at a point where we want to turn the themes we set into metrics that we can actively measure and work towards improving.

Like actual evolution, this is not a fast process, not 600 million years long, but still pretty slow. Getting proficient in these topics is something that takes time and practice because it fundamentally changes the way you interact with each other. Give it some time and keep your eyes and ears on what you are trying to achieve together.

Time for you to venture out there and explore everything your environment has to offer!

This article was heavily inspired by one of my favorite blogposts/talks: https://emptysqua.re/blog/api-evolution-the-right-way/ by A. Jesse Jiryu Davis
The beautiful imagery comes from a collection of old atlases bundled here: https://www.flickr.com/photos/biodivlibrary/albums/page1
Another inspiration for this article was the book "Other Minds - The Octopus and the Evolution of Intelligent Life" by Peter Godfrey-Smith

How to automate your GitHub workflow and go home early

Carlo Palinckx — Thu, 31 Oct 2019 07:35:55 +0000

If you have more than zero co-workers you are probably using some kind of platform to help you with pull requests and reviews. If your platform of choice is GitHub, you're in luck. We compiled a list of tools and tricks that can help you get your commits merged in that sweet master branch as fast as possible.

Set up a pull request template

Writing a good pull request template can help you and teammates find a common ground on how to summarize what's in a PR. You can also add a checklist if there are some requirements that have to be met before it can be merged.

Auto label your pull requests

With the new GitHub actions you can automatically label your pull requests based on what files you touched in your pull request. This can help a lot with the discoverability of your pull request overview.

To set this up, go to your GitHub repo with actions enabled, click on "New workflow" and once in the marketplace scroll down to "Automate every step in your process" where you'll find the "labeler" action:

Automatically request reviews with "Code owners"

We can take the automatic labeling of your pull request one step further. There is a feature in GitHub called "code owners" which lets you assign co-workers to certain parts of your application(s). GitHub will use code owners to automatically assign reviews.

Setting up code owners is easy, check this guide to get started with code owners.

Let a panda spam your co-workers into submission for reviews.

One thing that has been very helpful to our team is the addition of Pull panda. It is a Slack integration that automatically sends a message to your co-workers when someone requests their review.

When you request a review, the reviewer gets a message like:

If someone approves your pull request, you'll be notified as well:

Even if someone comments on your pull request, panda will show you the comments right away in Slack:

Automatically merge the pull request

After applying all these steps, Our pull request get's labeled automatically, the correct reviewers get assigned automatically and they receive a Slack message reminding them that there is work to be done. Now there is one final thing for us the robots to do, merge the pull request into the master branch! If your team uses any form of automated checks on pull requests, you have probably already wasted some time blindly staring at your screen until the merge button turns green.

With another GitHub action called automerge, this is a thing of the past. This action automatically merges your pull request based the preferences of your team.

For instance: We set up automerge to merge a pull request once:

An "automerge" label is added to the pull request
All required checks are complete and successful
All the required reviews are approved

And of course after your pull request is automatically merged, you get a message from pull panda:

Conclusion

I hope this list gives you some inspiration on how to automate the little things in your workflow. Even though these steps are probably not the worst bottlenecks for the speed of your team, saving a few minutes per pull request can quickly add up to something worthwhile.

If you liked this blog, please let us know by giving us some claps, retweets or likes.

If you think working at MyOnlineStore would be something for you, here are our job openings (NL).

If you have questions about this blog or just want to get in touch, you can tweet to me at https://twitter.com/CarloPalinckx

You can find more of our blogs on Medium

Cheers 👋