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.
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:
Just provide the best hardware (laptop, chairs, cameras, etc.) and software the team considers appropriate without making a big deal out of it.
If the team can’t agree on what those…
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.g. Google Docs)
The original structure takes around 12 minutes, but I suggest…
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…
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 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.
In recent years, however, many development teams have been focusing on reducing the lead time…
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.
Tech Lead, Facilitator, Trainer, Agile Developer