Comment savoir si je suis un bon programmeur?

Comme la plupart des gens, je me considère un peu au-dessus de la moyenne dans mon domaine. Je suis bien payé, j'ai eu des promotions et je n'ai jamais eu de réel problème à trouver de bonnes références ou à trouver un emploi.

Mais j'ai suffisamment remarqué que beaucoup des pires programmeurs avec lesquels j'ai travaillé pensaient qu'ils étaient parmi les meilleurs. Les mauvais programmeurs qui sont entourés d'autres mauvais programmeurs semblent être les plus auto-induits en erreur.

Je ne suis certainement pas parfait. Je fais des erreurs. Je manque des délais. Mais je pense avoir à peu près le même nombre de mouvements Bonehead que "d’autres bons programmeurs". Le problème est que je définis «autres bons programmeurs» comme signifiant «des gens qui sont comme moi».

Alors, je me demande s’il existe un moyen pour un programmeur de réaliser une sorte d’auto-évaluation raisonnable? Comment savons-nous si nous sommes bons ou mauvais dans notre travail?

Ou, si les termes bons et mauvais sont trop mal définis, comment les programmeurs peuvent-ils identifier honnêtement leurs propres forces et faiblesses, afin de pouvoir en tirer parti et travailler à l'amélioration de celles-ci?

Un bon programmeur comprend qu'il doit continuer d'apprendre et de grandir. Ils s'efforcent de faire de leur mieux à chaque effort, admettent leurs échecs et apprennent d'eux.

Ils sont extraordinairement communicatifs. Non seulement ils sont en mesure d'expliquer des termes techniques complexes à un profane, mais ils se mettent en quatre pour défendre en leur nom les idées du diable afin de s'assurer qu'ils offrent les meilleures options à leur client.

Les meilleurs programmeurs savent et acceptent qu'il existe plus d'une façon de faire les choses, que tous les problèmes ne sont pas un clou et que, parce qu'il y a toujours une meilleure façon de faire quelque chose que la façon dont ils ont planifié leur projet, ils cherchent constamment à apprendre de nouvelles techniques. , technologies et compréhension.

Un bon programmeur adore programmer et le ferait pendant son temps libre, même s’il passe déjà plus de 80 heures par semaine à programmer.

Un bon programmeur sait qu'il / elle n'est pas un grand programmeur. Les véritables grands programmeurs n'existent pas, il n'y a que ceux qui prétendent être grands et ceux qui savent qu'ils ne sont pas grands.

Comme Paul Graham le fait remarquer avec éloquence dans ce pod pod , vous ne pouvez pas. Seuls vos collègues peuvent vous le dire.

J'ai toujours trouvé qu'il était plus facile de juger de votre performance en faisant deux choses.

1. Entourez-vous d'autres bons programmeurs
2. Voyez combien ils se plaignent du code que vous écrivez.

Bien sûr, le problème est de trouver de bons programmeurs, et être un bon programmeur n’est pas uniquement une question de codage. Vous devez être capable de bien travailler en groupe, mais aussi de travailler seul.

Passons maintenant au sujet de Robert A. Heinlein et de son point de vue sur le sujet:

"[Un programmeur astucieux] devrait être capable de changer une couche, de planifier une invasion, d'abattre un porc, de créer un bâtiment, d'écrire un sonnet, d'équilibrer des comptes, de construire un mur, de fixer un os, de réconforter les mourants , prenez des ordres, donnez des ordres, coopérez, agissez seul, résolvez des équations, analysez un nouveau problème, plantez du fumier, programmez un ordinateur, préparez un délicieux repas, combattez avec efficacité et mourrez galamment. La spécialisation est réservée aux insectes. "
- extrait du Carnet de notes de Lazarus Long.

Voici la matrice de compétences des programmeurs rien que pour vous: http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm

Jeff a l'un de mes billets de blog préférés sur ce sujet ... Pourquoi suis-je le meilleur programmeur au monde?

