Comment expliqueriez-vous que le génie logiciel est plus spécialisé que les autres domaines du génie? [fermé]

Je travaille avec quelqu'un qui insiste sur le fait que tout bon ingénieur logiciel peut se développer dans n'importe quelle technologie logicielle, et l'expérience dans une technologie particulière n'a pas d'importance pour construire un bon logiciel. Son analogie était que vous n'avez pas besoin de connaître le produit en cours de construction pour savoir comment construire une chaîne de montage qui fabrique ledit produit.

D'une certaine manière, c'est un compliment à regarder d'un œil tel que "si vous êtes bon, vous êtes bon à tout", mais d'une certaine manière, cela banalise également la profession, comme dans "Codemonkey, go sling code". Sans expérience dans certains frameworks logiciels, vous pouvez rapidement avoir des ennuis, et c'est important.

J'ai essayé d'expliquer cela, mais il ne l'a pas acheté. Y a-t-il des opinions ou des pensées différentes à ce sujet pour aider à expliquer que mon expérience en une chose ne se traduit pas en toutes choses?

mais d'une certaine manière, cela banalise également la profession, comme dans "Codemonkey, go sling code".

Je dirais tout à fait le contraire. Un bon ingénieur logiciel aurait la capacité de conceptualiser, d'architecter et de concevoir un logiciel de qualité indépendant de la technologie. L'extrémité opposée de ce spectre est le .NET ou Java ou PHP uniquement "codemonkey" qui est bon pour recevoir des directives ou des spécifications et utiliser l'outil pour implémenter le logiciel.

Un ingénieur logiciel n'a pas besoin d'être un maître de tous les outils, mais devrait avoir une assez bonne compréhension de haut niveau de la majorité d'entre eux, de ce qu'ils apportent à la table et de ce qui sera probablement le plus approprié pour le projet donné. . Je m'attendrais à ce qu'un singe de code soit seulement un maître de leur expertise proclamée dans un outil spécifique.

Je ne ferais pas confiance à un ingénieur Ford qui ne sait pas comment faire le travail du mécanicien.

Cependant, le génie logiciel est l'un de ces domaines où, dans de nombreux cas, nous sommes censés être l'ingénieur, le constructeur et le mécanicien en même temps.

Je suis d'accord dans une certaine mesure avec la personne avec laquelle vous travaillez. Un bon ingénieur logiciel s'occupe des principes généraux de conception et de production de logiciels. Les langages et cadres réels sont des détails.

Cela ne veut pas banaliser la facilité avec laquelle vous pouvez choisir de nouveaux langages et cadres. Il y a toujours une courbe d'apprentissage qui leur est associée, mais le fait est que c'est une courbe, pas un mur vertical pour un bon ingénieur logiciel.

Un bon ingénieur logiciel possède une vaste expérience dans un certain nombre d'outils et de technologies différents. S'il ne le fait pas, comment peut-il choisir le meilleur outil pour le travail? Pour sortir le vieux cliché, à un homme qui sait utiliser un marteau, chaque problème ressemble à un clou. Même si vous n'êtes pas un expert avec un tournevis, cela vaut la peine de les comprendre pour que vous puissiez reconnaître une vis comme non seulement un ongle à l'allure amusante.

