Un meilleur job mieux payé ?

Deviens chef de projet, développeur, ingénieur, informaticien

Mets à jour ton profil pro

ça m'intéresse

Le nombre d'heures passées sur un code reflète-t-il le degré d'implication du développeur ?
Un développeur senior s'interroge

Le , par Arsene Newman, Expert éminent sénior
Alors qu’il est relativement simple de constater qu’une personne travaille dur lorsqu’il s’agit d’un travail physique ou encore d’un sport, comment est-il possible de juger si une personne s’implique dans son travail lorsqu’il s’agit d’une activité mentale, comme dans le cas des développeurs ?

C’est la question posée par le développeur senior Mike Shadlow dans un billet de blog, où il revient entre autres sur une de ses expériences personnelles, qui se déroule en 2004 au sein d’une large équipe de développeurs travaillant sur un système de facturation et d’approvisionnement pour des chaînes télévisées.

Au cours de cette expérience, Mike Shadlow a été affecté à l’équipe chargée du développement du système relatif à la chaine numérique. En parallèle, une seconde équipe se chargeait de la chaine analogique. Mis à part ces différences, les deux équipes étaient chargées de concevoir le même système.

Toutefois, alors que l’on pourrait penser que les deux équipes allaient avoir la même approche, cela n’a pas été le cas. La conception du système pour la chaine numérique a été effectuée dans l’ensemble par un développeur ayant adopté les préceptes de la programmation orientée objet, les principes SOLID ainsi que les tests unitaires.

La lecture du dit code semblait une tâche ardue aux premiers abords, mais grâce aux conseils avisés de son concepteur, Mike Shadlow a pu se documenter et étudier les bases sur lesquelles reposait le code. Dès lors, tout devenait clair et sensé. Le développement du code fut relativement une tâche facile et concise, sans retard, surprise ou difficulté et les développeurs n’ont pas eu à effectuer des heures supplémentaires.

Du côté de la seconde équipe, les choses étaient complètement différentes. Le développement du système s’était montré plus complexe et difficile, le code était moins stable, les développeurs étaient confrontés à plusieurs bugs. Il était alors possible de les voir se réunir autour du bureau de l’un des développeurs essayant en vain d’élucider le problème. La tâche était si chronophage que les développeurs travaillaient durement jusqu’à des heures tardives ou encore lors des week-ends.

Alors, lorsqu’il était question de jauger le sérieux, le degré d’implication des développeurs issus des deux équipes, sur une perception purement temporelle, il était clair que la seconde équipe montrait une plus grande implication, mais était-ce la vérité ?

Le semblant de paresse et de non-implication de la 1ère équipe contrastait beaucoup avec celui de la deuxième équipe. Néanmoins, cela ne signifiait pas une moindre implication dans le fond, mais plutôt une capacité à travailler de manière efficace et sans trop d’effort, travailler peu et bien au lieu de trop pour peu.

Au final, cette situation montre clairement qu’il est difficile de juger le travail d’un développeur sur un plan purement temporel ou encore en observant l’agitation des développeurs au sein de l’espace de travail. Il est donc plus judicieux de s’accorder sur une approche plus décalée pour juger du sérieux du développeur en tenant compte de la qualité du code et du temps passé à la bonne conception du logiciel, ce qui débouche généralement sur un travail efficace.

Source : blog de Mike Shadlow

Et vous ?

Qu’en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de matpush matpush - Membre averti https://www.developpez.com
le 28/07/2014 à 11:28
J'en pense que ça reflète bien ce qui se passe dans ma boite.

Pour un résultat égal, on préfèrera un développeur moyen qui fera beaucoup d'heure sup. qu'un bon développeur faisant ses heures (sic mon chef de projet ) car il donnera l'impression de plus s'investir ...
Avatar de Mr_Exal Mr_Exal - Membre expert https://www.developpez.com
le 28/07/2014 à 11:29
Qu’en pensez-vous ?

Le code n'est que la finalité, le plus important étant surtout de savoir réceptionner et comprendre le besoin client, puis de le retranscrire. Et c'est sur cette retranscription que s'appuiera le code.
Avatar de khazna khazna - Membre actif https://www.developpez.com
le 28/07/2014 à 11:38
Ce qu'il faut c'est bien comprendre les besoins du clients, et bien concevoir l'architecture pour avoir un minimum de changements une fois le codage commencé.
Et le mieux c'est de faire en sorte que tout le monde comprenne l'architecture, et quelle est la logique derrière.

Rien ne sert de pondre 40 000 lignes alors que 10 000 suffisent...
Avatar de - https://www.developpez.com
le 28/07/2014 à 11:46
Ça me fait penser à ce commentaire :

