+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 869
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 869
    Points : 63 209
    Points
    63 209

    Par défaut Quels sont les atouts qui permettraient de booster la productivité d'un développeur ?

    Quels sont les atouts qui permettraient de booster la productivité d'un développeur ?
    Un ingénieur s'appuie sur son expérience pour partager son point de vue

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    86
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2013
    Messages : 86
    Points : 420
    Points
    420
    Billets dans le blog
    1

    Par défaut

    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.

  3. #3
    Membre expérimenté
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    803
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2010
    Messages : 803
    Points : 1 632
    Points
    1 632

    Par défaut

    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!!!

  4. #4
    Membre éprouvé
    Profil pro
    Inscrit en
    avril 2004
    Messages
    647
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations forums :
    Inscription : avril 2004
    Messages : 647
    Points : 930
    Points
    930

    Par défaut Irrésistible

    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."
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  5. #5
    Expert confirmé
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    2 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 047
    Points : 4 510
    Points
    4 510

    Par défaut

    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, ...

  6. #6
    Membre averti
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 194
    Points : 305
    Points
    305

    Par défaut

    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.

  7. #7
    Membre éclairé
    Avatar de Aurelien Plazzotta
    Homme Profil pro
    UML/SQL/Python/Knowledge Management
    Inscrit en
    juillet 2006
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : UML/SQL/Python/Knowledge Management

    Informations forums :
    Inscription : juillet 2006
    Messages : 271
    Points : 879
    Points
    879

    Par défaut

    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
    Je porte l'épée brisée, et sépare les vrais rois des tyrans. Qui suis-je ?

  8. #8
    Membre émérite
    Avatar de azstar
    Homme Profil pro
    Consultant Senior BizTalk /.NET
    Inscrit en
    juillet 2008
    Messages
    1 196
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Consultant Senior BizTalk /.NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 1 196
    Points : 2 418
    Points
    2 418

    Par défaut

    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.

  9. #9
    Membre confirmé Avatar de petitours
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    février 2003
    Messages
    1 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : Industrie

    Informations forums :
    Inscription : février 2003
    Messages : 1 188
    Points : 570
    Points
    570

    Par défaut

    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" !
    Il y a 10 sortes de personnes dans le monde : ceux qui comprennent le binaire et les autres

  10. #10
    Membre confirmé Avatar de petitours
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    février 2003
    Messages
    1 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : Industrie

    Informations forums :
    Inscription : février 2003
    Messages : 1 188
    Points : 570
    Points
    570

    Par défaut

    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.
    Il y a 10 sortes de personnes dans le monde : ceux qui comprennent le binaire et les autres

  11. #11
    Membre du Club
    Inscrit en
    juillet 2009
    Messages
    60
    Détails du profil
    Informations forums :
    Inscription : juillet 2009
    Messages : 60
    Points : 55
    Points
    55

    Par défaut Simplicité

    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

  12. #12
    Candidat au Club
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    mai 2015
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Services à domicile

    Informations forums :
    Inscription : mai 2015
    Messages : 2
    Points : 2
    Points
    2

    Par défaut Les atouts qui sont bien souvent des faiblesses aujourdhui

    Pour de nombreux projets montés et développeurs rencontrés, j ai remarqué en effet que la procrastination est souvent au Rdv. Transformant ou construisant des développeurs qui sont plus des intégrateurs que des concepteurs de programmes c est à dire des développeurs finalement.
    Et ce qui amène à faire ce constat prend sa source dans des faiblesses acquises au sein des écoles et surtout des cursus universitaires de premier cycle. Peu de pratique, aucun apport en ce qui concerne les méthodes de travail ( prise de note, recherche d informations et de connaissances, gestion de la connaissance, reportant. ..) et un survol des fondamentaux tels que logique et algorithmique. Associé à cela une imagination assez pauvre qui semble également un invariant et vous avez la recette magique pour faire des projets qui traînent en longueur et dont aucun Sprint ne permet de vérifier l atteinte des objectifs sans repousser de manière récurrente les délais. Mais tout cela comme cultiver la capacité à avoir une vision globale des projets , se travaille et peut être améliorer pour devenir des atouts qu on aimerait pouvoir observer chez chaque développeurs.

  13. #13
    Membre habitué
    Homme Profil pro
    Développeur .NET
    Inscrit en
    mai 2014
    Messages
    137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : mai 2014
    Messages : 137
    Points : 189
    Points
    189

    Par défaut

    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...).

  14. #14
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 203
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 203
    Points : 11 969
    Points
    11 969

    Par défaut

    Citation Envoyé par Grimly Voir le message
    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.
    C'est discutable voire faux ou j'ai mal compris le commentaire...
    s'investir dans un poste dans une entreprise ça permet tout de même d'apprendre , d'acquérir des compétences , d'avoir une vision globale des chose ( mais là il ne suffit pas d'être le nez dans le guidon il faut prendre suffisamment de recul ).
    Faire le "minimum syndical" ça se conçoit le problème c'est que des développeurs de l'Europe de l'est ou du Maghreb ou de Bangalore sont autant capables

    c'est comme le soudeur qui va se dire "ah ben non je vais pas m'investir je ferai mieux ailleurs" donc en définitif s'il ne sait faire qu'un certain type de soudures ( mettons à l'arc ) il ne sera pas capable de faire des soudures au chalumeau et trouver d'autres opportunités de poste.
    Faut être un minimum professionnel..

    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.
    mmhhh citation très connue de Nicolas Boileau mais qui fait partie de mes favorites
    * Descartes: "je pense donc je suis"
    * Bob l'éponge : "je pense donc j'essuie"
    * l'infirmière : "je panse donc je suis"

  15. #15
    Membre averti
    Avatar de didier.cabale
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    août 2004
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : Conseil

    Informations forums :
    Inscription : août 2004
    Messages : 120
    Points : 330
    Points
    330

    Par défaut

    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

  16. #16
    Membre habitué
    Homme Profil pro
    Développeur .NET
    Inscrit en
    mai 2014
    Messages
    137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : mai 2014
    Messages : 137
    Points : 189
    Points
    189

    Par défaut

    la productivité d'un développeur ?

    euh..... le Taylorisme.

  17. #17
    Membre confirmé Avatar de petitours
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    février 2003
    Messages
    1 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : Industrie

    Informations forums :
    Inscription : février 2003
    Messages : 1 188
    Points : 570
    Points
    570

    Par défaut

    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.
    Il y a 10 sortes de personnes dans le monde : ceux qui comprennent le binaire et les autres

  18. #18
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    644
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 644
    Points : 2 291
    Points
    2 291

    Par défaut

    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'.

  19. #19
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 428
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 428
    Points : 7 140
    Points
    7 140

    Par défaut

    Un adepte de cette philosophie probablement
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

Discussions similaires

  1. Réponses: 8
    Dernier message: 24/11/2016, 16h33
  2. Quels sont les critères qui vous permettraient d’estimer si untel est un bon ou un piètre développeur ?
    Par Stéphane le calme dans le forum Débats sur le développement - Le Best Of
    Réponses: 31
    Dernier message: 10/09/2015, 12h04
  3. Quels sont les champs qui ont été modifiés?
    Par Michelk12 dans le forum ASP.NET
    Réponses: 1
    Dernier message: 09/12/2008, 11h11
  4. Quels sont les jobs qui payent le mieux ?
    Par ishikawa dans le forum Etudes
    Réponses: 13
    Dernier message: 27/04/2007, 10h59
  5. quels sont les checkbox qui sont cochés?
    Par debutant.informatique dans le forum JavaScript
    Réponses: 5
    Dernier message: 16/03/2006, 21h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo