EE vs informatique: effet sur les approches, les styles des développeurs? [fermé]

Existe-t-il des différences systématiques entre les développeurs de logiciels (ingénieurs sw, architectes, quel que soit le titre du poste) avec une formation en électronique ou en ingénierie, par rapport à ceux qui sont entrés dans la profession par l'informatique?

Par électronique, je veux dire un diplôme d'EE, ou un bricoleur d'électronique autodidacte, d'autres types d'ingénieurs et de physiciens expérimentaux.

Je me demande si l'entrée dans les professions de création de logiciels à partir d'une solide connaissance des tongs, des tampons à trois états, des temps de montée du front d'horloge et ainsi de suite, conduit généralement à une approche distincte des problèmes, des mentalités ou des compétences supérieures dans certaines spécialités et manque des compétences chez les autres, par rapport aux types informatiques qui sont pleins de concepts comme les types de données abstraits, l'orientation des objets, la normalisation de la base de données, qui parlent de "fermetures" dans les langages de programmation - des choses qui n'ont guère de sens pour la foule de fer à souder jusqu'à ce qu'elles apprendre suffisamment de programmation.

Le monde réel, j'en suis sûr, offre une gamme sauvage d'exceptions individuelles, mais pour la plupart, pouvez-vous dire qu'il existe des différences globales? Est-ce que cela aurait des implications sur l'embauche, par exemple (pour inventer quelque chose) "ne jamais embaucher un lutteur d'électrons pour faire la conception d'une base de données"? Le fait de connaître des différences pourrait-il aider les demandeurs d'emploi à trouver quelque chose de plus efficace? Ou fournir des éclaircissements ou des conseils pratiques à ceux qui se retrouvent inadaptés à un poste particulier?

(Btw, je n'ai jamais pris de cours d'informatique; mon impression de ce qu'ils couvrent est floue. Je suis moi-même un type d'électronique / physique / art.)

Ayant un mineur EE et un majeur CS, j'ai travaillé avec les deux groupes académiquement. Je n'ai jamais occupé un emploi où je concevais des produits de style EE, mais j'en ai consommé beaucoup en travaillant pour des entreprises avec des choses comme le PLC, et donc avoir pu comprendre (à partir d'une formation) ce qui se passait était agréable . Je ne peux donc pas dire que je connais à 100% le comportement et les caractéristiques du lieu de travail, mais je peux décrire les academicdifférences entre les deux dans une certaine mesure.

Les gens d'EE ont tendance à se concentrer sur les détails et à connaître la mise en œuvre exacte. Si ce n'est pas 100% mappable, ils ne l'aiment pas. Les gens d'EE optimiseront leur fonctionnement pour supprimer les détails inutiles s'ils le peuvent.

Les gens du SE ont tendance à aimer les couches et la compartimentation de la logique. Les gens de SE ne se soucient pas des projets gonflés. Les gens de SE ont tendance à être très orientés mathématiques. Ils ont tendance à penser en termes d'équations et comment résoudre des problèmes à partir d'un concept de modèle. Les jointures sont plus intuitives pour ce groupe, comme le travail de base de données. Plus vous allez loin, plus vous avez tendance à voir des gens qui parlent couramment des choses comme la programmation fonctionnelle. Ce n'est tout simplement pas un terrain sûr pour une personne chargée de l'EE.

Les deux personnes connaissent des trucs comme les cartes de Karnaugh, il y a donc beaucoup de chevauchement dans ces domaines. Réduction logique, ce genre de chose.

D'accord, c'est ma réponse subjective. J'espère que ça aide.

Si je devais généraliser, voici ce que mon expérience a été:

• Les ingénieurs (ou simplement EE) ont tendance à mieux faire dans la "perfection du petit". Étant donné une petite tâche de programmation, ils réfléchissent très longuement à tous les cas marginaux et sont plus susceptibles de finir par créer un logiciel très robuste. Il est généralement basé sur une approche de conception descendante, car c'est ce à quoi ils sont habitués dans le matériel. Cela implique généralement l'utilisation de machines d'état, car elles sont habituées à les concevoir pour le matériel, et cela correspond à l'approche du «grand design». D'un autre côté, ils ne pensent pas autant à l'évolutivité ou à la maintenabilité.

