Étapes de développement du programmeur

Le développeur de jeux indépendants Erik Rydeman a identifié une liste d'étapes typiques du développement d'un programmeur.

• Copieur-pasteur/débutant complètement vert : il essaie de rassembler des exemples de code qu'il a trouvés en ligne. A la plus vague idée de quoi et comment cela fonctionne.
• Débutant indépendant : voir la matrice ! En fait, il l’a vu du coin de l’œil, mais il n’en est pas encore conscient et est dans une illusion sincère, pensant qu’il a appris le pouvoir et que maintenant c’est une petite affaire (hehe). Peut écrire du code simple et complexe sans regarder d’exemples. Il est très heureux lorsque les résultats de son travail fonctionnent exactement comme prévu.
• Examiner de plus près les modèles de conception. Il maîtrise déjà la syntaxe de sa langue maternelle et étudie désormais les meilleures pratiques. Il commence à étudier les modèles de conception et la toute-puissance qui s'est abattue sur lui à l'étape précédente se dissout comme un brouillard d'automne. Devant nous se trouve à nouveau un nouveau venu désespérément vert et éternellement sceptique...
• Passionné de modèles de conception. Sa conscience vit avec l'idée du « code idéal ». Un passionné essaie de structurer son propre code de manière à ce qu'il soit proche d'un idéal inaccessible et s'intègre autant que possible dans les modèles existants. C'est désormais beaucoup plus agréable de travailler avec le code qu'il a écrit.
• Architectural Overfanatic : Cela arrive à tout le monde. Mais certains programmeurs se penchent avec tant de zèle sur les meilleures pratiques qu'ils sont prêts à les défendre avec un zèle que même des fanatiques religieux expérimentés pourraient envier. Et, comme ces derniers, ils ne se calment que lorsque tout leur entourage accepte leur point de vue ou quitte leur champ de vision. Parfois, à ce stade, la productivité diminue, et tout cela parce que de mauvaises décisions sont prises (trop de confiance dans la théorie, non confirmée par la pratique).
• Architecte expérimenté. L’expérience accumulée commence à porter ses fruits. L’« architecte » sait instinctivement ce qui se passe réellement et quoi faire face à tout cela. A ce stade, le programmeur commence à s'éloigner des dogmes stricts, et sa phrase principale devient « ça dépend » (« tout peut arriver »). Les décisions difficiles ne sont plus son fétiche.
• Ascétique minimaliste. Question : Quelle est la meilleure façon de structurer le code ? La réponse de l'ascète : la plus simple de toutes. Maintenant, il s'intéresse beaucoup moins aux développements théoriques de l'ingénierie qu'aux résultats pratiques, et trouver une solution qui s'avère bonne, et la mettre en œuvre du premier coup, est tout à fait possible : l'expérience d'un ascète aide.

A quel stade en êtes-vous ?