Version TLDR: les autres disciplines de l'ingénierie ont besoin de connaître les matériaux qu'ils utilisent (par exemple, les architectes doivent savoir quelle charge les matériaux qu'ils utilisent dans leur conception peuvent supporter ). Les langages et les cadres que nous utilisons pour le génie logiciel ont certaines limites et nous devons les connaître pour les concevoir et les développer efficacement.

Notre action comporte deux phases distinctes. Le premier est la conception conceptuelle. Il s'agit d'une conception de système de haut niveau et de bas niveau (par exemple en utilisant UML). Les conceptions de haut niveau peuvent théoriquement être indépendantes de la mise en œuvre (même si parfois une conception de haut niveau doit prendre en compte des spécificités telles que la plate-forme de base de données, le middleware standard, etc.). Les conceptions de bas niveau sont un peu plus délicates. Vous pouvez concevoir les spécificités de la logique métier sans y mettre les détails de l'infrastructure et, encore une fois, ceux-ci peuvent théoriquement être indépendants de la plate-forme.

La deuxième phase est la programmation proprement dite. Alors que certains considèrent la programmation comme une construction, d'autres (dont moi) soutiennent que le codage est toujours une discipline de conception (en PPP , Bob Martin fait référence à un article où l'auteur avance un très bon argument à cet effet, je ne l'ai pas avec moi maintenant, mais je mettrai à jour cette réponse avec un lien vers cet article). La construction réelle se produit lorsque vous appuyez sur la compilation et est en fait gratuite.

Tout comme un architecte doit prendre en compte des éléments tels que la résistance à la traction et à la compression des matériaux de construction qu'il utilise, un ingénieur logiciel doit également connaître les capacités de la plate-forme contre laquelle il se développe lors de l'écriture de code. Je dirais qu'une conception de système de bas niveau n'est pas très efficace si elle ne prend pas également en compte les choix de plate-forme.

En tant que diplômé d'un programme d'études en génie logiciel, je peux dire que votre collègue a partiellement raison. Un bon ingénieur logiciel se concentre sur l'application des mathématiques, des statistiques, de l'informatique et de l'expérience dans le domaine afin de construire un système. Les méthodes qu'un ingénieur logiciel utilise sont généralement indépendantes de la technologie et du langage - les outils importent moins que les principes sous-jacents.

Cela dit, l'analogie de votre collègue est erronée. La compréhension des problèmes de domaine est essentielle à toute discipline d'ingénierie. Si vous ne comprenez pas parfaitement le problème que vous essayez de résoudre et les personnes que vous essayez de satisfaire, il devient infiniment plus difficile de trouver la meilleure solution possible à leurs problèmes.

En fin de compte, l'ingénierie logicielle (et toute discipline d'ingénierie) consiste à appliquer un certain nombre de concepts pour résoudre un problème. Si vous utilisez fréquemment les mêmes outils, vous deviendrez plus compétent avec ces outils. Il vous sera plus facile d'identifier les problèmes que ces outils peuvent résoudre, les risques ou les pièges liés à l'utilisation de ces outils, puis d'utiliser ces outils pour construire une solution.

Son analogie était que vous n'avez pas besoin de connaître le produit en cours de construction pour savoir comment construire une chaîne de montage qui fabrique ledit produit.

C'est presque certainement incorrect. Les ingénieurs de production spécialisés doivent bien comprendre les produits dont ils ont la charge.

Dans tous les cas, une meilleure analogie est avec les diplômés des cours de génie mécanique: même si tout le monde commence (en mécanique et en logiciel) avec à peu près les mêmes compétences, personne ne reste "un ingénieur en mécanique", mais se spécialise plutôt dans les types de les choses qu'ils construisent. De même, le développement de logiciels comporte également des sous-domaines très distincts.

Pour revenir à l'analogie de la chaîne de montage, chaque chaîne de montage est différente pour chaque produit, et différents types de développement logiciel nécessitent des méthodologies différentes - vous ne construisez pas votre logiciel de sécurité de la même manière que vous construisez un jeu.

Il y a une courbe d'apprentissage impliquée dans différentes spécialisations. Je parle des différences entre la programmation embarquée / temps réel, la programmation d'applications Web, la programmation de systèmes / OS, la programmation de clients lourds, le développement mobile, etc.

Quelqu'un qui est expert dans un type de programmation pourrait ne pas être en mesure de passer immédiatement à un autre en raison d'exigences différentes. Bien sûr, un ingénieur logiciel a les bases pour le faire, mais il faut du temps pour se spécialiser dans quelque chose.

Je suis d'accord avec la prémisse suggérée par votre collègue, bien que j'ajouterais une mise en garde.

Un bon ingénieur logiciel sera en mesure de construire de bons logiciels dans n'importe quelle technologie ..... après avoir fait un peu d'apprentissage dans la nouvelle technologie.

Il peut y avoir des bizarreries qui ne sont pas évidentes au début, mais un bon ingénieur logiciel les apprendra bientôt.

Je pense que ce qu'il veut vraiment dire, c'est que ce n'est pas parce qu'un développeur a 2 ans d'expérience solide en C # qu'un meilleur ingénieur logiciel avec une formation Java, qui n'a jamais fait de C # auparavant, ne pouvait pas venir, apprendre C #, et rapidement devenir un meilleur développeur C # que le premier gars.

En d'autres termes, vous ne devez pas nécessairement escompter le gars Java pour un travail, JUSTE parce qu'il a "fait le temps" en C #.

Exemple concret: le cadre logiciel que vous jugez si essentiel d'avoir une expérience spécialisée n'existait probablement pas il y a 10 ans, ou a subi une transformation importante si tel était le cas. La nature même de notre métier ne permet pas de se spécialiser pour l'ensemble de sa carrière. Selon vos niveaux de compétence respectifs, votre spécialisation vous donne un avantage entre 1 et 6 mois par rapport à quelqu'un qui n'a jamais utilisé votre cadre particulier. Après cela, vous êtes au pair.

Je travaille pour une compagnie d'hélicoptères et les ingénieurs aéronautiques ici sont spécialisés par les types d'avions avec lesquels ils peuvent travailler. Ils doivent être "de type". Techniquement, ils pouvaient travailler sur n'importe quoi, du Robinson R22 au Jumbo Jet, mais pas sans la formation de conversion.

