Posts

Problem Organisations building multiple applications (services, websites, apps, etc) and adopting Continuous Delivery are required to maintain the infrastructure required to build, configure, and deploy each application. This Continuous Delivery Infrastructure (CDI) covers aspects such as: Continuous Integration (pipeline definitions) Deployment Procedures (encoded in pipelines or separate tooling) Application/environment configuration for deployment Observability & Monitoring (external applications and dashboards) As the number of applications and teams grow, those should be standardised across the organisation so teams don’t have to reinvent the wheel and good practices can spread....

TL;DR - What I see in the wild is that Kotlin adoption on the server-side is slow due to a mix of complacency, career self-preservation, and lack of Kotlin visibility. In some specific cases, though, avoiding the adoption is entirely justified. It’s now almost five years since I wrote my first lines of Kotlin, after using Java for over fifteen years. Our team didn’t follow the typical Java playbook: we used Utterlyidle instead of Spring and embraced a Functional Programming approach with Totallylazy....

In addition to a good salary, there are many ways companies try to attract and retain good people. Those benefits tend to say a lot about the organisation culture, which explains why companies bragging about their ping-pong tables have become a running joke in the industry. Here are some tips in case your company intends to treat developers like actual adults, as in Chris Argyris' Theory of Adult Personality: Give the best tools for the job, no questions asked Just provide the best hardware (laptop, chairs, cameras, etc....

One of the challenges of running meetings over Zoom is including every single participant. Without some structure, only the most vocal people will share their thoughts, and the whole group will miss the opportunity to hear perhaps the most innovative ideas that may come from quiet people, individual contemplation or smaller conversations. We can solve most of these issues using a Liberating Structure called 1-2-4-All. In this article, I’ll share an adapted way to use this structure with Zoom + Breakout Rooms + any collaborative note-taking tool (e....

I’ve recommended “Eight Behaviors for Smarter Teams” by @LeadSmarter so many times that I decided to make a summary of them: 1. State views and ask genuine questions Give context and share your views before asking questions to get better quality of answers. Genuine questions come from a place of curiosity. You should avoid leading or rhetorical ones to encourage more productive conversations. 2. Share all relevant information By sharing relevant information, including things that don’t support your point of view or preferred solution, you add to a shared pool of knowledge that the team can use to make better decisions....

There aren’t many teams where meetings don’t become a contentious subject at some point or another. Regardless of the topic and even before any meeting takes place, the way a team manages meetings says a lot about how they operate and how invested in self-organisation they are. The main contention I see is around attendance: often people feel they’re invited to too many meetings, or that they’ve been excluded from the important ones....

When your tests depend on a database, you accept (most times unintentionally) that they’ll be slower, harder to maintain, and more fragile than your average unit tests. For a start, you’ll need an actual database to connect to, up and running and listening to the right port, with the correct permissions and the correct version of the schema. You also need to make sure the state of the data is as expected before each test....

When a team is looking to move towards Continuous Delivery, it comes a time when it’s essential to differentiate deployment from release. Traditionally, new versions of the software are built, tested, and made available to users in cycles that vary from once every few days to every few months. In that context, each new version will most likely contain some visible impact to the user, so the words release and deployment tend to be used interchangeably to express when a new version has reached users....

One of the most challenging aspects of learning a new codebase is to understand how things got to be the way they are now. Rather than viewing the current code/documentation as the current representation of reality, I find useful to see them as the result of many internal and external influences over time. As developers, we tend to see source control as the official history of a codebase. Unfortunately, just looking at the previous commits, no matter how well organised they are, is barely enough to understand the decisions that shaped the system....

After seeing Ron Jeffries' post about different takes on the Diamond Kata, I’ve decided to try it as well. This comment on Philip Schwarz' solution in particular got my attention: I don’t know Clojure, which certainly made Philip’s solution harder to grok, but one can sort of read it. He added some tests later, which certainly helps. Would a solution driven by tests be easier to understand? I’ll let you be the judge....