Comment coder plus rapidement (sans sacrifier la qualité) [fermé]

Je suis un codeur professionnel depuis plusieurs années. Les commentaires à propos de mon code sont généralement les mêmes: écrit un excellent code, bien testé, mais pourrait être plus rapide .

Alors, comment puis-je devenir un codeur plus rapide, sans sacrifier la qualité? Pour les besoins de cette question, je vais limiter la portée à C #, car c’est principalement ce que je code (pour le plaisir) - ou Java, qui est assez similaire à bien des égards qui comptent.

Les choses que je fais déjà:

• Ecrire la solution minimale qui fera le travail
• Écrire une série de tests automatisés (éviter les régressions)
• Écrire (et utiliser) des bibliothèques réutilisables pour toutes sortes de choses
• Utiliser des technologies connues où elles fonctionnent bien (par exemple, Hibernate)
• Utilisez des modèles de conception là où ils s’insèrent (par exemple, Singleton)

Ce sont tous très bien, mais je ne pense pas que ma vitesse augmente avec le temps. Je m'en fiche, car si je peux faire quelque chose pour augmenter ma productivité (même de 10%), c'est 10% plus vite que mes concurrents. (Pas que j'en ai.)

De plus, mes gestionnaires m'ont toujours offert ce retour sur investissement, qu'il s'agisse d'un développement Flash à petite échelle ou d'un développement Java / C ++ d'entreprise.

Edit: Il semble y avoir beaucoup de questions sur ce que je veux dire par rapide, et comment je sais que je suis lent. Permettez-moi de préciser avec quelques détails supplémentaires.

J'ai travaillé dans des équipes de petite et moyenne taille (5 à 50 personnes) dans différentes entreprises sur différents projets et technologies (Flash, ASP.NET, Java, C ++). L'observation de mes gestionnaires (qu'ils m'ont dit directement) est que je suis "lent".

Cela tient en partie au fait qu’un nombre important de mes pairs ont sacrifié la qualité au profit de la vitesse; ils ont écrit un code qui était bogué, difficile à lire, difficile à maintenir et difficile à écrire pour des tests automatisés. Mon code est généralement bien documenté, lisible et testable.

Chez Oracle, je résolvais systématiquement les bugs plus lentement que les autres membres de l'équipe. Je le sais parce que j'aurais des commentaires à ce sujet. cela signifie que d'autres développeurs (oui, plus expérimentés et plus expérimentés) pourraient faire mon travail en moins de temps qu'il ne m'a fallu, à peu près de la même qualité (lisibilité, maintenabilité et testabilité).

Pourquoi? Qu'est-ce que je rate? Comment puis-je m'améliorer à cela?

Mon objectif final est simple: si je peux fabriquer le produit X en 40 heures aujourd'hui et que je peux m'améliorer quelque part pour pouvoir créer le même produit à 20, 30 ou même 38 heures demain, c'est ce que je veux savoir - Comment puis-je y arriver? Quel processus puis-je utiliser pour améliorer en permanence? J'avais pensé qu'il s'agissait de réutiliser du code, mais cela ne semble pas suffisant.

J'aime l'approche de Jeff Atwood à cet égard, qui peut être trouvée ici http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Il fait essentiellement référence à un passage du livre Art & Fear de David Bayles et Ted Orland. Le passage va:

Le professeur de céramique a annoncé le jour de l'ouverture qu'il divisait la classe en deux groupes. Tous ceux du côté gauche du studio, a-t-il dit, seraient classés uniquement en fonction de la quantité de travail produit, tous ceux de droite uniquement en fonction de la qualité. Sa procédure était simple: le dernier jour de classe, il apportait sa balance de salle de bain et pesait le travail du groupe "quantité": cinquante livres de pots notés "A", quarante livres par "B", etc. Ceux qui sont classés sur la "qualité", cependant, n'ont besoin de produire qu'un seul pot - même s'il est parfait - pour obtenir un "A". Et bien, le temps du classement est arrivé et un fait curieux a émergé: les œuvres de la plus haute qualité ont toutes été produites par le groupe classé en fonction de la quantité. Il semble que pendant que la "quantité"

Essentiellement, se salir les mains plus rapidement et plus souvent améliore vos compétences mieux que de passer votre temps à étudier et à théoriser sur la manière "parfaite" de le faire. Mon conseil, continuez à vous entraîner, suivez la technologie et étudiez le design.

Une possibilité que personne ne semble avoir mentionnée est que vous vous débrouillez bien et que vos gestionnaires ne sont pas très bons. Comment mesurent-ils la productivité? Peuvent-ils vous donner des exemples spécifiques ou s'agit-il simplement d'une perception générale? Ont-ils pris en compte le temps passé à réparer le travail d'autres personnes par rapport au vôtre?

J'ai vu beaucoup de gens se faire créditer pour avoir accompli des choses pendant que le reste de leur équipe répare le gâchis qu'ils ont laissé derrière eux.

La plupart de ce que les gens considèrent comme important n’est pas important. La vitesse de frappe n'est pas importante. Des machines ou des outils plus rapides ne sont pas importants. Nous ne sommes pas des dactylographes ou des opérateurs de machines. Nous sommes considérés comme des travailleurs. Nous sommes des décideurs .

Ce qui est important en utilisant vos commentaires pour améliorer continuellement votre processus de décision. La seule façon de faire cela, comme d’acquérir toute autre compétence, est l’expérience, une pratique volontaire et une rétroaction continue.

• Travailler sur des projets parallèles.
• Travailler sur des projets open source.
• Travaillez avec des développeurs meilleurs que vous. Programme de paires!
• Exposez-vous à de nouveaux outils et techniques. Gardez ce qui fonctionne.
• Faites des exercices de programmation conçus pour former votre appareil décisionnel *.
• Surveillez vos améliorations en fonction de mesures objectives telles que le taux de défauts et la vitesse, ainsi que de mesures subjectives telles que la qualité du code et la forme physique.

Enfin, rappelez-vous que la vitesse sans qualité est inutile et vice versa. Pour maximiser votre utilité, trouvez un équilibre entre ces tensions.

* http://codekata.pragprog.com/

Il est fort possible qu'en réalité, on vous demande de sacrifier une qualité pour une vitesse supérieure.

Dans certains environnements de développement ¹ , il ne faut tout simplement pas plus de temps pour produire quelque chose de poli, quand "juste assez bon" fera l'affaire.

^{1 - Je pense en particulier aux "outils internes", mais il y en a probablement d'autres.}

On dirait que vous faites toutes les bonnes choses - qu’à moyen terme, cela vous rendra plus rapide, il n’est donc pas évident que vous soyez vraiment lent. Seulement tu le sais vraiment. (mais c'est une possibilité très réelle - PeopleWare revendique une différence de productivité jusqu'à 10 fois supérieure entre développeurs pour la même tâche).

J'ai donc quelques suggestions pour vous:

1. Le temps est une chose relative, alors le problème n’est peut-être pas votre vitesse réelle, mais plutôt la perception du temps que vous donnez. Vous pouvez en déduire que cela va prendre une semaine, mais finir par passer deux semaines, alors que d'autres passeraient peut-être trois semaines ... mais vous regardez juste une semaine plus lentement.

2. Comme vous recevez souvent ces commentaires, vous avez peut-être le temps de parler à votre supérieur hiérarchique et à vos pairs pour voir ce qu’ils disent.

3. Faites de la programmation en binôme avec un développeur "rapide" pour voir si vous pouvez distinguer la différence.

En réalité, il s’agit d’ expérience . Pour être plus rapide dans ce que vous faites, c'est comme conduire une voiture. Au départ, vous avez peur car les autres sont des conducteurs rapides (ou ivres) (ou les deux) et que vous souhaitez atteindre votre domicile en toute sécurité (en termes logiciels, vous voulez vous assurer que votre code fonctionne comme développé et cela fonctionne bien).

Au fil des ans et des mois, une fois que vous maîtrisez les routes et les autoroutes, vous apprendrez quelques astuces qui rendront votre conduite agréable. C'est ce que nous appelons l'expérience. Ces "astuces" (que j'appelle des traits) sont ce qui aide.

Dans mon cas, j’ai appris l’utilisation réelle des modèles de conception en codant (même @ home) et en apprenant les utilisations de certains. Ainsi, lorsque je rencontre un problème qui nécessite un modèle de conception, j’utilise l’expérience passée pour déterminer ceux qui ont fonctionné et pourquoi cela fonctionnerait-il / ne fonctionnerait-il pas dans ma situation?

En résumé:

• L'expérience crée des traits qui renforcent la confiance et un meilleur logiciel.

PS: L'expérience vient aussi d'apprendre des autres. Par exemple, aide de SO, programmation en binôme, évaluation par les pairs, etc. Vous ne pouvez pas avoir d'expérience si vous ne pouvez pas regarder en arrière et apprendre des erreurs (ou si quelqu'un ne conteste jamais vos efforts).

La question est de savoir si vous êtes moins cher en regardant le coût total à long terme.

En d’autres termes, vos corrections de bogues soigneusement conçues sont-elles d’une qualité telle (y compris les scénarios de test et la documentation) qu’elles dépassent les coûts liés à la maintenance des corrections de bogues effectuées par vos collègues les plus rapides?

Si oui, vous devez informer vos supérieurs de ce fait. Il peut être difficile d'argumenter s'ils ne mesurent pas et ne disposent pas des données nécessaires pour confirmer votre évaluation.

Si non, alors vous devez fortement considérer pourquoi c'est le cas:

• Êtes-vous trop inexpérimenté?
• Passez-vous beaucoup trop de temps à faire des choses non demandées qui, selon vous, devraient être là?
• Avez-vous de la difficulté à déterminer quand le correctif est terminé?
• Votre code est-il après tout de qualité inférieure à ce que vous pensez?
• Devriez-vous aborder le développement de code différemment, car il vous faut trop de temps pour accélérer le processus?
• Avez-vous passé trop de temps sur des choses comme ce site?

Réfléchissez-y et modifiez votre question avec vos conclusions.

Toutes les questions que les gens ont posées pour savoir si vous êtes vraiment lent ou non sont stupides. Devenir un programmeur plus rapide sans sacrifier la qualité est toujours un bon objectif, que vous soyez déjà lent ou rapide. Ceci est mon objectif numéro 1 en tant que programmeur et je ne le ferai jamais. J'essaie toujours d'aller plus vite sans sacrifier la qualité, j'en suis obsédé. Voici ce qui a fonctionné pour moi jusqu'à présent dans l'ordre de l'utilité, avec quelques idées expérimentales à la fin:

1) N'arrêtez jamais d'apprendre: apprenez tout ce que vous pouvez sur la programmation et l'utilisation des ordinateurs en général. Trouvez les domaines dans lesquels vous êtes faible et apprenez-les. Même si cela semble totalement indépendant de votre travail et de C #, je vous garantis que si vous le recherchez, vous trouverez souvent le moyen de l’appliquer à ce que vous faites. Apprendre, c’est aussi une question d’expérience. Ne vous contentez pas de lire des textes, essayez-les et développez vos compétences. Si vous utilisez Windows, essayez Unix ou inversement. Si vous préférez utiliser les outils de ligne de commande et les éditeurs de texte de IDE, ou inversement. Si vous entendez parler d'un outil ou d'une technologie dont vous n'avez pas entendu parler auparavant ou dont vous ne connaissez pas grand chose, ne cédez pas à la tentation de passer à autre chose. Cherchez-le! N'ayez pas peur de sortir des sentiers battus et d'apprendre de nouvelles technologies expérimentales qui, selon d'autres, ne sont pas pratiques.

2) Casser des projets: essayez de diviser vos projets en mini-projets. Essayez de faire une nouvelle version tous les jours ou une fois tous les deux jours au plus. Demandez-vous "Quelle est la quantité minimale de fonctionnalités que je peux libérer et publiez-vous quelque chose qui soit utile à l'utilisateur." C'est une compétence que vous apprendrez en le faisant. Vous devrez peut-être convaincre vos responsables de vous laisser faire, mais ils seront généralement satisfaits des résultats assez rapidement. En faisant cela, vous remarquerez que les éléments que vous pensiez essentiels à votre fonctionnalité sont en réalité des fonctionnalités supplémentaires pouvant être développées ultérieurement. Cela vous permet, à vous et à vos responsables, de hiérarchiser uniquement les fonctionnalités les plus importantes au lieu de toutes les fonctionnalités liées à celle sur laquelle vous travaillez. Cela vous permet de penser plus rapidement en gardant votre esprit clair et concentré. À votre tour, vous programmez légitimement plus rapidement. Vos gestionnaires, ou du moins vos gestionnaires, sont également susceptibles de percevoir que vous programmez maintenant encore plus vite que vous ne le êtes réellement, car vous diffusez davantage de communiqués. Un autre avantage énorme de cela est que vous serez beaucoup mieux en mesure d'estimer le temps que prendront les publications, et vos gestionnaires vous aimeront pour cela. Étant donné que vous effectuez déjà de nombreux tests automatisés, vous ne devriez pas rencontrer de problèmes pour effectuer des versions fréquentes et stables. Cependant, vous devrez peut-être renforcer votre système de construction automatisé. Je recommande fortement de lire le livre Continuous Delivery dans la série Martin Fowler. C'est une lecture difficile et extrêmement répétitive, mais toujours très utile. Les gestionnaires s sont également susceptibles de percevoir que vous programmez maintenant encore plus vite que vous ne l’êtes réellement parce que vous publiez plus de communiqués. Un autre avantage énorme de cela est que vous serez beaucoup mieux en mesure d'estimer le temps que prendront les publications, et vos gestionnaires vous aimeront pour cela. Étant donné que vous effectuez déjà de nombreux tests automatisés, vous ne devriez pas rencontrer de problèmes pour effectuer des versions fréquentes et stables. Cependant, vous devrez peut-être renforcer votre système de construction automatisé. Je recommande fortement de lire le livre Continuous Delivery dans la série Martin Fowler. C'est une lecture difficile et extrêmement répétitive, mais toujours très utile. Les gestionnaires s sont également susceptibles de percevoir que vous programmez maintenant encore plus vite que vous ne l’êtes réellement parce que vous publiez plus de communiqués. Un autre avantage énorme de cela est que vous serez beaucoup mieux en mesure d'estimer le temps que prendront les publications, et vos gestionnaires vous aimeront pour cela. Étant donné que vous effectuez déjà de nombreux tests automatisés, vous ne devriez pas rencontrer de problèmes pour effectuer des versions fréquentes et stables. Cependant, vous devrez peut-être renforcer votre système de construction automatisé. Je recommande fortement de lire le livre Continuous Delivery dans la série Martin Fowler. C'est une lecture difficile et extrêmement répétitive, mais toujours très utile. et vos gestionnaires vont vous aimer pour cela. Étant donné que vous effectuez déjà de nombreux tests automatisés, vous ne devriez pas rencontrer de problèmes pour effectuer des versions fréquentes et stables. Cependant, vous devrez peut-être renforcer votre système de construction automatisé. Je recommande fortement de lire le livre Continuous Delivery dans la série Martin Fowler. C'est une lecture difficile et extrêmement répétitive, mais toujours très utile. et vos gestionnaires vont vous aimer pour cela. Étant donné que vous effectuez déjà de nombreux tests automatisés, vous ne devriez pas rencontrer de problèmes pour effectuer des versions fréquentes et stables. Cependant, vous devrez peut-être renforcer votre système de construction automatisé. Je recommande fortement de lire le livre Continuous Delivery dans la série Martin Fowler. C'est une lecture difficile et extrêmement répétitive, mais toujours très utile.

