it-swarm.dev

Quelles sont les principales différences entre les ingénieurs logiciels et les programmeurs?

Quelles sont les principales différences entre les ingénieurs logiciels et les programmeurs?

102
grokus

Lors de l'embauche, nous recherchons une distinction entre quelqu'un qui va nous aider à architecturer notre système, définir des processus, créer des spécifications techniques, implémenter une refactorisation avancée, etc. et quelqu'un qui va nous aider à réaliser des tâches de programmation à partir d'une liste de contrôle . Je crois que vous pourriez appeler le premier un ingénieur logiciel et le second un programmeur.

79
Nicole

Cela dépend vraiment de l'entreprise, car je ne pense pas qu'il existe un cadre juridique pour appliquer une dénomination ou une autre, ou du moins pas que je sache, et cela peut varier d'un pays à l'autre (par exemple, l'utilisation du terme "ingénieur" est en fait assez réglementé en France, mais il existe des variantes qui sont autorisées pour les cas "abusifs").

Cela étant dit, la tendance générale se présente comme suit:

  • Une position programmeur est généralement celle d'un professionnel embauché pour produire le code d'un programme informatique . Cela impliquera que vous savez écrire du code , pouvez comprendre un algorithme et suivent les spécifications . Cependant, cela s'arrête généralement là en termes de responsabilité.

  • Une position développeur est généralement considérée comme un super-type de la position du programmeur . Il englobe les mêmes responsabilités, plus la capacité de concevoir et d'architecturer un composant logiciel , et de rédiger la documentation technique pour cela (y compris les spécifications). Vous êtes capable - au moins techniquement - de diriger les autres (donc, les programmeurs), mais pas nécessairement une équipe (là vient le fuzz ...)

  • Une position ingénieur impliquerait généralement que vous êtes un développeur qui possède un type de diplôme spécifique , certains connaissance de l'ingénierie , et est capable de concevoir un système (comme dans: une combinaison de logiciels composants/modules qui forment ensemble une entité logicielle complète). Fondamentalement, vous voyez une image plus large , et vous êtes capable de concevoir et d'expliquer et le séparer en modules plus petits .

Cependant, tout cela est discutable, et comme je l'ai dit, il n'y a aucune exigence légale à ma connaissance dans les pays US/UK . Cela dit, en France, vous ne pouvez vous appeler "ingénieur" que si vous venez d'une école d'ingénieurs (reconnue par la Commission des Titres d'Ingénieurs ou quelque chose comme ça). Vous ne pouvez pas dire que vous avez un "diplôme d'ingénieur", mais vous pouvez dire que vous avez un "diplôme d'ingénieur" si vous avez étudié une discipline qui relève du portemanteau de l'ingénierie et des technologies.

Il se peut que certains pays aient une distinction similaire, je ne sais pas vraiment.

Revenons au titre d'ingénieur logiciel ... Une fois, un de mes professeurs a dit à notre classe - et à juste titre - que il n'y a rien de tel, à ce jour, que l'on appelle le "génie logiciel". Parce que l'ingénierie de quelque chose (que ce soit un bâtiment, un véhicule, un matériel ...) signifie que vous êtes capable d'envisager sa conception et toutes les phases de sa production, et de prédire avec précision les ressources dont vous aurez besoin, et donc la coût de la production.

Cela est vrai de la plupart des "vraies" disciplines d'ingénierie. Il y a bien sûr des fluctuations (les prix des matériaux varieront avec le temps, par exemple), mais il existe des modèles théoriques très finis (pour la conception et la planification) et des modèles empiriques (pour à peu près garder n'importe lequel des premiers dans des contraintes accessibles) qui vous permettent de prédire la date de fin d'un projet et son utilisation des ressources.

Le problème majeur avec le logiciel est qu'il n'est pas encore là. Nous voulons viser le génie logiciel, mais nous n'y sommes pas encore vraiment. Parce que nous avons un environnement très fluide et dynamique, des contraintes de projet très variables, et encore un manque de maturité rétrospectivement dans nos processus. Bien sûr, nous pourrions dire que nous nous améliorons (mais très discutable avec les données matérielles), mais nous n'y sommes que depuis les années 60 (les projets antérieurs étaient en fait plus proches des ordinateurs uniquement matériels, donc plus proches de la vraie ingénierie, ironiquement) ). Alors que nous construisons des véhicules à moteur depuis plus d'un siècle, des véhicules en général depuis quelques millénaires, et construisons encore plus de millénaires (et nous avons été sacrément bons dans ce domaine dans certaines parties du monde, vous faisant sentir comme nous sont des enfants ridicules qui jouent avec nos nouveaux jouets logiciels flashy en comparaison).

