Comment un ingénieur compilateur se compare-t-il à un ingénieur logiciel ordinaire ? Techniquement, le travail au jour le jour, l’ensemble des compétences, etc.


Je suis un ingénieur compilateur. Cela signifie que j'ai une spécialité. Je connais quelques trucs que la plupart des autres ingénieurs logiciels ne connaissent pas. Et, je connais probablement des coins obscurs du langage, que vous ne pouvez même pas imaginer. Je peux même imaginer des cas de coin pour des langages que je ne connais pas, parce que je connais la technologie sous-jacente et ce que les implémenteurs sont susceptibles d'avoir fait.

Cependant, cela a un prix. Il y a des choses que je connais moins que l'ingénieur moyen. Je ne sais pas grand-chose sur l'écriture d'une interface utilisateur, surtout pas une interface graphique. Je n'en sais peut-être pas autant sur le web, les réseaux, les bases de données ou, surtout, sur la logique d'entreprise. Ce sont toutes des choses que je n'ai pas beaucoup pratiquées.


Cela s'est avéré être un problème chez Google.

Ce n'était pas qu'ils voulaient que je programme d'abord en Python, puis en Java, deux langages que je n'avais pas utilisés avant de travailler là-bas. Beaucoup d'ingénieurs compétents peuvent apprendre un langage dans le temps qu'il faut pour comprendre l'application, surtout s'il y a des échantillons existants d'applications connexes à regarder. C'est pourquoi, les gens vous disent que le langage de programmation n'a pas d'importance, ne faites pas une fixation dessus.

Non, c'est qu'ils m'ont demandé de concevoir un algorithme de partage de charge après avoir travaillé chez Intel où nous avions des clients télécoms avec des exigences de partage de charge en temps réel. Et chez Intel, nous voulions prouver que vous pouviez les résoudre avec des ordinateurs COTS (commodity off-the-shelf), c'est-à-dire n'importe quelle puce qu'Intel poussait pour son segment de marché. Cela nécessitait des algorithmes très intelligents. Je me suis donc assis pour concevoir un de ces systèmes.

Ce n'était pas du tout ce que l'équipe sœur voulait construire. Ils voulaient juste une base de données simple à utiliser comme une file d'attente pour les travaux en attente et qui se connectait à leur système de comptabilité. Cependant, ils n'ont pas réalisé (et moi non plus au début) que je surconcevais sérieusement la solution. Je pense qu'ils considéraient toutes les choses que je me préoccupais de faire faire au système comme des "cloches et des sifflets" et supposaient simplement que sous tout cela se trouvait leur simple base de données. Ils ne m'ont donc pas laissé construire ce que j'avais conçu, et il a fallu neuf mois pour surmonter ce problème de communication. À ce moment-là, le projet était en retard.

Donc, si vous voulez un ingénieur compilateur, vous en voulez probablement vraiment un. Vous pouvez même dire à votre patron de me chercher et si je ne suis pas disponible, je peux en connaître un qui l'est.

Mais, si vous ne voulez pas d'un ingénieur compilateur, je ne suis probablement pas la personne que vous devriez embaucher. Vous voulez quelqu'un qui connaît le domaine dans lequel vous travaillez. C'est pourquoi tant d'annonces d'emploi énumèrent tant d'exigences. Une personne qui fait le bon type de travail, répondra souvent à la plupart de ces exigences parce que c'est ce qu'elle a fait à son dernier emploi et celui d'avant et ainsi de suite.

Et si je peux concevoir un système de base de données simple, vous devez être certain que je sais que c'est ce dont vous avez besoin. Ne supposez pas que je comprends vos besoins en matière de base de données simplement parce que j'ai construit des analyseurs syntaxiques pour SQL. Ce que je connais de SQL n'a pas grand-chose à voir avec la conception de tables sous forme normalisée.

La conception d'un système de base de données est un processus complexe.