Lire des docs fait-il partie du travail du développeur ?

Salut tout le monde !

Régulièrement dans le métier de développeur, je suis amené à lire de la doc pour utiliser de nouvelles APIs ou en apprendre plus sur le projet sur lequel je suis (entre autres).
Certains jours ces tâches de "lecture" prennent peu de temps mais parfois lire de la doc me prend au moins la demi-journée et cela m'inquiète car dans le métier de développeur aujourd'hui tout est tracé : on voit la quantité de travail produite et à quel moment grâce à la gestion de version (git,...), pendant les daily meetings il faut raconter ce qu'on a fait ces derniers temps (et si on a + lu de la doc que touché au clavier on se fait regarder sévèrement par les autres devs :aie: ) sans compter le fait qu'on peut vous voir bosser dans l'openspace. D'ailleurs j'ai l'impression que le daily meeting est plus un système de contrôle pour vérifier qu'on travaille qu'autre chose. En plus, je sais pas vous mais j'ai souvent l'impression que partout où je tombe mes collègues donnent l'impression de savoir tout sur tout et regardent vraiment d'un œil sévère les devs qui ne connaissent pas telle ou telle techno.

Pour contrer cela j'ai donc mis au point une astuce que j'applique depuis que je suis développeur (et que tout le monde fait j'imagine). :mrgreen: Quand je suis sur site, à chaque fois que je ne connais pas quelque chose je le note dans mon téléphone pour pouvoir regarder de quoi il s'agit le soir (ou si possible dans les transports pour que ça me fasse perdre moins de temps). :P Quand je suis en télétravail par contre c'est plus cool car je n'ai pas besoin de faire ça et je me documente pendant le boulot. J'ai néanmoins tendance à faire de plus grosses journées ensuite pour compenser la baisse de productivité.

Néanmoins je trouve quand même ce rythme crevant (ou alors il faut que ce soit ponctuel). Est-ce qu'au lieu de devoir toujours faire semblant de tout savoir il ne serait pas possible de justifier le fait qu'on ne sache pas quelque chose qui sort du cadre des compétences exigibles et donc prévoir du temps de formation pendant le boulot ? Ne serait-ce qu'une demi-journée par semaine serait suffisante.

D'autres devs qui vivent aussi le métier de cette manière-là ?

Et vous ? Vous lisez des docs pendant le temps de travail ou vous considérer que le temps de travail n'est destiné qu'à la production ?

Bonjour, je pense que lire les doc et se documenter sur le métier avant de développer on appelle cela de l'étude, dans le sprint il doit donc y avoir des tâches d'études qui sont sizé, et regarder le soir comme tu fais c'est des heures supplémentaire non payé donc si tout le monde fait ça (j’espère c'est pas le cas) c'est tout benef pour les patrons :mouarf:

De mon peu d'expérience l'étude de doc ou d'un sujet avant de commencer un dev est quelque chose de normal dans le métier de développeur et je n’ai JAMAIS vu quelqu'un de mes collègues ne pas utiliser une doc sur un nouveau sujet.

Peut-être que tes sentiments vis à vis de ton travail sur les docs est plus psychologique, et que tu te sens pas légitime à étudier un sujet car tu penses qu'être dev c'est pisser du code h24, je t'avoue avoir déjà eu ce sentiment au début, car t'as ton déjà fait la remarque en dayly ou après par exemple ?

Citation:

---

Envoyé par Röyksopp

Est-ce qu'au lieu de devoir toujours faire semblant de tout savoir il ne serait pas possible de justifier le fait qu'on ne sache pas quelque chose qui sort du cadre des compétences exigibles et donc prévoir du temps de formation pendant le boulot ? Ne serait-ce qu'une demi-journée par semaine serait suffisante.

---

ça faut le demander au management.
Ce que vous décrivez ça s'apparente au syndrome de l'imposteur déjà décrit sur ce forum.
Mais j'arrive pas trop bien à saisir la pertinence du message; si vous êtes boulanger et que vous préparez, faites cuire du pain, le principal c'est que le client achète votre pain et apprécie de la manger non ?

Bonjour,

Alors mo je ne suis pas développeur mais AMOA mais partout où je suis intervenu les développeurs ont toujours une phase d'étude et de prise de connaissance donc pour moi cela fait partie du métier Comme dit plus haut ce que vous faites en gros c'est des heures supplémentaires non rémunérés je ne vois pas de raison qui vous empêche de vous documenter pendant vos heures de travail.

Citation:

---

Envoyé par Kiwi15