"... ce n'est pas notre travail d'être meilleurs que quiconque; nous devons simplement être meilleurs que nous ne l'étions il y a un an."

Je pense que le fait que vous posiez la question prouve que vous n'êtes pas un mauvais programmeur, donc, à mon avis, vous êtes à mi-chemin. :)

Les mauvais programmeurs pensent toujours qu'ils sont de grands programmeurs, d'après mon expérience.

La déclaration de @ Nick "Les mauvais programmeurs pensent toujours qu'ils sont de grands programmeurs ..." est expliquée par l'effet Dunning Kruger , qui généralise le fait que les personnes qui connaissent un peu le sujet surestiment souvent ce qu'elles savent réellement.

Être un peu facétieux ... moins vous pensez savoir, plus vous en ferez probablement ... à moins que vous ne soyez un idiot vraiment conscient de soi.

Répondre à la question initiale, même si j'ai tendance à penser que plus vous avez d'influence (pas de contrôle), c'est généralement un bon indicateur. Si vous voyez que d'autres suivent votre exemple ou choisissent vos pratiques, vous êtes sur la bonne voie.

La réponse qui a obtenu le plus de votes est vraiment pénible. En gros, cela signifie que vous n’avez pas de vie en dehors de la programmation. Qu'en est-il de la famille? Communauté? Loisirs? Dans quel type de profession sommes-nous dans lesquels vous devez être préoccupé au point de devenir une obsession pour être considéré comme "bon"? Je pense vraiment que nous devons avoir une certaine perspective ici.

Vous pouvez essayer de participer aux concours d'algorithmes TopCoder .

Je ne suis pas parfait. Je fais des erreurs. Je manque les délais. Mais je pense avoir à peu près le même nombre de mouvements Bonehead que "d’autres bons programmeurs".

Cette réalisation à elle seule fait de vous un meilleur programmeur que la plupart des mauvais programmeurs.

Beaucoup des pires programmeurs ont tendance à penser qu'ils savent déjà tout ce qu'il y a à savoir et qu'ils ne sont pas conscients de leurs limites. En conséquence, ils n'améliorent jamais leurs compétences.

Si vous regardez votre code d'il y a un an, par exemple, et que vous pensez que j'aurais pu le faire beaucoup mieux, vous êtes probablement bon :).

Voici quelques exemples concrets de mauvaise programmation. Bien sûr, un code similaire était partout copié / collé à 100 endroits. Guy s'est fait virer, mais j'ai entendu dire qu'il avait à nouveau un bon travail. Prendre plaisir:

une)

if (! TableObject.loadList("sql condition").isEmpty()) {  
    List<TableObject> myList = TableObject.loadList("sql condition");  
    ...  
}

b)

public static Type getInstance() {  
    if (instance == null) {  
        return new Type();  
    }  
    return instance;  
}

c)

getForeignKeyObjectProperty1() {  
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getProperty1();  
}  

getForeignKeyObjectProperty2() {  
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getProperty2();  
}  

...

getForeignKeyObjectPropertyN() {
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getPropertyN();
}

ré)

public boolean isHasImage() throws SQLException {
    StringBuilder query = new StringBuilder();
    query.append("select user_name");
    query.append(" from user");
    query.append(" where has_image = 1");
    query.append(" and user_name ='"+getUserName()+"' and user_image is not null");
    Connection c = Database.getInstance().getConnection();
    Statement st = c.createStatement();

    try {
        ResultSet rs = st.executeQuery(query.toString());
        if (rs.hasNext()) {
            return true;
        } else {
            return false;
        }
    } finally {
        st.close();
    }
}

Si vous créez ce type de code, arrêtez la programmation. Si vous ne voyez rien d’étrange dans ce code, arrêtez la programmation. Sinon, vous n'êtes pas mauvais, alors vous pourriez même être bon :)

