Una de mis preguntas de entrevista favoritas para candidatos de ingeniería es contarme algo que les gustó y algo que no les gustó de la cultura de ingeniería de su empresa anterior. En el transcurso de unos cientos de entrevistas, esta pregunta de la entrevista me ha dado una idea de qué buscan los buenos ingenieros y qué están tratando de evitar. También reflexioné sobre mis propias experiencias de los últimos seis años trabajando en Google, Ooyala y Quora y destilé algunas cosas que un equipo puede hacer para construir una buena cultura de ingeniería:
1. Optimizar para la velocidad de iteración.
La velocidad de iteración rápida aumenta la motivación laboral y la emoción. Las barreras infraestructurales y burocráticas para la implementación del código y el lanzamiento de funciones son algunas de las razones más comunes y frustrantes que los ingenieros citan durante las entrevistas sobre por qué abandonan sus compañías actuales.
Organizacionalmente, la velocidad de iteración rápida significa dar a los ingenieros y diseñadores flexibilidad y autonomía para tomar decisiones cotidianas sin pedir permiso. Mientras estaba en Google, cualquier cambio visible para el usuario en los resultados de búsqueda, incluso para experimentos de bajo tráfico, requirió la aprobación de Marissa Mayer en una revisión semanal de la interfaz de usuario. No es necesario decir que, si bien esto permitió a Google proteger su marca de búsqueda, obstaculizó significativamente la innovación. La optimización de la velocidad de iteración también significa que existen procesos bien definidos para el lanzamiento de productos, de modo que las cancelaciones no sucedan inesperadamente después de una inversión de tiempo considerable.
Infraestructuralmente, optimizar la velocidad de iteración significa construir una implementación continua con un proceso de implementación rápido, una alta cobertura de prueba para reducir las roturas de construcción y del sitio, pruebas unitarias rápidas para que las personas las ejecuten, y compilaciones y recargas rápidas e incrementales para reducir el tiempo de desarrollo. Merece una mención especial el despliegue continuo, donde los compromisos van inmediatamente a producción. Antes de usarlo en Quora, habría sido difícil para mí internalizar que los beneficios que proporciona hacia la velocidad de iteración superan los riesgos de roturas del sitio, al menos para pequeños equipos de ingeniería. La gente está más entusiasmada con las funciones e incentivada para corregir errores porque los cambios ven el tráfico en vivo rápidamente. También es significativamente más fácil razonar y determinar la fuente de errores para una ventana estrecha de código comprometido en lugar de una semana o más de cambios por lotes.
La velocidad de iteración rápida en equipo significa tener un conjunto de líderes fuertes para ayudar a coordinar e impulsar los esfuerzos del equipo. Las partes interesadas clave en una decisión deben decidir con eficacia y comprometerse con sus elecciones. Para tomar prestada una frase de Bill Walsh, un líder que entrenó a los 49ers a 3 Super Bowls, los líderes fuertes deben “comprometerse, explotar, recuperarse”, lo que significa comprometerse con un plan de ataque, ejecutarlo y luego reaccionar a los resultados. Un equipo paralizado por la indecisión solo hará que los esfuerzos individuales fracasen. [1]
2. Empuje sin descanso hacia la automatización.
En su charla técnica “Scaling Instagram”, el cofundador de Instagram Mike Krieger citó “optimizar para una carga operativa mínima” como una lección clave que su equipo de 13 personas aprendió al escalar el producto a decenas de millones de usuarios. [2] A medida que crece un producto, también lo hace la carga operativa por ingeniero, medida por la relación de usuarios a ingenieros o de características a ingenieros. Facebook, por ejemplo, es conocido por promocionar métricas de escalamiento como apoyar a más de 1 millón de usuarios por ingeniero. [3]
Las soluciones automáticas y las secuencias de comandos repetitivas son importantes porque liberan al equipo de ingeniería para trabajar en el producto real. Asegurar que los servicios se reinicien automáticamente si es posible cuando fallan y que los servicios se replican fácil y rápidamente en el tráfico máximo es la única forma sensata de gestionar la complejidad a escala. A corto plazo, siempre existe la tentadora compensación de aplicar una tirita rápida de forma manual en lugar de automatizar y probar una solución a largo plazo.
El lema de Etsy de “medir cualquier cosa, medir todo” [4] y su soporte de herramientas de gráficos y monitoreo de código abierto como grafito [5] y statsd [6] resaltan un aspecto importante de la automatización: que la automatización debe ser impulsada por datos y monitoreo . Sin monitoreo y registros para saber qué, cómo o por qué algo va mal, la automatización es difícil. Un buen lema de seguimiento sería “medir cualquier cosa, medir todo y automatizar tanto como sea posible”.
3. Cree las abstracciones de software correctas.
El profesor Daniel Jackson del MIT capta bien la importancia de las abstracciones de software [7]:
“Elija las correctas, y la programación fluirá naturalmente desde el diseño; los módulos tendrán interfaces pequeñas y simples; y es más probable que la nueva funcionalidad encaje sin una reorganización extensa. Elija las incorrectas y la programación será una serie de sorpresas desagradables: interfaces se volverán barrocos y torpes, ya que se ven obligados a acomodar interacciones imprevistas, e incluso los cambios más simples serán difíciles de hacer “.
Parte de lo que permitió a miles de ingenieros construir sistemas escalables en Google es que ingenieros realmente inteligentes como Jeff Dean y Sanjay Ghemawat construyeron abstracciones simples pero versátiles como MapReduce [8], SSTable [9], buffers de protocolo [10] y similares. Parte de lo que permitió a la ingeniería de Facebook escalar es el enfoque en abstracciones centrales similares como Thrift [11], Scribe [12] y Hive [13]. Y parte de lo que permite a los diseñadores crear productos de manera efectiva en Quora es que Webnode y Livenode [14] son bastante fáciles de entender y construir.
Mantener las abstracciones básicas simples y generales reduce la necesidad de soluciones personalizadas y aumenta la familiaridad y la experiencia del equipo con las abstracciones comunes. La creciente popularidad y confiabilidad de sistemas como Memcached, Redis, MongoDB, etc. han reducido la necesidad de construir sistemas de almacenamiento y almacenamiento en caché personalizados. Encauzar el enfoque del equipo en un pequeño número de abstracciones centrales en lugar de fragmentarlo en muchas soluciones ad-hoc significa que las bibliotecas comunes se vuelven más robustas, el monitoreo se vuelve más inteligente, las características de rendimiento se entienden mejor y las pruebas se vuelven más completas. Todo esto ayuda a contribuir a un sistema más simple con una carga operativa reducida.
4. Desarrolle un enfoque en la alta calidad del código con revisiones de código.
Mantener una base de código de alta calidad aumenta la productividad de todo el equipo de ingeniería. El código más limpio es más fácil de razonar, más rápido de desarrollar, más susceptible a los cambios y menos susceptible a los errores. Un proceso de revisión de código saludable lo hace posible.
Establecer un proceso para revisiones de código oportunas, ya sea antes o después del compromiso, mejora la calidad del código de varias maneras. Primero, la presión de los compañeros de saber que alguien revisará su código y que cometer un código mal escrito probablemente decepcionará a sus compañeros de equipo es un fuerte elemento disuasorio contra el código hacky, insostenible o no probado. En segundo lugar, las revisiones de código brindan oportunidades para que el revisor y el autor del código aprendan unos de otros para escribir un código mejor.
Si las revisiones del código son fácilmente accesibles para otros miembros del equipo de ingeniería, entonces las revisiones también traen consigo los beneficios de a) aumentar la responsabilidad de revisar el código de manera oportuna, b) permitir a los miembros del equipo, particularmente los más nuevos, modelar de las buenas revisiones de código de otros, yc) acelerar la difusión de las mejores prácticas de codificación.
Los contraargumentos de que los equipos ágiles no tienen tiempo para gastar en revisiones de código ignoran la deuda técnica que puede acumularse fácilmente a partir de un código mal escrito. Ooyala, en sus primeros días de inicio, solía optimizar para obtener tantas funciones como fuera posible, con la ausencia de revisiones de código; el resultado fue que, si bien el producto inicial pudo haber salido al mercado más rápidamente, el código resultante resultó difícil de modificar y pasamos más de un año reescribiendo el código frágil para eliminar la deuda técnica.
Google, en su tamaño, realiza revisiones previas del código para todo el código, pero los equipos más pequeños no necesitan ser tan completos o estrictos, y no todo el código debe revisarse con el mismo rigor. Ooyala más tarde adoptó revisiones posteriores a la confirmación por correo electrónico para cambios centrales o riesgosos mientras estuve allí. En Quora, actualmente llevamos a cabo todas las revisiones de código en Phabricator [15], en su mayoría posteriores a la confirmación, y aplicamos diferentes estándares para el código del modelo o controlador y ver el código; para el código sensible o para el código de los ingenieros más nuevos, haremos revisiones previas al compromiso o trataremos de revisarlas dentro de unas horas después de que se envíe el código.
5. Mantener un ambiente de trabajo respetuoso.
El respeto entre iguales forma la base de cualquier tipo de comunicación abierta. Un lugar donde las personas se sienten cómodas desafiando las ideas de los demás es uno donde las ideas sólidas se forjan a través del debate. Un lugar donde las personas se ofenden fácilmente es aquel en el que se retienen los comentarios cruciales.
En 1948, Alex Osborn describió el enfoque familiar de lluvia de ideas que ha sido popular en los entornos laborales durante las últimas décadas, donde los participantes se unen, dejan de lado las críticas y los comentarios negativos, y reúnen colectivamente ideas creativas sin temor a ser juzgados. [16] El aplazamiento respetuoso del juicio es clave para este tipo de sesión de lluvia de ideas. Investigaciones psicológicas recientes han comenzado a cambiar el enfoque de Osborn, lo que sugiere que alentar el debate en las sesiones de lluvia de ideas en realidad ayuda a evitar el pensamiento grupal y genera ideas más efectivas. A la luz de esta investigación, un ambiente respetuoso se vuelve aún más crítico para que los ataques se dirijan hacia ideas en lugar de ser ad-hominem. [17]
La ingeniería a menudo abarca una amplia gama de áreas (sistemas, aprendizaje automático, producto, etc.) y no todos tienen la misma experiencia en cada área. De hecho, un equipo fuerte probablemente debería tener individuos que sean excepcionalmente fuertes en ciertas áreas, incluso si terminan siendo deficientes en otras. Esto a veces hace que sea difícil, por ejemplo, que un ingeniero de sistemas evalúe la competencia de un ingeniero de producto, pero es importante en una cultura de ingeniería saludable respetar esas diferencias y no juzgar únicamente en función de sus propias fortalezas.
6. Construir la propiedad compartida del código.
Si bien es natural que las personas se vuelvan competentes en varias partes de la base o infraestructura del código, ninguna persona debe sentir que posee o es el único responsable de una sola pieza. Si bien hacer que los individuos se conviertan en expertos que poseen ciertas áreas durante un año o más podría aumentar la efectividad a corto plazo, este enfoque termina perjudicando a largo plazo.
Organizacionalmente, la propiedad de código compartido proporciona tres beneficios. Primero, mantener el factor de bus [18] mayor que uno alivia el estrés del mantenedor y reduce el riesgo para el equipo en caso de que el mantenedor se vaya. También hace que sea difícil para esa persona tomarse un tiempo libre sin preocupaciones. Estoy seguro de que no me pierdo los días en que era el único responsable del procesador de registros de Ooyala y recibí mensajes de texto por alertas de buscapersonas mientras caminaba en volcanes en Hawai.
En segundo lugar, la propiedad compartida capacita a los ingenieros que no están a la altura de las rodillas en el área en particular para que aporten nuevas ideas. Libera a los ingenieros de la sensación de que están atrapados en ciertos proyectos y los alienta a trabajar en una diversidad de proyectos, lo que ayuda a mantener el trabajo interesante y aumenta el aprendizaje y la motivación de los empleados. A la larga, reduce el riesgo organizacional de que algún ingeniero se sienta estancado y decida irse. [19]
En tercer lugar, la propiedad compartida también sienta las bases para que varios miembros del equipo pululan (una técnica de desarrollo ágil) en un problema de alta prioridad cuando sea necesario para terminar un objetivo estratégico más rápidamente. Con la propiedad aislada, la carga generalmente recae en una o dos personas.
Un error que muchas organizaciones de ingeniería cometen demasiado pronto es dividir a todo el equipo en sub-equipos con líderes tecnológicos cuando el equipo aún es pequeño. Los equipos secundarios construyen muros de propiedad que reducen los incentivos para cruzar esos muros, ya que los individuos probablemente serán evaluados por los objetivos de su equipo secundario. Ooyala tenía equipos secundarios mientras estuve allí, y una cosa que me perdí fue la oportunidad de trabajar con algunas personas en otros equipos; Desde entonces, han adoptado un proceso de desarrollo ágil con un enfoque mucho más amplio en la propiedad de código compartido que, según he escuchado, ha dado grandes pasos en la felicidad y productividad del trabajo. Un aspecto de Quora que me ha encantado es que hemos enfatizado los proyectos sobre los equipos, y he tenido la oportunidad de trabajar en proyectos que van desde el crecimiento de usuarios, aprendizaje automático, herramientas de moderación, recomendaciones, análisis, velocidad del sitio y correo no deseado. detección.
7. Invierta en pruebas automatizadas.
La cobertura de prueba unitaria y cierto grado de cobertura de prueba de integración es la única forma escalable de administrar una gran base de código con un gran grupo de personas sin romper constantemente la compilación o el producto. Las pruebas automatizadas brindan confianza y protección significativa contra las refactorizaciones a gran escala que se requieren para mejorar la calidad del código. En ausencia de pruebas automatizadas rigurosas, el tiempo requerido para las pruebas manuales, ya sea por el equipo de ingeniería o por un equipo de pruebas subcontratado, se vuelve fácilmente prohibitivo, y es fácil caer en una cultura de miedo por mejorar un código solo porque puede romperse .
En la práctica, las pruebas automatizadas son un requisito para hacer que la implementación continua funcione a medida que el equipo crece. El tamaño de la base de código crece con el tiempo a medida que crece el producto, pero la familiaridad promedio con la base de código por parte de los miembros del equipo disminuye a medida que se unen nuevas personas. Las pruebas y la validación son más fáciles de realizar por los autores del código original cuando el código está fresco en sus mentes que aquellos que intentan modificar el código meses o años después. Fomentar una cultura de prueba de unidad fuerte desplaza la responsabilidad de validación hacia los autores.
8. Asignar 20% de tiempo.
Gmail encontró sus raíces en el proyecto del 20% de Paul Buchheit, y hackeó la primera versión en un solo día. [20] Google News, Google Transit y Google Calculate también comenzaron y se lanzaron como proyectos del 20%. Utilicé un 20% de tiempo mientras estaba en Google para escribir un marco de Python que hizo que fuera mucho más fácil crear demostraciones de páginas de búsqueda. Si bien el 20% del tiempo de Google puede ser menos productivo ahora que durante los primeros días de la empresa [21], la noción de dejar que los ingenieros pasen el 20% de su tiempo trabajando en algo que no está en su mapa de productos sigue siendo una cuna de innovación para organizaciones de ingeniería más pequeñas .
Ooyala no tenía oficialmente un 20% de tiempo mientras estuve allí, pero tomé algo de todos modos y escribí una herramienta de construcción de línea de comandos para Flex y Actionscript que aceleró los tiempos de construcción del equipo, justo cuando la cadena de herramientas Flex Builder de Adobe comenzó a degradarse, y la herramienta todavía está en uso hoy a pesar de que el equipo de ingeniería casi ha triplicado su tamaño. Atlassian adoptó un 20% de tiempo después de experimentarlo durante un año. [22] Una variación del 20% del tiempo que le gusta a Facebook y que Ooyala agregó más tarde es hackatones periódicos, eventos de toda la noche en los que la regla es que puedes trabajar en cualquier cosa, excepto en tu proyecto normal. [23]
Los enfoques de arriba hacia abajo para la planificación de productos, aunque son necesarios para enfocar la dirección general de la empresa, no pueden explicar la multitud de ideas que pueden surgir de los ingenieros más cercanos al suelo. Mientras los ingenieros sean responsables de su 20% de tiempo y se centren en lo que pueden ser cambios de alto impacto, estos proyectos pueden llevar a grandes avances en el progreso. Sin un tiempo oficial del 20%, todavía es posible, pero es mucho más difícil para los ingenieros y diseñadores probar ideas locas: las dedicadas básicamente tienen que encontrar los fines de semana o días de vacaciones para hacerlo.
9. Construir una cultura de aprendizaje y mejora continua.
Aprender y ser lo suficientemente desafiado son requisitos para lo que el profesor de psicología Mihaly Csikszentmihalyi llama un estado de “flujo”, donde alguien está tan completamente enfocado y motivado por lo que está haciendo que incluso pierde la noción del tiempo. [24] El ciclo de retroalimentación directa e inmediata proporcionado por ciclos de iteración más rápidos es otro requisito.
Las charlas tecnológicas semanales proporcionan foros para que los ingenieros compartan sus diseños o lo que han construido, creando una oportunidad para que los ingenieros se enorgullezcan de su trabajo y para que el equipo aprenda más fuera de su ámbito de trabajo inmediato. Documentar procesos internamente como cómo funciona un servicio de correo electrónico o cómo realizar cambios en la clasificación de un servicio de búsqueda también permite a los ingenieros aprender y explorar cosas nuevas por su cuenta, complementando muy bien el 20% del tiempo. En Quora, hacemos esto ejecutando una instancia interna de Quora donde hacemos preguntas relacionadas con el producto y el desarrollo.
Un corolario de la construcción de una cultura de aprendizaje es centrarse en la tutoría y la capacitación para asegurarse de que todos tengan los algoritmos básicos, los sistemas y las habilidades del producto necesarias para el éxito. Cuanto más crece una organización de ingeniería y se gasta más esfuerzo en el reclutamiento (particularmente en el reclutamiento universitario), se necesita invertir más esfuerzo en mentoría y capacitación. Puede parecer engorroso para un solo mentor pasar una hora por día durante las primeras 4 semanas de un nuevo empleado en el trabajo, pero esa inversión representa menos del 1% del tiempo total que empleará en un año y tiene un apalancamiento significativamente alto en determinar si la persona está preparada para el éxito.
10. Contrata a los mejores.
Contratar a los mejores es la base de muchas de las otras filosofías enumeradas. Es difícil respetar a alguien si crees que es un ingeniero de nivel B. Es difícil dar autonomía a alguien en el desarrollo de productos si no confía en sus instintos de producto. Es difícil reconocer la abstracción correcta para construir sin suficiente experiencia en ingeniería. Es fácil caer en la trampa de construir algo complejo sin otras personas inteligentes que desafíen sus ideas y lo lleven a la simplicidad.
Hay un dicho en torno a Silicon Valley, acuñado por Steve Jobs, que “los jugadores A contratan a los jugadores A. Los jugadores B contratan a los jugadores C”. [25,26] Centrarse en reclutar y contratar a las personas adecuadas es difícil pero crítico para el crecimiento efectivo de una organización de ingeniería. Yishan Wong, quien anteriormente era gerente de ingeniería y director en Facebook, argumentó que la contratación debe ser la prioridad número uno para todos en la organización de ingeniería, no solo para los gerentes, sino también para los ingenieros. [27] También señala con razón la diferencia entre “contratar al mejor” y “contratar al mejor candidato que hayas entrevistado”.
En los primeros días de Ooyala, estábamos tan abrumados con la cola del trabajo de los clientes entrantes que casi cedimos a reducir nuestra barra de contratación para que pudiéramos contratar a suficientes personas para realizar todo nuestro trabajo. Me alegro de que no lo hicimos, ya que la deuda técnica del código de menor calidad y los ingenieros más débiles del equipo habrían acabado dañando al equipo y al producto.
Construir una buena cultura de ingeniería es ciertamente mucho trabajo, pero el ambiente de trabajo resultante bien lo vale.
¿Busca más mejores prácticas en ingeniería? Descargue un capítulo de muestra gratuito de mi libro, The Effective Engineer . Se basa en extensas entrevistas con líderes de ingeniería en las principales compañías tecnológicas de Silicon Valley y está repleto de lecciones, historias e ideas útiles sobre cómo hacer que usted y su equipo sean más efectivos.
——–
[1] Bill Walsh. El puntaje se cuida solo: mi filosofía de liderazgo http://books.google.com/books?id …
[2] Escalando Instagram. http://www.scribd.com/doc/890250 …
[3] Escalando Facebook a 500 millones de usuarios y más. https://www.facebook.com/note.ph …
[4] Medir cualquier cosa, medir todo. http://codeascraft.etsy.com/2011 …
[5] http://graphite.wikidot.com/
[6] https://github.com/etsy/statsd
[7] Daniel Jackson. Abstracciones de software: lógica, lenguaje y análisis http://mitpress.mit.edu/books/so …
[8] http://research.google.com/archi …
[9] ¿Qué es un SSTable en la infraestructura interna de Google?
[10] http://code.google.com/p/protobuf/
[11] https://thrift.apache.org/
[12] https://github.com/facebook/scribe
[13] http://hive.apache.org/
[14] http://www.quora.com/Shreyes-Seshasai/Posts/Tech-Talk-webnode2-and-LiveNode
[15] http://phabricator.org/
[16] Alex Osborn. Tu poder creativo. http://www.amazon.com/Your-Creat …
[17] Pensamiento grupal. http://www.newyorker.com/reporti …
[18] ¿Qué es el “número de autobús” y por qué quieres que sea mayor que 1?
[19] ¿Cómo los ingenieros experimentados en las startups evitan el estancamiento debido al exceso de problemas operativos?
[20] Comunicación con el código. http://paulbuchheit.blogspot.com …
[21] ¿Cómo funciona en la práctica la política de Google Innovation (Google Innovation Time Off) (20% de tiempo)?
[22] http://www.atlassian.com/company …
[23] Dentro del último Hackathon de Palo Alto de Facebook. http://gigaom.com/2011/12/16/exc …
[24] http://en.wikipedia.org/wiki/Flo …
[25] ¿Qué es un “jugador A”? Steve Jobs siempre enfatiza que “A Players” solo quiere trabajar con “A Players”. ¿Cuáles son los atributos de dichas personas?
[26] Lo que aprendí de Steve Jobs. http://blog.guykawasaki.com/2011 …
[27] http://algeri-wong.com/yishan/en …