Nous ne parvenons pas à prévoir systématiquement les délais avec précision , nous ne parvenons pas à prédire systématiquement les coûts avec précision , nous ne parvenons pas à identifier et à atténuer systématiquement les risques inhérents et externes de manière efficace et déterministe . Le mieux que nous puissions faire est de produire assez bien guesstimates, et d'accommoder un peu de tampon, tout en essayant de notre mieux pour optimiser les processus afin de réduire les cycles et les frais généraux.

Mais voyez, c'est peut-être ça l'ingénierie. Et c'est ce que, lorsque quelqu'un parle d'un "ingénieur logiciel", il doit penser et viser.

Cela semble donc difficilement interchangeable avec le simple fait de programmer des routines ou l'acte plus avancé de développer des applications.

Pourtant, tout est une question de tendances. Dernièrement, il est assez courant d'avoir une équipe de développement horizontale où tout le monde dans l'équipe est un développeur de logiciels senior (oui, capitales, car cela nous fait nous sentir spéciaux, n'est-ce pas?), Sans réelle distinction d'âge (assez bien, dans mon opinion) et pas tellement la distinction des compétences (uh-oh ...) et des responsabilités (maintenant ça ne peut pas être bon, à part purement pour le buzz PR).

C'est aussi parfois juste une force d'habitude et spécifique à la culture et au jargon d'une industrie. Plus de postes pour la production de logiciels embarqués utilisent des titres pour les ingénieurs logiciels. Surtout parce que cela impliquerait probablement que vous devrez toujours vous occuper dans une certaine mesure du matériel également dans ce domaine, vous vous occupez donc évidemment d'autres aspects de la production et de l'ensemble du "système" que vous produisez. Pas seulement les morceaux qui deviennent fous à l'intérieur. D'un autre côté, vous ne voyez pas vraiment le terme ingénieur utilisé dans les postes de production de logiciels financiers. C'est soit parce qu'il s'agit d'une évolution mimétique de cette industrie par rapport à l'un de ses prédécesseurs (disons, l'ingénierie embarquée trouve ses racines dans l'ingénierie automobile, par exemple), soit parce qu'ils veulent simplement donner plus ou moins de crédit/poids à un poste.

Et pour être sûr de perdre tout le monde dans le brouillard, vous trouverez alors d'autres titres mélangeant les deux (comme "Software Development Engineer" ou "Software Engineer in Test"!), Et puis d'autres soulignant même des ponts plus fous avec d'autres domaines (pensez à "Software Architect" et comment "architecture logicielle" pourrait être un vol sans vergogne de vocabulaire). Et gardez-les à venir: Release Engineer, Change Development Manager, Build Engineer (que l'on va ffaaarrrrrr là-bas aussi). Et parfois simplement "ingénieur".

J'espère que cela a aidé, même si ce n'est pas vraiment une réponse.

Oh, et cela signifie que votre nouvelle entreprise essaie de vous attirer avec un nouveau titre ou qu'elle ne se soucie pas vraiment des titres, ou que vous allez vraiment avoir un poste de niveau supérieur. La seule façon de le savoir est de lire votre cahier des charges, de leur parler et éventuellement de faire un essai et de juger par vous-même. J'espère que c'est la dernière option et que vous en êtes satisfait (et que vous pouvez potentiellement en retirer plus). ;)

130
haylem

Ingénieurs logiciels sont des personnes qui travaillent dans des entreprises qui appellent les personnes qui écrivent des logiciels pour eux "ingénieurs logiciels".

Programmeurs sont des personnes qui travaillent dans des entreprises qui appellent les "programmeurs" des personnes qui écrivent des logiciels.

