Qu'est-ce qui peut ralentir un développeur? [fermé]


12

Quelles choses ont tendance à ralentir un développeur?

Veuillez vous abstenir de publier des réponses qui:


@Mark Trapp: Hein?! Ce n'est pas un double du tout ...: -S
Tamara Wijsman

1
Si la question ne s'avère pas utile, je la supprimerai dans un proche avenir, les gens répertorient les distractions qui sont déjà couvertes par une autre question de ma part. J'ai donc tendance à chercher des choses sans distraction ... TheLQ et Bill sont de bons exemples de réponses.
Tamara Wijsman

Huh, l'URL a été déformée. Le doublon est Quelles distractions peuvent se produire pendant la programmation?

Choisi pour laisser la question ouverte parce qu'il s'agit de choses qui ne sont pas des distractions ...
Tamara Wijsman

11
Stackoverflow, SuperUser, Programmers ... oui, essentiellement des sites comme celui-ci :)
bedwyr

Réponses:


49

Oh celui-ci facile:

  1. Réunions
  2. Plus de réunions
  3. Réunions sur la dernière réunion
  4. Réunions pour préparer la prochaine réunion
  5. Élaboration d'une présentation PowerPoint pour une réunion
  6. Développer une présentation PowerPoint pour une réunion discutant des fonctionnalités qui n'ont pas été implémentées, ne devrait pas être implémenté, et pour une raison quelconque, ce gars des ventes va sauter partout. Je ne peux pas prédire quel document vous souhaitez afficher dans l'application en fonction de votre emplacement actuel sans connexion Internet ou accès à votre disque dur. Non vraiment, arrêtez de le demander aussi.

4
en bref: la gestion? ; o)
n1ckp

11
@ n1ck Non, non. Une bonne gestion peut accélérer un développeur. Une mauvaise planification des temps d'un programmeur (c'est-à-dire un aspect de la gestion) peut vraiment ralentir le développement.
fromages

3
ce qui me tue, c'est quand mon entreprise fait cela: réunions, plus de réunions, réunions sur la dernière réunion, réunion pour préparer, réunion pour discuter des raisons pour lesquelles nous ne pouvons rien accomplir. Pourquoi ne pouvons-nous rien accomplir? Vous avez quarante développeurs assis dans une pièce qui vous écoute !!
Mike M.

2
Veuillez noter que cette réponse correspondrait presque à une diapositive Powerpoint.

44

Même problème ici
pramodc84

1
Je m'achèterais un ordinateur portable dès que possible et j'y travaillerais si j'étais dans cette situation, en supposant que la société le lui permette.
Adam

Les ordinateurs lents ont tendance à être à l'origine d'une distraction. Chaque fois que le programmeur attend, il peut entrer en mode distraction et ne reviendra au programme que quelque temps plus tard.
edA-qa mort-ora-y

Ils ont remplacé mon ordinateur il y a quelques semaines. Il est moins puissant que celui de 4 ans qu'il remplace. Agréable.
MetalMikester


25

StackOverflow, programmers.stackexchange.com, etc. :)


4
Être en désaccord! StackOverflow aide à résoudre les problèmes, ce qui accélère le développement!
Wizard

3
Bêtise offensive. Pour chaque minute que j'ai «gaspillée» sur SO, cela m'a racheté 20.
MIA

11
+1. pas du tout offensant. SO est très bon pour la procrastination. C'est mon nouveau facebook. :)
back2dos

@ back2dos Veuillez ne pas comparer le caractère génial de SO avec le morceau de .. qui est facebook.
Adam


15

Toute tentative de suivre un processus qui n'est pas adapté à la tâche à accomplir.

Cela peut être toutes sortes de choses, mais les plus courantes que je vois incluent:

  • tester des méthodologies qui ne correspondent pas au code testé
  • des processus beaucoup plus agiles ou traditionnels que les produits livrables le justifient
  • directives destinées à un jeu d'outils différent du jeu d'outils sélectionné
  • des principes de conception qui ne correspondent pas aux besoins du projet
  • à l'aide d'un ensemble d'outils qui n'est pas adapté à la tâche

Toutes ces choses peuvent être extrêmement utiles sur certains projets ou dans certaines situations, mais certaines organisations essaient de tout faire dans un sens et cela conduit à une mauvaise intégration sur d'autres projets, ce qui est souvent une perte de productivité.


13

Politique

Par exemple: lorsque plusieurs personnes possèdent les exigences (ou pire, deux intérêts différents) et qu'elles apportent des modifications concurrentes et conflictuelles aux exigences pendant le développement.


