Un ingénieur logiciel pense généralement qu'un bon logiciel est le résultat de la mise en œuvre de modèles éprouvés, du respect des règles, de la discipline et du suivi de processus formels et de bonnes pratiques.
Un programmeur sait que tout cela, ce sont des conneries.
Écrire du code ressemble plus à la composition de musique, ou à l'écriture de livres, à la production de films et définitivement aux arts graphiques qu'à la construction de ponts. En fait, c'est plus difficile parce qu'il doit faire plus que simplement paraître ou sonner bien. Tout le monde sait que la bonne musique, la bonne littérature et le bon art ne dépendent pas de la manière dont les règles ont été suivies, mais plutôt des règles qui sont transgressées et des nouvelles idées qui sont explorées. Quelqu'un pense-t-il que les articles les plus populaires des palmarès musicaux et des listes de best-sellers sont placés là en fonction de leur conformité à des normes ou à des règles ? Cette liste serait très différente et pas très populaire parce que la société avance vers de nouvelles choses ou d'anciennes choses avec une nouvelle tournure, mais elle ne s'installera jamais.
Les meilleurs programmes sont simples, font naturellement ce que vous voulez, fonctionnent de manière fiable et peuvent être utilisés de manière suffisamment intuitive pour ne pas être ennuyeux. Ce qui est laissé de côté est généralement plus important que ce qui est ajouté - nous ne voulons pas qu'il soit configurable, nous voulons qu'il se configure lui-même ou qu'il n'ait pas besoin de configuration. Nous ne nous rendons probablement même pas compte de la plupart des meilleurs programmes utilisés partout autour de nous aujourd'hui, car ils fonctionnent tout simplement et nous n'avons pas à y penser ou à nous en préoccuper. Quand un logiciel nous ennuie, nous ne nous soucions pas de savoir si les "ingénieurs logiciels" ont bien suivi leurs règles et leurs processus, nous sommes juste ennuyés et le logiciel est nul parce qu'il s'agit de personnes et de la résolution d'un problème, pas d'outils et de technologie - prenez l'outil approprié une fois que vous avez compris le problème - et essayez différents outils au fur et à mesure que vous le comprenez - et non l'inverse. Lorsque le logiciel nous étonne, nous ne nous soucions toujours pas des règles et des processus, mais seulement du fait que nous sommes étonnés et inspirés pour faire des choses similaires. Il semble donc que seuls les ingénieurs se soucient des règles et des processus.
Je trouve que les personnes qui penchent vers une mentalité d'ingénieur ont tendance à se concentrer sur la technologie et le code et sur le fait de savoir si le processus a été suivi correctement (TDD ? MVC ?) et à quel point il se mesure à des règles de structure et de style pour la plupart arbitraires, sans trop se soucier du problème réel résolu ou de ce dont l'utilisateur a réellement besoin. Les meilleurs logiciels sont le fruit d'une attention équilibrée portée à l'utilisateur, au problème et à la technologie, et ce dans cet ordre de priorité. Les meilleurs résultats proviennent généralement de petits changements simples dans les trois, mais si nous nous concentrons uniquement sur l'" ingénierie ", nous ne voyons qu'un aspect de la situation.
Le problème est que la créativité est étouffée lorsque nous sommes obligés de suivre des règles ou de respecter un processus détaillé. Quelques directives générales et un processus, c'est bien pour garder la direction heureuse d'obtenir la valeur qu'elle souhaite, mais cette industrie évolue très rapidement et les véritables innovations du futur ne sortiront pas des " meilleures pratiques ". Les ingénieurs tendent vers ces " meilleures pratiques " tandis que les programmeurs cherchent à innover et à trouver un moyen d'en faire plus avec moins de travail et cela peut ne pas suivre le processus ou arriver selon le calendrier mais cela fonctionnera.
Par exemple : Peut-être que 200 lignes de code Node.js résoudraient ce problème plus facilement et mieux que 10 000 lignes de code Java EE ? Peut-être qu'un petit changement dans la façon dont l'utilisateur perçoit le problème pourrait réduire la complexité de la solution ?
Au point où l'utilisateur, le problème et la technologie(le programmeur) convergent, une réalité et des opportunités intéressantes émergent que seul un programmeur peut voir. Je trouve que les ingénieurs ont tendance à ne pas les voir parce qu'ils ont déjà décidé comment le problème sera résolu avant de comprendre le problème. Le contrôle du changement sera invoqué au fur et à mesure que le problème se révèle dans leur monde.
Je suis programmeur depuis l'âge de 14 ans (autodidacte puis collège) et j'ai suivi tout le cheminement de carrière vers le concepteur, l'architecte et j'ai réalisé que je ne faisais plus que dessiner des diagrammes, écrire des documents et que c'était une perte de temps et pas très satisfaisant. J'ai maintenant 48 ans et je code à nouveau et j'aime ça parce que je peux faire en sorte que les choses se produisent plus rapidement et mieux que je n'ai jamais pu le faire auparavant et faire en sorte que cela fonctionne correctement pour l'utilisateur, pas seulement en parler dans des descriptions de haut niveau et des abstractions.
Alors que certaines personnes estiment que le terme d'ingénieur porte une certaine crédibilité au-dessus d'un modeste " programmeur ", je préfère le terme de programmeur ou de développeur de logiciels parce que l'ingénierie est une discipline par nature et que si une poutre en acier et du béton obéissent aux règles si nous suivons le processus pour les installer, les gens, les ordinateurs et les logiciels ne fonctionnent pas de cette façon - imaginez que l'acier et le béton aient des traits comportementaux et des propriétés qui peuvent être modifiés à la volée.
Pour moi, la programmation et le développement de logiciels sont plutôt un art ou un talent à pratiquer et, bien que cela demande une certaine discipline, il s'agit bien plus de créer quelque chose de nouveau - et, espérons-le, de vraiment génial - qui divertit ou apporte une réelle valeur à quelqu'un.