Comme dit plus haut ce que vous faites en gros c'est des heures supplémentaires non rémunéré.

---

aah un grand merci ! Affirmé ainsi je comprends mieux.
C'est bien connu "ce que l'on conçoit bien s'énonce clairement" comme dirait l'autre :mouarf:

Citation:

---

Envoyé par Röyksopp

Certains jours ces tâches de "lecture" prennent peu de temps mais parfois lire de la doc me prend au moins la demi-journée et cela m'inquiète car dans le métier de développeur aujourd'hui tout est tracé : on voit la quantité de travail produite et à quel moment grâce à la gestion de version (git,...), pendant les daily meetings il faut raconter ce qu'on a fait ces derniers temps (et si on a + lu de la doc que touché au clavier on se fait regarder sévèrement par les autres devs :aie: ) sans compter le fait qu'on peut vous voir bosser dans l'openspace. D'ailleurs j'ai l'impression que le daily meeting est plus un système de contrôle pour vérifier qu'on travaille qu'autre chose.

---

Citation:

---

"À DÉCOUVERT"

Pour Danièle Linhart, sociologue du travail au Cresppa-CNRS, le contrôle visuel induit par l'open space est plus pesant encore que les difficultés de voisinage. "Sur un plateau, les salariés travaillent en permanence sous l'oeil de leurs collègues et de leurs chefs. Or tout le monde a besoin d'un peu d'ombre, d'un peu d'intimité, d'un peu de quant-à-soi. Il faut, dans une journée de travail, pouvoir, de temps en temps, prendre de la distance, souffler, adopter une posture de dérision. Dans un open space, c'est impossible : il faut au contraire adopter des comportements de façade et revêtir les habits du salarié modèle. Ce contrôle de soi épuise les salariés et nourrit leur stress. Ce n'est sans doute pas un hasard si la question du mal-être est au coeur de nos débats sur le travail."

Danièle Linhart va même beaucoup plus loin : elle estime que l'open space, dans sa version la plus difficile – les grands plateaux – est le symbole même des dérives du management moderne. "Ce management recherche une relative déstabilisation du salarié car il veut éviter les habitudes ou les routines qui pourraient éloigner des méthodes de travail les plus performantes. Avec sa transparence, l'open space est au coeur de cette stratégie : les salariés sont en concurrence visible, ils travaillent à découvert et comprennent vite qu'il faut se mobiliser et adopter les règles de l'entreprise. L'open space est une manière de planter le décor de la guerre économique."

---

Source : Dans la cage de l'open space - Le Monde (2012)

Danièle Linhart - wikipedia

et,

Citation:

---

Il y a là de quoi inquiéter. On comprend, à lire l’ouvrage, que la pratique du management repose sur une sorte de myopie morale. La question de la liberté individuelle est évacuée, au profit d’une liberté communautaire largement illusoire. Il engendre aussi l’apparition d’un type humain malheureusement bien connu, celui du manager stressé, suicidaire, bourreau de soi et de ses subordonnés. Il institue une sorte d’état d’exception permanent, dans l’entreprise comme dans l’État, où le droit se meurt, au profit d’un certain culte de la performance et du résultat.

Surtout, il y a là une perversion abyssale. Parlant de Höhn et consorts, Chapoutot écrit : « Ils ont élaboré, paradoxalement, une conception du travail non autoritaire, où l’employé et l’ouvrier consentent à leur sort et approuvent leur activité, dans un espace de liberté et d’autonomie a priori bien incompatible avec le caractère illibéral du IIIe Reich, une forme de travail “par la joie” qui a prospéré après 1945 et qui nous est familière aujourd’hui à l’heure où l’“engagement”, la “motivation” et l’“implication” sont censés procéder du “plaisir” de travailler et de la “bienveillance” de la structure. »

---

Source : Libres d’obéir de Johann Chapoutot | Résumé sur Dygest

Johann Chapoutot - wikipedia


Autre source sur developpez, entre autres, pour les deux auteur.e.s cité.e.s ici :

:fleche: 91 % des responsables des ressources humaines s'inquiètent du taux de rotation du personnel
50 % des employés des 12 derniers mois ont reçu deux autres offres d'emploi, selon Gartner


ps
Tout est tracé/surveillé de nos jours; ç'est valable pour tous les métiers, notamment également, les fonctions autres que les études et développement IT pro

Salut,

Tu soulève pas mal de points différents là.

