How to feel more productive after moving from coder to manager, Yes, You Should Estimate Software Projects, Is CSS Turing Complete, More, Not Less, Regeneration and Reframing
at the end of a day coding, I could look back at my code and feel productive, whereas at the end of a day managing, mostly meetings, I felt exhausted and with nothing to show for.
I’ve been managing for 10 years, taking over and building teams from scratch, being hands on and hands off and that feeling of not being productive is rarely there and I think there’s one habit that I have that helps a lot and I highly recommend it to all managers: write down notes.
Sur ma dernière mission c'est probablement ce que je pouvais faire de mieux, et effectivement c'est l'une des rares activités qui me donnaient l'impression d'être utile (d'autant plus que peu s'y collaient et nombreux oubliaient les contenus des nombreuses réunions).
Giving estimates, than missing them forces deeper reflection and faster learning about the types of unknowns in the software world. When it comes to why estimates are difficult, most engineers and engineering leads throw their hands up in the air and say, "Software has too many unknowns! We can't tell what unknowns we'll find, even with the simplest task!" This is how I thought, when I started out. But when you end up giving estimates, then miss them by a large margin, you cannot avoid having an honest conversation with yourself and your team. What did we miss? Why did we miss it? How can we try to account for it, the next time?
Vécu et vérifié. En 2018, l'un des clients pour lequel je (et l'un d'entre vous aussi ^^) bossais avait besoin de reprendre son site avant un évènement critique. Critique dans le sens : ce seul évènement remplissait l'essentiel des caisses sur l'année. Chaque année ce même évènement avait lieu, et les besoins d'aménagement d'infrastructure physique pour cet évènement rendait impossible tout décalage de date.
Nous avons travaillé avec des estimations, une roadmap sur 8 mois a été établie, et ce faisant nous avions toutes les informations pour comprendre que nous devions traiter nos risques dès le premier sprint. Tous les mois, nous recommencions l'exercice de réestimation de tous le backlog, au regard des évolutions du système actuel, des tâches à venir qui avaient plus ou moins changé en fonction des apprentissages métier et techniques. Dit comme ça, ça peut paraitre long et complexe, mais l'exercice ne durait pas plus de 2h pour les devs, un peu plus pour les PO qui devaient préparer le terrain et le synthétiser.
Les plus gros risques ayant été traités au plus tôt, la tension n'a eu lieue qu'au début lorsqu'il s'agissait de s'ajuster sur le plus structurant, mais très vite, notre client et nous-mêmes étions de plus en plus à l'aise, sereins, que nous atteindrions la cible avec le bon produit, fini pour l'évènement, et prêt à accueillir les évolutions des années à venir : oui sans la charge mentale d'une dette à rattraper après l'évènement.
Je vais partager le point de vue d'un collègue sur le sujet "no estimates" : c'est possible et souhaitable d'utiliser cette méthode lorsque vous vous êtes rendus capable de découper suffisamment finement toute tâche jusqu'à ce qu'elles soient toutes petites et de la même taille. L'avantage de ce petit découpage c'est que l'on évite les effets tunnel, réorienter le travail devient beaucoup plus simple. Et ce qui est amusant de fait, c'est que cela permet, malgré ce qu'indique le nom, de faire des roadmaps pour réajuster la trajectoire. Car oui, le travail d'estimation doit tout de même avoir lieu, autrement comment saurait-on qu'une tâche est petite et de la même taille que les autres ?
Okay, now we are going to make a big jump, and I haven’t quite connected the dots enough to explain it in my own words, so here is a blanket statement and some sources:
Rule 110 is a cellular automaton (we’ll get to that in a moment) that is capable of universal computation and is therefore Turing complete.
I don’t entirely understand how cellular automata are capable of computation, but apparently there are systems modeled after certain automata and those systems are Turing complete. At least, according to this Stack Overflow thread that references this research paper that I did not read.
So, from what I can gather, Rule 110, is a kind of litmus test for Turing completeness: if the language can encode Rule 110, then it is Turing complete.
Parce qu'elle le pouvait ? C'est amusant et en même temps intéressant. Ses autres articles sur le CSS comme langage de programmation sont pas mal aussi !
As I’ve mentioned a few times, the Montreal Protocol to reduce CFCs and repair the ozone layer likely succeeded not because corporations suddenly became altruistic, but because ready—and profitable—substitutes existed.
[…]
After many years of losing ground on the climate-change front, the approach that will (finally!) work is to replace things people don’t like with things they do like, and to replace carbon-heavy things people do like with things they like even more. That’s a trade-off people will make. It works with human nature, not against it.
De toute évidence, la stratégie actuelle ne paie pas. Alors pourquoi pas ?
