Quels sont les atouts qui permettraient de booster la productivité d'un développeur ?
Un ingénieur partage son point de vue

Le , par Stéphane le calme, Chroniqueur Actualités
Fort de ses 20 ans d’expérience, un ingénieur qui utilise le pseudonyme Antirez, évoque les qualités qui, selon lui, pourraient faire la différence dans la productivité des développeurs.

Les capacités de développement : implémenter une partie d’un programme

Une des limites les plus évidentes, ou forces, d'un développeur s’observe durant l’implémentation d'une partie d'un programme : une fonction, un algorithme ou autre. Étonnamment, la capacité d'utiliser des constructions impératives de programmation de base très efficacement afin de mettre en œuvre quelque chose n’est pas aussi répandue que l’on pourrait le penser, d’après son expérience. Il explique que dans une équipe, il a parfois observé des programmeurs très incompétents, qui n'étaient même pas au courant de l’existence d'un simple algorithme de tri, fournir plus de travail que des programmeurs diplômés qui étaient extrêmement compétents en théorie, mais très pauvres en pratique et en implémentation de solutions.

L’expérience: correspondance de modèles

Par expérience, il entend l'ensemble de solutions déjà explorées pour un certain nombre de tâches récurrentes. Un développeur expérimenté sait éventuellement comment faire face à une variété de sous-tâches. Cela évite à la fois beaucoup de travail de conception, mais surtout, constitue une arme extrêmement puissante face aux erreurs de conception, qui font partie des plus grands ennemis de la simplicité.

Concentration : temps réel VS temps hypothétique

