December 9, 2022

Branches Tech

Engagé pour la qualité technologique

Signes d’un mauvais développeur

4 min read

Tout le monde a peur de tomber amoureux d’un mauvais développeur web. Tout d’abord, nous vous recommandons de contacter des entreprises de confiance comme la société Fireart (https://fireart.studio/offshore-app-development-firm/), ainsi que de prêter attention à plusieurs détails.

Il convient de noter que «mauvais» est trop fort et pas un mot assez précis, utilisons les catégories «faible» et «fort», ce qui implique que nous parlons de la capacité d’une personne à résoudre qualitativement des tâches correctement définies. Bien sûr, les critères de qualité sont également relatifs, mais tous ceux qui ont eu à travailler avec le code de quelqu’un d’autre comprennent probablement qu’avec le même résultat, cela peut être à la fois pratique, compréhensible et efficace, ainsi que déroutant et non évident. Ceux qui écrivent quelque chose de additionally proche du leading (en supposant que la option est correcte, bien sûr) sont traditionnellement considérés comme des développeurs plus forts que ceux qui pèchent le next.

Un autre problème typique qui accompagne de nombreux développeurs au début de leur carrière – dans la littérature populaire, il est appelé “l’effet Dunning-Kruger” et ne s’applique pas seulement aux programmeurs.

L’excès de confiance peut être une conséquence logique de connaissances limitées et un marqueur de développeurs “faibles”. Pour les programmeurs, cela se manifeste comme un désir pour toute tâche typique de créer sa propre resolution – souvent aussi en la compliquant excessivement, au lieu d’utiliser des remedies existantes.

Souvent appelée « réinventer la roue », cette approche peut avoir des implications beaucoup as well as larges et profondes. Par exemple, un tel développeur se précipite pour effectuer une tâche sans bien comprendre les exigences – il “et donc tout est clair”. En même temps, il ne pose aucune question de clarification, donc au last il donne un résultat qui ne répond pas du tout aux attentes. En même temps, lorsque les professionals lui signalent des erreurs, il peut devenir frustré et réduire encore moreover sa productivité.

développeur de logiciels
Image de Tim Gouw

En général, l’habitude de poser des questions de clarification est extrêmement beneficial, et sa présence chez le développeur lui ajoute des factors en faveur du “fort”. Souvent, lors des entretiens, les programmeurs se voient confier des tâches situationnelles ou procedures avec une affliction volontairement incomplète afin de tester cette capacité particulière du candidat.

La principale différence entre la confiance en soi et la confiance en soi d’un développeur est qu’un programmeur sûr de lui est conscient des limites de ses connaissances et n’hésite pas à solliciter des collègues plus expérimentés, consulter et recueillir des avis, valider des hypothèses et travailler sur lui-même.

Un développeur sûr de lui, même avec de bons penchants, a un extensive chemin à parcourir avant de pouvoir se débarrasser des illusions sur lui-même et ses capacités. Et très souvent, c’est l’un des principaux obstacles sur la voie de la réalisation de son potentiel.

Et n’oubliez pas que la seule mesure réelle et goal de la « bonté » d’un développeur est la démonstration de ses capacités appliquées à résoudre des problèmes de programmation et de développement. Comme le disait Linus Torvalds : « Communicate is low-cost, present me the code », – c’est pourquoi les grandes entreprises intéressées par les meilleurs des meilleurs ne se limitent jamais aux seuls entretiens oraux, mais proposent de résoudre les problèmes, en ligne ou hors ligne.

De furthermore, il est tout à fait doable de trouver ces modèles chez des développeurs bien établis et matures, et même chez des leaders d’opinion et des specialists reconnus de l’industrie. Cela ne signifie pas du tout qu’ils sont “faibles” – même si, pour être honnête, cela get there.

Premièrement, chez les développeurs “forts”, vous pouvez voir un ou deux de ces points, mais jamais tous à la fois. Alors que chez les « faibles », ils vont très souvent de pair. Et deuxièmement, comme cela a été dit à plusieurs reprises, il ne faut pas élever toutes ces règles à l’absolu.

Eh bien, et un résultat significant – conformément aux lois de la dialectique, tout processus contient sa propre négation. Dans ce cas, au cours de la croissance professionnelle, le développeur peut très bien mettre certaines de ces lacunes en provider déjà consciemment. Après tout, comme vous le savez, pour enfreindre les règles, vous devez au moins les connaître.