3) Utilisez la technique pomodoro et adaptez / modifiez ce qui ne fonctionne pas pour vous. Si vous combinez cela avec le numéro 2 de cette liste, vous obtiendrez une énorme productivité.

4) Apprenez Vim. Même si vous finissez par utiliser ces commandes dans Visual Studio via ViEmu, ou à partir d’Eclipse via un plug-in, ou à partir d’Emacs, vous gagnerez en productivité. La meilleure façon d'apprendre Vim est de commencer à l'utiliser et de vous forcer à ne jamais (le désactiver / revenir à vos anciens outils) jusqu'à ce que vous l'ayez maîtrisé. C’est douloureux au début, mais vous ne voudrez jamais revenir en arrière, et même vous faire grincer des dents lorsque vous devez travailler sans lui. Certains diront que cela n'augmentera pas beaucoup votre vitesse. Mais plus vite, plus vite, en particulier lorsque la lecture et la modification de code constituent CE QUE NOUS FAISONS, et je me suis retrouvé à économiser beaucoup de temps avec cela à l'occasion.

5) Ce dernier n'est pas nécessairement recommandé car je ne suis pas sûr que ce soit une bonne idée, et cela pourrait en fait diminuer votre productivité, mais je le ferai quand même. Vous pouvez essayer de faire plus de tests d'acceptation et moins de tests unitaires, ou peut-être au moins de vous assurer de faire des tests d'acceptation. J'ai eu du succès avec SpecFlow, mais je soupçonne qu'il y a quelque chose de mieux. Même rédiger les spécifications peut être assez technique, vous pouvez donc demander à votre responsable / client d’écrire une première version brouillon que vous modifiez de manière significative, ou vous pouvez écrire le texte entier vous-même et simplement le lire et le confirmer. Cela vous aidera avec le numéro 2 de cette liste. De plus, les tests d'acceptation peuvent être plus pratiques et nécessitent moins de code que les tests unitaires. Cela ne veut pas dire qu'ils les remplacent, des outils différents pour des choses différentes.

