[Sondage] Quelles sont les tâches les plus difficiles pour un développeur ?

**BugFactory** · 22/10/2015, 14h54

Intéressant, le sondage de Developpez.com n'obtient pas du tout les mêmes résultats que celui de Quora. Je me demande pourquoi?

**autran** · 22/10/2015, 14h55

Estimer le temps nécessaire :
Je commence par faire l’estimation honnête de mon travail. Ensuite j’applique une surcote de 30% (coefficient de sécurité)

**grunk** · 22/10/2015, 16h06

Envoyé par Gulien

Pour moi le plus dur n'est pas dans le sondage :

-Endurer la répétition d 'opérations faites maintes et maintes fois :
Création de classe, de table, d'entité, de DTOs BO, DTOs FO, Formulaires FO ...

Alors que tout ça c'est du vu et revu.

Il n'y a plus que le code métier qui m'amuse (enfin un tant soit peu).

C'est justement pour se concentrer sur le code métier que les framework sont là en général

**tchize_** · 22/10/2015, 20h51

Toutes les decisions de groupe.

Déterminer le resto où aller à midi
Déterminer la dose de café a mettre dans le filtre de la cafetière
Retrouver la tablette de test
Nettoyer les tables après le lunch
Vider le lave vaisselle

Invité · 22/10/2015, 21h36

Les choses les plus difficiles pour moi en tant que programmeur pour moi c'est travailler sur un projet déjà fait et surtout vérifier les bugs du projet déjà entamé. Mais c'est vrai que respecté les délais c'est la chose le plus délicate.

**Kaamui** · 23/10/2015, 09h32

La tache la plus compliquée pour un développeur en France c'est de se faire payer correctement pour son travail.

**midonet7** · 23/10/2015, 10h07

Pour moi, c'est l'estimation du temps nécessaire pour effectuer les tâches, c'est pour cette raison il faut penser toujours à faire des macro-chiffrages des tâches avant de communiquer officiellement l'estimation finale au client.

Cordialement,

**Gunny** · 23/10/2015, 11h07

Je suis content qu'il y ait l'option "Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord" parce que je trouve ça vraiment frustrant. Quand ça touche vraiment à la technique ça ne me dérange pas, parfois je ne suis pas forcément d'accord avec la solution de l'architecte ou de mes collègues devs, et à ce moment là on discute, et même si ma solution n'est pas retenue et bien ce n'est pas dramatique : au moins on en a parlé. Par contre, quand vient "d'en haut" une demande clairement contre-productive, stupide, ou myope, et que toute discussion sur le sujet est impossible, bref quand on m'impose de faire ce qui serait considéré par n'importe quel professionnel comme du mauvais travail, j'ai un peu de mal.

**tp1024** · 23/10/2015, 11h08

Je pense qu'il manque un choix:

* Obtenir toutes les informations utiles pour concevoir la solutions technique et/ou réaliser le chiffrage.

De mon expérience, le pb ne concerne pas le client, mais les relais entre le client et l'équipe technique.

**IronBibs** · 23/10/2015, 12h34

Pour ma part:
- Estimer le temps nécessaire pour effectuer des tâches
- Expliquer ce qu'on fait (ou ne fait pas)

L'estimation du temps nécessaire est un classique contre lequel on se heurte beaucoup, surtout en début de carrière où l'on est souvent plein de bonne volonté, on veut absolument bien faire et dans un temps donné court, et un peu trop naïf car on ne voit souvent qu'une partie de l'iceberg quand on s'interroge sur la charge de travail.
Je suis assez content de voir que l'option "Expliquer ce qu'on fait". C'est bien plus complexe pour moi d'expliquer par des mots ce que je fais de manière naturelle en codant. Surtout quand on est pris à froid et qu'on ajuster son discours à quelqu'un d'externe au projet. A mes yeux, c'est bien plus difficile à faire que de la documentation par exemple.

**Guikingone** · 23/10/2015, 15h03

Personnellement je pense que bosser sur le code de quelqu'un d'autre et définir un délai de livraison précis et chose ardue, durant le développement tout peut se passer à merveille et le temps estimé peut se raccourcir mais si les choses se compliquent, on perd du temps pour rien et les soucis relatif au fait de bosser sur le code de quelqu'un d'autre arrivent durant cette phase.

Rédiger une documentation ? Oui aussi, cela prend du temps pour pas grand chose parfois mais il faut y passer.

Je pense aussi au fait de versionner son code, tout le monde n'y pense pas forcément mais cela prend du temps en fin de compte si on compte les heures passés à coder suivi des heures passées à signaler ce que l'on a fait, les changements de branches, les ajouts, les suppressions, c'est peu pratique au final si on y pense et cela prend du temps qui pourrait être utilisé de façon plus utile.

**nirgal76** · 23/10/2015, 15h29

La chose la plus difficile que j'ai à faire pratiquement tous les jours, c'est savoir précisément ce qu'il faut faire. LA demande client se résume bien souvent à "j'voudrais un machin qui fait des trucs...combien de temps il te faut ?"...c'est lassant

dk · 23/10/2015, 15h47

Résultats intéressants. Ce qui me frappe c'est le point "concevoir une solution" : 0.92% / 2%

Il n'y que des archi qui ont répondu au questionnaire ou quoi ?

