Comment devenir un programmeur «plus rapide»?

Ma dernière évaluation d’emploi ne portait que sur un point faible: la rapidité. Je suis déjà conscient de certaines choses que je peux faire pour améliorer cela, mais ce que je recherche, c’est d’autres.

Quelqu'un a-t-il des conseils ou des conseils sur ce qu'il doit faire pour augmenter la vitesse de production sans en sacrifier la qualité?

Comment estimez-vous les délais et les respectez-vous? Que faites-vous pour en faire plus dans des délais plus courts?

Tous les commentaires sont grandement appréciés, merci,

Éteignez l'ordinateur. Prenez un crayon et du papier. Esquisser votre conception. Examinez-le avec vos pairs. Ensuite, écrivez le code.

Quelques idées...

• Évitez le placage à l'or - faites seulement ce qui vous est demandé (en termes d'exigences)
• Comprendre les exigences de l'entreprise et le faire correctement dès la première fois
• Bien comprendre votre environnement et vos outils
• Devenez une dactylo fantastique, utilisez les raccourcis clavier au lieu de la souris
• Adoptez une approche itérative et intégrez des contrôles de cohérence pour vous assurer que vous êtes sur la bonne voie.
• Ne réinventez pas la roue, envisagez de réutiliser le travail du passé et celui des autres
• Éliminez les distractions, ne continuez pas à consulter vos courriels, à regarder à l'extérieur, à parler à vos collègues, etc.
• Ne surchargez pas vous-même - reconnaissez le moment où vous devez prendre des pauses

Votre désir d'être un programmeur "plus rapide" en lui-même est louable. Cependant, ne pas livrer à temps ne signifie pas que vous êtes lent, mais que le projet a été mal planifié. Être un programmeur "plus rapide" ne va pas aider; cela signifie simplement que vous dépasserez le délai plus rapidement.

Vous (et votre équipe) commettez l'une des erreurs suivantes (ou la totalité d'entre elles):

• sous - estimer le travail à accomplir;
• manque une grande exigence ou pièce d'architecture lors de la planification;
• confondre les estimations de travail avec les estimations de calendrier et ne pas prendre en compte des éléments tels que des réunions / téléphone / autres frais généraux

Il existe de nombreuses façons de s’adresser à l’une des trois réponses ci-dessus. Mais avant de pouvoir améliorer l'un d'entre eux, vous devez savoir pourquoi les choses vont comme elles sont. Faites un post mortem sur les estimations des deux ou trois derniers projets par rapport au temps réel et déterminez où le temps supplémentaire a été passé.

Je le répète: être lent à écrire du code ne vous fera pas manquer l'échéance , si vous l'avez bien planifié pour en tenir compte.

Vraiment, vraiment apprendre votre éditeur. Si vous utilisez un IDE, assurez-vous d’utiliser toutes les fonctionnalités qu’il offre. Obtenez une feuille de triche pour apprendre les raccourcis clavier pour votre éditeur de choix. Si vous utilisez un shell, configurez des raccourcis pour les répertoires couramment utilisés

"Quelqu'un a-t-il des conseils ou des conseils sur ce qu'il doit faire pour augmenter la vitesse de production sans sacrifier sa qualité?"

Beaucoup, beaucoup de gens aspirent à une qualité "ultime" au détriment de quelque chose qui est (a) simple, (b) fiable et (c) correct.

Le moyen le plus important d’accélérer votre développement est de simplifier ce que vous faites afin que ce soit aussi simple que possible.

La plupart des gens qui ont des problèmes de livraison à temps livrent beaucoup trop. Et les raisons données sont souvent ridicules. Ce ne sont souvent que des exigences perçues, pas des exigences réelles.

J'ai entendu beaucoup de gens me dire ce que le client "attend". C'est une mauvaise politique.

Construisez la chose la plus simple possible. Si le client a besoin de plus, construisez plus. Mais construisez d'abord la chose la plus simple possible.

Évitez de polir votre code à la perfection, faites-le simplement fonctionner. C'est ce que l'entreprise attend.

