Recrutement
Travailler dans des systèmes existants

Définition

La capacité de travailler compte tenu des contraintes et de la complexité des bases de code, des infrastructures et des systèmes existants.

Pourquoi est-ce important chez Palantir ?

Chez Palantir, notre activité exige de travailler avec les systèmes, le code et les infrastructures qui existent chez nos clients et chez nous. Que nous améliorions des fonctionnalités déjà en usage, que nous déployions un produit Palantir nécessitant une intégration à d’autres systèmes ou que nous trouvions des moyens d’échanger des données entre les systèmes de nos clients et leurs instances Palantir, il y a toujours des composants tiers à gérer. Même lorsque nous travaillons exclusivement sur notre propre code, un développeur passera beaucoup plus de temps à débuguer, modifier et étendre le code existant qu’à écrire de nouvelles séquences d’instructions à partir de zéro.

En dépit de termes tels que « génie logiciel » et « informatique », la programmation est un domaine créatif. Chaque développeur fait des choix différents, que ce soient des décisions stylistiques de formatage du code ou des choix structurels de haut niveau. Chaque projet utilise des langages différents, des bibliothèques diverses et présente des exigences qui lui sont propres en ce qui concerne l’interfaçage à d’autres systèmes.

Il est important de pouvoir prendre des décisions fiables et en connaissance de cause à propos de la bonne manière de corriger un bug ou d’ajouter une fonctionnalité, même si vous ne comprenez pas parfaitement le système dans son ensemble. Imaginez une interruption d’exploitation sur un site client. Comment remettre le système en ligne ? Quels sont les risques potentiels et comment les éliminer sans lire le code du début à la fin ? Ou nous devons peut-être ajouter une nouvelle fonctionnalité importante. Le code n’a peut-être pas été écrit comme vous l’auriez fait, mais comment lui greffer proprement la fonctionnalité voulue ?

Comment se préparer

Il est courant de regarder des lignes de programme et de penser « C’est mauvais. Ça devrait être réécrit. » Prenez le temps de rejeter cette envie. Explorez le code que vous avez écrit dans le passé. Vous avez probablement constaté depuis, que si vous deviez recommencer, vous écririez sans doute des lignes entièrement différentes. Lisez votre ancien code et rappelez-vous pourquoi vous avez fait ces choix à l’époque et pourquoi ils étaient logiques (ou non).

Échangez vos projets avec un ami. (Si vous êtes à l’université, ne le faites que si vous avez déjà rendu votre travail !) Pouvez-vous rapidement comprendre comment son code fonctionne dans l’ensemble ? Devez-vous lire chaque ligne de chaque fichier ou pouvez-vous formuler des hypothèses, les tester et les améliorer au besoin ?

Choisissez un projet open source. Si vous avez de la chance, il disposera d’un système de suivi dans lequel vous pourrez trouver quelques rapports de bugs. Choisissez-en un. Ça n’a pas besoin d’être un bug important (en fait, commencez par quelque chose de simple). Comment trouvez-vous le bon endroit pour le corriger ? Avez-vous des hypothèses sur la façon dont le projet est organisé ? Comment les testez-vous ? Même si le changement à effectuer est minime, combien de temps vous a-t-il fallu pour trouver l’endroit où il doit être fait ?

Si vous ne détectez pas de bug à corriger, ajoutez une nouvelle fonctionnalité ou un autre comportement. Cela n’a même pas besoin d’être logique. Si vous utilisez systématiquement le mauvais raccourci clavier dans un programme, modifiez le code source pour imposer votre propre combinaison de touches. Ajoutez une nouvelle boîte de dialogue de confirmation lorsque vous voulez quitter l’application. Réorganisez l’interface utilisateur.

Si vous avez systématiquement recours aux mêmes frameworks ou bibliothèques dans votre travail, choisissez un projet qui en utilise d’autres. Entraînez-vous à comprendre aussi efficacement que possible comment les choses fonctionnent en général. Entraînez-vous à penser en termes de profondeur comme en termes d’ampleur. Ce n’est que par l’expérience que vous apprendrez à choisir entre l’une ou l’autre approche initiale.

Comme dans le cas de nombreuses compétences, les meilleurs professeurs sont le temps et la répétition. Vous tirerez le meilleur parti de votre investissement si vous êtes délibéré et réfléchi. Ne faites pas que débuguer votre programme. Analysez votre travail et demandez-vous si vous l’avez bien fait. Y aurait-il eu une meilleure façon de trouver le bug ? Avez-vous ignoré un test en échec, négligé un avertissement, fait une hypothèse qui s’est révélée fausse ? Votre correction a-t-elle provoqué le plantage de votre programme à un autre endroit ? En êtes-vous sûr ?

Plus vous vous exposerez à des environnements nouveaux et inconnus, plus vous serez capable de les gérer efficacement. Sachez comment et quand regarder au-delà des détails pour voir la situation dans son ensemble.