Le nombre d'heures passées à écrire du code n’a pas de sens s’il n’est pas associé à la qualité du temps. Le manque de concentration peut être généré par des facteurs internes et externes. Les facteurs internes sont la procrastination, le manque d'intérêt dans le projet à portée de main (vous ne pouvez pas bien faire des choses que vous n'aimez pas), le manque d'exercice / bien-être, un manque de sommeil. Les facteurs externes sont des réunions fréquentes, des environnements de travail sans bureaux réels, des collègues qui interrompent souvent, etc. Il semble naturel que le fait d'essayer d'améliorer l'attention et de réduire les interruptions ait un effet non marginal sur la productivité de la programmation. Parfois, afin de se concentrer, des mesures extrêmes sont nécessaires. Par exemple, je ne lis que des e-mails de temps en temps et je ne réponds pas à la plupart d'entre eux.

Sacrifice du design : tuer 5 % pour obtenir 90 %

Il arrive que la complexité soit engendrée lorsqu'il n’y a pas de disposition à reconnaître qu'un objectif non fondamental d’un projet compte pour beaucoup dans la complexité d’un design. Ou alors rend difficile d’atteindre un objectif important. Il est très important pour un concepteur de reconnaître toutes les parties d'un design qui ne représentent pas des victoires faciles, c'est-à-dire, il n'y a pas de proportionnalité entre l'effort et les avantages. Un projet qui est exécuté afin de maximiser la production va se concentrer exactement sur les aspects qui comptent et qui peuvent être mis en œuvre dans un délai raisonnable. « Par exemple, lors de la conception de Disque, un courtier de messages, à un certain moment, j'ai réalisé qu'en fournissant un plus gros effort sur les commandes pour les messages, tous les autres aspects du projet pourraient être considérablement améliorés : la disponibilité, le langage de requête et l'interaction des clients, la simplicité et les performances ».

Simplicité 

Afin de comprendre ce qu'est la simplicité, il a estimé qu’il est utile de vérifier comment la complexité est souvent générée. « Je crois que les deux principaux facteurs de complexité sont la réticence à effectuer des sacrifices de conception et l'accumulation d'erreurs dans l'activité de conception ».

Si vous pensez au processus de conception, chaque fois qu'un mauvais chemin est emprunté, nous sommes de plus en plus loin de la solution optimale. Une erreur de conception initiale, entre de mauvaises mains, ne générera pas une refonte du même système, mais conduira à la conception d'une autre solution complexe pour faire face à l'erreur initiale. Le projet devient donc plus complexe et moins efficace à chaque étape fausse.

La façon dont la simplicité peut être obtenue est de raisonner en termes de petites « preuves de concept », de sorte qu'une grande quantité de designs simples puissent être explorés dans l'esprit du programmeur, afin de commencer à travailler à partir de quelque chose qui semble être la solution la plus viable et directe. Plus tard, l'expérience et les capacités personnelles de conception permettront d'améliorer la conception et de trouver des solutions sensées pour les sous-modèles qui doivent être résolus.

Cependant chaque fois qu'une solution complexe est nécessaire, il est important de raisonner longuement sur la façon dont la complexité peut être évitée, et ne continuer dans cette direction que si aucune meilleure possibilité n’est trouvée, même en considérant des alternatives complètement différentes.

Perfectionnisme, ou comment tuer votre productivité et biaiser vos conceptions 

Le perfectionnisme se décline en deux variantes : en tant que culture d'ingénierie consistant à atteindre la meilleure performance possible mesurable dans un programme, mais aussi en tant que trait de personnalité. « Dans les deux cas, je vois cela comme l'un des plus grands obstacles empêchant un développeur de livrer rapidement ». Le perfectionnisme et la peur des jugements externes peuvent influencer le design, ce qui va se traduire par de mauvais choix afin d'affiner un design uniquement en fonction de paramètres psychologiques ou trivialement mesurables. Dans de telles conditions, des éléments comme la robustesse, la simplicité, la capacité de livrer dans le temps ne sont souvent pas pris en compte.

Connaissances : quand la théorie vient à la rescousse 

Lorsque les développeurs font face à des tâches complexes, les connaissances sur les structures de données, les limites fondamentales de calcul, les algorithmes non triviaux qui conviennent très bien à la modélisation de certaines tâches vont avoir un impact sur la capacité à trouver un design approprié. Être un « super-expert de tout » n'est pas nécessaire, mais être au moins conscient d'une multitude de solutions possibles pour un problème l’est certainement.

Bas niveau : comprendre la machine 

Un certain nombre de problèmes dans les programmes, même en utilisant des langages de haut niveau, découlent de la mauvaise compréhension de la façon dont l'ordinateur va effectuer une tâche donnée. Cela peut même conduire à la nécessité de reconcevoir et de réimplémenter à nouveau à partir de zéro un projet parce qu'il ya un problème fondamental dans les outils ou les algorithmes utilisés. Une bonne compétence de C, la compréhension de la façon dont les processeurs fonctionnent et des idées claires sur la façon dont le noyau fonctionne et comment les appels système sont mis en œuvre, peuvent sauver des mauvaises surprises de dernière étape.

Compétences de débogage 

Il est très facile de fournir une énorme quantité de travail afin de trouver des bogues. Être bon dans le déchiffrement des états d’un bogue, associé à la capacité à le corriger par un ensemble rationnel d’étapes et également écrire un code qui est peu susceptible de contenir trop de bogues, peut avoir un grand effet sur l’efficacité d’un développeur.

Source : billet Antirez

Et vous ?

Partagez-vous son point de vue ?

Quels sont les points qui vous semblent les plus pertinents ?

Avez-vous d'autres éléments à rajouter dans la liste ?


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


 Poster une réponse

Avatar de Grimly Grimly - Membre averti https://www.developpez.com
le 01/03/2017 à 11:11
Avez-vous d'autres éléments à rajouter dans la liste ?
N'avez vous pas déjà entendu un "Manager" demander à un développeur de s'investir dans l'entreprise ?

Prenons un instant le point de vue du développeur et acceptons la proposition suivante :
Afin qu'il fasse évoluer significativement sa carrière, il sait que la démission est obligatoire.

L'investissement qui est demandé par la hiérarchie met en avant l'entreprise qui l'emploi.
Mais cet investissement n'est pas appliqué aux concurrents chez qui le développeur peut aller chercher ce nouvel emploi. Il aura donc été inutile.
Pire encore, l'investissement aura été contraire aux intérêts du concurrent et ce dernier peut le lui reprocher.
Le développeur, s'il s'investi, réduit sa capacité à trouver un emploi.
Donc si le développeur s'investi, il réduit sa capacité à faire évoluer sa carrière.

Finalement, un développeur qui s'investi est donc un développeur qui détruit sa carrière.

Pour qu'un développeur puisse devenir plus productif et s'investisse pour la même entreprise, il faut donc casser la première proposition que j'ai énoncé.

J'espère que les bonnes personnes (non pas les développeurs eux-même) auront compris ce message.
Avatar de NSKis NSKis - Membre émérite https://www.developpez.com
le 01/03/2017 à 12:52
En tout cas, une chose est sûre: Pour le Monsieur, la productivité n'est pas une priorité... Parce que lorsque l'on voit ses théories en mode "roman de gare en 12 tomes", nul doute que le Monsieur a beaucoup, vraiment beaucoup de temps libre!!!
Avatar de Nebulix Nebulix - Membre éprouvé https://www.developpez.com
le 01/03/2017 à 17:01
http://www.liberation.fr/planete/201...uleuse_1550815
Mais attention !
"Si vous pensez au processus de conception, chaque fois qu'un mauvais chemin est emprunté, nous sommes de plus en plus loin de la solution optimale."
Avatar de foetus foetus - Expert confirmé https://www.developpez.com
le 02/03/2017 à 1:17
Je suis entièrement d'accord sur le fait d'avoir une [grosse] culture (théorie - généraliste) + de l'expérience (éventuellement une spécialisation) permet d'avoir une vision large des outils/ des moyens de résolution d'un problème/ savoir où chercher en cas de problèmes.

Mais il y a des bémols
1) L'expérience: je ne sais pas si c'est l'expérience ou l'âge, mais les 2 chefs de projet que j'ai eu, se sont enfermés dedans. Alors, d'accord, ils maitrisaient leur sujet, l'application était robuste et correspondait à ce que le client demandait. Mais n'est-ce pas aussi pour se reposer sur leurs lauriers ?

