# Tag #travail — David Larlet
Publications relatives au tag #travail

Les plus récentes en premier, les 3 premières sont dépliées et ensuite c’est à la demande, bonne exploration !

## Horaires (2021-11-23)

> Autrement dit et pour résumer ces transformations, on peut parfaitement envisager dès maintenant une réduction massive du temps de travail. Ce n’est pas du tout « utopique » ou imaginaire de réclamer deux heures de travail par jour, du moins dans les secteurs susceptibles de l’automatisation-informatisation. D’ailleurs, compte tenu du fait que l’usure nerveuse est beaucoup plus grave et moins réparable que la fatigue musculaire, il est devenu indispensable dans ces métiers d’abréger les séquences de travail continu et de réduire déjà sérieusement la durée de la journée de travail. Mais ceci pourrait aller beaucoup plus loin. Or, il semble que ni dans le monde capitaliste ni dans le monde socialiste on ne soit décider à entrer dans cette voie. Il y a comme un blocage qui s’est effectué, et l’on choisit délibérément de ne pas appliquer les moyens techniques que l’on a à sa disposition pour maintenir l’ancienne structure à dominante industrielle. On introduit seulement de façon incoordonnée, à dose homéopathique, tel ou tel procédé. On automatise ici une chaîne de montage. On met en place une banque de données. On introduit un ordinateur etc. Mais il y a en réalité répugnance à changer le système.

> Ceci provient d’un certain nombre de difficultés qu’il ne faut pas méconnaître : une inadaptation idéologique évidente. Il y a une répugnance à abandonner « l’idéologie du travail », une angoisse à l’idée de tellement de temps « libre ». On ne sait pas ce que deviendrait la vie humaine si elle n’était pas remplie par le travail. On soupçonne que cela supposerait un changement radical, total de société, de ses orientations, de ses objectifs, de ses structures, mais on n’est pas mûr pour tenter une pareille expérience.

> Pour qui, pour quoi travaillons-nous ?, Jacques Ellul, Foi & Vie, n°4, juillet 1980

Facturation à la journée, à l’heure, parfois sur des créneaux un peu hybrides. Pas facile de trouver la granularité qui soit la plus pertinente en ce moment. À la fois pour mon énergie, et pour les produits, et pour les équipes.

À cela vient s’intégrer, de manière transverse, la pénibilité de la tâche en elle-même. Comment facturer au temps lorsque cette durée n’est pas fatigante de manière équivalente d’une heure sur l’autre ? Quid de l’implication émotionnelle ? De ce bug que l’on amène courir avec soi ? De ce commentaire qui va longtemps rester en travers ?

Je ne sais pas si la solution est la semaine (cache) de 4 jours (cache) ou celle de 168 heures, il y a du vrai dans chacune de ces approches et des ressentis différents vis-à-vis du travail. De ces activités ayant créées des professions (cache) très lucratives et dont je bénéficie si facilement.

Je payerais cher pour savoir ce que penserait Jacques Ellul d’une telle situation.

Lu depuis :

> Mais il faudrait déjà que l’on se parle
> Malgré les bouchons d’oreille les machines qui martèlent nos silences à la pause pourquoi se dire et quoi se dire d’ailleurs
> Que l’on en chie
> Que l’on peine à trouver le sommeil le week-end
> Mais que l’on fait
> Comme si
> Tout allait bien
> On a un boulot
> Même si de merde
> Même si l’on ne se repose pas
> On gagne des sous
> Et l’usine nous bouffera
> Et nous bouffe déjà

> À la ligne, Joseph Ponthus

De quoi remettre en perspective mes questionnements de privilégié.

## Vélocité (2021-10-29)

> It’s true that the gains from picking the right problem can be greater than the gains from having better tactical execution because the gains from picking the right problem can be unbounded, but it’s also much easier to improve tactical execution and doing so also helps with picking the right problem because having faster execution lets you experiment more quickly, which helps you find the right problem.

> Some reasons to work on productivity and velocity (cache)

Une réflexion récente de Sarah sur la vitesse (dans un contexte de développement) m’a interpellé car je suis de moins en moins convaincu que ce soit un facteur de réussite important pour un produit. Et c’est là où il va falloir définir « réussite ». C’est un peu un accident lorsque ça marche :

