Le logiciel paie-t-il plus que le matériel pour l’ingénierie informatique ?


Le sophisme du salaire.

J'ai déjà écrit à ce sujet.


Il faut voir le monde en couches, un peu comme le modèle OSI (OSI model - Wikipedia), le modèle Open System Interconnect.

Le niveau le plus bas est le matériel.


Au-dessus, vous avez le logiciel.

C'est le sujet de mon espace Quora (HW accelerators eating AI).

Prenons un exemple, concevons un CPU (Ryzen, Xeon, Epyc, Core ix).

Aujourd'hui, en 7 nm, vous avez besoin de concepteurs d'ASIC, d'architectes, d'ingénieurs de vérification, de personnes chargées du firmware, de la validation du silicium, d'ingénieurs DFT et de test, ...

Dans une grande entreprise, quelques centaines de personnes s'impliquent dans le grossier de ce projet.

Sur le processeur, il y a un système d'exploitation et des pilotes.

Dans les processeurs à usage général comme Ryzen et Core ix, vous avez plusieurs systèmes d'exploitation.

Sur le système d'exploitation, vous avez plusieurs applications qui tournent au-dessus.

Pour les quelques centaines qui sont impliquées dans la conception du CPU, il y a des centaines de milliers à quelques millions de personnes du logiciel impliquées du niveau de l'OS à celui de l'application.

Vue simplifiée, je l'admets, mais l'image est claire.

Dans le logiciel, généralement, les bugs sont une réalité acceptée.

Patchs, mises à jour, failles zero day, Bill Gates nous y a habitués en l'espace de deux décennies.

Il y a des entreprises qui arrivent encore à être grandes et à respecter des règles strictes parce qu'elles ont besoin de passer à l'échelle, on pense à Google.

Cela ne veut pas dire qu'elles écrivent du code sans bug.

Mais au niveau de la puce, un jeu de masques de puce est fixé.

S'il y a un bug dans l'exécution de telle instruction tout en allant chercher telle donnée dans telle plage d'adresses, cela peut être mortel pour une entreprise.

Nous ne parlons pas de sécurité ici, nous parlons de bugs dans le matériel qui empêchent les logiciels d'exécuter certains codes.

La puce doit être conçue et vérifiée de manière à ce que le risque de bug majeur soit réduit à presque zéro.

Et que le risque de bug mineur soit faible, très faible.

Parce que tous les niveaux au-dessus sont impactés.

Le matériel est la fondation sur laquelle le logiciel se construit.

Les excellentes ressources logicielles sont difficiles à trouver, alors le monde s'est contenté de la règle empirique de Gates, " good enough ".

Il suffit d'y jeter plus de ressources mais moins chères.

Puisque le pool de ressources logicielles est tellement plus grand que le pool de ressources matérielles, les problèmes du logiciel sont pires dans le matériel.

Qui peut repérer un ingénieur logiciel exceptionnel ?

Qui peut repérer un ingénieur matériel exceptionnel ?

La connaissance du matériel n'est pas aussi indulgente pour les bugs du silicium.

Dans le matériel, on se contente d'un faible coût, d'une grande quantité.

Mais dix athlètes ne font pas un champion olympique.

La quantité rend la plupart des conceptions de grosses puces stressantes, extrêmement inefficaces et frustrantes.

Et au niveau du PCB, de la carte mère, c'est similaire.

La conception de matériel est bonne pour une chose, pour comprendre les fondements.

Mais ce n'est pas une carrière, et le salaire ne va pas en valoir la peine.

La plupart des ingénieurs ASIC commencent dans le secteur et le quittent au bout de 5 à 10 ans.

Pourquoi ?

Parce qu'un concepteur de site web travaille depuis chez lui et gagne sa vie, a une grande flexibilité, n'a pas besoin de reporter ses vacances ou de devoir faire face à des catastrophes potentielles dans un jeu de masques silicium à 1 million USD.

La conception d'applications a besoin d'une sorte d'ordinateur portable ou de bureau et vous êtes prêt à partir.

Travail à domicile, forte demande, flexibilité.

La responsabilité, le contexte, l'expertise, le niveau de stress presque inexistant par rapport à un système sur puce de 7 nm avec un budget de quelques centaines de millions USD.

The world works that way.

Like Ohm’s law, the path of least resistance.

Nobody is going to win against Ohm’s law.

My answer wants to explain Ohm’s law, so you know the rules of the game, how it is played.

Digital VLSI design and methodology is my passion, but it is a hobby.

It gives insight in opportunities and how things are evolving in high-tech.

But the opportunities lie in the big markets, all things software.

The game is not about what you like to do, it is about what is the biggest market with the lowest requirements.

That is the smart thing to do, that is how the game is played.

The stoic says: observe.

Never attach a label of good or bad.

Observe, understand the game and play once you understand the rules.

Older answers that might be of interest:

https://www.quora.com/q/lusocxepxzcqvagw/Why-salary-should-never-be-important-for-an-employee

La réponse de Bert Verrycken'à la question suivante : " Comment les personnes qui changent fréquemment d'emploi répondent-elles à la question de l'entretien : " Pourquoi avez-vous quitté votre dernier emploi ? "

Que le logiciel soit avec vous !

.