Journal Pourquoi les programmeurs sont grognons

Posté par  . Licence CC By‑SA.
Étiquettes :
27
6
mar.
2013

Cher Journal,

j'ai lu cet article avec grand plaisir l'autre jour. L'auteur a reussi a mettre des mots sur des pensees que j'avais du mal a exprimer clairement.

Pourquoi les programmeurs sont grognons (en).

C'est en anglais malheureusement, mais c'est quand meme tres interessant.

Oui, c'est un journal bookmark.

  • # Traduction FR

    Posté par  (site web personnel) . Évalué à 10.

    La traduction française :
    http://blog.mandraxe.info/ingenieurs-grincheux.html

  • # L'Éthique hacker et l'esprit de l'ère de l'information

    Posté par  (site web personnel) . Évalué à 9.

    La lecture de cet article (qui était pas mal repris sur twitter par exemple, il y a presque 2 mois) m'a fait pensé à un bouquin que j'ai adoré : « L'Éthique hacker et l'esprit de l'ère de l'information » de Pekka Himanen.

    Je reprends ce que j'avais écris à l'époque.

    Je conseil réellement ce livre à tous les développeurs, tous les ingénieurs, toutes les personnes qui sont intéressées de près ou de loin par les hackers (ou qui pensent en être un).

    Pour vous parler de ce livre, je vais déjà vous citer un passage de l'article sur les ingénieurs grincheux qui m'a vraiment fait penser à celui-ci :

    Revoyons un instant ce qui fait avancer les ingénieurs :

    • Être créatif
    • Résoudre des problèmes
    • Avoir une incidence sur la vie des gens

    Notez une absente dans cette liste. L'argent. Donner bêtement de l'argent à un ingénieur ne le satisfera que rarement. Cela fait cliché, mais ça n'a rien à voir avec l'argent. L'argent permet de s'amuser, mais ce qui nous intéresse vraiment c'est le code et la création. Lorsque nous pouvons le faire dans un environnement sain, nous sommes heureux, et pour très longtemps.

    Ce livre est en réalité un livre de philosophie. Si vous désirez un livre technique, passez votre chemin. Par contre, mine de rien il a une préface intéressante, par un certain Linus Torvalds…

    Ce livre oppose l'éthique hacker à l'éthique protestante du travail. D'ailleurs le titre de l'ouvrage est une sorte de clin d'œil au premier livre dans lequel le terme d'éthique protestante du travail est apparu. Il s'agit d'un livre de Max Weber intitulé « L'éthique protestante et l'esprit du capitalisme ». Et cette opposition cadre parfaitement avec le passage cité.

    Tant qu'à faire, voici la quatrième de couverture :

    « Il y avait la rock'n'roll attitude, il y a désormais la “hacker attitude“, un modèle social pour l'ère post-industrielle », expliquait Libération lors de la parution de ce libre au début de l'année 2001 aux Etats-Unis. On considérait jusqu'à présent le « hacker » comme un voyou d'internet, responsable d'actes de piratage et de vols de numéros de cartes bancaires. L'essor du Net a contribué à cette mauvaise réputation, certes tronquée et trompeuse, des flibustiers de la grande toile.

    Le philosophe Pekka Himanen voit au contraire les hackers comme des citoyens modèles de l'ère de l'information. Il les considère comme les véritables moteurs d'une profonde mutation sociale. Leur éthique, leur rapport au travail, au temps ou à l'argent, sont fondés sur la passion, le plaisir ou le partage. Cette éthique est radicalement opposée à l'éthique protestante, telle qu'elle est définie par Max Weber, du travail comme devoir, comme valeur en soi, une morale qui domine encore le monde aujourd'hui.

    Cet essai de Himanen - déjà salué par la critique aux Etats-Unis et au Japon - ouvre de nouvelles voies pour penser l'avenir des sociétés post-industrielles et la transformation en cours du capitalisme.

    Pekka Himanen, né en 1973, docteur en philosophie, enseigne à l'université d'Helsinki, ainsi qu'à l'université de Berkley en Californie.

    Linus Torvalds, illustre hacker, est à l'origine du système d'exploitation Linux.

    Manuel Castells, professeur de sociologie à l'université de Berkley, est notamment l'auteur de L'ère de l'information (Fayard).

    Sinon vous pouvez aussi aller lire cette intéressante interview de Roberto Di Cosmo.

  • # Commentaire supprimé

    Posté par  . Évalué à 4. Dernière modification le 06 mars 2013 à 09:45.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re

      Posté par  . Évalué à 2.

      Il y a un juste milieu entre définir un cahier des charges exhaustif (impossible) et la méthode larache. Désolé mais dans la réalité d'une grande majorité de développeurs c'est cette dernière qui est subie.
      Et il préconise d'intégrer les dev dans le processus créatif, il n'y a rien de plus crédible et évident à cela.
      Apparemment tu dois vivre sur une autre planète ou bien un de ces rares et chanceux développeur qui n'a jamais vécue ce qu'il démontre.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 8. Dernière modification le 06 mars 2013 à 12:03.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 0.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Re

          Posté par  . Évalué à 7.

          Mais cela m'a appris à refuser.

          C'est bien tu as de la chance de pouvoir refuser. Le problème est quand dans la plupart des boites tu es mal barré point de vu carrière si tu refuses ….
          Je continue à penser que tu ne vies pas, et c'est tant mieux bien sur, ce que vive la majorité des devs.

          Je conteste le fait, notamment, qu'il voit la création d'un logiciel comme une cascade. Ce modèle est trivialement dysfonctionnel et c'est prouvé depuis des décennies.

          J'ai plutôt l'impression qu'il dénonce que les décideurs voient le développement de cette manière ce qui amènent aux conséquences qu'il présente. De la à conclure que son texte n'est pas crédible c'est juste une blague. Son texte il doit y avoir 90% de devs qui l'on vécu et le vive.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 8. Dernière modification le 06 mars 2013 à 16:55.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Re

              Posté par  . Évalué à 4.

              C'est pas si simple. 90% des devs ont conscience de taffer dans une des boites de merde qui représentent 90% des boites en info… Dans ces boites dire non à un projet c'est dire non à tous les projets de la boite. Le problème n'est pas le projet en lui même mais sur l'organisation de la boite, sur le comment elle manage ses projets et donc ses ingés par des marketeux et/ou commerciaux…
              Le "yakafokon argumenter le refus" ça fait un peu bisounours land :) Mais ca marche surement dans quelques boites un peu moins merdique que les autres.

              • [^] # Re: Re

                Posté par  . Évalué à 6.

                Mouais, je suis assez daccord avec lui
                sachant que même en SSII tu communiques avec des humains
                j'ai déjà dit non à des projets, ça se finit soit avec le commercial qui retéléphone au client, soit avec une engueulade où tu peux facilement ressortir gagnant (en ayant les arguments).
                Tout comme j'ai refusé au client des changements majeurs dans l'appli, si il change d'idée en cour de route, il faut passer par la compta avant.
                Faut pas croire, même le commercial/chef de proj que tu méprises est un être humain avec qui tu peux discuter (et qui a des enfants que tu peux prendre en ota… euh oubli ce dernier point)

                Les conséquences sur la carrière ? peu si au final ton projet abouti, peu vu que tu changeras de boite dans moins de 2 ans

                • [^] # Re: Re

                  Posté par  . Évalué à 9.

                  Oui mais ça implique des rapports de force, pas tout le monde a envie ou peu les gérer. Si comme le préconise l'auteur du texte, l'ingénieur était invité dès le départ à la réflexion à la création, il y aurait moins de tensions après coup et plus de réussite.
                  Perso je remarque juste que les boites qui réussissent vraiment ont intégré dans leur stratégie de management la vision de l'Ingénierie. L'ingénieur n'est pas juste là pour pisser du code, mais influe directement sur les produits voir même en est à l'origine (les 20% de projets perso chez Google par exemple) et ça change tout.
                  En France, les boucheries sont gérés par des bouchers, les cabinets comptables par des experts comptables, les cabinets dentaires par des chirurgiens dentistes, et les SSII/éditeurs par des commerciaux, tout est dit :)

                  • [^] # Re: Re

                    Posté par  . Évalué à 5.

                    Pas obligatoirement, j'éxagerai le trait
                    des rapports de force j'en ai eu une fois et ça cest finit par des insultes, une rupture à l'amiable et 8000euros dans ma poche
                    ça n'avait dailleurs pas en grand chose à voir, c'était une histoire de note de frais et de faux cv

                    Dailleurs, si ton projet foire, il risque fort d'y avoir de rapport conflictuel lors de la chasse aux sorcières qui peut s'en suivre.

                    Mais en dehors de ça, généralement ça se passe bien, pas besoin de se mettre en opposition. Dailleurs il y a des réponses tout à fait acceptable (je sais pas faire, c'est pas possible, je suis sur autre chose, etc…). Faut bien voir une chose: le client, tes supérieurs et toi avez tout intérêt à ce que le projet marche, des fois ça implique une rallonge de temps, des fois de faire sauter une ou 2 features, etc… des fois le client s'est trompé sur son besoin, c'est son problème (ou celui de l'analyste), le client peut avoir l'impression de s'être fait escroquer, c'est la responsabilité de celui qui a vendu, des fois c'est toi qui a mal jugé ou qui n'a pas su calmer les ardeurs de ton supérieur, et là tu es en tort. (Mais généralement un projet foiré est un mix de diverses responsabilités.)

                    Je dis pas que c'est le rêve, qu'on ne serait pas mieux chez google, ou qu'il n'y a pas de moment tendu, mais hors cas spécifique, on vit tout de même mieux en disant non de temps en temps.

              • [^] # Re: Re

                Posté par  . Évalué à 1.

                C'est pas si simple.

                En quoi ? C'est ton job !

                Franchement l'organisation de ton équipe, la facon dont elle travaille et communique est vraiment primordial. Il y a vraiment moyen de travailler correctement en s'y prenant bien.

                90% des devs ont conscience de taffer dans une des boites de merde

                Il y a grosso modo autant de boite de merdes que de dev de merdes. La première partie finissant peu à peu part employer la seconde partie, les autres finissant inexorablement par aller voir ailleurs ou changer de métier.

                Dans ces boites dire non à un projet c'est dire non à tous les projets de la boite.

                Quel est le problème ? Si on te fait sciemment saborder les projets et perdre ton temps, c'est qu'il est tant d'aller voir ailleurs non ?

                • [^] # Re: Re

                  Posté par  . Évalué à 2.

                  Quel est le problème ? Si on te fait sciemment saborder les projets et perdre ton temps, c'est qu'il est tant d'aller voir ailleurs non ?

                  Certes, certes, sauf que les 10% de boites sérieuses restante, il y a du bon dev qui fait la queue pour y entrer, bref elles ont le choix … :)

                  • [^] # Re: Re

                    Posté par  . Évalué à 4.

                    Note que tout n'est pas noir ou blanc. Se faire sa place pour pouvoir bosser tu peux le faire dans une "boîte de merde" et beaucoup des problèmes sont du aux équipes elles même. J'ai déjà vu des différences phénoménales entre deux équipes avec le même contexte et management au dessus…

                    Certes, certes, sauf que les 10% de boites sérieuses restante, il y a du bon dev qui fait la queue pour y entrer, bref elles ont le choix … :)

                    Ca t'étonne tant que ca que les boites qui font les choses bien cherchent à recruter des gens compétents et pro ?

                    Mais soyons sérieux deux minutes. Actuellement on est un métier où les gens compétents sont très recherchés, très bien traités et payés. Les portes sont grandes ouvertes contrairement à beaucoup d'autres métiers qui se sont fait entièrement verrouiller.

                    • [^] # Re: Re

                      Posté par  . Évalué à 3.

                      Ca t'étonne tant que ca que les boites qui font les choses bien cherchent à recruter des gens compétents et pro ?

                      Ca ne m'étonnes pas, je fais juste un constat.

                      Mais soyons sérieux deux minutes. Actuellement on est un métier où les gens compétents sont très recherchés, très bien traités et payés. Les portes sont grandes ouvertes contrairement à beaucoup d'autres métiers qui se sont fait entièrement verrouiller.

                      Oui tout à fait, à la condition de vouloir vivre à Paris, Londres, ou aux USA.

                      • [^] # Re: Re

                        Posté par  (site web personnel) . Évalué à 1.

                        Oui tout à fait, à la condition de vouloir vivre à Paris, Londres, ou aux USA.

                        En informatique il y a de quoi faire à Toulouse, Bordeaux, Sophia-Antipolis, Aix-en-Provence, Grenoble, etc.
                        Si tu as du mal à trouver des emplois intéressants là bas, je me demande quels sont tes critères…

                        • [^] # Re: Re

                          Posté par  . Évalué à 2.

                          Taff avec de l'opensource, quelques technos qui datent de moins de 20 ans, boite, management et projet crédible, pas la lune donc. Sophia c'est souvent pour bosser pour Orange, on a vu mieux, le reste à part quelques exceptions deci delà, c'est Paris, et pour les plus sérieux/envoutant, Londres et les USA.

                        • [^] # Re: Re

                          Posté par  (site web personnel) . Évalué à 7.

                          Même en dehors des SSII ?

                          Parce que bon ça oui, on en trouve à la pelle. Des SSII qui se disent différentes / mieux que les autres aussi (en fait elles disent toutes ça).
                          Par contre, des éditeurs de logiciels c'est pas tout à fait la même histoire…

      • [^] # Re: Re

        Posté par  . Évalué à 5.

        Il y a un juste milieu entre définir un cahier des charges exhaustif

        Si c'est totalement possible par fonctionnalité et ton équipe ne devrait pas accepter du travail qui n'est pas correctement spécifié.

        C'est pour ca qu'on fait par petit incrément. On laisse les managers décider "uniquement" de la fonctionnalité qu'ils veulent avoir dans le produit maintenant. On les force à définir exactement ce qu'ils veulent en leur fournissant toutes les informations utiles, et on revient vers eux pour l'étape suivante. Les devs/designers savent sur quoi bosser et ne perdent pas leur temps. Les managers ont exactement ce qu'ils demandent et peuvent se rendre compte qu'ils ne veulent pas toujours ce qu'ils ont demandé. Et si ca dérive c'est que la gestion des priorités a été mauvaise, que l'objectif à long terme n'était pas réaliste, ou qu'il y a eu des modification en court de route. Dans tout les cas, on peut tracer et comprendre pourquoi ca à foiré et s'en servir pour ne par refaire la même erreur. Les deux côtes du métier peuvent apprendre de cela et en discute pour ne pas que ca se reproduise.

        Dans tout les cas, si tu acceptes du travail non défini ca va dans le mur.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4. Dernière modification le 06 mars 2013 à 12:07.

          Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.