• Vos développeurs traditionnels sont mieux à même de gérer une grande complexité, principalement parce que la formation pousse à décomposer les problèmes en petits morceaux plus faciles à gérer. On leur apprend à éviter la grande conception, à séparer les problèmes, à écrire des tests et à réussir les tests. En règle générale, il y a beaucoup de petits cas de bord manqués, simplement en raison de la complexité et du temps, mais ceux-ci finissent par être couverts. Les développeurs ont tendance à tirer parti du fait qu'il ne s'agit que de logiciels et que cela devrait (ou est) facile à modifier. Quand EE travaille avec du matériel, ils n'ont pas cet avantage, et je pense qu'il faut du temps pour faire la transition.

Comme je l'ai dit, c'est mon expérience généralisée. Ce n'est pas vrai dans tous les cas.

D'après mon expérience, les types EE semblent concevoir des programmes linéaires et ne pas incorporer les couches d'abstraction. Les types CS semblent être à l'aise.

Aucun commentaire sur les différences de qualité ou leur absence.

Je doute que vous verriez beaucoup de différence dans le type habituel d'applications commerciales ou Web sur lesquelles la plupart des gens finissent par travailler, une fois que les deux ont quelques années d'expérience à leur actif. Toutes les choses que vous citez comme source de confusion pour la «foule de fer à souder» sont des compétences de programmation normales. Essentiellement, vous répondez à votre propre question - quelqu'un sans expérience en programmation peut apprendre la programmation, mais jusqu'à ce qu'il le fasse, il n'est pas programmeur. Quelqu'un avec un esprit logique et analytique trouvera beaucoup plus facile d'apprendre à bien programmer que quelqu'un qui ne le fait pas - ce serait le seul avantage que je puisse penser pour un bricoleur électronique autodidacte.

L'informatique (par opposition à l'ingénierie informatique) est principalement des mathématiques, comme (aux niveaux supérieurs) sont les diverses autres sciences telles que la physique - mais c'est une sorte très différente de mathématiques. Si vous avez fait une science différente, vous aurez également fait des mathématiques et vous devriez donc pouvoir vous mettre au courant contrairement à quelqu'un qui n'a pas de formation en mathématiques. Bien sûr, très peu de programmeurs ont vraiment besoin de connaître la théorie des ensembles, le big-O ou quoi que ce soit d'autre - certainement pas à un niveau élevé de toute façon.

J'ai commencé avec un BSEE, je suis allé travailler à la conception de circuits logiques pour un grand laboratoire de R&D téléphonique et (il y a environ 40 ans) j'ai réalisé que la plupart de ce que je construisais pourrait éventuellement être fait avec un programme informatique. Je suis donc retourné et j'ai obtenu un diplôme MSCS.

J'ai toujours été intéressé par l'architecture informatique et ce qui se passe au niveau matériel. La majeure partie de ma carrière a été consacrée à la conception de systèmes de microcontrôleurs intégrés, où j'essaie de trouver la meilleure correspondance entre ce qui se fait dans le matériel et ce qui se fait dans le micrologiciel. Cependant, j'ai fait pas mal de programmation Web et une certaine conception de base de données.

Sans ma formation en CS, je pense que j'aurais beaucoup plus de mal à saisir des concepts plus abstraits. Outre de nombreux langages d'assembleurs différents, j'ai utilisé C, C ++, C #, Pascal, Delphi, Perl, PHP et certains Lisp. J'essaie actuellement d'apprendre Ruby et Python. Conception OO avec laquelle je suis assez à l'aise. Programmation fonctionnelle Je ne le suis pas (encore).

Idem pour les bases de données. Je comprends la normalisation. J'ai des problèmes avec certains des JOIN les plus ésotériques et je les évite. Je ne suis pas vraiment à l'aise avec quelque chose à moins de comprendre ce qui se passe sous le capot.

Je veux pouvoir "voir" comment l'ordinateur exécuterait le programme dans ma tête.