Mais souvent, augmenter la vitesse implique de sacrifier la qualité.

Réutilisation - J'essaie de prendre en compte tous les éléments intelligents de projets précédents afin de pouvoir les utiliser à nouveau dans de futures entreprises. Il vaut toujours la peine de se demander "pourrais-je l'utiliser à nouveau un jour?"

Rester simple.

Si vous utilisez TDD, vous devez suivre " red, green, refactor ":

1. Ecrivez un test qui a échoué (en rouge ). (Souvent, votre code n'a pas encore de fonctionnalité.)
2. Commettez des crimes de codage horribles pour faire passer vos tests ( vert ). Hardcode si nécessaire.
3. Refactor , probablement en train de briser les tests pendant un moment, mais en améliorant globalement la conception.

Téléchargez toute la documentation de vos langues / bibliothèques sur votre ordinateur, puis débranchez votre câble réseau / désactivez le Wi-Fi .

Ne pas essayer d'être drôle ici. Cela m'aide vraiment!

Notez que vous avez trop longtemps lu le débordement de pile. L'excuse "Compilation" ne fonctionne que pendant si longtemps. :)

Évitez de changer de tâche trop souvent. Les distractions et le changement de tâches peuvent être fatals, même si vous utilisez des outils comme Mylyn pour gérer vos tâches.

Déterminez une granularité (par exemple, 30 minutes) et ne travaillez que sur des tâches liées à la tâche à accomplir. Tout le reste (nouveaux rapports de bogues, courriels concernant d'autres problèmes, questions de procédure non liées) est retardé au moins jusqu'au "prochain point de contrôle". Assurez-vous de désactiver l'affichage des notifications par courrier électronique pour ne pas vous laisser entraîner.

C’est particulièrement efficace si vous avez un ami dans votre équipe qui vous laissera savoir si tout va vraiment mal et requiert votre attention immédiate.

Faites-le bien, la meilleure façon, la première fois. Si cela signifie que vous devez vous arrêter et y réfléchir pendant un moment avant de commencer, alors agissez. Fonctionne 90% du temps.

Apprenez à taper le plus rapidement possible .

Je le fais demain .

Faire avancer les choses est également extrêmement utile.

De toute façon, ma capacité d'attention est courte, donc ces livres m'aident à rester concentré ... que faisais-je encore?

Pratique et travail acharné.

Vous devez consacrer du temps et des efforts. À mesure que vous devenez plus à l'aise et confiant avec les outils que vous utilisez, la vitesse et la créativité devraient suivre.

Si vous souhaitez améliorer une compétence particulière, il peut également être utile de concevoir des exercices qui vous permettront de travailler spécifiquement sur cela. Si votre lenteur est en phase de conception, essayez de trouver des problèmes de conception sur lesquels vous pourrez travailler en ligne. Refaire le même exercice vous permettra de le terminer plus rapidement et de pratiquer la vitesse. Personnellement , je aime les exercices de l' algorithme de TopCoder pour la pratique vitesse de programmation pure. Ils ont également des problèmes de conception, mais je ne les ai pas essayés.

Apprenez-en davantage sur The Zone, apprenez à vous y mettre et à reconnaître que vous n'y êtes pas.

Une fois que je suis "dans la zone", je suis extrêmement productif et le code coule de moi, souvent je peux obtenir un codage de 2 ou 3 jours en une journée. Mais je trouve qu'il est souvent difficile d'arriver à cet endroit, je me retrouve à tergiverser, à me laisser distraire par d'autres choses (Stack Overflow, par exemple).

Citation tirée de ce que vous pouvez faire pour vous mettre à la place

Connaissant bien votre IDE et votre framework. Devoir se tourner vers Google pour chaque petite chose prend du temps.

Emacs

Avant de commencer à développer:

• Déconnectez-vous de votre boîte aux lettres
• Désactiver tous les clients de messagerie instantanée
• Demandez poliment à vos pairs de vous laisser le temps de vous concentrer
• Bien sûr, arrêtez de surfer sur Internet

Chaque fois que vous êtes interrompu, vous ralentissez car il faut du temps à votre esprit pour reprendre ses esprits. J'ai entendu dire que pour chaque interruption, il fallait 5 à 10 minutes à l'esprit humain pour revenir au processus de pensée qu'il avait avant l'interruption. Avec autant de temps par interruption, il ne faut pas perdre beaucoup de temps toute la journée.

Les membres de notre entreprise ont en fait pris l'habitude de bloquer le temps qui leur était consacré, puis se sont déplacés dans une salle de conférence vide pendant quelques heures chaque jour.

Apprenez votre IDE de développement. Apprenez les touches de raccourci. Apprenez à moins utiliser la souris. Je trouve que cela me fait gagner beaucoup de temps.

Êtes-vous plus lent que vos collègues ou vos estimations sont-elles trop optimistes?

Pour produire des logiciels plus rapidement, j’ai trouvé que la meilleure chose à faire était d’apprendre le mieux possible votre API d’exécution. Ne tapez pas la logique de liste quand une extension LINQ fera l'affaire; ne créez pas un groupe d'auditeurs d'événements lorsque la liaison fonctionnera, etc.

En ce qui concerne l'estimation, cela vient avec l'expérience. Vous pouvez utiliser un logiciel d'estimation pour vous aider à déterminer de meilleures estimations.

Personnellement, j’ai trouvé avec les développeurs de niveau junior, prendre quelle que soit leur estimation initiale et le multiplier par 2, puis le doubler. Cela représentera tout l'apprentissage, les réunions, les pertes de temps, etc. Les développeurs de niveau supérieur ont tendance à travailler avec un facteur de 2 par rapport à leurs estimations.

Souvent, la question n'est pas de savoir si votre estimation était fausse. C'est votre estimation qui tient compte de toutes les bonnes choses? Donnez-vous vos estimations et vos échéances en termes d'effort de codage ou de temps calendaire? Pensez à tout le temps que vous passez dans la journée et à la quantité de temps réel, de codage productif par rapport aux réunions, à l’apprentissage, au débogage, etc.

Deux choses peuvent être impliquées, mais je n'ai pas encore vu parmi les réponses qui augmentent la productivité:

• Utilisez une sorte de scripts de construction et de déploiement. Compiler, déployer, redémarrer un serveur d'applications et ne pas perdre du temps à se concentrer, cela devrait être du genre à un clic.

• Avoir une sorte de contrôle de version. Avoir à coder sans pouvoir annuler un changement, c'est comme essayer de marcher sur des œufs

Quelques idées me viennent à l’esprit:

1. Obtenez d'autres avis sur vos estimations - Y a-t-il d'autres développeurs à qui vous pourriez demander quelque chose comme: "Hé, pensez-vous que vous pouvez obtenir ce type de fonctionnalité dans ce délai?" L'idée étant que la contribution d'autres personnes peut aider à la précision dans certains cas, car quelqu'un peut noter un tas de choses que vous avez manquées en faisant l'estimation.

2. Affinez vos compétences en matière d'estimation - Commencez par suivre votre estimation et expliquez pourquoi vous êtes indisponible: d'autres tâches ont-elles pour effet de ne pas respecter les délais? Est-ce que vous sous-estimez constamment à quel point quelque chose est compliqué? Donnez-vous un calendrier complet quand ce n'est pas pratique, par exemple, ce qui est demandé est suffisamment vague pour que la simple mise au point d'un prototype prenne des semaines et qu'il faille ensuite réévaluer ce qu'il reste à faire? Faire cela peut aider le plus à développer cette compétence, de sorte que si vous dites quelque chose va prendre x heures, vous pouvez avoir confiance en cela parce que vous l'avez fait encore et encore, encore et encore. Une autre façon d’énoncer ceci est simplement pratique, pratique, pratique.

Certes, vous avez probablement déjà pris en compte ces éléments, mais j’ai pensé qu’il valait la peine de le mentionner pour ceux qui n’en ont peut-être pas tenu compte.

1. Connaître la technologie à l'intérieur et à l'extérieur
2. Arrêtez! Pense! Aller!
3. Architecte pour tout ce qui peut survenir, mais ne mettez en œuvre que ce qui est demandé.
4. KISS - Keep It Simple Stupid
5. Si cela devient trop complexe, probablement, ce n'est pas bien pensé. (Retournez aux 2 et 4)
6. Ne restez pas coincé dans le 5. Il est souvent payant de recommencer à zéro (Retournez aux points 2 et 4)
7. Retournez à 1.

Je pense qu'ils sont le mot clé ici est "opportunité". Ils n'ont pas dit que vous étiez trop lent, mais plutôt que vous n'étiez pas au bon moment.

En gestion de projet, il est important que le responsable puisse estimer avec précision le moment où vos tâches seront complètes. Je suppose que la raison principale pour laquelle vos efforts n'ont pas été jugés opportuns est que vous avez souvent eu des articles qui n'ont pas été livrés à la date prévue et qui ont été livrés beaucoup plus tard que prévu.

Pour améliorer votre rapidité d'exécution, vous voudrez peut-être consacrer plus de temps à comprendre le temps qu'il vous faudra pour terminer un travail en particulier, en fonction de vos compétences, de votre expérience et du domaine. Cela vous permettra de donner de meilleures estimations à votre chef de projet. La clé ici est "mieux" ... vous pouvez livrer à temps plus fréquemment en complétant tout avec un facteur de fudge, mais ce que vous voulez vraiment, c'est obtenir une estimation plus précise.

J'en discuterais avec votre responsable pour voir si tel est le problème. Sinon, vous risquez de finir par programmer deux fois plus vite, de faire des promesses deux fois plus vite et d’être critiqué pour votre ponctualité, car vos estimations auront toujours le même facteur d’erreur.

Restez stable, restez stable.

Construisez quelque chose qui implémente un petit peu de la fonctionnalité et assurez-vous que cela fonctionne de bout en bout. Ensuite, laissez-le fonctionner lorsque vous ajoutez de nouvelles fonctionnalités. Oui, c'est en partie une pratique de TDD, mais c'est logique même si vous ne faites pas de TDD.

La raison en est que chaque fois que je vois une personne avec 2 semaines de code qui n’a jamais été stable, il faut toujours 2 semaines supplémentaires pour que cela devienne stable.

Si vous restez stable, vous supprimez cette incertitude et vous vous donnez également la possibilité de vous rapprocher, si nécessaire.

Le contre-argument évident est que cela prendra plus de temps que de l'écrire une seule fois, car vous devrez faire un travail supplémentaire pour stabiliser le code non final. Je ne l'achète pas une seconde. Lorsque vous avez un code qui fonctionne , vous changez 5 lignes et quelque chose se casse, vous savez exactement où la rupture doit s'être produite.

Si vous avez 10 000 lignes de code qui n'ont jamais fonctionné et que vous devez trouver une rupture, vous avez une tonne de code à parcourir.

Petits changements incrémentiels sur un système toujours stable FTW. Allez lentement pour aller vite.

Pour moi, obtenir une bonne productivité, c'est avoir une idée claire de ce que vous essayez d'atteindre et de la façon dont vous allez y arriver.

Presque toutes les réponses ont été dites à mort dans de nombreux endroits ici et ailleurs. Ou du moins je l'ai entendu à mort. Apprenez votre IDE, apprenez à taper plus vite, utilisez des frameworks, utilisez une génération de code, etc. Mais étant le type de programmeur qui pose ces questions et fréquente des sites tels que Stack Overflow, vous connaissez déjà ces choses. . Vouliez-vous simplement ici les répéter ou voulez-vous simplement vous défouler un peu?

Mais si nous pouvions arriver à cet état? Je veux dire maîtriser toutes ces suggestions? Que se passerait-il alors? Bien. J'imagine que les délais seront encore plus courts. Et encore une fois, nous allons revenir à une perception de qualité. Je veux dire, notre métier a définitivement progressé et est devenu de plus en plus productif au fil des décennies. Mais la qualité a-t-elle augmenté pendant cette période (en excluant les toutes premières années de cours)?

Ma réponse est simple: un logiciel de qualité prend du temps ! Vous ne pouvez échanger l’un contre l’autre (qualité / vitesse). Mais oui, nous savons tous que, toutefois, nous ne sommes pas honnêtes sur le degré auquel ce compromis finit souvent par atteindre la vitesse maximale. Et nous sommes encore plus grands menteurs dès le début des projets!

Je dis que vous n'êtes pas en faute ici. Le problème réside dans la perception qu'ont les gens de la durée d'un logiciel de qualité. Nous nous leurrons de croire que nous sommes capables de créer un logiciel de qualité avec les types de chronologie que nos gestionnaires ou même nous estimons. Nous ne fabriquons pas de logiciel de qualité . Nous écrivons des logiciels qui fonctionnent, mais parfois avec des flashs de qualité dans certains coins d’une application.

Alors, que pouvons-nous faire à ce sujet? Nous ne pouvons pas simplement convaincre nos chefs que nous devons doubler ou tripler les investissements dans chacun de nos projets. Je dis donner l'exemple. Créez un logiciel vraiment génial en tant que projet parallèle. Mettez votre temps à l'intérieur et ne faites pas de compromis. Pendant tout ce temps, faites attention à vos progrès. Prenez note des tâches apparemment sans rapport avec lesquelles vous avez dû consacrer un temps inattendu et voyez si vous pouvez le justifier. Comparez cela avec tous les autres projets que vous avez réalisés. Être brutalement honnêteavec vous-même et tous les aspects de cette analyse. Les extras que vous avez réalisés avec votre logiciel de qualité peuvent-ils être négligés dans les "vrais" projets au travail? Mais peut-être que votre tentative a échoué. Quelle était la raison? Vous êtes-vous ennuyé et vous êtes-vous précipité pour obtenir les fonctionnalités de base? Je n’ai pas encore fait quelque chose comme cela moi-même, c’est pourquoi je termine cette pensée avec un doute - mais j’ai l’intention de tenter le coup. Je te tiendrai au courant :).

Enfin, je pense que la plupart (sinon toutes) les évaluations de performance sont déformées et extrêmement manipulatrices. Vous ne pouvez pas limiter la qualité et la vitesse à 100%. Votre patron devrait vous marquer par rapport à une norme définie par l'organisation. La norme de l'organisation sur le compromis entre qualité et rapidité. Imaginons qu'OrangeSoft Inc. attend 33% de qualité et 66% de vitesse. Donc, si vous écrivez du code qui comporte peut-être un tiers des tests unitaires, vous devriez le faire, mais en le rattrapant avec rapidité et délai de livraison réduit, vous devriez obtenir un score proche de 100% sur votre commentaire! (Ce sont des analogies assez approximatives mais vous comprenez le point). Mais au lieu de cela, ce qui se passe, c’est que Bob écrit du code extrêmement rapidement mais qui est notoirement buggé. Ainsi, lors de son évaluation des performances, il marquera 3/5 pour la qualité et 5/5 pour la vitesse. Par contre, Carol écrit le code beaucoup plus lentement mais produit beaucoup moins de bugs. Elle marque 5/5 pour la qualité mais 3/5 pour la vitesse. De toute façon, Bob et Carol sont immobilisés sur leur augmentation. Est-il possible pour un employé d'obtenir un score parfait? Est-ce juste?

La technique que j'utilise est le prototypage évolutif

Vous pouvez rechercher plus d’informations sur Google, mais si le besoin est de produire quelque chose rapidement, c’est à peu près tout. De plus, il a l'avantage que lorsque les utilisateurs disent qu'il aime ça, vous avez terminé (... et pouvez commencer à faire la documentation).