Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    ActiveState : 60 % des développeurs consacrent au plus 4h à la programmation dans une journée de travail
    ActiveState : 60 % des développeurs consacrent au plus 4h à la programmation dans une journée de travail typique
    à quoi est dédié le reste de leur temps ?

    Un développeur ne fait pas qu'écrire du code, même si la programmation peut occuper une partie relativement importante de son temps de travail au quotidien. Et parfois, l'écriture de code n'occupe même pas la moitié de sa journée. En tout cas, c'est ce que vient de révéler une enquête internationale réalisée par l'éditeur de logiciels canadien ActiveState Software basé à Vancouver.

    Au cours de cette enquête annuelle, ActiveSate a demandé à 1250 développeurs (dans le monde de l'open source) provenant de 88 pays différents combien d’heures ils avaient passé cette année à programmer, dans une journée de travail typique. Sur les 1250 réponses, la plus grande partie des personnes enquêtées (38,8 %) dit ne consacrer que 2 à 4 heures par jour à la programmation. Les résultats du sondage montrent notamment que 61,52 % des répondants (soit 3 développeurs sur 5) passent 4 heures ou moins à la programmation, alors que 27,92 % y consacrent 5 à 7 heures par jour et 10,56 % au moins 8 heures.


    À quoi les développeurs consacrent-ils le reste de leur temps en-dehors de la programmation ?

    ActiveState a également demandé aux répondants à quelle activité ils consacrent la majeure partie de leur temps quand ils ne sont pas en train de programmer. Pour la plus grande partie d'entre eux (44 %), ils consacrent le reste de leur temps à une multitude d’activités, notamment des réunions, des tests, la maintenance et même des activités de socialisation. Cependant, si l'on considère les activités individuellement, plus nombreux sont les développeurs qui disent, en dehors de la programmation, passer du temps sur la conception/architecture des logiciels (11,36 % des répondants), puis ceux qui disent participer à des réunions/standups (8,24 % des répondants).


    Temps consacré aux problèmes

    ActiveState a également voulu mieux comprendre combien de temps relatif, sur une semaine typique, était consacré aux problèmes de sécurité, problèmes liés à la construction d'une bibliothèque ou un package, problèmes liés à la gestion des dépendances ou encore les problèmes de licences.

    Vous trouverez ci-dessous les résultats pondérés :


    Notons avant tout qu'une pondération deux plus grande qu'une autre signifie que les développeurs consacrent deux fois plus de temps au premier problème. Ainsi, les résultats pondérés montrent que la plus grande partie du temps a été consacrée aux problèmes liés à la sécurité ou au code. Le temps consacré aux problèmes liés à la construction d'une bibliothèque ou d'un paquet par rapport à la gestion des dépendances était presque le même (1,77 contre 1,72 respectivement). On peut également constater que les répondants ont consacré aux problèmes de licences seulement 70 % du temps qu'ils ont passé à gérer les problèmes relatifs à la sécurité ou au code.

    Ci-dessous les résultats pour chacun des quatre problèmes :


    La figure ci-dessus montre que 72,81 % des répondants n'ont presque jamais passé de temps à gérer les problèmes de licences. À l'inverse, 61,67 % des répondants consacrent une partie ou la totalité de leur temps (temps consacré aux problèmes) à la gestion des dépendances. Notons également que 61,19 % des répondants consacrent une partie ou tout leur temps (temps consacré aux problèmes) à la construction d'une bibliothèque ou d'un paquet, tandis que 72,03 % consacrent une partie ou tout leur temps (temps consacré aux problèmes) à des problèmes liés à la sécurité ou au code.

    Source : Rapport ActiveState

    Et vous ?

    Combien de temps consacrez-vous à la programmation dans une journée de travail typique ?
    Que faites-vous le reste de votre temps au travail quand vous n'êtes pas en train de programmer (écrire du code) ?
    À quels problèmes consacrez-vous plus de temps au travail ?
    Peut-on associer le temps passé à écrire du code à l'expérience du développeur ? C'est-à-dire un développeur expérimenté aura-t-il tendance à moins se consacrer à programmer qu'un développeur junior ? Ou est-ce plutôt l'inverse ?
    Si vous êtes un développeur expérimenté, votre avis nous intéresse : laissez-vous la plupart des tâches de programmation aux juniors pour consacrer plus de temps à autre chose ou vous vous en occupez vous-mêmes ?

    Voir aussi :

    Quelle influence les développeurs exercent-ils sur les investissements dans les plateformes et outils de développement ? Partagez votre expérience
    Quels sont les facteurs qui poussent les jeunes développeurs à travailler plus longtemps ? Un amour pour le travail ou un mauvais management ?
    Les travailleurs sont-ils plus productifs lorsqu'ils travaillent plus de 40 heures par semaine ? Qu'en est-il des développeurs ?
    Travailler 60 heures par semaine n'est pas un gage de sérieux
    « 52 minutes de travail, 17 minutes de pause », la formule idéale pour un bon rendement, selon une étude
    « Trop travailler est stupide », les programmeurs ajoutent plus de bogues que de fonctions après 40 heures de travail par semaine pour un développeur
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé
    il y a bien la réunionite : une maladie contagieuse qui affecte les développeurs (surtout dans les entreprises "agiles")... Je passe entre 6 et 10h dans des réunions diverses et variées dont la moitié n'est pas efficace... :-(

  3. #3
    Expert éminent sénior
    Citation Envoyé par pboulanger Voir le message
    il y a bien la réunionite : une maladie contagieuse qui affecte les développeurs (surtout dans les entreprises "agiles")... Je passe entre 6 et 10h dans des réunions diverses et variées dont la moitié n'est pas efficace... :-(
    Vous n'avez qu'à faire une réunion sur comment rendre les réunions plus efficaces.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  4. #4
    Membre actif
    ben oui tout le monde connait le plan des réunions
    1. la réunion de planification de la réunion
    2. la réunion de préparation de la réunion
    3. la réunion (qui sert à rien évidemment)
    4. la réunion de débriefing de la réunion
    5. la réunion de conclusion de la réunion

  5. #5
    Membre actif
    Le reste du temps ? j'ai bien une idée

  6. #6
    Membre averti

  7. #7
    Membre expert
    ActiveState sous-entend "temps passé à pisser du code" par "heures consacrées à la programmation" puisqu'ils comptent le "software design/architecting" comme quelque chose en dehors de la programmation. Je ne partage pas cette vision. Le "pissage de code" n'est que l'aboutissement d'une réflexion menée auparavant sur le papier, là où se fait l'essentiel du travail. Donc l'aboutissement d'une certaine forme de "software design/architecting". Le codage ne va donc pas sans cette partie "conception". Se ruer sur son EDI pour y taper (frénétiquement) du code n'est pas la première chose à faire quand on a une tâche à accomplir. L'étude présente cette partie "conception" comme quelque chose d'aussi nocif au développement informatique que la réunionite alors que c'est tout l'inverse.

    Et c'est pareil pour bien d'autres choses de cette étude.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  8. #8
    Membre éclairé
    Pour moi, le plus effrayant, dans tous ces chiffres, c'est que je n'y vois nulle part, la part de veille technologique...
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

    Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
    (Contributions bienvenues)

  9. #9
    Membre averti
    Effectivement selon moi ont passe plutot 80% de sont temps en dehors du développement de son projet, perso je passe 30% de mon temps à faire des POC (proof of concept) + de la veille techno, ensuite il y a 20% effectivement perdue dans du temps de réunions mais aussi 30% dépensé à debuguer / refaire le travail qu'un autre a salopé mais certain jours c'est plutôt 90% du temps. Lorsque je bosse depuis chez moi j'arrive à consacrer 80% de mon temps sur mon projet et là je sais que je gagne 3 jours pour seulement 1 jour travaillé mais ça mon bosse n'en a pas la moindre idée. Bref le quotidien ordinaire d'un developpeur ...

  10. #10
    Membre actif
    Citation Envoyé par air-dex Voir le message
    ActiveState sous-entend "temps passé à pisser du code" par "heures consacrées à la programmation" puisqu'ils comptent le "software design/architecting" comme quelque chose en dehors de la programmation. Je ne partage pas cette vision. Le "pissage de code" n'est que l'aboutissement d'une réflexion menée auparavant sur le papier, là où se fait l'essentiel du travail. Donc l'aboutissement d'une certaine forme de "software design/architecting". Le codage ne va donc pas sans cette partie "conception". Se ruer sur son EDI pour y taper (frénétiquement) du code n'est pas la première chose à faire quand on a une tâche à accomplir. L'étude présente cette partie "conception" comme quelque chose d'aussi nocif au développement informatique que la réunionite alors que c'est tout l'inverse.

    Et c'est pareil pour bien d'autres choses de cette étude.
    Corriger les bugs a subit le même traitement. Je pense que les clients seront ravis que l'on soit plus efficaces en retirant cette tâche inutile.

  11. #11
    Expert éminent sénior
    2,8% de maintenance? Mais dans quel monde vivent ces gens? J'ai l'impression de vivre dans un autre univers. Dans leur esprit, on programme, et quand ça marche, on jette et on refait autre chose???
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  12. #12
    Membre expert
    Citation Envoyé par Jitou Voir le message
    Effectivement selon moi ont passe plutot 80% de sont temps en dehors du développement de son projet, perso je passe 30% de mon temps à faire des POC (proof of concept) + de la veille techno, ensuite il y a 20% effectivement perdue dans du temps de réunions mais aussi 30% dépensé à debuguer / refaire le travail qu'un autre a salopé mais certain jours c'est plutôt 90% du temps. Lorsque je bosse depuis chez moi j'arrive à consacrer 80% de mon temps sur mon projet et là je sais que je gagne 3 jours pour seulement 1 jour travaillé mais ça mon bosse n'en a pas la moindre idée. Bref le quotidien ordinaire d'un developpeur ...
    Citation Envoyé par Kulvar Voir le message
    Corriger les bugs a subit le même traitement. Je pense que les clients seront ravis que l'on soit plus efficaces en retirant cette tâche inutile.
    Citation Envoyé par el_slapper Voir le message
    2,8% de maintenance? Mais dans quel monde vivent ces gens? J'ai l'impression de vivre dans un autre univers. Dans leur esprit, on programme, et quand ça marche, on jette et on refait autre chose???
    Dans leur esprit t'as en effet l'impression que la tâche noble du code se limite à pisser frénétiquement du code évolutif dans un EDI qui serait vachement bien foutu pour ça. Paye ta tâche noble de codeur ! Certes ils ont des licences de Komodo IDE à vendre, mais il y a mieux à faire pour séduire les développeurs qui l'utiliseront.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).