6) Celui-ci est encore plus expérimental et controversé. Je ne l’ai pas fait moi-même, donc je ne peux pas le recommander avec précision. Apprendre et utiliser le système de méta-programmation de JetBrains. Utilisez-le pour créer des outils que votre responsable / client utilise pour créer lui-même le logiciel souhaité. Vous pourrez peut-être même arrêter de faire des tests d'unité et d'acceptation si vous pouvez utiliser ceci pour créer des outils que votre responsable / client utilise pour spécifier le comportement de manière très simple et non compliquée. L'idée n'est pas de se débarrasser du programmeur. Les programmeurs auraient toujours besoin d'ajouter de nouvelles fonctionnalités à ces outils utilisés par le client / responsable chaque fois qu'ils (les personnes, pas les outils) ne peuvent pas facilement créer certaines fonctionnalités souhaitées. Je pense que MPS ou d’autres outils similaires sont la voie de l’avenir.

Utilisez votre cerveau plus et faites moins de tests. Pour être honnête, le test a sa place, mais c’est cher.

Lisez également The Art of Unix Programming (gratuit en ligne, le livre vaut son prix)

Enfin, vous ne pouvez pas être au bon endroit. Cheville ronde dans un travail carré, etc.

En fin de compte, c'est comme à l'école: "Créer ce que veut l'enseignant" devient "Créer ce que la direction demande et paye".