- un public qui a un besoin ;
- un produit qui est connu de ce public ;
- une équipe qui se fait confiance ;
- un budget/revenu qui permet d’arriver à un produit fonctionnel ;
- une connaissance autour de la problématique qui est capitalisée ;
- etc.

La vitesse d’avancement de l’équipe technique dans tout ça est rarement le goulot d’étranglement. (En ayant conscience du biais de ne pas vouloir faire partie de ce goulot, qui m’invisibilise peut-être des situations passées…).

Si ça se trouve, introduire un peu de lenteur permet de mieux évaluer la pertinence de ce que l’on expérimente parfois, de prendre du recul, de trouver des solutions moins techniques, de diluer la pression, d’avoir davantage d’interactions avec les utilisateur·ices. Si ça se trouve.

> The acceleration of our collective pace of life is not a result of stupidity or irrationality; rather, it is a symptom of what is perfectly predicted by the prisoner’s dilemma at a global scale: Hyper-rational individuals making hyper-rational decisions on how to spend their time by launching into an inescapable arms race of productivity. Burnout is inevitable.

> We’re Optimizing Ourselves to Death (cache)

## Carrière (2021-10-14)

> Without understanding the context, the advice is meaningless, or even worse, harmful. If those folks had followed their own advice early on, they themselves would likely have suffered from it. It is hard to escape this trap. We may be the culmination of our experiences, but we view them through the lens of the present.

> 20 Things I’ve Learned in my 20 Years as a Software Engineer (cache)

Beaucoup de sagesse dans cette liste. J’en aurais d’autres à ajouter mais je ne sais pas si j’en suis à 20 années de carrière, ayant du mal à dater le moment où celle-ci a véritablement commencée.

Ce serait peut-être mon premier conseil : envisager cela comme un cheminement en forêt et non comme un concassage de cailloux. Le papillon semble avoir plus de fun que la chenille (relire cette phrase en anglais).

## Promotion (2021-10-06)

Déplier pour lire le contenu de la publication

> At most companies, it’s common for the person leading you to have experienced a promotion in taking on the role. At Automattic, we view taking on the team lead role as a focus change rather than as a promotion. This means people are welcome to step up into the lead role and step down without a change in salary. We’re all ultimately individual contributors at the end of the day!

> You might not love working at Automattic if… (cache)

Beaucoup de choses très inspirantes dans cet article. J’apprécie que l’on puisse considérer que le rôle de lead (difficilement traduisible) soit temporaire et ne soit pas indexé sur le salaire. C’est accepter une certaine impermanence dans nos envies, nos appétences et nos expérimentations. C’est une façon de pouvoir se tromper sans que les conséquences ne soient rapidement critiques.

J’ai l’impression de porter différentes casquettes actuellement sur les différents produits auxquels je participe et j’adore cette diversité. Une forme de full stack (1, 2) mais en mode distribué où j’apprends des autres casquettes présentes dans les équipes.

Pour moi, une promotion correspond au courage et à la confiance suffisante en soi de consentir à une casquette relativement inconnue, au moins pour un tour.

Littéralement : pro-motion, être en faveur du mouvement.

> For example, I was a lead for 3.5 years and was able to easily step away to pursue other work when an opportunity came up without a change in pay. I never approached leadership as being a “forever lead” which helped me make decisions that I knew I’d have to live out if down the line I was no longer a lead.

> Ibid.

## Équipes (2021-09-02)

Déplier pour lire le contenu de la publication

> You might assume that if you put together a bunch of people and give them a goal, they’re a team. But that’s not how it works. While all constellations are working groups of some sort, in order for a working group to be considered a team two criteria need to be met.

> The First Question To Ask When Building Teams - Is This Really A Team? (cache)

Je me réfère souvent à cette classification lorsqu’on me parle d’équipe. Elle a l’avantage d’être relativement simple à (re)mettre en mémoire grâce aux schémas.

Un but commun qui nécessite d’être ensemble. Tous les mots comptent.

Ne pas confondre avec un « groupe d’affinité » :

