Probably not. Or maybe.

First, to be honest, I was unsure my tweet would even yield a single answer 😄.

Second, while I did start reflecting on the various subjects submitted to me when they were, I definitely did not dedicate enough of a continuous focus to it.

So while I think the goal was sustainable by itself, I didn’t manage myself well enough to make it. Hence, I do think I could have made it. If I had been able to do less of a few unimportant things (like browsing Twitter 🤦). Or manage my time, and my health, better.

Still, Romén has a point on this "sustainable" aspect. I assume he meant the size of the task itself, rather than the "shape" of the one actually doing the task (which I’ve focused on above).

This aspect is actually documented in Duhigg’s Smarter Better Faster book.

In short, the study shows setting unreasonable goals will yield worst results than difficult ones.

I had blogged already on this when I did (and succeeded on) the 15.000 push-ups challenge in late-2018-early-2019.

First, I am committing to finish the blog entries for each answer of my original tweet (for tweets posted in January 2021 😄).

Second, I am adjusting this to be one article per fortnight. Given I received 5 proposals, this means I am left with 3 to be done.

This means my new target is the Sunday 14th of March 2021.

I joined CloudBees in August 2016 as a software developer. This position is 100% remote. CloudBees had already very few, and small, offices in 2016. It is even truer in 2021 with covid-19.

While unrelated to the distributed aspect, I think this is important to mention I’m not a native-speaker in English. My English reading and writing skills were decent, but I had no habit of speaking English, this made for some awkward moments I still remember :).

Another thing: I think I’m more of an extrovert. You’ll see below how this can be another interesting data point.

As always, there’s no silver bullet.

Distributed working also has its challenges. Meet more, remotely and in-person when possible.

In a distributed company, the job flexibility and working with so many many great people and cultures are an extraordinarily rewarding experience. Because of this, and despite these challenges, I would never consider going back to an office that requires full-time presence.

The first Lean Software Development principle is Eliminate Waste. Oh wait, I thought, that’s interesting.

I started scribbling a schema with my 5-year-old capabilities to represent the indirect "result" that individual learnings are lost if unshared. Basically, if we are looking for an analogy, these "lost/unoptimized learnings" could be seen as a by-product, or worse as swarf. ^[2]

So I guess it is now clear I posit that not sharing learnings with the full team in a systematic manner is a lost opportunity :-).

Obviously, the analogy could be seen as falling short on the aspect that the learnings are not lost for the developer who went through it?

Well, I am inclined to think that this still would be very suboptimal. I believe we all have realized too often how trying to explain something to someone else was revealing how shallow our understanding actually was.

Hence agreeing as a team that for each Story, a lightning talk ^[4] will for example be delivered sounds like a good way to make sure the knowledge will be forced to be structured, understood deeply and magnified for the benefit of the whole team. ^[5]

In my experience, doing this kind of sharing on a voluntary basis, during brown bag lunches for example, has always stopped more or less quickly. The pressure and the day-to-day life we all go through generally tends to come back naturally after some time and make this habit fade out progressively.

By making it part of the team’s definition of done, it sounds like we could amplify individual learnings to the full team (and more! ^[6]).

For instance, I would imagine something like a 30-minutes session on Friday mornings after the team standup. Each presentation would be maximum 5 minutes, presented by people who completed Stories since the previous Friday.

What do you think?

When I tweeted a few days ago:

I got off-the-band feedback talking about a case at a well-known company where a person on a leadership role would challenge a lot teams to do bolder moves, think more strategically etc. People felt attacked, and even threatened.

To be clear, I am not arguing that this behavior is desired. I am actually saying this behavior is the exact opposite.

Challenge is needed, for sure. But it cannot come before trust is established, or worse things will happen.

One critical finding was discussed in Duhigg’s Smarter, Better, Faster ^[1]: the People team at Google was trying to find out what were the criteria for high performing teams. After shaking data, they found that the one criterion that was shared among all these teams were the so-called psychological safety.

Or, as written in Smarter, Better, Faster:

In other words, you know you can make mistakes, and that it will generally not threaten your job.