Il y a aussi développeurs, ou développeurs de logiciels. Ce sont des personnes qui travaillent dans des entreprises qui appellent les personnes qui écrivent des logiciels pour eux "développeurs" ou "développeurs de logiciels", respectivement.

81
Jer

Il y a donc le "Software Engineer", le "Programmer", et aussi le "Developer", "Coder" et vous ne pouvez jamais oublier "SOA expert"

Ce sont tous des termes de marketing pour les personnes qui ne peuvent pas dire quelque chose de significatif dans leur CV, comme leur rôle réel (pas seulement le titre du poste) dans les postes précédents.

Sur les offres d'emploi, la différence est à la personne RH.

Conclusion: chaque personne a sa propre vision de "ce qui fait un bon employé qui travaille avec du code", et certains aiment associer telle ou telle compétence à tel ou tel titre.

Qu'as tu besoin de faire? Les offres d'emploi doivent décrire les compétences requises et les CV doivent expliquer les détails de l'expérience du candidat.

15
Ken Egozi

Pas de différences. Ce sont les mêmes choses. Cependant, les entreprises peuvent avoir des descriptions de poste formelles en utilisant les termes, puis il peut y avoir une signification spécifique à l'entreprise.

10
GrandmasterB

La programmation concerne le code. Le génie logiciel concerne le produit final.

8
darreljnz

Dans certaines juridictions, "l'ingénieur" entraîne l'exigence d'être un ingénieur professionnel, c'est-à-dire avoir un ingénieur. désigation parmi ses qualifications. Cependant, dans d'autres domaines, il n'y a peut-être pas une telle différence car j'étais un "Softwere Design Engineer" travaillant dans l'État de Washington il y a quelques années.

3
JB King

Cela dépend vraiment de la façon dont l'entreprise définit les postes. Il se peut qu'en tant qu'ingénieur logiciel, vous ayez plus d'opportunités de décision de conception, tandis qu'en tant que développeur, ils vous donneraient des diagrammes UML et vous écririez le programme.

Mais, il n'y a pas de véritable définition d'ensemble, de sorte que, sur la base du titre, les gens sauront ce que vous faites ou votre expérience.

Quand j'étais architecte/développeur, mon titre était informaticien, mais je dirais simplement aux gens que j'étais programmeur, car les deux premiers ne sont pas faciles à définir, mais la plupart des gens savent ce que fait un programmeur.

Si un titre est important pour vous, acceptez le nouveau, car l'ingénieur sonne mieux qu'un développeur.

3
James Black

Je ne pense pas qu'il y ait de "différences officielles", pour mon expérience cela pourrait signifier:

  • Certaines entreprises utilisent des ingénieurs logiciels et des développeurs de logiciels pour faire référence à la même chose. Ils utilisent simplement leur terme préféré.
  • D'autres utilisent les deux termes pour différentes positions internes, mais les rôles varient d'une entreprise à l'autre! Dans certains cas, il pourrait y avoir juste une différence sur la fonction (un ingénieur logiciel travaillera sur la maintenance et l'amélioration des systèmes tandis qu'un développeur travaillera sur le produit de l'entreprise), ou pourrait être hiérarchique (l'ingénieur est au-dessus du développeur), ou même l'ingénieur est vraiment dépendant des questions/réponses!

Il y a aussi des termes de mode qui changent ... D'abord le terme était "programmeur", puis "ingénieur logiciel" et semble maintenant être "développeur" ...

Il est préférable de lire la description de poste ou à quelqu'un sur l'entreprise spécifique

3
Khelben

Les ingénieurs logiciels ont tendance à travailler sur des systèmes très volumineux qui prennent plusieurs années-homme à développer, par exemple 5 à 16 ans par exemple. Les programmeurs ont tendance à avoir ce stéréotype de codage et rien d'autre. Mais cela dépend vraiment de l'organisation dans laquelle vous travaillez et de la façon dont les RH commercialisent le rôle, comme expliqué ci-dessus. Ils sont essentiellement la même chose. Ne vous attachez pas trop à un titre, car il est également synonyme.

2
Siamac Nikoo