> L’influence du mouvement anarchiste sur l’alter-mondialisme procède en grande partie de la diffusion de modes d’organisation comme le groupe d’affinité, une unité militante autonome d’environ 5 à 20 individus qui partagent une même sensibilité à l’égard des causes à défendre et des types d’actions à privilégier. Le processus de prise de décision y est anarchiste, c’est-à-dire qu’il est égalitaire, participatif, délibératif et consensuel.

> Les nouveaux anarchistes, Francis Dupuis-Déri

## Définition (2021-08-19)

Déplier pour lire le contenu de la publication

> On pourrait distinguer des développeur·ses, designer‧ses, agilistes et coach dont c’est l’activité ou la profession, si leur travail nourrit directement une structure capitalistique et qui renforce le maillage néolibéral.

> La victoire des professionnels (cache)

Suivi de :

> (j’ouvre une parenthèse ici pour préciser que quand je dis que je « suis développeur web », j’ai l’impression que ça cache la valeur que j’apporte quand je réfléchis à ces questions de « résilience sociale » autour du logiciel que je créé)

> David sur Mastodon

Réflexions croisées qui viennent alimenter mes propres explorations plus ou moins récentes sur le sujet. Ce besoin de définition est même assez récurrent ici, le blog étant probablement une forme de définition en soi mais je m’égare et ça devient trop meta.

« Pour qui, pour quoi travaillons-nous ? » pour reprendre le titre de Jacques Ellul, avec quels espoirs plus ou moins communs engageons-nous notre attention, aspirons-nous à dédier notre fameuse « force de travail » ? J’ai l’impression d’avoir de moins en moins de réponses à tout cela, une définition peut rester floue, une identité aussi finalement, lorsqu’on est suffisamment en confiance. Peut-être qu’en dépassant cette dénomination, on s’élève, on se libère d’un poids à la fois social et culturel. « Je fais des trucs en équipe que j’espère utiles et qui parfois se retrouvent sur le Web », c’est sûr que ça n’est pas très vendeur pour obtenir un emploi mais c’est peut-être ce qui se rapproche le plus de mon activité. En tout cas, ça se retrouve pas mal dans ce qui nous anime depuis bientôt 9 ans.

Au niveau du « pour qui », il y a toujours cette tension à travailler pour un gouvernement, ce péché d’orgueil d’espérer faire moins pire que ce que ça pourrait être. J’imagine que l’Histoire est remplie de personnes bien intentionnées qui — avec ce même raisonnement — en sont arrivées à commettre les pires atrocités. Se pose peut-être davantage la question du « jusqu’à quand » dans ce cas là, savoir s’arrêter avant que la collaboration ne change de sens…

> Les gens veulent toujours quelque chose de plus qu’une joie immédiate ou que ce sentiment plus profond qu’on appelle le bonheur. C’est là un des secrets qui nous aident à façonner l’accomplissement de nos visées. Ce « petit quelque chose » exerce un pouvoir décuplé sur ceux qui ne savent lui attribuer un nom ou (comme c’est le plus souvent le cas) ne soupçonnent même pas son existence. La plupart des gens ne réagissent qu’inconsciemment à de telles forces cachées. De sorte que nous n’avons plus qu’à concevoir un « petit quelque chose » bien étudié et à lui donner une forme et une définition acceptables pour qu’on nous suive comme un seul homme.

> Les secrets du pouvoir au Bene Gesserit, Dune V. Les Hérétiques de Dune, Frank Herbert

Un flux d’idées, momentanément figé.

## Regroupement (2021-05-19)

Déplier pour lire le contenu de la publication

> Si atteindre une position dominante sur leurs marchés respectifs s’avère épineux, ce n’est pas leur principal levier d’influence, relève l’économiste : « Les coopératives contribuent à faire évoluer les règles du jeu, car elles diffusent leurs idées et leurs pratiques de production au-delà d’elles-mêmes. »

> […]

> Malgré leur motivation, la plupart demeurent des coopératives de tailles et d’effectifs modestes. « Ce n’est pas simple de travailler de concert, surtout quand on porte des projets énergivores en ressources humaines, et qu’on ne possède pas la force de frappe de levée de fonds d’une start-up », dit Adrien Montagut.

