Je pense que le mien est "il n'y a rien de tel qu'un travail de cinq minutes" - que les programmeurs ont tendance à être trop optimistes quant au développement et que nous devrions vraiment réfléchir aux implications avant de promettre une solution rapide à un problème puis de plonger dans le code
Réponses:
Il y a toujours une meilleure façon d'écrire votre code.
Peu importe à quel point vous trouvez le code que vous écrivez excellent, vous serez surpris de voir à quel point il est mauvais si vous le révisez dans quelques années. Tout simplement parce que quelques années auparavant, vous ignoriez certains schémas que vous connaissez aujourd'hui, ou certaines fonctionnalités de langage que vous avez apprises entre-temps, etc.
Réfléchissez avant de commencer à coder.
Il n'y a rien de plus permanent que des solutions temporaires :)
S'il est extrêmement difficile de résoudre un problème, le problème lui-même est très probablement mal posé dès le début.
Votre logiciel vivra considérablement plus longtemps que vous ne le pensez au moment où vous l'écrivez.
J'ai commencé ma carrière dans les années 80. J'ai commencé avec un logiciel qui était originaire des années 70 et qui était encore utilisé dans les années 90 (peut-être plus longtemps, je ne sais pas avec certitude de son sort). Une partie de mon propre code open source est à mi-chemin de sa deuxième décennie.
Bien travailler avec les autres est très important.
"Montrez-moi votre" Allez voir le gars "et je vais vous montrer votre problème"
Slapdash Hero Coders - ceux qui viennent de lancer du code sans aucun respect pour la convention, la lisibilité ou tout ce sur quoi quelqu'un d'autre travaille - peuvent causer plus de mal que de bien.
Ne pas dire que les gens qui peuvent écrire des tonnes de code de bonne qualité sont une mauvaise chose. C'est rare.
Apprendre de nouvelles langues fait partie du métier
J'ai appris environ quatre langages de programmation à l'école dans les années 80, mais j'en ai utilisé un dans un travail. J'ai eu quatre emplois où je ne connaissais même pas la langue que j'avais embauchée.
Dans l'ensemble, j'ai appris et utilisé professionnellement peut-être une douzaine de langues dans ma carrière, y compris FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, batch, DCL, javascript et a quelques petites DSL. En faisant un peu de mathématiques, il me semble que je fais la moyenne d'une nouvelle langue tous les deux ans, bien qu'il y ait beaucoup de chevauchements.
Si quelque chose a été une constante dans ma carrière, c'est le changement.
Continuez à étudier tous les jours. La connaissance d'aujourd'hui est obsolète demain.
Ironiquement, cette réponse devrait également être obsolète demain. Mais vraiment, étudiez dur un ou deux trucs et soyez certifié si c'est possible, soyez le dieu de ces choses (peut-être les langages de programmation ou l'administration du système / réseau / base de données) et gardez toujours un œil sur d'autres choses mineures, comme d'autres langues sans importance pour toi.
Je veux dire par exemple, être un grand professionnel de l'administration Java et Oracle DB, mais étudiez un peu Python, PHP, C ++, HTML5, Javascript, bien que non à un niveau de certification. Étudiez chaque framework web ou linguistique existant. Étudiez ou essayez d'avoir une expérience (de base) avec chaque base de données existante, comme SQL Server, MySQL, Cassandra, HBase, PostgreSQL et tout le monde No-SQL comme MongoDB et CouchDB. Essayez d'avoir une certaine expérience avec l'administration et la virtualisation Linux.
C'est la plus grande leçon que j'ai apprise de mes 16 années d'expérience. J'ai été pendant près de 10 ans un programmeur mono-langage, utilisant Pascal à son époque, et Visual Basic 6 au début du millénaire, et un développeur PHP depuis 9 ans. Mais à partir de là, j'apprends que les développeurs doivent savoir au moins un peu de tout.
J'ai appris que le meilleur principe de conception est KISS (Keep it simple, Stupid!) .
J'ai appris que garder votre code simple et propre devrait être la principale préoccupation, et chaque membre de l'équipe devrait comprendre ce que vous avez du code. The KISS principleindique que la plupart des systèmes fonctionnent mieux s'ils restent simples plutôt que complexes, la simplicité devrait donc être un objectif clé de la conception et une complexité inutile devrait être évitée.
Il n'y a pas d'essai
Supposons que vous ayez une tâche ou un groupe de tâches dont la durée est estimée à 4 jours. Ensuite, votre patron ou chef de projet vous demande si vous pouvez essayer de le faire en deux jours pour une raison importante. Voulant être un bon employé flexible, vous pourriez être tenté de dire: bien sûr, vous pouvez essayer. Les résultats les plus probables de cela sont que vous manquez la date limite ou que vous allez faire un hack à moitié pour le faire. Et ce n'est pas la faute de votre patron de vous avoir demandé de le faire, c'est son travail. C'est ta faute de ne pas dire non, c'est ton travail.
Vous ne pouvez pas négocier avec le temps. Vous pouvez négocier avec la portée. Soyez professionnel et ne vous vendez pas à découvert.
"Cela n'arrivera jamais" signifie en fait "Cela n'arrivera jamais avant le premier jour de production"
L'écriture de code est simple. La lecture du code est difficile. Même si le code est le vôtre. Donc, dans la mesure du possible, optez pour une approche lisible.
Vous n'êtes pas plus intelligent que les autres. Ne pensez jamais que votre approche est la meilleure simplement parce que c'est la vôtre.
Faites attention à CE qui est dit, pas PAR QUI il est dit. Des idées brillantes pourraient venir des sources les plus inattendues.
Ne sois pas paresseux. Prenez votre temps pour écrire du bon code. Vous devrez quand même le réparer à un coût plus élevé.
N'utilisez pas les fonctionnalités de POO fantaisie juste parce que vous le pouvez! - YAGNI (tu n'en auras pas besoin)
Use fancy OOP featurescar ils présentent des avantages spécifiques et démontrables pour le problème que vous essayez de résoudre . Vous riez, mais je le vois tout le temps. La plupart des programmeurs n'ont jamais rencontré d'objet qu'ils n'aimaient pas. Je pense que cela devrait être l'inverse: ces techniques sont coupables jusqu'à preuve du contraire devant le tribunal de KISS .