9

Conversations des autres

et le bruit en général

De nombreuses réponses parlent de changement de contexte et de sortie de la zone, et le bruit, en particulier la conversation, est l'une de ces choses qui m'amène à cela.

Dans mon monde cubique, je suis entouré de bruit et de conversations de tous côtés. Une ligne plus loin, l'équipe mainframe tient constamment des réunions de planification dans la ligne du cube. Parfois, ils rencontrent des consultants dans un bureau le long du mur, ce qui a tendance à faire des sifflements, des cris et des rires bruyants et je dois aller les voir et leur demander de fermer leurs portes.

De l'autre côté, la table de conférence de l'équipe Web est de l'autre côté de mon mur de cube ouest, donc je fais partie de chaque réunion, que cela vous plaise ou non. Il y a aussi une imprimante de l'autre côté du mur du cube sud, et c'est toujours bon pour bavarder avec des gens qui traînent en attendant leurs impressions.

La réponse immédiate et évidente de " Vous ne pouvez pas simplement obtenir des écouteurs antibruit" n'aide pas quand vous voulez du silence.

Parfois, pour les revues de code, j'emmène ma pile de papiers dans la salle à manger (en dehors des heures de déjeuner, bien sûr), mais il y a une télévision qui est généralement criante. Je l'éteindrai si personne ne regarde. Sinon, je vais chercher un cube vide dans un autre département dans une autre partie du bâtiment.

Si vous voulez que vos programmeurs fassent le travail dont ils ont besoin, ce qui est principalement de réfléchir, de réfléchir et de réfléchir, ils ont besoin d'un environnement où ils peuvent le faire.


Parfois, ça devient trop calme où je suis. Je commence à me concentrer sur les clics de souris de tout le monde et les gens qui respirent lourdement, etc ... C'est comme s'allonger dans son lit et entendre un grillon.
kirk.burleson

8

Écriture de trop de lignes de code sans tests adéquats.


C'est la première cause de blocage de mon expérience.
Paddyslacker

1
@Paddyslacker: plus de test = plus productif? Hein? Uniquement pour les personnes qui ne devraient pas être en programmation en premier lieu. Le test peut être utile, mais "la première cause d'arrêt des choses"? Es-tu sérieux?
n1ckp

1
@ n1ck: Oui, je suis sérieux. Le code entre dans un état impossible à maintenir et le manque de tests et de testabilité de la base de code signifie que chaque nouvelle fonctionnalité devient de plus en plus difficile à ajouter. Je trouve amusant que vous pensiez que vous pensez que les personnes qui écrivent plus de tests "ne devraient pas être en programmation en premier lieu." Alors Roy Osherove, Michael Feathers, Oncle Bob, Kent Beck, etc. ne devraient pas être en programmation alors?
Paddyslacker

@Paddyslacker: Je ne sais pas. Je ne les ai jamais vus coder. Peut-être qu'ils devraient être meilleurs en gestion d'après votre description? Et pourquoi le code devient-il impossible à maintenir en raison du manque de test exactement? Tester le mauvais code par une sorte de magie peut-être?
n1ckp

1
@ n1ck, les tests ne sont pas payants lors de l'écriture initiale du code, mais font une énorme différence lors de la maintenance ultérieure du code.

5

Manque de café de haute qualité.


Ou manque de bon soda. Je manque tellement de coke de cerise de régime décaféiné! Dans mon pays, je ne peux obtenir que du coke diététique ou du coke décaféiné, et pas du tout du coke de cerise :-(
Wizard

1
@Wizard - J'avais l'habitude de travailler pour une entreprise qui fournissait du Diet Cherry Coke. Je ne sais pas pourquoi je suis parti. Si vous ressentez votre douleur.
JeffO

2
@Wizard: il suffit d'acheter un pot de cerises au marasquin et d'ajouter un peu de sirop à votre boisson. Maintenant, vous pouvez le rendre aussi fort que vous le souhaitez ... (même astuce pour la vanille: le vrai coke de vanille est de loin supérieur au pré-mixé)
Shog9

@Monsieur. C: Le problème est que j'ai besoin d'un régime + coke décaféiné, une combinaison qui n'est pas disponible dans mon pays.
Wizard du

5

avoir à faire des estimations parfaites qui ne doivent pas être écartées une fois le développement commencé, c'est un scénario œuf de poule à mon avis


Si vous rencontrez beaucoup cela, je suggérerais de passer du temps non trivial à étudier l'estimation. Ensuite, vous pouvez répondre "si c'est une estimation, ce n'est par définition pas le temps qu'il faudra réellement".
MIA

oh j'ai déjà utilisé celui-là auparavant, la réponse est toujours que je suis mauvais à estimer, si cela ne peut pas être décomposé en tâches visibles de 2 à 4 heures, je me trompe apparemment
MetaGuru

5

Réparer la version cassée de quelqu'un d'autre


on dirait que quelqu'un n'encadre pas bien son collègue.
Afficher le nom le

@bold: cela peut se produire naturellement par asynchronicité. Supposons que l'heure de coupure quotidienne de la construction soit à 5 h, et que vous extrayiez la dernière version à 9 h. (En d'autres termes, vous ne pouvez pas empêcher les gens de venir travailler plus tôt.)
rwong