Si vous prenez un projet long et fini et obtenez le nombre de lignes de code "finales" par heure-homme, vous constaterez que les programmeurs codent BEAUCOUP plus lentement que vous ne l'auriez imaginé.

Nous ne parlons que quelques lignes de code par jour. Le reste du temps, vous passez au débogage, à la réécriture et à la programmation générale.

Vous avez peut-être entendu le vieil adage - si vous détectez une erreur pendant que vous la saisissez, vous gagnerez 10 fois plus de temps si vous la récupériez au moment de la création, ce qui est 10 fois supérieur à celui détecté lors de l'assurance qualité, qui est 10 fois supérieur. que de l'attraper après la libération ..

Alors, comment accélérez-vous? Je ne me concentrerais sur aucune forme de vitesse de frappe. Réduire les erreurs et améliorer les "futures interactions" avec votre code devrait constituer un meilleur investissement de votre temps.

Un code lisible et clair est essentiel. Vous écrivez votre code une fois, mais il sera lu des dizaines de fois. Écrire pour la lisibilité vous épargnera BEAUCOUP de problèmes en bout de ligne (ce qui vous fera également gagner beaucoup de temps). Si vous revenez JAMAIS lire votre code et que vous devez y réfléchir même une seconde, vous le faites mal.

La programmation en paires peut réduire le temps d'assurance qualité et, si vous considérez qu'un programmeur produit seulement quelques lignes par jour, si deux peuvent coder au même taux qu'une, mais avec moins d'erreurs, vous êtes donc BEAUCOUP en avance.

