Quelles sont les erreurs non-programmation qu'un programmeur doit éviter? [fermé]
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Les gens font des erreurs, même dans la vie réelle ... Ce qui devrait nous, les programmeurs geeks, éviter?
La solution
En savoir que ce qui constitue « un degré acceptable de précision » pour vous est « Annoying foutue tatillonne » à la plupart du monde.
Autres conseils
Apprenez à écouter les gens (ou les utilisateurs de votre produit).
Trop de programmeurs sont rapides pour passer à « cet utilisateur est un idiot » au lieu d'écouter ce que la personne ou l'utilisateur a à dire. Il y a quelque chose à apprendre de tout le monde dans ce monde.
La plus grande erreur de non-programmation que j'ai jamais vu:
apprentissage pas comment communiquer efficacement, oralement et par écrit.
Prenez deux programmeurs de compétences de programmation égale, l'une avec de bonnes compétences en communication et un sans. L'ancien va aller plus loin, plus vite tous. Célibataire. temps.
Pièces de gens normaux de tous les détails techniques inutiles. Ils ne se soucient pas.
Et ne pas baver sur vos collègues féminins.
Ergonomie. Obtenir un vrai professionnel pour évaluer votre poste de travail et recommander le placement de moniteur, clavier et chaise.
Étirez vos mains, les poignets et les bras avant de commencer une longue séance de saisie au clavier. Faites attention à votre posture aussi.
Je commencé à avoir beaucoup de douleur au poignet en 1998 et je devais changer un tas de mes habitudes. À ce jour, je porte un appareil orthodontique du poignet tout en travaillant à l'ordinateur (j'utilise le IMAK SmartGlove).
Ne pas jouer trop de jeux vidéo, qui vient augmenter les heures que vous passez torturant vos mains et vos poignets.
En outre, boire beaucoup d'eau et de l'exercice régulièrement. Licencier les boissons non alcoolisées.
Pas d'apprentissage autant sur le domaine commercial, les utilisateurs, le contenu que vous écrivez un logiciel pour.
Ne jamais manger quoi que ce soit plus grand que votre tête
programmeurs Geeky et les développeurs devraient éviter de dire ce qu'ils pensent vraiment les gestionnaires de projet, les testeurs d'assurance qualité, et d'autres DBAs non-programmeurs à leur visage.
En substance, être gentil .
traiter tout le monde ce que vous rencontrez comme un programmeur. Vous devez comprendre que tout le monde autour de vous se soucie des ordinateurs autant que vous le faites. Il est une pilule difficile à avaler, mais malheureusement, très réel.
Sachez que si vous êtes dans un environnement de développement en cascade, des documents d'exigence, BRD, etc. sont, en général, les contes de fées. Exigences et projets logiciels dans son ensemble sont dans un état constant de flux et il est extrêmement rare d'avoir un ensemble d'exigences qui ne changent pas tout au long du cycle de vie du projet. Les gens d'affaires sont pointilleux et aiment changer leur esprit beaucoup. Cela dit, la plupart des magasins de logiciels fonctionnent toujours avec un état d'esprit de chute d'eau. Il y a un mouvement de plus en plus que le soutien Agile méthodes (le changement est inévitable et devrait être adopté), mais moi, personnellement, n'ont jamais vu ou entendu parler d'un projet de développement moderne, l'entreprise qui avait des exigences concrètes, pratiques, etc. pour sa durée de vie. L'emporter clé est que les choses changent à peu près toujours. Dans mon expérience, le degré probable auquel le changement des choses est directement proportionnelle à la longueur du projet ... qui est également dans un état constant de flux.
"Il fonctionne sur ma machine!" est une excuse qui ne peut aller aussi loin. Assurez-vous que vous considérez comme de multiples environnements non biaisées. Votre machine de développement, malheureusement, est bien construit pour exécuter tout ce que vous programmez sur elle!
Apprenez à reconnaître ce que vous ne savez pas. Si vous ne connaissez pas la réponse, dites. Ne pas essayer de faire quelque chose que vous pouvez juste pour donner une réponse. Cela vous causer des ennuis à long terme.
Thinking vous sera assez récompensé pour vos efforts. En d'autres termes, vous pourriez penser que vous serez récompensé pour travailler dur et faire du bon code et que vous serez punis pour passer toute la journée sur StackExchange.
Mais ce n'est pas le cas. Dans de nombreux cas, vous travaillerez avec / pour les personnes désemparés qui simplement deviner combien vous travaillez, quelle est votre valeur et vous daignent.
Apprendre à estimer.
Une « erreur non-programmation » Je vois des gens qui font (en particulier le gars dans le miroir) est «raboutage votre orteil.
Par cela, je veux dire, se trop excité sur une petite erreur, comme stubbing votre orteil. Puis, prenant une réaction négative excessive. La frustration des boules de neige en fin de compte et un tas de petits problèmes finissent par provoquer des maux de coeur massif et la douleur. Quand quelque chose va mal, faire une courte pause, le souffle puis réengager.
- Coincé sur un bug, prendre une pause.
- App fonctionne sur 3 serveurs, mais pas le 4, prendre une pause 5-15 minutes.
- IDE se bloque au hasard, prendre une pause.
- Les enfants ne seront pas rebondir arrêt sur les murs, prendre une pause. (Peut-être réduire le sucre alimentaire ainsi)
Dans la première décennie de ma carrière, ce qui est arrivé à moi tout le temps. J'étais mon pire ennemi le plus souvent. Je tombe toujours en proie à ce piège, mais beaucoup moins fréquemment.
"Assomption est la mère de tous les f ** Kups".
- Under Siege 2: Dark Territory (1995)
Évitez d'être trop dramatique lorsque des erreurs se produisent. Une faute de frappe est pas la fin du monde. Juste parce qu'une tâche a pris un peu plus longtemps que prévu initialement n'est pas la pire chose possible. L'histoire du Norden Bombsight serait un exemple où pendant que quelqu'un avait une bonne idée et bonne intentions en faisant un nouveau dispositif, il peut y avoir d'autres choses qui arrivent à réduire l'efficacité de la nouvelle chose créée. Certainement un récit édifiant comme il espère obtenir la sauce à spaghetti parler derrière lui de février 2004 .