And while so many crappy companies or crappy managers still stupidly punish mistakes, we all know very well what happens: people will not stop making mistakes, they will hide them. And everybody ends up suffering: people and the business. What for then, FFS?

Mistakes. Mistakes, and taking risks. Together.

Another famous book discusses the importance of challenging your teammates: Radical Candor. The framework is impressively simple and powerful to understand why caring and challenging are so critical. The book is literally stuffed with insightful, and often funny, anecdotes illustrating many points.

Kim Scott spends in particular a good amount of pages discussing the case of ruinous empathy, deemed as the most common mistake when working together. Basically you are nice with someone, very nice. You want to be nice, and to not hurt people, so you do not tell them what is going wrong. And if or when things go bad, people get mad at each other because of unvoiced problems, or worse people end up fired. ^[2]

This is where the crux actually lies. To be able to challenge, there must be a strong relationship. Challenging someone is hard.

Imagine a long-time friend comes and tells you:

Likely, you’d be genuinely interested to hear what you did bad.

Now, picture yourself in a similar situation, but with someone you’ve only been working remotely with for one month, and never met in real life. That person you only saw roughly once per working day during daily standup calls and various team rituals with the full team.

Which one is more likely to trigger a immediate bad reaction? Which one is at least going to shift your mindset to a defensive mode instead of a learning one?

This all comes down to trust. This all comes down to knowing that showing your weaknesses won’t be held against you. And to build trust, one has to work on relationships.

And if you want data to back this discussion, building trust inside and across team is also recommended in Accelerate ^[3].

Care deeply about your coworkers, and challenge them.

I would even say: really caring about your teammates implies you will make the effort to challenge them. They will trust you because they know it is not to hurt them, but quite the contrary. People will know you expect them to do the same. ^[4] And overall, the team will grow together.

Basically, using story points estimation is the less worst tool that we have handy as a way to trigger discussions as a team.

We require Acceptance Criteria, and try to refine them until we have estimations that are closer with each other during the planning poker.

If someone in the team says 2 and another one 8, we will never average the value and move on. We will use this difference as showing that we need to discuss more and refine the scope together.

Often it will mean rephrasing or adding an acceptance criterion, or even in some cases adding some "anti" acceptance criterion clarifying that something is NOT in the scope of a given chunk of work. (E.g. we could decide to exclude testing a specific deployment target among many as a first step, because we know it will jeopardize the probability to achieve the work in the Sprint)

Smaller chunks of work is always a target.

I have experimented in my past that we would agree on having either small stories, or too big. Removing the blurry zone in the middle had helped us avoiding accepting more dangerously uncertain tasks in our Sprint.

This came up again recently to only accept 3-pointers maximum. This was because 5 or more in our ^[1] scale ended up being generally dangerous.

I think this is probably where teams should look first, if the goal is to try and be more predictable. In other words: either you would have a Sprint with only small, or very small stories, or you work on splitting the bigger ones so they can enter a Sprint and start being delivered.

As it stands now, I think the estimation sessions are still the best imperfect tool we have to refine and agree together as a team on the scope of a work item.

I am however eager to hear any counter-opinions or alternative practices to Story estimations for this purpose.

On using these points to do the planning, I will most probably reflect more on switching to story counts. At least I definitely like this idea, because then it would reaffirm even more that story points are neither important outside of the team, nor once the planning meeting is done. ^[2]

So I started going, and in parallel, I started watching fitness youtube channels about how to do things right. (Lucas Gouiffes, Nassim Sahili, Jean of All Musculation, Enzo Foukra, Jeff’s Athlean-X, etc. ^[1]) I started to learn about nutrition, the right number of reps & sets depending on your goals, the so-called mind-muscle connection, full-body, half-body, split, the name and functions of various muscles, etc. (spoiler: I’m still bad at this). It was great. I was litterally starting to realize what some muscles were designed for.

And because I was a beginner, liked it, and I was committed to it, I got great results. I got better than my previous self in just a few months. Between mid March 2017, and June 2017, I trained 42 times. In that same period, I lost close to 7kg. ^[2] When I went to Devops World - Jenkins World 2017 in August, I was so addicted that I trained at the Hotel Gym every mornings. I even ended up creating a ContinuousSport Instagram account, where I didn’t post that much.