4

Réunions sans ordre du jour.

Une machine lente.

Absence d'un deuxième moniteur.

Une vieille souris qui a une balle au lieu des belles nouvelles.

Le manque d'accès à Internet sur la machine, ce qui rend la requête MSDN / stackoverflow / etc un peu pénible.


Le pirate de l'air est lié à la réunion sans ordre du jour. Vous savez ... vous le mettez sur le calendrier pendant une heure mais même si le sujet est terminé en 20 minutes, il y a ce gars qui continue à trouver d'autres sujets pour compléter les 20 minutes. Je vous voterais positivement, mais il faudrait que je vous note sur le "manque d'un deuxième moniteur" comme ralentissement. C'est pratique, mais ne pas l'avoir à l'occasion ne m'a pas ralenti.
MIA

4

J'ai passé trop de temps à programmer

Même si vous aimez vraiment la programmation, y consacrer trop de temps finira par vous épuiser ...


4

Évitez tout ce qui vous fait sortir de «la zone». Cela signifie que votre boîte de réception e-mail, votre application popup Twitter, votre chat d'entreprise, etc.

Avoir une condition de travail silencieuse signifie également éviter ce bruit de bureau .


3

Toute demande de modification qui aurait été plus facile à mettre en œuvre si vous l'aviez connue au préalable.


"Marcher sur l'eau et développer un logiciel à partir d'une spécification sont faciles si les deux sont gelés"
back2dos

1
Citation idiote. Marcher sur la glace n'est pas toujours facile.
Peter Boughton du

1
@Peter Boughton: Si nous choisissons une échelle, où le développement de logiciels à partir de spécifications fluctuantes est difficile et à partir de spécifications figées est facile, alors marcher sur la glace est toujours facile. Vous pouvez apprendre à un enfant de 6 ans à le faire. Mais je suppose que vous le savez, vous prenez juste plaisir à vous faire un cul intelligent.
back2dos

Et vous pouvez aussi apprendre à un enfant de six ans à travailler selon des spécifications fluctuantes. Ce n'est pas intelligent, c'est l'irritation de la surutilisation de citations comme ça, qui ne sont pas utiles. Les spécifications figées ne sont pas faciles à développer si elles sont erronées (car elles ne peuvent pas être corrigées), et les spécifications changeantes sont correctes si vous savez à l'avance quelles parties sont en flux (car vous pouvez y répondre).
Peter Boughton

3

Mauvais code.

Devoir réécrire la partie de quelqu'un d'autre qui aurait pu faire le travail correctement en premier lieu est le plus grand puits de temps que j'imagine.


2

The Much That Slows You Down est un bon article de blog pour cela.

...

De nombreux projets répètent encore et encore les principales fonctionnalités au niveau de l'infrastructure, ce qui ralentit l'activité de l'entreprise en proposant des fonctionnalités qui la différencient de ses concurrents.

...

Il est inévitable que les produits et les innovations contribuent à réduire le temps que les développeurs passent sur des tâches non différenciantes. La question est de savoir quelle forme ces services et outils prendront.

...


+1: Excellente réponse. J'ai quitté un emploi parce que l'entreprise n'était pas disposée à consacrer du temps à la réduction de la dette technique. Les développeurs ont été contraints de «répéter encore et encore les fonctionnalités de base des infrastructures.»
Jim G.

2