Pour ce qui est de lire de la doc, en soit, pour moi ça fait partie du job, que la doc soit technique ou non. Si tu as besoin de lire de la doc pour comprendre ce que tu fais et proposer / implémenter la meilleure des solutions à un problème plutôt que la solution "bête et méchante", fais le. C'est ce qui différencie quelqu'un qui réfléchis et qui fait avancer les choses, d'un simple exécutant.

Pour ce qui est des collègues qui te regarde de travers car tu lis de la doc plutôt que de pisser du code, il y'a pour moi deux raisons possibles derrière cette attitude :
- Tu pisse pas de code, du coup tu retarde les devs. Ca veut dire que globalement vous chiffrer pas vos taches de façon safe, et vous serez dans la mouise dès le moindre imprévue. Comme dit plus haut, l'étude doit faire partie du chiffrage.
- Se documenter, faire de la veille tout ça, globalement, presque tout le monde est d'accord pour dire que c'est important, et presque tout le monde ne prend pas le temps de le faire (pour diverses raisons pas forcément dépendant de leur volonté, et également pour certains par flemme). C'est pas impossible que les autres devs aiment pas trop le fait que tu fasse ce qu'eux ne veulent / peuvent pas faire.
- Recherche = progression. A force de te documenter, tu vas progresser et donc tu finira par mettre un fossé de connaissance avec tes collègues.

Globalement, la majorité des soucis avec tes collègues, c'est surtout un problème d'égo mal placé de leur part. Vous formez une équipe et devriez plutôt avancer dans la même direction. Faut en discuter avec eux, mais peut être que le problème est ailleurs (délais, organisation du projet, répartition des responsabilités, etc). Ce qui est sûr, c'est que si vous n'en discutez pas entre vous, rien ne s'arrangera. La rétro sert à ça justement. Pointer les problèmes du doigt, confronter les idées.

Momoth

Bonjour,

Faire semblant de tout savoir, c'est bon en entretien.
Une fois sur mission, ne pas hésiter de dire que tu ne comprends pas, que tu ne connais pas. Sauf si bien sûr on t'a recruté pour faire du PHP et tu déclares que tu ne sais pas. Mais si c'est un "plus", une activité annexe, le client aura déjà oublié.

Et puis sinon, c'est la chose la plus débile à faire que de lire le soir au sujet d'une chose que tu ne sais pas. La veille technologique fait partie de ton boulot. Lire la documentation, surtout.

Quant au daily meeting, que dire à part que "Oui", c'est pour savoir si tu es sur quelque chose et que tu avances ? Cela semble poser beaucoup de problème le "flicage". Cela ne me dérange pas de dire que je suis sur une tâche en particulier. Ce que j'apprécie moins, c'est les remarques que "cela n'avance pas" au rythme que l'on voudrait ; d'expérience, mes analyses ont souvent permis de gagner beaucoup de temps plutôt que de livrer un patch qui va foutre la prod en carafe.

Merci pour vos réponses. Je crois avoir compris parmi vos retours que lire de la doc est OK pendant le temps de travail. Là où je me pose plus de question c'est jusqu'à quelle quantité de recherche documentaire un dev est autorisé à faire ? En particulier quand il bloque sur un problème. :mrgreen: Ou même lorsqu'il doit apprendre une nouvelle techno qu'on pourrait considérer comme faisant partie de la "base" genre Subversion.

Dans des cas comme ça on est obligé de mouiller un peu la chemise.

:mouarf: cela sent à plein nez le junior qui est vendu comme "prestataire" et qui tombe dans 1 équipe d'experts ou de trous de balle.

Citation:

---

Envoyé par Röyksopp

En particulier quand il bloque sur un problème.

---

C'est juste 1 truc classique :mrgreen: on lit la documentation. En cas de problèmes, Internet et les forums ... peut-être la documentation en interne. Et toujours en cas de problèmes, on demande à ses collègues.
Et à l'extrème, si tu n'arrives pas à faire le travail, tu demandes à passer à autre chose : tu feras gagner du temps à l'équipe (et tu pourras voir la solution plus tard)

Citation:

---

Envoyé par Röyksopp

Ou même lorsqu'il doit apprendre une nouvelle techno qu'on pourrait considérer comme faisant partie de la "base" genre Subversion.

---

Si tu ne sais pas faire 1 [partie du] travail lorsqu'on te l'affecte, il faut que "les chefs" le savent, le planifient et te permettent de te former correctement s'ils le peuvent.

Citation:

---

Envoyé par Röyksopp

Dans des cas comme ça on est obligé de mouiller un peu la chemise.

---

