Shaare your links...
3030 links
Httqm's Links Home Login RSS Feed ATOM Feed Tag cloud Picture wall Daily
Links per page: 20 50 100
◄Older
page 1 / 9
163 results for tags Job x
  • Human Task Switches Considered Harmful – Joel on Software
    Conclusion : never let people work on more than one thing at once.
    Mon Jan 11 15:03:13 2021 - permalink -
    - https://www.joelonsoftware.com/2001/02/12/human-task-switches-considered-harmful/
    Best_Practice Development Job
  • Workplace interruptions lead to physical stress
    Wed Nov 4 07:22:38 2020 - permalink -
    - https://ethz.ch/en/news-and-events/eth-news/news/2020/10/workplace-interruptions-lead-to-physical-stress.html
    Job Santé Science Stress
  • The Andon Cord
    The key, as Rother suggests, is that it wasn’t the tools that made Toyota great, it was the culture and specific behavior associated behind those tools.

    ==> As said by other smart persons :
    - Don't fix bugs, fix your process.
    - Don't work harder, work smarter.
    Tue Oct 20 12:35:15 2020 - permalink -
    - https://itrevolution.com/kata/
    Best_Practice Japan Job Wisdom
  • Your calendar should be a whitelistlist, not a blacklist
    I like this point of view : with a shared agenda, instead of saying "Here's the time you CAN NOT talk to me" (already scheduled things), we should have a "Here's the time you CAN talk to me", showing time periods that are open for meetings.
    This should limit the number + hours spent in meetings, but more important : leave time to do the actual work.
    Mon Aug 10 14:58:43 2020 - permalink -
    - https://critter.blog/2020/08/03/your-calendar-should-be-an-allowlist-not-a-blocklist/?mc_cid=5bdc7c6f5a&mc_eid=c15c92a706
    Agenda Job Organization
  • The Problem with Saying “Don’t Bring Me Problems, Bring Me Solutions”
    A very interesting article about dealing with problems at work.

    It also reminded me about :
    https://dilbert.com/strip/2016-03-30
    https://dilbert.com/strip/2020-01-29
    Mon Jun 8 08:42:24 2020 - permalink -
    - https://hbr.org/2017/09/the-problem-with-saying-dont-bring-me-problems-bring-me-solutions
    Job Wisdom
  • Critères pour les entreprises tech
    Qu'est-ce qu'une "bonne" boîte où on aura envie de travailler ?
    Mon Jun 1 17:33:25 2020 - permalink -
    - https://n.survol.fr/n/criteres-pour-les-entreprises-tech
    Job
  • Production Oriented Development
    'BUY' ALMOST ALWAYS BEATS 'BUILD' : If you can avoid building something, you should. Code is the most expensive way to solve a problem that isn’t addressing a core area of your business.

    MAKE DEPLOYS EASY : Deploying should be a frequent and unexciting activity. Engineers should be able to deploy with minimal manual steps and it should be easy to see if the deploy is successful. (...) It’s not a coincidence that two of the four key metrics that the book focuses on are directly related to this (Deploy Frequency, Change Lead Time). Shipping is your company’s heartbeat.

    TRUST THE PEOPLE CLOSEST TO THE KNIVES : The people who work with a system are the ones who understand it best. (...) They should, therefore, be the primary stakeholders responsible for prioritizing technical work.

    BORING TECHNOLOGY IS GREAT : (...) you want a wide area of expertise for routine operations and when shit goes sideways (...). Very few organizations have the bandwidth to debug unique problems. (...) Using boring technology means you can lean on a large community of users. Shit on it all you want, but there are very few PHP issues that someone else hasn’t already encountered.
    Tue Mar 3 10:39:21 2020 - permalink -
    - https://paulosman.me/2019/12/30/production-oriented-development.html
    Best_Practice Development DevOps Job
  • La dictature du bonheur en entreprise
    Si tu es malheureux, c’est toi le problème

    Comme dit plus haut, on finit par faire comprendre aux gens que ce sont eux le problème et jamais l’organisation. Et c’est justement là que les risques psychosociaux apparaissent. En effet cette dictature du bonheur induit une sensation de décalage entre l’entreprise et son salarié malheureux, ce qui renforce encore cette sensation de malheur. Et c’est ainsi qu’un cercle vicieux se crée, encore renforcé par le fait que le salarié malheureux ne trouve plus d’oreille prête à l’entendre, ni à l’intérieur de l’entreprise, ni à l’extérieur à cause de l’image cool renvoyée par l’entreprise.
    Mon Jan 27 08:45:55 2020 - permalink -
    - https://jobprod.com/la-dictature-du-bonheur-en-entreprise/
    Job Psychology
  • Comment être sûr de rater ton projet informatique
    Plein de bons conseils, malheureusement souvent mis en pratique :-/

    L'ensemble de l'article est aussi vrai que drôle.
    Mention spéciale à cette phrase qui a un petit goût de "j'ai-déjà-vu-ça-quelque-part" :

    Dans le désordre tu peux obliger tout le monde à travailler minimum 60 H par semaine. Quand les gens n’auront plus de vie personnelle, c’est avec plaisir non dissimulé qu’ils vont chier à l’intérieur de ton projet.
    Fri Jan 17 16:37:34 2020 - permalink -
    - https://www.jesuisundev.com/comment-etre-sur-de-rater-ton-projet-informatique/
    Best_Practice Job Manager
  • Reconnaître et mettre fin à ton burnout – 24 jours de web
    Par Mehdi Zed, l'auteur de https://www.jesuisundev.com/ego-des-developpeurs/
    Fri Jan 17 16:27:23 2020 - permalink -
    - https://www.24joursdeweb.fr/2019/reconnaitre-et-mettre-fin-a-ton-burnout/
    Best_Practice Job Psychology Santé Wisdom
  • Arrêtez de demander si votre idée d'entreprise est bonne !
    La vérité dans tout ça, c'est que les gens ne savent pas ce qu'ils veulent jusqu'à ce qu'on leur propose.

    L'unique façon de vérifier que son idée est bonne, c'est vendre.

    Les gens arrêtent de mentir quand on leur demande de l'argent.

    Pour ça, la stratégie consiste à créer du contenu tout en donnant la possibilité d'acheter notre produit.

    Il existe un terme populaire dans le monde des startups qui résume bien cette stratégie : "Fake it until make it".
    Fri Jan 10 10:08:03 2020 - permalink -
    - https://ston3o.me/entrepreneuriat/arretez-de-demander-si-votre-idee-d-entreprise-est-bonne/
    Argent Job Startup Wisdom
  • L'étrange marché du travail des développeur(euse)s
    La vérité c’est qu’il n’y a pas de pénurie de développeur(euse)s. Il y a une pénurie de développeur(euse)s au niveau exigé. (...) Les postes disponibles sur ce marché du travail sont pas très junior friendly. Vindieu que les postes sont exigeants aujourd’hui. Que ça soit le poste de rockstar fullstack devops à l’ultra expert hyper pointu de ReactJS y’a de moins en moins de place pour l’apprentissage.

    Et ça constitue le second paradoxe de ce marché du travail. De plus en plus d’efforts pour créer des développeur(euse)s et une pénurie qui ne fait que gonfler. Les entreprises sont très frileuses à prendre quelqu’un en dessous de 3 ans d’expérience. C’est difficile de leur en vouloir quand on voit les enjeux autour des développeur(euse)s. Ce qui fait que, malgré la pénurie, quand une personne se présente avec peu d’expérience c’est souvent compliqué.

    (...)

    La pénurie des développeur(euse)s Français est nourrie par la pénurie des salaires Français.
    Mon Dec 16 10:12:42 2019 - permalink -
    - https://www.jesuisundev.com/letrange-marche-du-travail-des-developpeureuses/
    Actualité Development France Job
  • Types de spécifications
    Les différents types de spécifications :

    - la spécification exhaustive : claire, concise, illustrée d'exemples (autant que nécessaire) et de schémas explicatifs, elle précise tout ce qui est attendu de manière non équivoque. Chaque information y est indiquée une (et une seule) fois, et peut être retrouvée très facilement via l'organisation logique du document et le sommaire clair. Les mentions "TBD" et "TODO" en sont absentes. Cerise sur le sundae : elle a même une table d'acronymes grâce à laquelle il devient évident que le "PTDR ne peut pas être XPT à cause du DDIG". Elle a, de plus, le bon goût d'être à jour par rapport à ce que veut réellement le client.
    NB : de même que les fées, korrigans et autres elfes, la spéc exhaustive est un artefact qui n'existe que dans votre imagination.


    - la spéc "Post-it" : elle a le mérite d'être courte (c'est le seul !). Pour le reste, il va falloir deviner ou bien entrer dans le ping-pong de l'enfer avec le client et lui tirer les vers du nez pour avoir une idée de ce qu'il attend de nous --tout en déplorant notre manque d'autonomie (voir "spéc en chapelet"). Rencontrée en moyenne dans UN projet sur UN.


    - la spéc "en chapelet" : ce type de spéc connaît de nombreuses variantes. Elles sont toutes caractérisées par une succession de micro-suspenses (maîtrisés ou pas), permettant, à chaque itération de "gagner" une nouvelle information permettant aux développeurs de faire leur travail.

    - variante : spéc "en chapelet typée ping-pong" (ou "chapelet - jeu de piste") : c'est un peu comme une enquête policière, où chaque indice conduit au suivant, et où chaque question engendre une nouvelle question (dont la réponse est évidente pour celui qui aurait dû vous la donner). C'est une succession de mails en question / réponse, entrecoupés de temps d'attente improductifs, puisque les informations requises sont dans la tête du client, qui n'a "pas qu'ça à faire de répondre à vos mails" étant donné qu'il passe 95% de son temps en réunion.

    - variante : spéc "en chapelet typée boule de neige" (ou "chapelet - réaction en chaîne") : le flou grandit à chaque itération et chaque réponse appelle 2 nouvelles questions. Auxquelles on aura peut-être une réponse, mais pas garanti. Explosion du niveau de stress des dév et du délai de livraison.

    - variante : spéc "en chapelet aux amEndes" : la spéc est mise à jour plusieurs fois pendant le projet alors qu'on n'a posé aucune question.
    NB1 : ce type de fonctionnement est typique des procédés "Agile", où l'on se doit d'être ouvert au changement. Si une nouvelle version de la spéc ajoute de nouvelles fonctionnalités sans remettre en question TOUT ce qui a été fait jusqu'ici, il est possible qu'on soit effectivement dans le cas d'un projet Agile. Dans ce cas, la spéc "en chapelet aux amEndes Agile" n'est pas un motif valable de sévices tels que :
    - fouettage avec un câble Wi-Fi
    - arrachage d'oeil avec une touillette à café en plastique
    - mort par décès
    - chanson de "la Reine des neiges"
    - Windows Millenium
    NB2 : il est fréquent que les clients croivent (croillent ?) être "Agile" alors qu'en pratique ils ont juste envoyé 27 brouillons successifs et contradictoires de leur spécification. La spéc "en chapelet aux amEndes multi-révisée" autorise les sévices décrits ci-dessus (homologation par l'ONU en cours).


    NB1 : bien que la spéc en chapelet valorise le client (puisque sans lui le projet n'avance pas), au-delà d'un certain nombre d'allers-retours, le client s'irrite de nos questions incessantes, met en doute notre compétence (ce qui renforce la bonne ambiance générale de l'équipe en plus de faire avancer le schmilblick), et on finit _vraiment_ par se demander si on serait pas "un peu c*n sur les bords". Il faut savoir que, de même que la gravité cause la chute de pommes sur la tête de scientifiques Britanniques, la spéc en chapelet cause l'enlisement de la tâche qu'elle décrit et l'explosion du délai de livraison (c'est une loi physique, faut faire avec).

    NB2 : Conformément à la loi de Murphy (et son corollaire sur les processus mal emmanchés), les spécs de type « Post-It » accouchent généralement de spécs « en chapelet ». Une estimation honnête de la date de réalisation est donc « un jour ou l’autre ».


    - la spéc "OCB" : variante de la spéc "Post-it" en plus court. Mêmes effets.


    - la spéc orale : "Comment ça, y'a pas de spéc ? M'enfin, le café que je t'ai offert il y a 3 semaines pour parler du projet, c'était ça, la spéc ! Je pensais avoir été clair. Donc, si je comprends bien, t'as rien noté ? Put**n, t'es vraiment un boulet !!!"
    NB : à ce point, l'envie de meurtre (ou de crevage d'yeux avec une touillette à café en plastique) est naturelle mais déconseillée à cause de complications administratives de type "prison". Étant donné que "les paroles s'envolent", la spéc orale est comme la cuiller dans Matrix : elle n'existe pas ;-). Pas plus que la demande ou le ticket décrivant la tâche à réaliser puisque c'est là que devrait se trouver la spéc. Pas de date de début à ce point non plus, donc les compteurs de délai et de "ce-sera-en-prod-quand?" restent bloqués à zéro. Je conseille donc une attitude non-violente de type "C'est vous qui voyez !" (cf "Le train pour Pau" de Chevallier et Laspalès)
    Thu Nov 28 13:51:10 2019 - permalink -
    - ?4mtHmg
    GRRR! Job
  • Ton estimation de temps est une blague
    Tellement vrai, rien à ajouter ;-)
    Mon Nov 25 08:36:01 2019 - permalink -
    - https://www.jesuisundev.com/ton-estimation-de-temps-est-une-blague/#comment-1670
    Development Job Time
  • The Efficiency-Destroying Magic of Tidying Up
    "Cleaner" does not mean "more efficient" : have a look at the urban planner's dream pizza to get the idea (well, read the article too ;-)

    Scott’s Law: never put order in a system before you understand the structure underneath its (apparent) chaos.
    Mon Nov 18 13:49:16 2019 - permalink -
    - https://florentcrivello.com/index.php/2019/09/04/the-efficiency-destroying-magic-of-tidying-up/
    Best_Practice Chaos Job Organization Process
  • B***EL, que j'en ai marre des "daily" !!!
    Ah, l'"Agilité", quelle vaste blague ! Notez bien que je n'ai rien contre les méthodes qui permettent de travailler MIEUX en s'organisant MIEUX et dont l'objectif est de faciliter les choses tout en améliorant la qualité du produit développé.
    En pratique, on nous a mis de l'"Agilité" à toutes les sauces, et j'en vois 2 manifestations principales :
    - les "daily"
    - les spécs "au fil de l'eau" (à ce sujet, voir aussi : https://shaarli.callmematthi.eu/?4mtHmg)


    Les 'daily' se transforment donc en un reporting quotidien et une vague estimation de ce qu'on va faire dans la journée. Estimation qui n'engage à rien puisqu'on pourra l'expliquer le lendemain. Pour peu qu'on travaille sur un sujet un peu transverse et qu'on n'interragisse qu'avec un ou 2 collègues seulement, ce reporting se transforme souvent en "J'ai fait des trucs avec Bob" puisqu'on n'est pas là pour entrer dans le détail.
    Pire encore : le daily, quelle que soit sa durée ou le moment auquel il a lieu, vient interrompre les gens. Pour peu qu'on soit "in the zone", PAF!, il faut en sortir pour aller en réunion et raconter ce qu'on a fait la veille et écouter les autres faire de même (alors que l'info est/devrait être dispo dans tout outil de ticketing qui se respecte).

    En résumé : daily = reporting quotidien + déconcentration


    Les spécs "au fil de l'eau" ne sont ni plus ni moins qu'un prétexte à commencer le développement avant d'avoir fini d'écrire les spécs. C'est discutable. Surtout quand on se sent autorisé à commencer le dév avant d'avoir fini l'analyse de besoin. Mais on me dit dans l'oreillette que faire et défaire, c'est aussi ça l'"Agilité", le droit de naviguer à vue et de se tromper. C'est fabuleux cette méthode qui, si on l'applique (mal!) conduit à gaspiller des ressources, et qui explique que c'est normal et même que c'est le signe qu'on applique bien la méthode...
    Si on fait un parallèle un peu osé à base de marteau et de doigt :
    - la méthode permet que le marteau tape sur le doigt (même si ce n'est pas sa finalité)
    - si le doigt a mal, c'est le signe qu'on a bien utilisé le marteau parce que, oui, on a effectivement tapé fort. Le fait qu'on ait tapé au mauvais endroit est un détail technique qu'on étudiera lors du "sprint" suivant.
    ==> et le clou n'est toujours pas planté !


    NB: tout cela est AMHA un problème parce qu'on s'y prend mal. Je ne remets pas en question la philosophie des méthodes qui ambitionnent RÉELLEMENT de changer les choses. Le problème, c'est l'implémentation, pas la méthode : on est à fond dans le "Culte du cargo" (https://fr.wikipedia.org/wiki/Culte_du_cargo#Le_culte_du_cargo,_m%C3%A9taphore_et_th%C3%A8me)


    Aujourd'hui, plus personne ne veut travailler en open-space parce que c'est bruyant et qu'on a du mal à s'y concentrer (même l'inventeur du concept a admis que c'était une mauvaise idée). Pourtant il y a quelques années, tous les dirigeants d'entreprises trouvaient ça génial et ça s'est généralisé.
    J'ai l'impression que l'"Agilité", c'est pareil : c'est à la mode, et il faut "en être", mais je ne ressens pas tellement d'avantages au quotidien et je ne trouve pas que la qualité des produits livrés ait réellement fait un bond par rapport à ce qu'on faisait avant. Le Manifeste Agile (https://agilemanifesto.org/iso/fr/manifesto.html) prône plusieurs valeurs fondatrices, parmi lesquelles :
    * Les individus et leurs interactions plus que les processus et les outils
    * L’adaptation au changement plus que le suivi d’un plan
    Or, on l'applique bêtement et sans essayer d'adapter la méthode au contexte (les personnes, l'équipe, l'entreprise, ...) au mépris des règles de bases. Si l'Agilité implique ou aggrave la réunionite, ce n'est pas un progrès.

    EDIT :
    juste pour rire, une p'tite BD sur ce thème : https://www.monkeyuser.com/2018/sprint-break/
    Thu Oct 24 06:47:13 2019 - permalink -
    - ?LsYxAw
    Agile Bullshit GRRR! Job
  • Asynchronous Communication: The Real Reason Remote Workers Are More Productive
    Wed Oct 16 12:39:20 2019 - permalink -
    - https://doist.com/blog/asynchronous-communication/
    Best_Practice Job
  • Desirable developer skills
    1. Ability to ignore new tools and technologies
    2. Taste for simplicity
    3. Good code deletion skills
    4. Humility
    Thu Sep 19 08:41:15 2019 - permalink -
    - https://twitter.com/codeinthehole/status/540117725604216832
    Best_Practice Development Job Wisdom
  • Gadsby (novel)
    I having the feeling that some projects at my current company have secret constraints like this book had ;-)
    Thu Sep 5 11:34:25 2019 - permalink -
    - https://en.wikipedia.org/wiki/Gadsby_(novel)
    Book Job Wikipedia
  • Pourquoi vous devriez fuir AWS, Azure ou Google Cloud !
    Une préoccupation que je partage : c'est bien joli AWS, ils ont des produits intéressants, mais :
    - ça reste de la techno propriétaire et ça gratouille ma conscience de Libriste
    - Amazon pille l'Open Source
    - on est en train de mettre tous nos oeufs dans le même panier (si on considère les GAFAM comme un panier unique) : il se passera quoi le jour où il n'existera plus d'alternative ? Qu'est-ce qui les empêchera de faire la pluie et le beau temps sur internet, sur NOS applications et sur nos entreprises ? Amazon a le pouvoir de vie et de mort sur les entreprises qui ont toute leur infra sur AWS : un clic et on ferme la boîte. Je trouve ça plutôt effrayant.
    - Amazon a une mentalité de merde (disons-le clairement) : entre les conditions de travail de toutes ses "petites mains" et leur réponse à la fameuse "taxe GAFA", c'est une belle brochette d'enc*lés.
    - Dans les années 90-2000, on a bien vu ce que donnait l'hégémonie (monopole ?) de Microsoft sur le marché du PC. On est en train d'en sortir peu à peu pour la simple raison que le PC est un produit en perte de vitesse (au profit des smartphones et tablettes, ce qui, au final, déplace le problème plus qu'il ne le résout), mais on est en train de foncer tête la première dans le même genre de situation avec les clouds AWS / Azure / GCP.

    See also : https://mobile.twitter.com/verge/status/1140367192304865282
    Wed Aug 28 08:45:21 2019 - permalink -
    - https://lydra.fr/pourquoi-ne-devriez-vous-pas-aller-chez-aws-azure-ou-google-cloud/
    Amazon Cloud DevOps Google Job Microsoft
Links per page: 20 50 100
◄Older
page 1 / 9
Shaarli 0.0.41 beta - The personal, minimalist, super-fast, no-database delicious clone. By sebsauvage.net. Theme by idleman.fr.