Le codage défensif (par exemple, la vérification des paramètres) peut réduire les problèmes ... Si vous avez un très bon analyste / architecte dans votre équipe, vous pouvez gagner du temps avec une bonne conception de départ.

Sinon, continuez à améliorer vos compétences en conception. Au fur et à mesure que vous gagnerez de l'expérience, vous serez plus en mesure de reconnaître des schémas qui ne fonctionneront pas et de les éviter, vous pourrez identifier les baisses de temps plus tôt, etc.

Avez-vous envisagé de faire une vérification détaillée de vous-même pendant que vous travaillez? Utilisez un stylo et un papier pour suivre votre emploi du temps ou utilisez quelque chose comme Rescue Time pour vous suivre.

Une fois que vous êtes plus conscient de la façon dont vous passez votre temps, vous pouvez avoir une meilleure idée de ce qui doit être amélioré et y concentrer vos efforts.

Idéalement, vous pouvez aussi demander à certains de vos collègues de le faire, de comparer vos résultats et d’obtenir des idées les uns des autres. Vous avez probablement des atouts dont ils pourraient bénéficier également.

Vous réalisez peut-être que vous passez trop de temps sur une partie de votre processus qui pourrait être automatisée ou simplement que vous avez beaucoup de distractions pendant une certaine journée et qu'une autre partie de la journée est calme, alors vous pouvez planifier vos tâches ça, etc.

