L'utilisation de nouvelles techniques nuit-elle à la productivité? [fermé]

Il semble qu'au fur et à mesure que l'expérience avec l'ensemble spécifique d'outils avec lesquels vous devez travailler augmente, l'incitation à essayer de nouvelles choses s'affaiblit.

Quand j'étais nouveau dans ce travail de programmation, essayer de nouvelles choses, faire des recherches en ligne, m'a rendu plus productif, car j'ai souvent trouvé un moyen (ou une bibliothèque) qui rendait la tâche plus facile que le cadre de code déjà en place. Donc, utiliser quelque chose de nouveau - pour moi aussi bien que dans le contexte de la base de code donnée - m'a rendu plus productif.

Maintenant , je remarqué, qu'il ya des cas où de plus en plus, pour un problème donné, je sais qu'il ya probablement est une meilleure solution « là - bas », et de trouver il - sans doute - améliorer le code. Cependant, étant donné ma connaissance désormais intime de la base de code, il est de loin plus facile d'utiliser les outils sous-optimaux dont nous disposons et d'obtenir une solution (y compris des tests) que de trouver quelque chose de nouveau et "meilleur" et "d'améliorer" la base de code.

Il y a donc cette tension: «faites-le correctement» vs «faites le travail décemment ».

Est-ce quelque chose qui arrive à beaucoup de développeurs? Est-ce un problème spécifique connu? (Est-ce que c'est un vrai problème après tout?) Cela a-t-il vraiment à voir avec l'augmentation des niveaux d'expérience?

Oh, et notez: j'aime toujours mon travail et j'aime le garder. C'est juste que cela semble - toujours intéressant! - la partie recherche devient plus petite à mesure que j'apprends la base de code et les ensembles de problèmes auxquels nous sommes confrontés avec notre application.

Il est souvent risqué d'essayer de nouvelles choses. Nous avons parfois des ennuis parce que nous avons tendance à faire deux choses:

1. Surestimez l'utilité de la chose cool / nouveau / snazzy. Nous voyons un bon exemple, du code mis en ligne. Très cool, nous pensons. Très cool! Dans XI peut faire la tâche Y dix fois plus vite. C'est clairement supérieur. Nous ne voyons pas encore toutes les "inconnues inconnues". Nous n'avons pas été gênés par les problèmes que les vendeurs de la nouveauté omettent. Nous n'avons pas assez d'expertise dans le nouveau pour voir les mines terrestres attendre sur la route.

2. Sous-estimer l'utilité des outils / framework / logiciels / objets existants. Nous n'étions souvent pas là lorsque le système actuel a été initialement construit. Nous n'apprécions pas les compromis délicats qui ont été faits. Il est facile de jouer le quart-arrière du lundi matin sur un système existant, mais cela fonctionne . Son probablement obtenu beaucoup de bizarrerie en raison de compromis très spécifiques entre le maintien maintenable, le travail et les bonnes performances. Ouais, c'est bizarre. Peut-être plus important encore, l'équipe est un expert de l'étrangeté actuelle et sait comment contourner l'étrangeté. Ils connaissent les mines terrestres et les pièges et les pièges à éviter. En fait, c'est précisément parce que nous voyons toutes les verrues dans la façon actuelle de faire les choses que nous sommes même intéressés à jouer avec de nouvelles choses.

Mais ne pas essayer de nouvelles choses et agir trop conservateur est probablement encore plus dangereux. Bien sûr, nous devons faire preuve de prudence, mais si nous ne savons pas comment construire le meilleur piège à souris, nos concurrents un peu plus disposés à essayer quelque chose de nouveau viendront et expulseront les mégots! Agir de façon conservatrice et ne pas évoluer peut entraîner une fatalité inévitable, en particulier dans un marché concurrentiel.

Alors oui, nous devons équilibrer le maintien et l'expédition de la chose actuelle avec un certain niveau d'expérimentation ludique / éducative avec de nouvelles façons de résoudre les problèmes en gardant à l'esprit que beaucoup de ces nouvelles façons sont des impasses tandis que d'autres peuvent être payantes. IMO C'est une bonne raison pour laquelle de nombreuses entreprises ont 20% de temps pour jouer avec de nouvelles choses. Ils savent souvent qu'ils ne fonctionnent pas, mais bon nombre des idées qui sortent de 20% du temps deviennent des gangbusters. Sans le temps de jouer et d'expérimenter, vous pouvez facilement stagner en tant qu'entreprise et vraiment vous défoncer.

Ça arrive tout le temps . Je l'ai dit dans d'autres articles, mais la plupart du temps, vous n'êtes pas en train de développer un code élégant, vous êtes en train d'expédier un produit. En tant que tel, vous aurez du mal à trouver un gestionnaire qui est prêt à vous allouer des nheures pour réparer quelque chose qui n'est pas cassé et qui, en fin de compte, n'améliore pas vraiment l'expérience de l'utilisateur final. Vous aurez autant de mal à trouver un gestionnaire prêt à consacrer des nheures à la recherche (sans objectif final clair) autre que «il y a probablement quelque chose de mieux» que ce qui est fait.

Cela dit, s'il y a des goulots d'étranglement dans votre application que vous avez découvert en utilisant des outils de profilage et autres et que vous pouvez clairement quantifier l'amélioration de l'expérience utilisateur attendue que leur correction apporterait, alors vous devriez (assez facilement) avoir le temps de faire de la R&D travailler pour les optimiser en utilisant des techniques que vous pouvez trouver à partir de diverses sources.

Je pense qu'une partie de cela se résume à avoir de l'expérience et une connaissance plus approfondie de la façon de résoudre avec succès certains problèmes.

Lorsque vous êtes nouveau, tous les problèmes sont également nouveaux et vous devez rechercher comment les résoudre. Mais comme vous avez résolu le même type de problème à plusieurs reprises, le besoin de recherche diminue car vous connaissez une solution réussie à celui-ci.

Ensuite, vous avez seulement tendance à rechercher les nouveaux problèmes ou ceux où les anciens éprouvés ne fonctionnent plus (ayant été dépréciés) ou provoquent un problème de performances ou d'échec. Au fur et à mesure que vous commencez à comprendre un système complexe de manière plus approfondie, vous savez que vous n'avez pas le temps de façon réaliste d'utiliser de nouvelles techniques à chaque fois qu'elles surviennent et vous avez découvert par expérience que la plupart du temps la nouvelle technique ne vit pas jusqu'à son battage médiatique et crée plus de problèmes qu'il n'en résout. Vous devenez donc moins enclin à utiliser de nouveaux outils et techniques lorsque vous n'en avez pas réellement besoin pour résoudre le problème.

Mais moins enclin ne devrait pas signifier que vous arrêtez d'apprendre ou n'utilisez jamais une nouvelle technique, juste que vous êtes plus judicieux quant au moment approprié.

Voici quelques détails:

1. Il y a des délais : le programmeur doit au préalable disposer de tous les détails nécessaires sur les outils qu'il utilise. Lire un site Web, trouver quelque chose de nouveau et l'utiliser dans un environnement de production est un gros non. Vous n'avez tout simplement pas assez d'expérience avec l'outil, et plus important encore, vous n'avez tout simplement pas le temps nécessaire pour commencer à apprendre quelque chose de nouveau. Si vous voulez quelque chose de nouveau, apprenez-le six mois ou un an avant de l'utiliser.
2. Assurez-vous de bien le connaître avant de l'utiliser : un nouvel outil agréable peut être amusant à utiliser, mais rechercher des solutions et les utiliser sans les apprendre correctement peut être très mauvais. Vous n'avez tout simplement pas assez d'expérience avec cela. Si vous avez besoin de le rechercher sur Google pour le comprendre, cela signifie que vous ne le connaissez pas assez bien pour le réparer lorsqu'il casse la moitié du système.
3. Utiliser les nouveautés ne le fait pas correctement : les nouveautés ne sont pas une technologie éprouvée. L'année prochaine, la technologie a probablement complètement disparu, vous êtes la seule au monde à l'utiliser. Tout le monde a remarqué que cela ne fonctionne tout simplement pas. Il faut beaucoup de travail pour éviter la toute nouvelle solution miracle, mais cela en vaut la peine.
4. Concentrez-vous sur les techniques qui sont vos connaissances de base : chaque programmeur ne connaît qu'une petite partie de l'ensemble des connaissances en programmation disponibles dans le monde. La partie où le programmeur est suffisamment à l'aise pour l'utiliser est encore plus petite. La partie qui fonctionne réellement est encore plus petite. Utilisez uniquement les connaissances que vous avez correctement apprises et vous savez que cela fonctionne. Cela vous rend le programmeur plus rapide et donne un meilleur code.
5. Ne le modifiez pas à l'infini : un code parfait est un bon objectif, mais cela ne signifie pas que vous écrivez d'abord de la merde, puis que vous le modifiez à l'infini pour l'améliorer progressivement. Écrivez-le parfaitement la première fois en utilisant toutes les bonnes connaissances que vous avez. Faites-vous confiance. Ne faites pas confiance au monde. Personne d'autre ne sait exactement la même chose que vous. Leur opinion n'a pas d'importance. Vous êtes le programmeur, vous devez le faire fonctionner. Le monde ne peut pas le faire pour vous. Une fois que c'est fait, arrêtez. Ne le touchez pas tant que quelqu'un ne s'en est pas plaint.
6. Passez du temps à apprendre de nouvelles choses : tout le monde doit continuellement apprendre de nouvelles choses. Notre avenir en dépend. Il suffit de refuser de l'utiliser! Apprenez de nouvelles choses, mais ne l'utilisez pas tant que vous n'êtes pas sûr que cela fonctionne réellement. Vous aurez la chance de l'utiliser l'année prochaine, une fois que la technologie aura fait ses preuves. Ou vous l'avez juste oublié, comme tout le monde - il ne reste que les bonnes choses ...
7. Ne perdez pas les bonnes choses : une fois que vous avez construit avec succès de gros systèmes et corrigé tous les problèmes, et appris de bonnes techniques, la pire chose que vous puissiez faire est de simplement vider ces connaissances et de vous lancer dans quelque chose de nouveau. Vous savez déjà comment cela fonctionne, quels sont les problèmes et comment les résoudre. Le jeter n'est qu'une perte de temps.
8. Suivez les nouvelles technologies : l'un des nouveaux systèmes va réussir. Il a quelque chose de fondamentalement meilleur que toute autre chose sur le marché. Vous ne savez tout simplement pas laquelle est la solution miracle. Si vous ne le trouvez pas à temps, vos connaissances seront obsolètes. Le monde peut vous faire perdre toutes les bonnes choses en supprimant l'accès aux anciens systèmes.

Oui, je l'ai fait. Habituellement, vous devez faire une analyse des risques sur le temps qu'il faudra pour apprendre la nouvelle technique, et pouvez-vous récupérer et utiliser une technique plus ancienne au cas où la nouvelle technique ne répondrait pas aux attentes. Je préfère apprendre de nouvelles techniques quand je le peux mais quand la pression est forte et que je ne peux pas me permettre de passer du temps à essayer de nouvelles choses qui pourraient échouer, je m'en tiens à des méthodes éprouvées.

En général, je trouve que le meilleur moment pour apprendre de nouvelles techniques est au début d'un nouveau projet. Il n'y a généralement pas trop de pression et si vous trouvez quelque chose de nouveau qui fonctionne bien, vous pouvez facilement l'intégrer au reste du projet, à l'avenir. Le pire moment pour essayer d'apprendre de nouvelles choses est les dernières semaines effrénées avant un grand déploiement.

Oui, de nouvelles choses nuisent à la productivité

Oui bien sûr. Même dans le meilleur des cas, les nouvelles choses nécessitent du temps supplémentaire car elles ne sont pas familières. Cela peut souvent coûter beaucoup plus de temps.

Non, de nouvelles techniques peuvent améliorer la productivité

Toute nouvelle technique qui vous permet d'exprimer plus facilement une solution améliorera votre productivité. Cela peut être aussi simple que de passer de grandes if-elseifconditions à une table de répartition.

Oui, cela peut nuire à la productivité. On a demandé à mon ex de faire un travail de traitement de données ennuyeux une fois, alors elle a décidé qu'il serait préférable d'écrire un long programme pour traiter les données puis de l'exécuter - ce qui résoudrait le problème en quelques secondes.

Il lui a fallu une semaine pour l'écrire bien sûr, mais le problème a été résolu en quelques secondes après cela.

Je pense que la même chose s'applique à votre question: oui, vous pouvez augmenter votre productivité en apprenant de nouvelles choses, mais vous feriez mieux d'appliquer vos connaissances existantes à la tâche et, globalement, de la faire plus rapidement. Qui se soucie de trouver et d'apprendre une nouvelle bibliothèque, si vous pouvez écrire la vôtre en moins de temps.

N'oubliez pas non plus, souvent le faire décemment avec les outils existants est une meilleure solution que de mettre les nouveaux trucs dedans. Chaque fois que vous en ajoutez de nouveaux, vous augmentez la surface de maintenance qui est requise, ce qui à son tour ralentit tout le monde (et rendre votre code assez désordonné - je pense aux couches de «nouvelles» technologies qui sont passées dans l'héritage au fil du temps mais qui sont toujours dans notre code, ce qui rend les choses horribles. Avec le recul, il aurait été préférable d'utiliser simplement les anciennes méthodes C au lieu d'ajouter tout ce COM et tout ce VB et tout ce .NET et maintenant pelleter du HTML dedans aussi)