2) Il n'y a pas que le résultat final: J'ai eu affaire à des chefs/ collègues non techniques et pour eux: application == truc final.
Or, il y a des notions qu'ils oublient: la conception (évidemment), le code source, la documentation (code ou autre), les tests (unitaire, de charges ... qui découlent d'une conception modulaire) et éventuellement les outils externes et la R&D.

Les outils externes: lorsque tu arrives dans une société et qu'il n'y a pas de git, de "ticketting" ou autres, il faut prendre le temps de les installer et le configurer.
La R&D: lorsque tu arrives sur un projet, dès fois il faut prendre le temps de [tester]/ [prendre la main sur] l'existant (bibliothèques, composants, code interne, outils, ...) et éventuellement en rechercher d'autres/ trouver des palliatifs

Et cela rejoint ce que le gars dit:
*) Perfectionnisme: on peut être aussi perfectionniste sur son code source (respecter des "coding styles"), sur la documentation (s'efforcer d'utiliser des ternes non techniques), ...
C'est un trait de personnalité, on perd du temps, mais ce n'est pas [forcément] négatif. La maintenance et l'évolution te diront merci.

*) Simplicité: [sujet à débat] On peut utiliser des bibliothèques qui vont tuer en partie la simplicité. Mais cela peut être bénéfique pour la productivité

*) Bas niveau: [sujet à débat] On peut utiliser des bibliothèques qui s'occupent de cela. Le problème peut arriver si les développeurs partent.
*) Bas niveau: C'est essentiellement pour des questions de performances/ optimisations. En règle générale, il faut juste quelques développeurs pour cela.