> Des coopératives se regroupent pour une alternative aux géants du web (cache)

En ce moment, on essaye de répondre à un appel d’offre en formant un regroupement de structures ayant des principes coopératifs. La principale difficulté est de définir un cap pour ce collectif sans qu’il n’y ait pour autant de cap…itaine(s). Réussir à s’accorder prend du temps — même en envisageant de commencer à travailler en commun pour mieux se connaître. Or, un appel d’offre amène cette contrainte forte. Là est l’enjeu.

Au-delà de l’acceptation ou du rejet de notre proposition, c’est ce chemin qui m’intéresse lorsqu’un collectif se forme. Avec l’espoir qu’il survive à l’appât du gain à court terme pour envisager d’autres formes d’interactions et de collaborations.

> — Les trois branches d’un accord sont l’intention, l’information et l’incertitude. La précision et l’honnêteté n’ont pas grand-chose à voir avec la question. […] La dialectique ferme la porte aux sens, déclara Leto en ramenant son visage plus près du sol. Elle masque l’agressivité. Poussée à outrance, la discussion conduit toujours à la violence. Et mes intentions envers toi ne sont pas violentes.
> — Que voulez-vous dire par… intention, information, incertitude ?
> — L’intention réunit les participants. L’information délimite le débat. L’incertitude crée les questions.

> Dune IV. L’Empereur-Dieu de Dune, Frank Herbert

## Évaluation (2021-03-29)

Déplier pour lire le contenu de la publication

> Alas, many developers don’t build with this mindset. I mean, I understand why: it means thinking about users with the most boring, least powerful technology. It’s simpler and more exciting to assume that everyone’s got a shared baseline of newer technology. But by doing that, you’re missing out on one of the web’s superpowers: that something served up at the same URL with the same underlying code can simultaneously serve people with older technology and also provide a whizz-bang experience to people with the latest and greatest technology.

> The principle of most availability (cache)

Pensée du jour suite à un retour interne (merci !) relatif à mon non-recrutement. Comme un besoin de déconstruire le refus pour pouvoir me reconstruire…

Lorsqu’on est évalué pour un nouveau poste, on essaye de connaître la situation technique la plus complexe à laquelle on a été confrontée. Et cela a tendance à me rappeler d’une certaine manière le Principe d’Aurélien. Ce qui me semblerait intéressant serait d’évaluer les choix qui ont été réalisés pour ne pas arriver à ce niveau de complexité.

Comment est-ce que vous avez réussi à garder une équipe à taille humaine ? Quelles mesures avez-vous mis en place pour conserver un ensemble technologique cohérent, compréhensible et maintenable ? Quelles sont les plus faibles compétences requises pour modifier les données sur ce produit ? Qu’est-ce qui a été automatisé et délégué, pourquoi ? Seriez-vous à l’aise pour transmettre cette application, à qui ? Qu’est-ce qui vous empêche de dormir la nuit à son sujet ?

Il est certain qu’en créant une usine à gaz on acquiert tout un lot de compétences. Mais ce ne sont pas celles qui m’attirent (et je ne parle même pas d’humain). Il est des moments où relire ses archives fait du bien.

> Je vous développe une application complexe parce que je n’ai pas l’expérience pour en écrire une moins sophistiquée.

> Blaise Pascal fait du développement web, Les dépendenciales (2021)

## Smolstack (2021-03-28)

Déplier pour lire le contenu de la publication

> The “smol” net is the “small” net. It’s small because it is build for friends and friends of friends. It doesn’t have to scale to millions of people because those millions should build their own local small nets.

> CommunityWiki: Smol Net (cache)

On me demandait récemment si je me considérais comme étant un développeur fullstack. Avec le recul, cette question m’a permis d’affiner ce que j’entends par ce terme et pourquoi je ne veux pas l’être. Je me suis aussi replongé dans mes archives car le sujet n’est pas nouveau mais j’ai besoin de le revisiter régulièrement.