Au taf je réalise beaucoup de revue de code / conception, s'il y a un problème récurrent, c'est bien la conception, et effectivement ensuite le nommage, ce qui est lié parce que les devs ne saisissent pas toujours très bien ce qu'ils implémentent, ni comment ils l'implémentent. Vive l'auto évaluation en somme

Invité · 23/10/2015, 20h37

Envoyé par dk

Résultats intéressants. Ce qui me frappe c'est le point "concevoir une solution" : 0.92% / 2%

Il n'y que des archi qui ont répondu au questionnaire ou quoi ?

Au taf je réalise beaucoup de revue de code / conception, s'il y a un problème récurrent, c'est bien la conception, et effectivement ensuite le nommage, ce qui est lié parce que les devs ne saisissent pas toujours très bien ce qu'ils implémentent, ni comment ils l'implémentent. Vive l'auto évaluation en somme

Très bonne remarque.

Et si on inclut les 16% de "Expliquer ce qu'on fait", ça pourrait vouloir dire que 65% des développeurs ne savent pas ce qu'ils font et n'en n'ont même pas conscience.
Ou alors ils font du PHP.

**autran** · 23/10/2015, 21h02

Envoyé par nokomprendo

Très bonne remarque.
Et si on inclut les 16% de "Expliquer ce qu'on fait", ça pourrait vouloir dire que 65% des développeurs ne savent pas ce qu'ils font et n'en n'ont même pas conscience.
Ou alors ils font du PHP.

Et pour cause, la plupart développeurs sont trop jeunes pour avoir cette maturité.
Quant à ceux qui sont matures, la RH les juge trop vieux et n'en veut plus comme développeurs

mais c'est un autre débat...

**Matthieu Vergne** · 24/10/2015, 01h53

Je vais faire froncer les sourcils, mais pour ma part, aucune difficulté à évaluer le temps nécessaire ! {^_^}
Comment voulez-vous trouver difficile une tâche qu'on ne fait pas ?

Ça fait longtemps que je ne fais plus d'évaluations de ce genre (et quand on me demande combien de temps il me faut, je propose une date pour voir où ça en est). Quand la tâche est simple, pas besoin d'évaluer sa durée, ça se fera entre deux tâches pour se changer les idées, sinon on se met d'accord sur une date de contrôle pour évaluer l'avancée des travaux (c'est pourquoi je préfère parler de milestone plutôt que de deadline), et on se dit si oui ou non ça a l'air de valoir le coup de continuer, de reporter ou d'oublier tout simplement.

Mais je l'avoue, je triche : je fais de la recherche. {^_^}v

**mister3957** · 24/10/2015, 09h37

Sortant d'une expérience en SSII assez douloureuse, je ne me sens pas assez objectif pour participer à ce débat

Juste que les réponses proposées sont très très limitées, on pourrait rajouter par exemple :

- "Assumer les manques de responsabilités de la hiérarchie"
- "Assumer de coûter un peu plus de 3 pesos"
- "Assumer de jouer avec la merde que le commercial a vendu"
- "Assumer le fait de ne rien pouvoir dire car le client est roi, le commercial rapporte, toi tu coûtes et trop cher pour juste faire joujou avec des ordinateurs"

- Et bien d'autres avant de parler de notre métier de développeur / d'ingénieur qui n'a strictement plus rien à voir dans ce contexte là.

**mister3957** · 24/10/2015, 09h41

Envoyé par nirgal76

La chose la plus difficile que j'ai à faire pratiquement tous les jours, c'est savoir précisément ce qu'il faut faire. LA demande client se résume bien souvent à "j'voudrais un machin qui fait des trucs...combien de temps il te faut ?"...c'est lassant

Mais une fois en qualif il devient subitement très très très précis sur les exigences.

**Mat.M** · 25/10/2015, 22h22

bonjour les tâches les plus difficiles essentiellement pour un développeur c'est de

comprendre précisément le métier du client dans le service informatique
si vous travaillez dans la banque il faut comprendre un minimum les métiers de la banque.

pouvoir conceptualiser , aller dans l'abstraction...avoir une vision globale d'un projet...

de ce qui est indiqué précédemment analyser un problème complexe et le décomposer en problèmes simples donc découper en modules.

reprendre le code de quelqu'un d'autre surtout s'il y a des tonnes de copier-coller avec du code redondant et aucun refactoring.

ce qui quelque part rejoint les avis précédents.
Etant donné que "ce qui se conçoit aisément s'énonce clairement" effectivement nommer ce que l'on fait peut être difficile je ne suis pas étonné par les résultats du graphique

Envoyé par nokomprendo

Et si on inclut les 16% de "Expliquer ce qu'on fait", ça pourrait vouloir dire que 65% des développeurs ne savent pas ce qu'ils font et n'en n'ont même pas conscience.

des projets que l'on est pas capable d'expliquer j'ai déjà participé à ce genre de projets..
à la base le projet est mal défini, n'a pas de fonctionnalités pertinentes et c'est pour satisfaire les ambitions d'un DSI

**Franck.H** · 26/10/2015, 13h24

Pour ma part, c'est surtout travailler avec le code d'autres développeurs, surtout dans mon cas, celui de mes prédécesseurs qui ont codé un peu comme des cochons