EDIT: Pour répondre aux commentaires: j'ai eu un emploi avant d'obtenir mon diplôme et ce gars avait déjà quelques années d'expérience en programmation. Il a été congédié quelques mois après mon embauche et je n’étais donc pas en position de tuteur. Les exemples ci-dessus venaient juste de dessus de ma tête - chaque code de code qu'il touchait était défectueux de différentes manières et de manière imaginative. La plupart des choses ont commencé à sortir de l'entreprise après son départ de l'entreprise, car ce n'est qu'à ce moment-là que d'autres personnes ont vu certaines parties du code. C'est en général un gars sympa, avec qui il est agréable de parler, etc., mais il ne sera JAMAIS un bon programmeur, tout comme je ne serai jamais un bon peintre, ni un écrivain ni quoi que ce soit.

Pour mettre cela en contraste avec un autre exemple, un type venu le remplacer était également un étudiant de premier cycle à l’époque. Il a étudié au collège plus célèbre pour la gestion puis la programmation. Il n'est pas trop geek dans le sens où il a programmé quelque chose pour s'amuser ou qui resterait à la maison et lirait des informations sur Java ou la programmation, mais il s'en sort très bien. Il s'est rapidement ajusté et a commencé à produire du code utile et maintenable. Certaines personnes peuvent faire cela, d'autres non, demandez simplement à dailywtf.

Vous pouvez essayer différentes choses pour avoir une meilleure idée de votre performance.

• Comparer les commentaires de code. Voir dont l'examen a révélé plus de problèmes.
• Demandez quand était la dernière fois qu'ils lisaient des livres qui étaient en marge de leurs études normales. Puis demandez-vous la même chose.
• Demandez-vous qui apporte de nouvelles idées à l'entreprise (et leur efficacité).
• Enfin (et le moins), existe-t-il une forme de reconnaissance de l'entreprise?

(J'en ai parlé une dernière parce que, lors de ma dernière entreprise, un programmeur avait reçu le titre de "développeur de l'année" deux fois en trois ans. Après son départ, nous avons trouvé au moins 20 extraits de code dignes de TDWTF. Il a développé le code rapidement , mais pas nécessairement correctement. La direction ne savait tout simplement pas la différence.)

Autorisez les autres développeurs que vous respectez à travailler ou à voir votre code.

Demandez aux gens d’utiliser ce que vous aimez et de voir ce qu’ils pensent.

- Kevin Fairchild

Pouvez-vous comprendre cela?

if(rp->p_flag&SSWAP) {
	rp->p_flag =& ~SSWAP;
	aretu(u.u_ssav);
}

:-)

La simple pensée que vous avez besoin de vous auto-évaluer vous permet de vous démarquer des autres.

L'une des façons dont je me juge toujours est d'écouter ce que mes collègues ont à dire sur moi. L'astuce consiste à trouver les bonnes personnes.

C'est toujours subjectif qui est un bon programmeur. Je conviens avec Nick que le simple fait de poser la question est un pas dans la bonne direction. Je pense que le désir constant d’apprendre plus et d’améliorer est ce qui fait un bon programmeur.

Pour moi, les meilleurs programmeurs ne cherchent jamais de travail. Ils ont des offres permanentes pour de nouveaux postes uniquement en fonction de leur réputation. Donc, un bon programmeur peut avoir des offres d’employeurs précédents à revenir, s’il le souhaite. Ou bien un bon programmeur aurait demandé à d'anciens collègues de venir travailler pour eux dans une nouvelle entreprise.

En termes de forces / faiblesses, vous les connaissez probablement déjà. Sinon, demandez à une personne plus âgée de votre équipe. Il n'est même pas nécessaire que ce soit un développeur. Un bon chef de projet connaît les forces / faiblesses des programmeurs. En outre, les traits qui définissent un bon programmeur ne se limitent pas au code. La compréhension de l'entreprise, les compétences en communication, le jugement, etc. sont toutes effectuées en dehors de votre IDE.

Je pense que c'est à peu près comme se demander comment vous pouvez savoir si vous êtes une personne agréable.