Ce que l’on entend traditionnellement par le terme fullstack me semble aller de l’orchestration de containers (incluant sécurité, disponibilité, redondance, etc.) à l’interface utilisateur·ice et à son expérience que l’on espère la plus pertinente possible (incluant l’accessibilité, les performances, etc.) en passant par le backend et le frontend qui apportent leur lot de connaissances à maîtriser et maintenir à jour. Mais ce n’est pas tant le périmètre en lui-même que l’appétence que l’on peut avoir pour l’ensemble de ce spectre qui est une attente qui m’est irréaliste.

Je vais maintenant essayer de définir ce que j’entends par smolstack, c’est brouillon et je vais probablement avoir besoin de plusieurs itérations :

- vérifier la pertinence des fonctionnalités avec des tests utilisateur·ices ;
- réduire les dépendances au maximum et être guidé par le besoin plus que par la tendance actuelle ;
- prendre le temps de faire le ménage à tous les niveaux : nouvelles attentes, évolution de dépendance, retrait de fonctionnalités, etc. ;
- faire en sorte que les données soient accessibles au plus grand nombre (je vais avoir besoin de préciser ce point) ;
- privilégier le statique tant que c’est possible, il n’y a rien qui soit plus performant et polyvalent ;
- arbitrer la complexité vis-à-vis de l’impact que cela va avoir sur les utilisateur·ices mais aussi la maintenance, la fiabilité et la légèreté du produit ;
- documenter les choix techniques ainsi que les joies/échecs associés (journal d’équipe ?) ;
- envisager l’essaimage plutôt que le passage à l’échelle.

Je vais m’arrêter là pour ce soir, je n’ai pas l’ambition d’en faire un manifeste, ni la prétention d’en faire un terme consacré. Je le vois plus comme une ébauche inspirante et vivante. C’est incomplet à dessein. Et ce sera obsolète dès demain.

Keep smoling! 😀

> That last bit is a bit of a concern as ageism is already strong enough in web development for 30 to be considered old. The last thing I want is to be labelled a conservative old fogey in an industry dominated by novelty-seeking. Mostly because it really isn’t accurate. I really do enjoy some of the new developments in the field. So much so that I constantly have to fight the urge to start building projects using the latest bit of shiny.

> Which type of novelty-seeking web developer are you? (cache)

## Stimulant (2021-03-26)

Déplier pour lire le contenu de la publication

> J’ai évité d’écrire un livre qui mastique toutes les pensées possibles en rapporte avec les questions soulevées dans les pages suivantes. Je ne voudrais pas livrer ces pensées comme une bouillie prédigérée à un lecteur passif. La tension dialectique que j’apprécie le plus se situe entre le lecteur d’un livre et l’écrivain : les indices, les suggestions, les pensées inachevées et les stimuli qui encouragent le lecteur à penser par lui-même ou elle-même. En ces temps qui connaissent de telles fluctuations, il serait arrogant de présenter des analyses et des recettes finies ; je considère plutôt qu’il est de la responsabilité d’un travail sérieux de stimuler la pensée dialectique et écologique. Pour une œuvre si « simple », si « claire » et si peu partagée — en un mot, si élitiste — qu’elle ne nécessite aucune modification, le lecteur devra regarder ailleurs. Ce livre n’est pas un programme idéologique ; c’est un stimulant de la pensée — un ensemble cohérent de concepts que le lecteur ou la lectrice devra achever dans l’intimité de son propre esprit.

> L’écologie sociale, penser la liberté au-delà de l’humain, Murray Bookchin

Un bon résumé de ce que j’aimerais que cet espace de pensées soit, devienne, vive, inspire, respire.

## Recrutement (2021-03-23)

Déplier pour lire le contenu de la publication

> À chaque étape la question est essentiellement « Est-ce qu’on veut travailler ensemble ? pourquoi ? qu’est-ce qui pourrait coincer ? ». À l’entretien technique on peut éventuellement ajouter « Où positionner le candidat par rapport aux salariés actuels au niveau compétences et rémunération ? ». Le reste c’est de la littérature.

> Longueur du processus de recrutement (cache)

Ma ligne de temps pour une candidature au CDS-SNC :

