Productivity is unproductive, Monoliths are not dinosaurs, Ctrl-Zine Issue 3, The Coaching Habit – Say Less, Ask More & Change the Way You Lead Forever
I went on a solid system clean-out over the holiday, but I noticed something interesting - as I got to inbox zero across all my various buckets, instead of feeling like I had made space for real creative projects (like writing this blog), I found myself missing that mini dopamine hit of clearing items off my lists, and kept revisiting inboxes instead of actually doing real sh**. This is especially pathological given that we now live in a world of limitless input, with literally thousands of hours of new content, writing, videos, podcasts being created every minute.
[…]
If you could just get organized, you'd put all the little tasks in the container and then you'd have plenty of time left to tackle all the big important things. It always feels like with just a bit more effort you'd finally get to the end of your to-do list once and for all. But that's not how to do lists work, and that's not how time works. The list is infinite, and time isn't a container, it's just one present moment after another.
[…]
It can in fact be a relief to realize this, to see that the goal is structurally impossible, and therefore that it's reasonable to disconnect your self worth from checking off all the things. There's this idea that if you finally get through doing this or that, your real life will finally begin, that there will be this moment where the dress rehearsal will end. But this isn't a rehearsal. This is it. This is your life. So paying attention to it right now is sort of all we've got.
Et bim. Un article bien court qui met des claques. J’en ai encore supprimé quelques trucs de mon téléphone et abonnements. L’auteur pose également des questions et suggère des méthodes pour s’aider à se libérer.
However, I want to reiterate, that there is not one architectural pattern to rule them all. How you choose to develop, deploy, and manage services will always be driven by the product you’re designing, the skillset of the team building it, and the experience you want to deliver to customers (and of course things like cost, speed, and resiliency). For example, a startup with five engineers may choose a monolithic architecture because it is easier to deploy and doesn’t require their small team to learn multiple programming languages. Their needs are fundamentally different than an enterprise with dozens of engineering teams, each managing an individual subservice. And that’s okay. It’s about choosing the right tools for the job.
There are few one-way doors. Evaluating your systems regularly is as important, if not more so, than building them in the first place. Because your systems will run much longer than the time it takes to design them. So, monoliths aren’t dead (quite the contrary), but evolvable architectures are playing an increasingly important role in a changing technology landscape, and it’s possible because of cloud technologies.
Un court article du CTO d’Amazon, en réaction aux réactions suite à l’annonce du passage d’une archi distribué à une unité de déploiement pour une équipe d’Amazon. J’espère qu’on s’en rappellera la prochaine fois qu’ils feront les éloges d’un nouveau style architectural ! (bien sûr ça s’achève par une promotion des vertus du cloud)
The tools of the original internet are still here for us, carefully preserved and maintained by those who never stopped finding them useful, and anyone can pick them up and start learning. Find an old computer you no longer use, or buy one locally or from the internet. Install a lightweight version of Linux on it- the process is easy, and the right one will run just fine. Write a website using simple HTML, or one of the many alternative protocols, and host it from your home. Domain name optional. Join a tilde and learn how to navigate around a commandline. Most of all, relax and have fun.
The pioneers of our field kept this software free for a reason.
Pour changer de format: un zine pas bien long et pas prise de tête.
In trying to be helpful, high performers become unhelpful and would be better served by focusing on developing their coaching habit instead. Though often they tend to rather create a dependency on themselves, becoming a bottleneck and unintentionally they fail to unlock the potential in others.
This is particularly detrimental when high performers (as they tend to) become managers, they end up doing too much of the deliverable or task themselves. Similarly, a manager becomes overly reliant on one or two high performers. They default to asking the high performers, instead of extending the development opportunities more widely. This is what I have heard termed as performance punishment, being punished with an excessive workload as a reward for performing well. Additionally, the reality is that high performers tend to have more options to leave, so it’s a risky strategy.
Un modèle descriptif d'expert qui s'isole, suivi d'un modèle prescriptif pour sortir de cette isolation et connecter avec le reste de l'équipe pour tendre vers son autonomie.