Malheureusement, je pense que la réponse est que seules d’autres personnes crédibles peuvent vous le dire. Je ne pense pas que ce soit quelque chose que vous puissiez déterminer avec précision pour vous-même (du moins, c'est très difficile - mais je pense que cela pourrait être impossible).

je dirais simplement: si vous êtes passionné (je veux dire VRAIMENT passionné) de ce que vous faites, si vous êtes flexible (une autre langue, une nouvelle technologie, la refonte complète d'un ancien projet - faisons-le!), si vous continuez à apprendre et améliorez vos compétences et ne pensez jamais que vous êtes assez bon pour arrêter - alors vous êtes un bon programmeur!

95% de tous les programmeurs pensent appartenir au top 5% des programmeurs, les 5% restants étant des gestionnaires. Donc, si vous êtes un gestionnaire, vous n'êtes probablement pas un bon programmeur, sinon vous l'êtes probablement.

Je pense que c'est plus une question de savoir ce que vous faites avec vos compétences en programmation. Être un bon programmeur, c'est bien, mais qu'importe si vous codez un logiciel de banque toute la journée (sans vouloir vous offenser). Ça ne fait rien.

Pour vraiment vous prouver que vous êtes un bon programmeur, prenez un projet parallèle intéressant et difficile. Cela montre quelques choses: vous êtes intéressé par la programmation sur votre temps libre et appréciez vraiment le sujet - ceci est essentiel pour être un bon programmeur. Cela montre la polyvalence en ce que vous pouvez étendre vos compétences au-delà de ce que vous faites dans votre environnement de travail. Cela montre également votre motivation et votre créativité: vous avez vous-même défini un problème et vous prenez des mesures pour le résoudre.

Tous ces aspects définissent un bon programmeur pour moi.

Ma réponse sera politiquement incorrecte. Cependant, je suis en fait le fondateur d'une start-up et mon travail consiste à embaucher les meilleurs programmeurs.

Comment savoir quelles personnes seront de bons programmeurs ou peuvent être de bons programmeurs?

1 mot: QI.

Le QI est pour la programmation comme la hauteur est pour les joueurs de basket.

Je mettrais les compétences en mathématiques comme un autre indicateur plus politiquement correct. Mes professeurs d'informatique m'ont dit qu'il existe un critère qui permet de prédire correctement qui réussira les cours de programmation. Scores au lycée. Celles-ci sont de toute façon un QI.

Cela peut être une surprise. On nous dit que la programmation est un travail de niveau universitaire. Devinez quoi, je me fiche de diplôme. Je me soucie seulement de 3 choses.

1. Compétences en programmation (pouvant être testées).
2. Aptitude.
3. Bon sens (pas trop bas) les compétences des gens.

Malheureusement, le QI ne mesure qu'une chose. Alors je fais des tests.

Je pose des questions aux gens. Une question simple Je pense que les enfants des écoles primaires devraient pouvoir y répondre.

Je pose des questions comme:

1. Quelle est la distance entre la main courte et longue de l'horloge à 7h35
2. Si je vais de Jakarta à Semarang et que je veux maintenir une vitesse de 60 km / heure. Ensuite, les deux premières heures, je conduis 100 km / heure. À quelle vitesse dois-je aller pour le reste du voyage afin que ma vitesse moyenne soit de 60 km / heure?

Si vous regardez attentivement, ces questions n'exigent pas du tout de créativité. Seul le bon sens. Tous les enfants des écoles primaires ayant un QI peuvent répondre à cette question.

La plupart des diplômés ne peuvent pas. Maintenant, imaginez si quelqu'un ne peut pas répondre à cela? Peut-il programmer? Pensez-y. À quelle fréquence vous devrez spécifier ce qu'il doit faire?

Vous pouvez également poser des questions telles que Microsoft qui nécessitent de la créativité. Vous pouvez poser des questions sur la façon de peser 8 balles dans une balance pour savoir laquelle est la plus lourde. Le problème avec de telles questions est que cela implique la chance. Cependant, certaines sont assez faciles, cela devrait être une exigence minimale.

Obtenir un programmeur génial peut améliorer les qualités des autres programmeurs. Obtenir un programme légal peut faire baisser le moral de tous les autres.

Après que les gens puissent répondre à des questions comme celle-ci, ce qui est très facile, je leur demanderais d'écrire du code de confiture Google.

Les bons programmeurs peuvent résoudre le code Google Jam et prévoir quels problèmes sont les plus faciles.

à mon humble avis, vous êtes un bon programmeur si

-vous avez un fond théorique solide. réinventer la roue ainsi qu'un algorithme ou un framework est une perte de temps, la plupart du temps.

-Vous pouvez parfois voir les choses et les problèmes d'un point de vue biaisé. cela peut vous amener à trouver des solutions innovantes.

-Vous consacrez du temps et de l’argent à la mise à jour des meilleurs outils et des meilleures compétences.

-votre code est facile à modifier. si vous concevez un code propre, élégant et compréhensible, le modifier ne sera pas douloureux.

-si votre taux de code / bugs est raisonnablement élevé. Je sais que cela peut sembler trivial, mais je connais de nombreux développeurs créatifs et compétents qui sont néanmoins très enclins à faire des bogues triviaux. cela nuit grandement à leur efficacité et à leur utilité.

Les gens autour de vous savent que vous pouvez aider à décider des choix à faire.

-Vous pouvez résoudre des problèmes en utilisant différents outils. les mauvais programmeurs continuent à utiliser le même outil (langage, technologie, architecture, etc.) quel que soit le problème qu'ils rencontrent

-Vous continuez à apprendre, vous êtes curieux.

-vous avez la programmation amusante, après toutes ces années

"Monsieur, j'ai traversé ça depuis Alpha jusqu'à Omaha, et je vous dis que moins un homme en sait, plus le bruit qu'il fait est grand et plus le salaire qu'il commande est élevé." Mark Twain

... ma conclusion est que les bons programmeurs ont un salaire bas et font peu de bruit ... :)

Meilleur programmeur: Terminez la tâche avec le plus petit nombre d'instructions de code à temps.

Combien de bogues votre code a-t-il par métrique? (c.-à-d. bugs par ligne) Combien de votre code doit être recodé lorsque de nouvelles fonctionnalités doivent être ajoutées? Vos collègues ont-ils des problèmes pour modifier votre code?

En fin de compte, il est presque impossible de répondre à la question étant donné que la question "Qu'est-ce qu'un code de qualité?" Est toujours un sujet très controversé après toutes ces années.

J'aime vraiment ce que Adam V a dit ci-dessus.

En plus de ce que d'autres ont dit, examinez la maintenabilité et l'historique de support de votre travail. Si votre code nécessite de gros travaux de maintenance et qu'il est constamment corrigé ou difficile à modifier, il peut indiquer sa qualité. Mais ceux-ci peuvent aussi être des indicateurs de faibles besoins.

C'est très difficile de s'auto-évaluer. Les personnes incompétentes ont tendance à avoir des évaluations exagérément gonflées de leurs propres capacités.

Une bonne mesure consiste à déterminer si d'autres personnes que vous respectez en tant que programmeurs souhaitent travailler sur / avec le code que vous avez écrit. Si vous avez la possibilité de travailler directement avec vous ou d'hériter du code que vous avez écrit, allez-vous le refuser? D'accord à contrecœur? Ou sautez sur l'occasion d'apprendre de votre travail? Cette technique fonctionne encore mieux s'il s'agit d'un pair, et non d'un sous-marin ou de quelqu'un qui pense qu'il peut être bénéfique de vous faire sentir bien.

Si vous voulez vraiment le savoir, envoyez du code à vos pairs et demandez une révision (constructive) du code. Dans le pire des cas, vous apprenez quelque chose. Le simple fait que vous soyez ici sur ce site à la recherche de l'illumination vous distingue déjà des masses non lavées. (sauf si vous êtes juste là pour vous caresser l'ego. :-)