- 22 janvier : Yannick poste un lien (cache) sur le chat interne de Scopyleft ;
- 25 janvier : j’applique (en bon québécois) après 5 années d’hésitations pour de nombreuses raisons — je suis rappelé dès le lendemain ;
- 27 janvier : rencontre avec la personne dédiée à mon recrutement (30 min), on échange un peu sur mon parcours et sur ce que je pourrais faire au CDS-SNC, je me rends compte que je n’ai jamais passé d’entretien de recrutement à proprement parler — je suis rappelé le 2 février ;
- 4 février : rencontre en anglais (1 h) avec deux personnes sur les Core Values, j’apprécie beaucoup que ces sujets soient abordés avant même de parler de technique, on parle d’humanité, d’empathie, d’inclusion — je suis rappelé le 16 février ;
- 17 février : rencontre en anglais (1 h 30 min) avec deux personnes sur les Technical Skills, je raconte certaines expériences, on évoque des scénarios, c’est relativement équilibré comme discussion et je ne peux m’empêcher de voir des parallèles avec ce qui se fait (ou pas) chez betagouv — je suis rappelé le 1er mars ;
- 10 mars : rencontre en français (1 h 30 min) avec deux personnes sur les Technical Skills encore une fois, j’apprécie le fait que ce ne soit pas un test technique (cache) mais un échange horizontal sur des situations plus ou moins fictives et les pistes de résolution associées ;
- 23 mars : courriel m’indiquant que je ne suis finalement pas retenu.

Ce qui n’est pas explicite avec ces dates, c’est le stress diffus avec de gros gros pics sur une période de plusieurs mois. C’est l’incapacité à travailler lorsque j’ai un entretien dans la journée. Ce sont les doutes entre chaque session avant d’attendre un retour qui arrive plusieurs jours après. Ce sont les questionnements au moment de la préparation, les remises en question de mes capacités.

Je comprends l’intérêt de tester la motivation dans la durée mais je me demande aussi si un tel processus ne ferme pas la porte à des personnes moins privilégiées, moins en confiance, dans une situation moins stable.

Au cours de ce processus, la série de billets de Jacob m’a été d’une grande aide. Le guide de 18F m’a beaucoup rassuré aussi pour avoir une idée du potentiel enchainement au complet. Et bien sûr, le Technical Playbook (version française) du CDS-SNC lui-même.

Sur une note positive, j’aurais beaucoup appris au cours de ce parcours, surtout sur moi. La relation au stress, à la confiance en moi mais aussi des réflexions sur le plus long terme. Ce que je suis prêt à changer dans ma vie, la dose de liberté que je peux/veux réduire, les libérations et les contraintes que cela m’apporterait. Au fil du temps, j’ai pu affiner mes questions/attentes aussi, afin de mieux connaître la structure et les façons de fonctionner. Je suis reconnaissant des personnes qui ont pris le temps de s’intéresser à ma candidature et qui ont été vraiment bienveillantes durant ce parcours.

En bonus, je crois que ça me permet de travailler mon acceptation de l’échec… et du contentement. J’espère néanmoins que ce sera le premier et le dernier parcours de recrutement de ce type que j’aurais à faire dans ma vie. Sans aigreur, ce n’est pas un processus qui me semble être adapté à ma façon de rejoindre une structure/équipe. Je crois que j’ai besoin de faire et d’être avec les personnes car l’hypothétique résiste rarement à l’épreuve du réel. Mais peut-être que cette démarche prend trop de temps ?

> How many hours does it take to hire someone, from approval of the open position to their first day? It takes about 100 person-hours, and that’s about a best-case scenario.

> How Long Does It Take to Hire Someone? (cache)

## Manuel (2021-03-20)

Déplier pour lire le contenu de la publication

> I’ve created a user manual about myself and I’d love to hear what other questions people think should be included in something like this. I also think there should be a caveat that this is done knowing that not all your needs and preferences can be met, but there is still value in making them explicit for those you work with.

> A user manual for me (cache)

Je découvre cet article via le SNC (cache) qui propose la version traduite suivante :

- les conditions dans lesquelles j’aime travailler ;
- les heures et les moments de la journée pendant lesquels j’aime travailler ;
- les meilleures façons de communiquer avec moi ;
- les façons dont j’aimerais recevoir des commentaires ;
- les choses dont j’ai besoin ;
- les choses avec lesquelles j’ai de la difficulté ;
- les choses que j’aime ;
- les autres choses à savoir à mon sujet.