Eh bien, dernièrement, le ralentissement le plus important est dû au fait que nous développons simultanément plusieurs choses qui auraient dû être faites dans un ordre spécifique. J'attends donc que (les noms changent pour protéger l'innocent) John termine son composant dont j'ai besoin pour mon package SSIS et Harry est ralenti en attendant que j'importe des enregistrements car il a besoin de données à voir pour tester son exportation (essayez jamais pour écrire un rapport d'exportation complexe quand il n'y a pas de données dans l'une des tables?) et tout le monde est ralenti parce que la conception n'est pas terminée et les tables de base de données dont nous avons besoin pour faire nos tâches n'ont pas encore été créées et peuvent même ne pas se terminer être ce qu'ils ont dit qu'ils allaient être, etc.


1
Il semble que vous parliez de goulots d'étranglement causés par une répartition trop fine du travail entre les membres de l'équipe.
MIA

1
Ce n'est pas tellement que l'équipe est dispersée, mais que la direction n'a pas pensé aux dépendances dans l'attribution des projets. Et certaines choses qui étaient supposées être prêtes au moment où l'autre personne a été affectée au projet ne l'ont pas été une fois que les gens ont essayé de les utiliser.
HLGEM du

2

Répondre à des questions sur stackexchange.com, comme celui-ci.


Vous pouvez alors envisager d'améliorer vos compétences de saisie tactile.

2

Même si vous avez demandé de ne pas répertorier les distractions, elles peuvent être un facteur important. Examinez leur environnement de travail, vérifiez s'ils sont souvent interrompus ou invités à faire d'autres choses qui ne sont pas liées au projet.

Parfois, un développeur peut être bloqué parce qu'il fait quelque chose qu'il n'a jamais fait auparavant et qu'il ne sait pas où chercher de l'aide. S'il s'agit d'une petite équipe ou d'un individu, cela peut être encore plus difficile. Nous avons tendance à être quelque peu fiers et n'aimons pas admettre quand nous ne savons pas comment faire les choses. De plus, nous n'aimons pas demander de l'aide aux autres. Il n'y a pas de moyen facile d'amener un développeur à l'admettre, sauf peut-être pour lui demander s'il peut respecter le délai, ou ce dont il a besoin pour respecter le délai, puis espérer qu'il sera honnête. Vous devrez peut-être proposer d'apporter d'autres aides ou trouver quelqu'un qui puisse les aider.

Manque d'exigences clairement définies, ce qui les oblige à comprendre ou à prendre des décisions.


2
  • Avoir à attendre environ 15 minutes pour que le PC démarre dans un état utilisable
  • Attendre que le PC change d'application
  • Être la seule personne au bureau qui doit faire son propre thé / café.
  • Un clavier cassé (réparé!)
  • Travailler en dehors du bureau du directeur général (PDG américain) (et non dans un bureau non plus), avec seulement une partition entre les deux (surtout lorsqu'il y a une réunion)
  • Le patron est uniquement accessible par e-mail, mais tout le monde est dans le bâtiment
  • Ne pas être autorisé à utiliser un VCS - apparemment, cela devrait être dans mon cerveau
  • Petit écran
  • Ne pas laisser de temps pour les pauses autres que le déjeuner
  • Devoir faire des sauvegardes de serveur à distance malgré un administrateur système dans le bâtiment
  • On vous dit de faire les dites sauvegardes manuellement.
  • Être obligé d'utiliser un stupide système de gestion du temps qui est inutilement compliqué
  • Juste avoir une vague idée des exigences après deux mois de travail

Je pourrais continuer, mais c'est vendredi et je veux oublier le travail.


On dirait que vous devez sortir de là!
Adam

2
  • Manque de documentation (système, entreprise, etc.)
  • Manque de code commenté
  • Une compréhension incomplète du système
  • Politique (c.-à-d. Réunions inutiles, paperasse, obstacles par la direction ...)
  • Documentation des exigences incomplète
  • Facebook!
  • Trop de sommeil?

1

Trop de personnes sur le projet.

Vu à plusieurs reprises, la direction décide en fonction de l'absence de données réelles dont elle a besoin pour ajouter plus de personnes au projet. Cela finit par le ppl qui sait ce qui se passe besoin de tout arrêter pour tenir la main de gens qui savent peu de choses sur ce qui se passe. J'ai vu plus d'un projet de champignon de taille, puis je suis allé rapidement dans les toilettes à partir de là, alors qu'avant ça allait bien, bien que peut-être un peu lent.

Donc, vous passez d'un mois de retard à cause de la vitesse insuffisante / trop à faire pour ne pas livrer du tout parce que vous avez totalement fait exploser le budget de toutes ces personnes supplémentaires.


0

Outre les choses mentionnées par d'autres, le long chemin entre la décision de compiler et d'exécuter votre code et d'obtenir un résultat positif / négatif . Idéalement, ce RTT ne serait qu'une seconde, mais j'ai vu un exemple d'heures. BTW, les tests unitaires tentent de résoudre ce problème.

Un autre problème lié à cela est une latence générale de votre environnement de travail. Imaginez que vous deviez travailler sur une connexion de bureau à distance à l'ordinateur de l'autre côté du monde, sur une connexion effrayante. J'ai été là. J'ai détesté ça.


0
  • Formalités administratives excessives

  • Être dépendant de quelqu'un qui n'est jamais là (comme votre patron - si vous avez besoin de poser une question mais qu'il est toujours en réunion)

  • Outils et équipements inadéquats.

  • Les gens poussent leur rame sans raison (tout changement visible dans l'interface utilisateur est soumis à cela) ou se disputent simplement à propos de choses triviales.

  • Machine à café cassée

  • Être assigné aux mauvaises tâches


0

La climatisation ne fonctionnait pas.

Ainsi, la température dans le bureau peut atteindre 40 degrés en été -5 en hiver.

Le -5 n'est pas bon pour taper, car je ne peux pas porter de gants ni taper. Le 40, ralentit juste ma réflexion.


0

C'est une opinion très personnelle et peut-être controversée, mais trop de planification et de réflexion à l'avance sur la conception ou l'écriture de code de «qualité». Il y a un dicton selon lequel «des semaines de codage peuvent vous faire économiser des heures de planification», ce qui pourrait être vrai dans certains cas.

Cependant, je vois souvent des programmeurs essayer d'esquisser un bon design avant de commencer à coder. Je me rends compte qu'il est plus facile de simplement "commencer", car en programmant, vous en apprendrez plus sur votre problème et votre solution, ce qui vous permettra de refaçonner rapidement votre solution en une bonne conception. La plupart des problèmes qui se posent sont à peu près inconnus au début du codage (du moins à mon faible esprit), donc perdre beaucoup de temps à concevoir à l'avance n'est qu'une perte de temps.

C'est aussi pourquoi je n'aime pas TDD, vous perdez trop de temps à écrire des tests, ce qui vous rend moins susceptible de refactoriser ou prend beaucoup de temps pour réécrire les tests. Les tests unitaires sont parfaits pour certains cas et certaines étapes d'un projet, mais le début de l'un n'est pas l'un d'eux à mon humble avis :)

Faites travailler quelque chose rapidement et améliorez-le.


-1 Je peux comprendre votre réflexion, mais l'objectif de la phase de conception est de limiter le besoin de refactoriser. Il facilite également les tests unitaires, ce qui est parfait tout le temps pour s'assurer que quelque chose qui fonctionnait ne soit pas cassé et libéré. Si vous ne faites aucune planification, vous compliquerez les tâches des autres quand ils devront essayer de maintenir ce qui sera inévitablement un code mal architecturé.
Adam

Qui a dit que ce serait mal architecturé? Je dis simplement que vous ne voulez pas d'une phase de conception excessive et que vous devez faire beaucoup de refactoring et de ré-architecture pendant un projet pour arriver à un code de qualité. D'un autre côté, pour que cela fonctionne, vous devez avoir des responsabilités de code clairement délimitées où différentes personnes ne se cachent pas dans le code de l'autre.
Homde

L'expérience montre qu'il aura une mauvaise architecture. Voler par le siège de votre pantalon et codage cowboy sont probablement les pires choses que vous puissiez faire pendant le développement. Avoir une phase de conception qui durera une semaine, vous fera économiser des mois de programmation et conduira à un code qui fait ce qu'il est censé faire pour la première fois. L'idée derrière TDD est que vous ne changez pas les tests. Ces tests sont destinés à émuler la convivialité du monde réel, et si votre code ne peut pas terminer le test, alors votre code est incorrect.
Mike S

Mon expérience dit le contraire, mais je suppose que cela dépend du cowboy et de l'équipe :) J'ai appris plus d'une semaine de codage et j'ai fait du code pour le montrer. Bien sûr, vous aurez une mauvaise architecture si vous ne faites pas de refactorisation extrême et continue et que vous avez une équipe / cow-boy suffisamment agile pour suivre. Penser que vous pouvez faire une "phase de conception", tout apprendre et le faire correctement la première fois est tout simplement naïf. La vraie valeur d'un prototype réside dans les leçons que vous apprenez, vous le jetez et le faites correctement. Faites cela plusieurs fois et rapidement :)
Homde

0

Blocage du programmeur : contrairement à d'autres ralentissements, celui-ci est plus difficile à résoudre.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.