Ou peut-être que vous découvrez que les tests prennent plus de temps que prévu et que vous devez repenser votre perception selon laquelle cela vous rend plus rapide.

Si rien d'autre ne vous donne des points de repère sur lesquels vous pouvez travailler.

De votre liste, vous vous en sortez bien.

Si vos collègues fabriquent du code avec un numéro CRAP plus élevé, ils iront plus vite. CRAP est une métrique au nom amusant qui combine complexité cyclomatique et couverture de test.

N'écrivez pas un code plus CRAP que nécessaire. ;)

Mon seul changement à vous suggérer est d'utiliser des bibliothèques, ne les écrivez que si:

1. Votre entreprise vend des bibliothèques
2. Vous avez refactored le code récurrent dans une bibliothèque

Vous lisez et faites et c'est génial. Mais vous pensez peut-être au code procuedural ou OO. Vous êtes-vous exposé à la programmation fonctionnelle (par exemple Haskell?) Et à Prolog?

Pour affiner votre technique de programmation OO, avez-vous joué avec Smalltalk / Squeak?

Et enfin, la théorie. Avez-vous au moins une compréhension rudimentaire de la théorie des graphes? (Certains programmes fonctionnent avec des arbres, des DAG ou simplement des graphiques simples à un moment donné. Les réseaux sont des graphiques)

Je vais citer oncle Bob :

La seule façon d'aller vite, c'est d'aller bien.

Chaque fois que vous tentez de négocier la qualité avec rapidité, vous ralentissez. À chaque fois.

- "La médiocrité véhémente", Robert C. Martin

Pour autant que je sache c'est:

1. bien
2. vite
3. pas cher

En tant que manager, vous pouvez en choisir 2.

Ne vous inquiétez pas des commentaires que vous avez formulés à propos de la vitesse. En tant que codeur, je préférerais conserver un code bien pensé et bien écrit plutôt que quelque chose de giflé.

Les principales choses auxquelles je peux penser sont les suivantes

• Augmentez votre vitesse de frappe.
• Utilisez des outils générant des gains de productivité. Par exemple, ReSharper.
• Machines ou outils plus rapides. Comme plus de RAM ou un lecteur à état solide.

