En Palantir, no es tu título lo que importa. Es lo que haces con él.
Soy un ingeniero de despliegue (FDE) en Palantir. (Si no sabes qué es un FDE, esta pregunta resume muy bien el papel de un FDE en Palantir: ¿Cuál es el día a día de un Forward Deployed Engineer en Palantir?)
En primer lugar, para empezar, el papel de Forward Deployed Engineering en Palantir cubre una variedad de posiciones, desde Deltaworks, que se consideraría un desarrollador principal en cualquier otra empresa; a Echos, que son expertos en la materia, pero no necesariamente de codificación. Sin embargo, la mayoría de los ingenieros desplegados hacia adelante son lo que llamaríamos Deltas, o FDEs técnicos, y voy a suponer que usted está preguntando acerca de ser un Delta en Palantir.
Estoy de acuerdo con uno de los usuarios de Anon que como un FDE, a menudo estás en un papel mucho más reactivo de lo que sería si estuvieras más aislado de un usuario final. Lograr el equilibrio entre el buen diseño y la ejecución es el nombre del juego. Para algunos, este estilo de ingeniería de respuesta en el que rara vez se tiene tiempo para sentarse y diseñar la solución perfecta es difícil de manejar. Para otros, este compromiso constante con los clientes y la creación rápida de prototipos es de lo que trata la ingeniería de software.
Escribo código. Mucho, mucho código. Alrededor de la mitad de mis proyectos son de una sola vez para una necesidad inmediata, y la otra mitad son cosas más experimentales / preventivas. Yo decido y priorizo casi todos mis propios proyectos, dependiendo de lo que veo como la necesidad actual. No pretendo que la mayor parte de mi código sea tan limpio, bien diseñado y probado por unidades como el grueso de nuestro código central. Pero esa es la vara de medir equivocada; considero que mi papel es diferente al de la ingeniería central, pero no menos ingeniería. Mi misión es conocer a fondo a nuestros clientes y sus difíciles problemas, pasados, presentes y futuros, y luego idear formas de resolverlos. Parte de eso es responder con extrema rapidez a las demandas de los clientes a través de mi contacto diario con ellos. A veces, eso es divertirse con la creación de algunas API para una fuente de datos que le interesa al cliente. A veces, se trata de revisar las directrices de red, que son un poco complicadas, para ver cómo podemos configurar nuestros equipos para que se ajusten a los protocolos de la organización. Pero una gran parte de ella es prototipo de soluciones nuevas y locas a los problemas difíciles, y, si funcionan bien, el mantenimiento de algunos de ellos y ver a sus hijos florecer en una característica del producto ampliamente utilizado a través de muchos sitios de los clientes.
Aquí están las cosas que he trabajado de manera significativa en la última semana o tres:
- Experimentar y prototipos de un sistema para manejar casi en tiempo real el análisis de ciertos tipos de datos de salud enorme. Estoy construyendo en la parte superior de una tecnología de back-end Palantir existente, así como un servidor de agregación que he construido cuando yo era un interno FDE. Un montón de técnicas MapReduce-como y el trabajo de almacenamiento en caché aquí, así como las visualizaciones y cuadros de mando que pueden actualizar de forma asíncrona.
- Tratando con un cliente potencial y los abogados para resolver los problemas en un contrato que estamos tratando de hash.
- Arreglar los errores de la interfaz de usuario en algunos de los plugins personalizados que hemos desplegado.
- Instalar servidores (físicamente en rack (y en el proceso de aprendizaje que un enchufe L5-30 definitivamente no encaja en un zócalo L6-30 …) (y aprendiendo que un enchufe L5-30 definitivamente no cabe en un enchufe L6-30…), haciendo la configuración de la red, y configurando la pila de Palantir y estableciendo las tuberías de integración de datos).
- Escribiendo consultas SQL para obtener datos en un formato que sería más rápido de importar, lo cual es importante para un socio que tiene datos a escala de terabyte en la base de datos que no tiene suficientes recursos cuando se trata de RAM.
- Escribir una extensión de la plataforma para permitir mirar los datos a un nivel agregado por defecto (para una perfección significativamente mejor en este caso), a continuación, tirar de los cortes de los datos en bruto subyacentes en el fondo de forma invisible si se desea.
- Trabajar con nuestros pasantes impresionantes en algunos proyectos interesantes. Uno de ellos es el prototipo de una plataforma de genómica. Otro es construir una forma superflexible y enchufable de crear y modificar visualizaciones de tableros. Otro consiste en modelar algunas tendencias medioambientales. Y otro es el análisis de los datos de descubrimiento de fármacos.
- Trabajar con el equipo de ingeniería principal para probar algunas de las próximas características de computación backend con un cliente beta. Tener un contacto constante con nuestros equipos de productos principales es muy valioso para ambas partes.
- Volar al medio oeste para reunirse con un posible cliente interesado. Pasamos cerca de dos horas hablando de las fuentes de datos y la escala, los diversos puntos de contacto en nuestras dos organizaciones, las cuestiones legales, y los requisitos de hardware y de red.
- Actualización de algunos plugins a nuestras nuevas versiones de la API, y la adición de algunas características solicitadas mientras yo. Estos fueron escritos por FDEs, incluido yo mismo, y ahora se utiliza en una docena de sitios de los clientes. Además, los FDEs de Palantir pueden hacer rotaciones como ingenieros de núcleo. E incluso si no hago una rotación, puedo comprobar el código base del producto principal si hay algo que quiero mejorar. (Todavía tendrá que ser aprobado y revisado por el código, por supuesto.)
Así que, como un Palantir FDE, mi opinión personal es que, de hecho, te prepara muy bien para un papel de ingeniería de software más tradicional, especialmente aquellos en las nuevas empresas y las empresas más pequeñas y las que tienen un componente de cara al cliente. Personalmente no veo que el contacto constante con los clientes sea una distracción de la ingeniería. Para mí es más bien un componente necesario para crear buenos productos y características. Entiendo que hay muchas personas que se entusiasman más con los retos de ingeniería en su forma más pura cuando se abstraen de cualquier preocupación del cliente o del negocio, pero es innecesariamente conflictivo secuestrar toda la ingeniería de software sólo en ese extremo del espectro. Todos somos ingenieros. Todos estamos ahí para resolver problemas difíciles e interesantes, pero tenemos diferentes impulsos y enfoques. No hay un camino mejor que otro.
Por citar a nuestra reclutadora de FDE, Amanda Gregg, «Si le preguntas a 10 ingenieros diferentes de Forward Deployed Engineers lo que hacen, obtendrás 10 respuestas diferentes. Hay una gran oportunidad para definir tu propio desarrollo».