My summary of the video The Thing About Burnout of ashleymcnamara

Symptoms and development

• Burnout is like PTSD. After some recovery time, you may feel you’re OK, but some triggers can get you back to the burnout state.
• The burnout recovery time is two years. A two-week-long vacation doesn’t help.
• The process is burning out is slow. It can take years.

Phases of burnout

• honeymoon
• onset of stress: you start feeling less motivated
• neglecting self: overeating, etc.
• losing motivation: can’t get excited about the work anymore
• physical issues: digestion issues, tinnitus, etc.

How to avoid burnout?

• Get clarity. What is the purpose of your work? What…

I’m a big fan of type hints, and I honestly don’t understand why some people find it ugly or unpythonic.

• They improve the auto-complete and code navigation in the IDE.
• They protect you against trivial errors and remind you about corner cases.
• Beyond IDEs, more and more tools in the Python ecosystem take advantage of typing information. The FastAPI framework is the first example that comes to my mind.
• They are like documentation, that is testable, both human- and machine-readable, and never outdated.
• They make you think about your code and highlight code smell. Do you need to return Optional…

A five-minute summary of the book “Accelerate: The Science of Lean Software and DevOps” by Nicole Forsgren, Jez Humble, and Gene Kim.

About the book

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.

Summarizing this…

My summary and takeaways from Martin Fowler’s “Patterns for Managing Source Code Branches”.

Summary

• Having a CI pipeline, running tests on every commit is not Continuous Integration.
• Copying Open Source best practices to commercial development without understanding their context and limitations can be harmful.
• Feature branches hinder refactoring.
• Slow code reviews kill Continuous Integration, and it’s a common problem.
• If you want CI, but can’t do fast code reviews, consider alternatives. Code reviews are the most common but not the only way to warrant the quality of the code.

Semantic conflicts

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.

https://www.cloudbees.com/case-study/doist

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…