Je suis sûr que vous pouvez également faire certaines choses dans le domaine des compétences en codage, mais il semble que vous soyez sur ce genre de choses. Les choses que j'ai énumérées ci-dessus sont généralement négligées par les développeurs.

Vous pouvez suivre un cours de dactylographie rapide. Je ne sais pas si la saisie plus rapide est un problème, mais "coder trop lentement" peut être provoqué simplement par une vitesse de frappe lente.

Qu'en est-il des générateurs de code? Parfois, le code devient répétitif. Le refactoring peut en supprimer une partie, mais même dans ce cas, vous pouvez avoir des appels répétitifs à la même fonction refactorisée. Selon les données et le code avec lesquels vous travaillez, les générateurs de code (écrits dans Excel, Perl, Java, etc. ) peuvent vous faire gagner beaucoup de temps. Et l'utilisation d'outils générant du code pour le développement de l'interface utilisateur est généralement une évidence.

Et enfin, peut-être que les métriques sont fausses. Avez-vous pensé que vous codiez à la vitesse la plus rapide possible compte tenu de tout le reste, et que les délais sont trop courts, ce qui vous fait apparaître comme un codeur lent?

D'après les modifications apportées à votre question, il semble que vous pouvez choisir de suivre le chemin emprunté par certains de vos collègues et de combiner ensemble la solution la plus rapide qui fonctionnera - et que la documentation et le contrôle qualité soient damnés!

Ou bien ... acquérez plus d'expérience et exercez-vous dans un domaine spécifique afin de connaître si bien la base de code et l'API que vous pourrez coder les solutions pendant votre sommeil. Cela peut être fait mais nécessite plus de temps. Si les autres développeurs plus rapides que vous sont connus pour être plus expérimentés et expérimentés, il n’ya qu’une chose à faire: vous devez devenir plus expérimenté!

Je m'oppose à la vue "qualité sacrifiée pour la rapidité" d'OP.

Les codeurs professionnels (programmeurs) doivent satisfaire à 3
objectifs : 1) le code doit fonctionner comme prévu
2) la livraison doit avoir lieu en temps voulu
3) être de bonne qualité, documentée, etc.
4) autre, etc.

Je pense qu’on a reproché à OP d’être lent, probablement parce qu’Op n’a pas terminé à temps.

C'est un piège 22 difficile à contourner. Bien que vous manquiez peut-être encore d'expérience et que certaines connaissances soient déjà plus rapides que beaucoup d'autres, il est toutefois plus difficile à mesurer .

Personnellement, le mieux que vous puissiez faire à ce stade est de vous mesurer. Donnez-vous des commentaires sur votre façon de travailler. Peut-être que de simples changements dans vos habitudes de travail peuvent vous rendre plus productif.

J'ai trouvé que les mails rongeaient beaucoup plus que je ne le pensais, simplement à cause de l'interruption. Maintenant, je ne réponds aux mails que deux fois par jour et j'ai gagné près d'une heure de productivité certains jours. Essayez des méthodes comme pomodoro , je l’ai utilisée comme moyen de mesure. À intervalles réguliers (15 minutes), je notais ce que je faisais à ce moment-là. Cela m'a permis de voir comment mes journées étaient structurées et ce que je pouvais faire pour maximiser mon efficacité.

L'avantage de Squeak pour le codage rapide va bien au-delà de "perfectionner ses compétences en POO". Il y a une raison pour laquelle les interfaces graphiques modernes, ainsi que les IDE, ont été inventés sur Smalltalk, pour ne pas dire que JUNIT était un port de SUNIT pour Java, le terme "OOP" a été inventé pour décrire Smalltalk, etc., etc.

Il faut toujours utiliser le langage et l’environnement qui conviennent le mieux à ce que l’on espère accomplir, mais pour le prototypage général, au moins, je ferais mouche contre quoi que ce soit, à l’exception possible d’HyperCard, et même cela nécessiterait une analyse comparative effectivement plus rapide étant donné qu'il existe des installations de type hypercart dans Squeak.