IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

89PARTAGES

8  1 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de 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.
6  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 23/03/2017 à 13:55
J'ai adoré cette réponse dans les commentaires du billet

There's another, more common way to be a 10x programmer: generate technical debt at a rate that requires ten other developers to clean up the mess. The real magic is that this feeds back on itself: you look more productive while producing garbage, and everyone else is less productive, because they're bogged down in your disaster. Management then directs more resources to you, and less to everyone else, since you're a '10x programmer' who is 'getting things done'.
5  0 
Avatar de footsteps
Membre actif https://www.developpez.com
Le 11/03/2017 à 13:25
Citation Envoyé par antalata Voir le message
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
- open space
- explications vaseuses
- démotivation
- compétenceS (15 langages à maîtriser, 36 frameworks etc...).
3  0 
Avatar de foetus
Expert éminent sénior 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, ...
2  0 
Avatar de kilroyFR
Membre éprouvé 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.
2  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 24/03/2017 à 11:12
Un adepte de cette philosophie probablement
2  0 
Avatar de Aurelien Plazzotta
Membre extrêmement actif 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
1  0 
Avatar de 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
1  0 
Avatar de didier.cabale
Membre confirmé https://www.developpez.com
Le 11/03/2017 à 21:48
Très bon article, car (d'après moi) tous les facteurs clés de compétence /faiblesse du développeur sont ici abordés
1  0 
Avatar de petitours
Membre chevronné https://www.developpez.com
Le 18/03/2017 à 14:05
Citation Envoyé par footsteps Voir le message

euh..... le Taylorisme.
Taylorisme au sens rémunérer au résultat oui certainement, pour le reste le Taylorisme ça marche avec ce que l'on peut faire faire aux robots. Pour le reste, plein d’imprévu, le taylorisme a depuis longtemps montré ses limites. Et puis le taylorisme c'est un mec qui bosse et 3 qui regardent ; la productivité est optimisée sur une base au potentiel nettement diminué en intégrant les non productifs. Donner aux gens des objectifs (et la carotte) et les laisser se débrouiller est non seulement plus épanouissant mais aussi d'un potentiel de productivité bien supérieur.
1  0