After one year of practice, I went to ski again. After a stupidly missed turn, I got in the air, and landed hard on my left shoulder. I had broken my scapula, and had to stop using my left arm for a few weeks. However, the upside was that I had that awesome 3D reconstruction of a scan of my scapula to brag about.

After a few weeks of no training at all, this was finally time to start my path to normal.

Years before this, around 2012, during a badminton match, I hurt my back badly and got a terrible lumbago. I think it was just the consequence of me progressively but drastically reducing the amount of sport I was practicing, between 20 and 30 years old, while doing a lot of renovation work during 2+ years for my home. So I went to a specialist, and he explained how the spine worked, and specifically vertebras. I almost had reached the point of a hernia, but not yet. I spent a number of month being keeping my back very straight. But I ended up with a mixed result of no pain anymore, but a definite feeling of a weak back and not being able to trustfully fetch things on the ground, or simply bathe my kids.

After practicing all sorts of pushes and pulls, especially deadlifts and associated movements for the area, I feel much better nowadays. I do feel strong, or at least way stronger and balanced than I was before. I can fetch my getting-heavier kids without efforts, without feeling pain or stress about doing so. Which is awesome for day to day life.

So here it is. I am doing bodybuilding, and I like it.

I am now convinced that this is a very nice sport to stay healthy in the long run (meaning, more than running for instance), especially for a knowledge worker who stays most of her or his time seated down, in front of a computer.

My current plan is to keep practicing as long as I enjoy it. I am also going to add a bit more cardio-training for a better global health. This is something I’ve not done enough in the past months, and is also encouraged to be very important too to perform in your day job in HBR’s 10 Must Reads on Managing Yourself. That might be an interesting followup for this article :-).

Since a bit more than a year, advised in part by Tyler, I started reading more around leadership and management.

In Smarter Faster Better ^[2], there’s an awesome story about a study where a group of people would be asked to run 100 meters in 10 seconds. Then, they would be be asked to run 200 meters, still in 10 seconds.

Both are obviously hard, or impossible for mere mortals, but still we all know 200 meters is just impossible for humans, period.

Guess what they found: when trying to run 100m, people would cover significantly more distance in 10 seconds than when aiming for 200m. In other words, it demonstrated than if you give a clearly unreachable objective to people, this will result in reduced performance.

When I started this challenge, I thought I would definitely do the first month (30 push-ups a day in average), and likely the second one in November. Unsure for December and January, and then quite certain I wouldn’t be able to keep going until the end in February, where it would average 179 a day!

But as I finally did it, I think there are two learnings here.

Linking back more to my usual job, I feel this can relate for instance be related to the common adage Start small. I also cannot help thinking about some convolution around John Gall’s law: if you start too high, you are likely to get burned and have to start over.

In Radical Focus ^[3], Hanna, Jim and Jack discuss OKRs, and defining a quantitative Key Result for the Objective they’ve just settled on.

I am happy I finally put this out.

As often in sociology I feel, this kind of things looks obvious after the fact, but it is not.

Also very happy to have experimented this in real life. It’s like common mistakes in Software Development: you get taught to avoid some well known ones. But still being able to afford making some yourself is going to prove soo much more useful for the long term.

Define hard goals, but not too hard. Iterate and raise the bar as you go, in the long run you will go much further and higher.

After a bit of research, I found two candidates to achieve this: trickle and tc.

Ideally, you never restart a container. You just start a new one from the same (or another) image.

Anything you want to keep has to be in the declared volume(s), that is all you need.

I suspect you’ve come here just to copy and paste commands and move on. We all do :).

So, here you are. Let’s imagine I want to run Jenkins 2.107.3, here is how you would do it for simple production usage.

Using Docker, upgrading should always just be a matter of using a more recent version of the image.

Jenkins follows this pattern, so if I want to upgrade to latest Jenkins LTS to date, 2.121.3, all I have to do is the following. You will notice that we do use the exact same command as above, but we’ve just updated the version to the one we want to upgrade to:

Done.