Et il manque aussi la prévision [sujet à débat].
On peut perdre du temps au début d'un projet à coder des "trucs" mais à les intégrer le plus rapidemment. Mais c'est seulement après plusieurs itérations qu'on saura si on a perdu du temps.
Exemple: une recherche avec des tries (arbres préfixes), mettre en place des caches entre ta base de données et ton application, ...
Avatar de kilroyFR kilroyFR - Membre actif https://www.developpez.com
le 02/03/2017 à 3:19
Alors par rapport a mon experience que je vis au quotidien (et ca s'est amplifié ces dernieres années ):
- LA SIMPLICITE (principes KISS) principalement

Par rapport a il y a quelques années, maintenant souvent nos dev passent leur temps a essayer de monter des mille feuilles logiciels - on lmeur a donné a certains le titre d'architecte logiciel alors ils pondent archi abracadabrantesques pour faire pas grand chose quand des solutions techniques simples feraient dans 99% des situations suffisament affaire (generalement en incorporant des composants pour faire joujou avec sans reel gain fonctionnel).

Au final du temps passé, des logiciels complexes pour rien; une maintenance complexifiée (plus de briques logicielles necessitent des gens polyvalent ce qui n'est pas toujours le cas (on a encore des gens dans ma boite qui ne font que de la BDD ou que des ihms dans certaines technos ciblées etc.), une maintenabilité toute relative (ex : pbs de compatibilité ascendante cassée).

L'apprentissage de langage ras les paquerettes au debut pour que le dev comprennent un peu ce qu'il est fait techniquement (ex: C plus pres de la machine) au lieu de langage evolué (C#, java) par exemple.
On a encore beaucoup de dev dans ma boite qui n'ont pas compris les principes de garbage collector, gestion memoire etc et on se retrouve sur des prods avec des logiciels qui te consomment 100% de CPU et en manque permanent de memoire (bref, ils travaillent a ressource infinies et pondent des algos sans se soucier de cet aspect ("on trouvera bien un outil qui nous regle ces pbs" (entendu - du veridique !).
La conception se limite souvent a faire appel a des classes C#/java, sous entendues "magiques", n'ayant a se soucier de rien (en theorie).
quand la realité les rattrape là c'est la misere.

On a quand meme un gars qui a claque +1000h pour creer un generateur de code en langage naturel (description des structures + fonctionnel sous forme de pseudo code en francais => generation structures et algorithmes correspondants en C++).
... avec du recul ecrire du code directement dans le langage cible aurait couté largement moins cher puisque generalement revoir le fonctionnel ne necessite pas de tout regenerer en automatique. Ou comment depenser 1000h pour pas grand chose; la moitié concerne le codage des tests unitaires (verifiant que le code generé est ok !).
Hallucinant. Officiellement le but etait de gagner en productivité... toujours pas demontré a ce jour et de tres loin (puisque le gars a un code "vivant" et fais du refactoring du generateur tres regulierement (au fur et a mesure de la decouverte de telle ou telle nouvelle librairie).
Et ca nous plombe enoremment de projets ces conneries.
Avatar de Aurelien Plazzotta Aurelien Plazzotta - Membre éclairé https://www.developpez.com
le 02/03/2017 à 9:48
Citation Envoyé par Nebulix Voir le message
"Si vous pensez au processus de conception, chaque fois qu'un mauvais chemin est emprunté, nous sommes de plus en plus loin de la solution optimale."
Ahah! Cela me fait penser à l'un des préceptes qu'Eric S. Raymond a écrit dans The Cathedral and the Bazaar, dans la sous-partie Programming Pearls je crois :
"Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong."

Traduction personnelle : Souvent, les solutions les plus frappantes et innovantes apparaissent lorsque vous réalisez que votre conception du problème était erronnée.

Dans la théorie, c'est fort mais dans la pratique, cela requiert de traiter avec un chef de projet rationnel qui comprend qu'il y a plus à perdre en temps, argent et énergie en refusant de revoir l'analyse et la conception qu'à y gagner en restant "la tête dans le guidon".
Ceux étant irrationnels sont faciles à identifier car lorsque vous leur proposez une amélioration qui peut faire gagner de l'argent à l'entreprise, ce dernier vous répond : "on a pas le temps".

à KilfroyFR:
Cela me fait penser aux études francophones qui traînent régulièrement sur le net concernant l'industrie du génie logiciel : 45% des fonctionnalités développées (comprendre réclamées dans le cahier des charges), ne sont jamais employées.

De tout temps, des budgets inutiles permettent d'identifier ceux qui font illusion pour conserver leur contrat de travail.

PS:
Tapez l'innovation quand on a pas le temps dans la rubrique /Images d'un moteur de recherche
Avatar de azstar azstar - Membre émérite https://www.developpez.com
le 02/03/2017 à 15:16
Par fois l'architecture des codes ne joue pas en faveur du développeur, et par fois cette architecture date de 5 ou même par fois 10 ans.
Oui faut coder de la façon que les autres pour garder un code lisible de la même manière, mais par fois elle tue la productivité.
Par exemple dans de mes missions pour créer un Web service pour un simple accès à la base de données, il m fallait que créer 2 classes entites 2 classe BLL et 2 classes DAL et un interface et classe pour le Web service.
Avatar de petitours petitours - Membre confirmé https://www.developpez.com
le 09/03/2017 à 20:21
Bonjour

j'adhère à 100% sur le perfectionnisme, particulièrement pour les petites équipes ou indépendants qui s'auto-gèrent. Je connais quelqu'un qui y a laissé tous ses sous, sa maison et sa femme...

Sur l'expérience je partage les doutes de foetus en pire. Certes l'expérience va permettre de définir plus vite le champ du possible, de résoudre plus rapidement un problème rencontré mais si l'expérience empêche de bien poser le besoin et la route à suivre par empirisme ou "parce qu'on a déjà fait pareil" alors on s'expose à courir dans la mauvaise direction, voir ne pas répondre au besoin.

Sur le débuggage je ne suis pas certain de ce que je lis. Pour moi savoir débugger c'est important pour différencier un lapin de 3 semaines qui apprend et découvre de celui qui sait coder efficacement. Mais le très bon, celui qui sera productif, saura construire un code bug safe ou capable de remonter des erreurs clairement (et donc de réduire à presque rien le besoin en debuggage). Pour ma part je suis à peine sorti de la catégorie lapin de 3 semaines dans pas mal de langages mais depuis que je prends le temps de réfléchir avant de coder afin de produire du code un peu robuste j'ai décuplé ma productivité et j'ai notamment beaucoup moins à débugger. Je passe plus de temps à tester différentes situations gérées (normales ou anormales) plutôt qu'à débugger.

Finalement la productivité ça revient à bien définir le besoin (faire ni plus , ni moins) et emprunter la bonne route avec le minimum d'embuches.
Ça revient à "marcher dans la bonne direction plutôt que courir dans la mauvaise" ou encore "ne pas confondre vitesse et précipitation" ou encore ne pas mettre la charrue avant les bœufs" !
Avatar de petitours petitours - Membre confirmé https://www.developpez.com
le 09/03/2017 à 20:33
Citation Envoyé par Aurelien Plazzotta Voir le message
Ahah! Cela me fait penser à l'un des préceptes qu'Eric S. Raymond a écrit dans The Cathedral and the Bazaar, dans la sous-partie Programming Pearls je crois :
"Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong."

Traduction personnelle : Souvent, les solutions les plus frappantes et innovantes apparaissent lorsque vous réalisez que votre conception du problème était erronnée.

Dans la théorie, c'est fort mais dans la pratique, cela requiert de traiter avec un chef de projet rationnel qui comprend qu'il y a plus à perdre en temps, argent et énergie en refusant de revoir l'analyse et la conception qu'à y gagner en restant "la tête dans le guidon".
Ceux étant irrationnels sont faciles à identifier car lorsque vous leur proposez une amélioration qui peut faire gagner de l'argent à l'entreprise, ce dernier vous répond : "on a pas le temps".

à KilfroyFR:
Cela me fait penser aux études francophones qui traînent régulièrement sur le net concernant l'industrie du génie logiciel : 45% des fonctionnalités développées (comprendre réclamées dans le cahier des charges), ne sont jamais employées.
C'est une belle vision du développement d'entreprise et il est clair qu'il y a des manager meilleurs que d'autres...

Cependant le développement (au sens le code du développeur) n'intègre pas l'innovation il me semble. L'innovation c'est un autre processus amont, et ce même s'il y a itération et que l'on s'autorise en cours de développement de dire "stop, je viens de me vautrer ou je viens de penser à un truc vachement plus mieux!". Pour moi la phase de développement DOIT satisfaire un cahier des charges et y répondre précisément. S'il y a matière à innover, si on découvre un autre chemin, on doit reprendre le processus de développement sinon au final on fait comme je faisais il y a quelques années : un truc qui fonctionne au final sans savoir pourquoi et pourquoi faire.
Avatar de antalata antalata - Membre du Club https://www.developpez.com
le 10/03/2017 à 2:39
Ce qui se conçoit bien s'ennonce clairement et mes mots pour le dire arrivent aisément.

Autrement dit
- environnement calme
- explication claire
- motivation
- compétence
Offres d'emploi IT
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Architecte électronique de puissance expérimenté H/F
Safran - Ile de France - Villaroche - Réau

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