Je pense que c'est assez similaire à l'ingénierie logicielle, sauf que la «formation à la conversion» est plus informelle pour les ingénieurs logiciels.

En parlant à un peintre, lui diriez-vous qu'il n'aurait aucun problème avec la sculpture?

Apprendre une nouvelle langue ou des spécificités dans un nouveau domaine est similaire à un artiste qui s'occupe principalement du crayon et de l'encre, apprenant à peindre (ou vice-versa). C'est ce dont parlent la plupart des autres réponses, comment votre ami a partiellement raison - beaucoup des mêmes concepts s'appliquent.

Mais apprendre à un peintre à sculpter un objet 3D ou à écrire un roman (les deux formes d'expression artistique) est une bête complètement différente. C'est le point de vue dont vous venez.

Les logiciels basés sur le Web nécessitent un type de réflexion complètement différent de celui des logiciels de bureau. Les deux sont complètement différents lorsqu'ils sont appliqués aux jeux par rapport à un environnement de travail. Je soupçonne que travailler sur un système d'exploitation ou des systèmes intégrés nécessite également de penser différemment (mais je n'ai aucune expérience avec eux). Et je ne doute pas qu'il existe d'autres domaines qui nécessitent également une façon de penser différente.

Résumé et exemples:

«L'art» comprend les sculptures, les romans, les bandes dessinées et les peintures. Les chevauchements de compétences comprennent:

• Forme corporelle et théorie des couleurs: sculptures, bandes dessinées et peintures
• Communication textuelle: romans et bandes dessinées

... Etc. Mais comme mentionné ci-dessus, il est peu probable qu'un artiste de bande dessinée réussisse bien sur son premier roman. Ils doivent penser différemment.

De même, il existe des chevauchements dans différents domaines de la programmation / génie logiciel, mais la plupart d'entre eux sont trop distincts pour pouvoir simplement intervenir. Par exemple:

• Algorithmes: OS / systèmes intégrés, jeux et autres endroits dont vous avez souvent besoin pour optimiser la vitesse ou la mémoire. Rarement un gros problème dans le développement Web
• Conception: Partout dans le développement Web, mais pas très important dans les systèmes intégrés sans interface utilisateur.
• Logiciel client / serveur: La mentalité «ne pas faire confiance au client», qui n'existe pas nécessairement dans certains domaines (jeux solo et autres logiciels de bureau autonomes, ce qui, je l'avoue, est plus rare de nos jours).

Tous les travailleurs de la construction routière sont-ils en mesure d'utiliser chaque équipement et machinerie sur le chantier? La réponse est non. Il y a des machines qu'ils connaissent et connaissent probablement les autres. La même chose devrait être vraie pour les ingénieurs logiciels, il y a un nombre de langages et de frameworks que vous connaissez parce que vous travaillez avec eux tous les jours, mais il ne faut pas s'attendre à ce qu'ils connaissent les opérations exactes des autres sans formation. C'est comme prendre le marteau-piqueur et lui confier la tâche de conduire la bétonnière.

Les langages de programmation et les frameworks ne sont que des outils dans une ceinture d'outils d'ingénieurs logiciels. Il existe certains outils que vous connaîtrez mieux que d'autres en raison de leur expérience. En fin de compte, le meilleur outil est la compréhension des concepts et principes de base de l'informatique. Choisir des langages et des frameworks, c'est simplement sélectionner quel tournevis utiliser sur quelle vis.

Ce genre de chose arrive souvent là où je travaille.

J'aime comparer avec la profession de l'oncle de ma femme - un mécanicien automobile.

Il est spécialisé dans Mercedes, il peut appliquer ses connaissances à d'autres marques de voitures, et il le fait - certaines plutôt rares, mais cela ne signifie pas qu'il peut réparer immédiatement la marque X parce que vous dites que cela fait du bruit.

Je programme en quelques langues, mais cela ne signifie pas que je sais pourquoi Safari sur votre MacBook recharge les pages à chaque fois que vous changez d'onglet (appel étrange d'aujourd'hui). Je vais essayer de comprendre pourquoi, mais je ne vais pas savoir du haut de ma tête parce que le domaine informatique est ÉNORME .

Dans les deux cas, après avoir passé un peu de temps dans nos domaines respectifs, nous pourrions probablement trouver la réponse, mais pas dans les dix secondes que les gens pensent parce que "mais vous travaillez avec des voitures" ou "mais vous travaillez avec des ordinateurs".

Est-ce que les gens disent de telles choses à leur médecin local (comme "J'ai mal à la tête quelle maladie ai-je?") - Je parie qu'ils le font parce que la plupart des gens ne comprennent vraiment pas qu'il y a plus dans une profession que leurs attentes immédiates de ladite profession.