//
// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 42
//
Avatar de Mr_Exal Mr_Exal - Membre expert https://www.developpez.com
le 28/07/2014 à 11:58
Citation Envoyé par chanyslas  Voir le message
Ça me fait penser à ce commentaire :

//
// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 42
//

J'ai pour idée de mettre celui là en commentaire d'un code pourri (modifié pour l'occasion ^^) :

- I don’t know who you are. I don’t know what you want. If you’re looking for a ransom, I can tell you I don’t have money, but what I do have are a very particular set of skills, skills I have acquire over a very long career, skills that make me a nightmare for people like you. If you let my me go now, that will be the end of it. But if you don’t, I will look for you, I will find you, I will kill you.
- Good luck.

Avatar de Luckyben Luckyben - Membre du Club https://www.developpez.com
le 28/07/2014 à 12:10
Complétement d'accord avec ce développeur. Bien trop souvent, on considère dans l'entreprise que seul le temps passé sur un projet rime avec sérieux et implication. Or, un "bon" développeur cherche à faire du code réutilisable dans d'autres modules/projets, et produit un code "propre". Au final, il économise du temps pour ses futurs dev similaires, et s'épargne une maintenance douloureuse. Effectivement, les heures suppl et les WE travaillés bénévolement ne sont pas forcement légion, et ça fait moins d'effet auprès de la Direction ...

Dans la même veine, il y a aussi le piège du développement vite-fait bien fait : en réussissant à livrer dans les temps une version qui fait ce qu'on lui demande sans que ça plante, on donne l'impression que la tâche était facile. Si la personne qui supervise n'a pas un minimum de connaissances techniques, elle en conclura que le boulot ne posait aucune difficulté, et n'hésitera pas lors de la prochaine demande à augmenter le nombre de points à corriger/développer pour le dév en question.

Après c'est un peu comme ça un peu partout, le gars qui finit à l'heure sera toujours suspecté d'être fainéant et/ou d'en faire moins que les autres ...
Avatar de Shuty Shuty - Membre éprouvé https://www.developpez.com
le 28/07/2014 à 13:29
Le travail de développeur n'est pas un travail de quantité mais plutôt de qualité.
Avatar de Uranne-jimmy Uranne-jimmy - Membre expérimenté https://www.developpez.com
le 28/07/2014 à 13:45
Malgré tout, l'exemple étudié ne rend pas compte de l'implication du développeur mais plutôt de sa capacité à faire les bons choix.
Par nature, j'ai l'impression qu'une bonne partie des développeurs préfèrent travailler intelligemment que beaucoup, ce qui se conçoit facilement dans le sens où ils font des logiciels dans ce sens. A partir de là, un bon dév ira au plus court et au moins fatiguant (à long terme) au but établi, produira un code stable, lisible et efficace. Mais on peut très bien être appliqué, travailler sans compter, s'investir sans avoir les capacités d'un bon développeur (notion idyllique, je ne prétend pas savoir qui est bon et qui est mauvais).
Ce que je vois dans l'exemple cité c'est une équipe organisé, préparé, qui connait les bons outils au moins de réputation, et une équipe sincère, travailleuse, qui ne connait pas ou n'a pas pour habitude de se baser sur les outils les plus adaptés.

A mes débuts, j'ai voulu utiliser les langages que je connaissais le mieux en dépit de la charge supplémentaire de travail que cela demandé par rapport à un langage plus adapté, pensant que justement l'expérience réduirait le temps nécessaire à mes fins, je me suis trompé et maintenant je fais autrement. Du coup ce cas me rappelle un peu moi, et je ne vois nul par de rapport avec l'implication du dév.
Avatar de Potomac Potomac - Membre habitué https://www.developpez.com
le 28/07/2014 à 15:15
Citation Envoyé par Shuty  Voir le message
Le travail de développeur n'est pas un travail de quantité mais plutôt de qualité.

et de méthode surtout, éviter de réinventer la roue grâce à l'usage de frameworks de développement,

et l'application de certains concepts pour fiabiliser/rationaliser le code ( programmation orientée objet, design patterns )
Avatar de rthomas rthomas - Membre du Club https://www.developpez.com
le 28/07/2014 à 16:19
Remplacez le mot "code" par le mot "maison" et cela fonctionne.
Préférez-vous une maison bien construite ou un truc où les briques ne sont pas alignés, plein de tranchés pour réparer les oublis...
Offres d'emploi IT
Ingénieur Informatique Editoriale
Hachette Livre - Ile de France - Île-de-France
Consultant fonctionnel h/f
Easy Partner - Ile de France - Meudon (92190)
Développeur full-stack symfony H/F
Le Smartsitting - Ile de France - Paris (75000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil