Au sein de Palantir, ce n'est pas votre titre qui compte. C'est ce que vous en faites.
Je suis un ingénieur de déploiement avancé (FDE) chez Palantir. (Si vous'êtes confus sur ce qu'est un FDE, cette question résume assez bien le rôle d'un FDE chez Palantir : Quel est le quotidien d'un ingénieur déployé vers l'avant chez Palantir ?)
Pour commencer, en préambule, le rôle d'ingénieur déployé vers l'avant chez Palantir couvre une variété de postes, des Deltaworks, qui seraient considérés comme un développeur de base dans n'importe quelle autre entreprise ; aux Echos, qui sont des experts en la matière, mais qui ne codent pas nécessairement. Cependant, la majorité des ingénieurs déployés vers l'avant sont ce que nous appellerions des Deltas, ou des FDE techniques, et je'vais supposer que vous'demandez comment être un Delta chez Palantir.
Je'serais d'accord avec l'un des utilisateurs Anon pour dire qu'en tant que FDE, vous êtes souvent dans un rôle beaucoup plus réactif que si vous étiez plus isolé d'un utilisateur final. Trouver l'équilibre entre une bonne conception et la réalisation est le nom du jeu. Pour certains, ce style d'ingénierie réactive où vous avez rarement le temps de vous asseoir et de concevoir la solution parfaite est difficile à gérer. Pour d'autres, cet engagement constant avec les clients et le prototypage rapide est ce qu'est le génie logiciel.
J'écris du code. Des tas et des tas de code. Environ la moitié de mes projets sont des projets uniques pour un besoin immédiat, et l'autre moitié sont des trucs plus expérimentaux/préemptifs. Je décide et priorise presque tous mes propres projets, en fonction de ce que je considère comme le besoin actuel. Je ne prétends pas que la plupart de mon code est aussi propre, bien conçu et testé que la majeure partie de notre code principal. Je considère que mon rôle est différent de l'ingénierie de base, mais pas moins important. Ma mission est d'être intimement familier avec nos clients et leurs problèmes difficiles, passés, présents et futurs, puis de trouver des moyens de résoudre ces problèmes. Une partie de cette mission consiste à répondre extrêmement rapidement à toutes les demandes des clients grâce à mes contacts quotidiens avec eux. Parfois, cela consiste à s'amuser à bricoler rapidement des API pour une source de données qui intéresse le client. Parfois, il s'agit de parcourir des directives de réseau un peu abrutissantes pour voir comment nous pouvons configurer nos boîtiers afin de respecter les protocoles de l'organisation. Mais une bonne partie consiste à prototyper des solutions nouvelles et folles à des problèmes difficiles et, si elles fonctionnent bien, à en maintenir certaines et à voir vos enfants s'épanouir en une fonctionnalité de produit largement utilisée sur de nombreux sites clients.
Voici les choses sur lesquelles j'ai'travaillé de manière significative au cours des trois dernières semaines :
- Expérimenter et prototyper un système pour gérer l'analyse en quasi temps réel de certains types de données de santé gigantesques. Je'construis par-dessus une technologie back-end Palantir existante, ainsi qu'un serveur d'agrégation que j'ai construit lorsque j'étais stagiaire FDE. Beaucoup de techniques de type MapReduce et de travail de mise en cache ici, ainsi que des visualisations et des tableaux de bord qui peuvent se mettre à jour de manière asynchrone.
- Parler avec un client potentiel et des avocats pour trier les problèmes dans un contrat que nous'essayons de hacher.
- Réparer les bugs d'interface utilisateur dans certains des plugins personnalisés que nous'avons déployés.
- Installer des serveurs (les mettre physiquement en rack (et dans le processus apprendre qu'une fiche L5-30 ne s'adaptera très certainement pas dans une prise L6-30...). ,faire la configuration du réseau, et configurer la pile Palantir et mettre en place les pipelines d'intégration de données).
- Écrire des requêtes SQL pour obtenir des données dans un format qui serait plus rapide à importer, ce qui est important pour un partenaire qui a des données à l'échelle du téraoctet dans la base de données qui est sous-dotée en termes de RAM.
- Écrire une extension à la plate-forme pour permettre de regarder les données à un niveau agrégé par défaut (pour une perforation significativement meilleure dans ce cas), puis tirer des coupes des données brutes sous-jacentes en arrière-plan de manière invisible si désiré.
- Travailler avec nos stagiaires géniaux sur quelques projets cool. L'un d'eux consiste à prototyper une plateforme génomique. Un autre est de construire un moyen super-flexible et pluggable pour créer et modifier des visualisations de tableaux de bord. Un autre porte sur la modélisation de certaines tendances environnementales. Et un autre sur l'analyse des données de découverte de médicaments.
- Travailler avec l'équipe d'ingénierie de base pour tester certaines fonctionnalités de calcul backend à venir avec un client bêta. Avoir un contact constant avec nos équipes de produits de base est inestimable pour les deux parties.
- S'envoler vers le Midwest pour rencontrer un client potentiel intéressé. Nous avons passé environ deux heures à parler des sources de données et de l'échelle, des différents points de contact dans nos deux organisations, des questions juridiques et des exigences en matière de matériel et de réseau.
- Mettre à niveau quelques plugins vers nos nouvelles versions d'API, et ajouter quelques fonctionnalités demandées pendant que j'y suis. Ceux-ci ont été écrits par des FDE, dont moi-même, et sont maintenant utilisés sur une douzaine de sites clients. Ils'sont "core" dans tout sauf le nom.
Alors, les FDE de Palantir peuvent faire des rotations comme ingénieurs de base. Et même si je ne fais pas de rotation, je peux vérifier la base de code du produit de base si je veux améliorer quelque chose. (Il'devra toujours être approuvé et examiné par le code, bien sûr.)
Donc, en tant que FDE de Palantir, mon opinion personnelle est que cela vous prépare en fait très bien à un rôle plus traditionnel d'ingénierie logicielle, en particulier ceux dans les startups et les petites entreprises et ceux qui ont une composante de contact avec le client. Personnellement, je ne considère pas le contact permanent avec les clients comme une distraction de l'ingénierie. Pour moi, il s'agit plutôt d'un élément nécessaire à la création de bons produits et de bonnes fonctionnalités. Je comprends qu'il y a beaucoup de gens qui sont plus excités par les défis de l'ingénierie dans leur forme la plus pure quand elle est abstraite de tout client ou préoccupation commerciale, mais c'est inutilement conflictuel de séquestrer tout le génie logiciel à cette extrémité du spectre. Nous sommes tous des ingénieurs. Nous sommes tous là pour résoudre des problèmes difficiles et intéressants, mais nous avons simplement des impulsions et des approches différentes. Aucune voie n'est meilleure qu'une autre.
Pour citer notre recruteur FDE Amanda Gregg, "Si vous demandez à 10 ingénieurs déployés en avant différents ce qu'ils font, vous'aurez 10 réponses différentes. Il'y a une énorme opportunité de définir votre propre développement."