En début de carrière ou au démarrage d'1 mission sur 1 nouvelle techno, l'autoformation est nécessaire ... à moins d'être "placardisé"/ "pistonné".
Mais comme les développeurs sont maintenant en grande partie recrutés/ vendus comme des prestataires, il faut être opérationnel tout de suite.
T'imagine 1 plombier ou 1 installateur d'équipement par exemple, prendre du temps pour lire les instructions et tester la procédure :ptdr: ... souvent à 25 €uros le quart d'heure.

Citation:

---

Envoyé par Röyksopp

Je crois avoir compris parmi vos retours que lire de la doc est OK pendant le temps de travail. Là où je me pose plus de question c'est jusqu'à quelle quantité de recherche documentaire un dev est autorisé à faire ?

---

bah oui c'est préférable ; se documenter ça fait partie de l'activité pro.
Cependant si vous devez par exemple apprendre Javascript et que vous n'arrivez pas à écrire la moindre ligne de code deux mois après ça va pas le faire comme dirait l'autre :aie:
y'en a qui ont essayé ils ont eu des problèmes

Citation:

---

Envoyé par Mat.M

(.../...) si vous devez par exemple apprendre Javascript et que vous n'arrivez pas à écrire la moindre ligne de code deux mois après ça va pas le faire comme dirait l'autre :aie:
y'en a qui ont essayé ils ont eu des problèmes

---

ça peut durer, ça, parfois des années. Mais oui, ça finit toujours mal.

Hello,

Je peux apporter un point de vue de manager, en espérant que ça t'aide. Attention, mon idée du management n'est valable que dans mes équipes, au mieux dans les équipes à côté car on est aligné avec d'autres managers, mais même pas au niveau de mon entreprise -- donc encore moins dans la tienne !

Un dev qui bosse en dehors de ses heures pour du boulot, ce sont des heures supplémentaires. Mais si c'est à l'initiative de l'employé, ce qui est ton cas, ça n'a pas à être pris en compte.

Est-ce que tu dois te former sur des APIs / 3rd party / ... ? Oui, bien sûr. Si demain on décide d'utiliser une nouvelle interface, je ne m'attends pas à ce que les devs de l'équipe la connaisse déjà, donc c'est normal qu'ils prennent du temps pour se former.
Combien ? Ben là, ça dépend du besoin et aussi de chacun. Dans certains cas, 30 minutes sur les principales API et tu en sais assez, dans d'autres tu vas devoir te taper toute la doc pour chercher le paramètre caché dont tu as besoin.

Pour le reste -- surveillance au daily, collègues qui savent tout et te regardent de travers -- ben... c'set difficile à juger en n'ayant que ton point de vue, mais visiblement cette équipe / ambiance ne te convient pas, donc est-ce que tu l'as rencontrée partout, ou bien uniquement dans cette boite ?
Si c'est partout, difficile de savoir si c'est pas de chance ou si ça vient de toi.
Si c'est que dans cette équipe / boite, alors il est peut-être temps de changer ?

Bonjour,

Citation:

---

Envoyé par gangsoleil

Un dev qui bosse en dehors de ses heures pour du boulot, ce sont des heures supplémentaires. Mais si c'est à l'initiative de l'employé, ce qui est ton cas, ça n'a pas à être pris en compte.

---

Je ne peux pas laisser passer cette opinion sans réagir : Ton rôle de manager est aussi de t'assurer qu'un développeur ne se sentira pas obligé de faire des heures supplémentaires de sa "propre initiative", ou plutôt à cause de la pression subie par l'encadrement et par des délais bien souvent incohérents imposés par la hiérarchie. Il ne devrait jamais arriver que quelqu'un se sente obligé de travailler chez lui en plus des heures sur place, pour quelque raison que ce soit.

Citation:

---

Envoyé par ed73170

Je ne peux pas laisser passer cette opinion sans réagir : Ton rôle de manager est aussi de t'assurer qu'un développeur ne se sentira pas obligé de faire des heures supplémentaires de sa "propre initiative", ou plutôt à cause de la pression subie par l'encadrement et par des délais bien souvent incohérents imposés par la hiérarchie. Il ne devrait jamais arriver que quelqu'un se sente obligé de travailler chez lui en plus des heures sur place, pour quelque raison que ce soit.

---

Entièrement d'accord : l'employé n'a pas à le faire, et c'est bien sûr au manager de s'assurer que ce n'est pas le cas. Et si c'est le cas, comme ici, alors le manager doit passer du temps pour comprendre ce qui pousse l'employé à le faire, pour voir ce qui ne va pas et changer cela dans l'équipe / l'organisation -- et non pas aller voir l'employé en lui disant que ce n'est pas bien...