I use multitasking as a measure of the success of our regular team meetings.
If someone has time to reply to emails or finish their code during the meeting, then the topic doesn’t concern them, and it’s a waste of their time. It’s that easy.
The worst thing you can do here is to reprehend. Saying that someone is not paying attention and you are disappointed is a reaction of a lousy school teacher. Effectively, you just got a very clear signal, but you prefer to ignore it and shoot the messenger. Instead, when I talk with my colleagues, I…
I’m a big fan of type hints, and I honestly don’t understand why some people find it ugly or unpythonic.
A five-minute summary of the book “Accelerate: The Science of Lean Software and DevOps” by Nicole Forsgren, Jez Humble, and Gene Kim.
The overall idea of “Accelerate” is to find how engineering practices affect companies’ performance and the well-being of their employees.
This book feels like two books under the same cover. The first part, “What we found,” is practical, while the second, “The research,” explains in detail the science behind the book. Finally, there’s a third smaller part, “Transformation,” with a case study. I read the first part and only skimmed thought the second and the third.
My summary and takeaways from Martin Fowler’s “Patterns for Managing Source Code Branches”.
When you merge your changes back to the master branch, two types…
Code ownership is a smell, and we need to avoid it. When several developers contribute to the same codebase, several great minds are thinking of the same problem, and this eventually results in a better solution. On the opposite side of the spectrum, with strong code ownership, you inevitably end up with a code that is easier to rewrite than to understand by others.
I took this as granted until I came across a Microsoft research that contradicted my common sense. They showed that code ownership results in higher code quality and fewer bugs.
That the more engineers modify a…
I shared our experience introducing feature flags in the tech ecosystem at Doist with our partners from CloudBees.
CloudBees, known for rollout.io asked us to share our case study, and it was good opportunity to reflect on our journey towards the feature-flag based development, what we achieved so far and where we’re heading towards. Also, it served me as a reminder how many different use cases unlocks such a simple idea.
It’s not like feature flags were new for us. Since forever, our platforms have ad-hoc switches like “if is_doister(): enable_feature()”. On the Day X, we removed these if-else…
Head of the Backend development team @doist.