J’aime le fait de pouvoir afficher cela de manière aussi explicite dans son équipe. Je vais essayer de rédiger mon propre manuel.

## Support (2021-03-19)

Déplier pour lire le contenu de la publication

> Yes, not only that, also just experience with selling very low priced products and how that’s incompatible with the kind of companies that we run and the kind of service we want to offer. So we have a relatively large support department who spend a lot of time being very diligent and careful with all the customers they interact with. And the math on that is that like someone writes us an email and it costs about five bucks, you take all the costs involved with running support department. It costs about five dollars to answer an email.

> If you lower your price to the point where one email essentially put you under water on a on a customer relationship, you end up in a place where you don’t want to talk to your customers.

> Small Is Beautiful livestream #7 (cache)

Il y a beaucoup de choses intéressantes dans cette discussion, je remercie Laura et Aral d’avoir pris le temps de faire un transcript de l’échange qui me permet non seulement de le lire à mon rythme mais en plus de l’archiver (bon et bien sûr de le rendre accessible aux personnes en ayant davantage besoin).

J’apprécie particulièrement cette partie relative au support, qui lui donne un coût permettant d’arbitrer une intention. Lorsque l’on crée une chose, on y place un espoir dont on essaye de s’approcher. La difficulté est de continuer à partager cet espoir et/ou de le faire évoluer sans renier totalement les conditions de son accession.

Cette difficulté est un travail quotidien.

> We were about 45 people, I think, at the time. We had four major products that were all sort of succeeding and growing. And we looked at that and said, you know what? We can’t continue with four major products at the same time, if we’re staying at 45 people, we have to probably go to 150 because there’s these tipping points where once you install this layer of management, you need a bunch more people and so on. So if we’re going to run this whole thing, I can see a straight path to us being 150, maybe 300 people. And I looked at that and said, you know what, I don’t want to work there. I don’t want to work at a Basecamp of 300 people.

> Ibid.

## Software (2021-02-01)

Déplier pour lire le contenu de la publication

> The right coding language, system architecture, or interface design will vary wildly from project to project. But there are characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:

> - Reusing good software is easy; it is what allows you to build good things quickly;
> - Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
> - The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.

> Understanding these characteristics may not guarantee good outcomes, but it does help clarify why so many projects produce bad outcomes.

> How to Build Good Software (cache)

Deux articles lus ce jour qui sont totalement dans mes réflexions du moment. Avoir de l’expérience dans le domaine dans lequel j’évolue, c’est se demander pourquoi est-ce qu’on y est encore et si on a vraiment appris un truc après toutes ces années. J’ai beaucoup de mal à répondre à ces deux questions, les réponses se mordent la queue et ça me donne parfois l’impression de tourner en rond.

Mon activité (rémunérée) est un chaos. Et le seul moyen que j’ai trouvé de le rendre acceptable est de le réduire. Moins de dépendances, moins de hiérarchie, moins de variables, moins de boîtes noires. D’une certaine manière, moins d’attentes aussi.

Une autre exploration est de consigner mes doutes, mes motivations, mes erreurs, mes joies. Je n’ai aucune illusion quand au fait de reproduire ces expériences plus ou moins mal·heureuses — même après les avoir écrites — mais le fait de les avoir formulées, externalisées, est déjà une étape dans leur acceptation. Ainsi que les émotions qui vont avec.

Je me demande rarement si je suis un « vrai » ingénieur. Je me demande davantage si je deviens un vrai humain à continuer cette activité. C’est peut-être ceci l’expérience : douter de plus en plus de l’utilité de ce que l’on produit… et de la façon d’y parvenir.

> Nobody I read in these arguments, not one single person, ever worked as a “real” engineer. At best they had some classical training in the classroom, but we all know that looks nothing like reality. Nobody in this debate had anything more than stereotypes to work with. The difference between the engineering in our heads and in reality has been noticed by others before, most visibly by Glenn Vanderburg. He read books on engineering to figure out the difference. But I wanted to go further.

> Are We Really Engineers? (cache)