Cómo y por qué enseñamos a los no ingenieros a usar GitHub en Thread

En Thread, una de nuestras creencias centrales es que la tecnología permite un gran cambio. Esto es importante para nuestro producto, pero también es importante para la forma en que trabajamos internamente.

Debido a esta forma de trabajar, tratamos de representar todo en los datos: productos, medidas, estilos, proveedores, ubicaciones en nuestro almacén, resoluciones de tickets de soporte y muchas cosas más en las que nunca pensaría.

Todos estos modelos de datos tienen el costo de necesitar una forma para aquellos en la empresa que los usan para mantener los datos. Esto significa construir interfaces de edición, con validación, diseño de base de datos y trabajo front-end. A menudo simplemente no tenemos tiempo para hacer esto: las nuevas funciones son de mayor prioridad y, además, un ingeniero puede actualizar algunos archivos de datos cuando sea necesario, ¿verdad?

Si bien esta es una solución mucho más rápida a corto plazo, un ingeniero tendrá que cambiar de contexto de su trabajo, ver cómo se publica el lanzamiento y asegurarse de que nada salga mal, todo eso perjudica la productividad. Sin embargo, quizás lo más importante es que la persona que necesita la información actualizada ahora ya no es propietaria de todo el proceso y depende del cronograma de otra persona.

En última instancia, este proceso puede ser útil para obtener una función rápidamente, pero causa demasiada fricción para funcionar a largo plazo.

Una mejor solución

Recuerdo cuando GitHub lanzó por primera vez su editor web, no me impresionó. ¿Por qué alguien editaría el código en un navegador web? ¿Por qué usaría un editor que solo podría cambiar un archivo por confirmación? Bueno, años después me di cuenta de que no soy el mercado objetivo para el editor.

En Thread ahora enseñamos regularmente a aquellos fuera del equipo de ingeniería cómo contribuir a nuestra base de código a través de la interfaz web de GitHub, para que tengan el control de actualizar los datos que necesitan para trabajar de manera efectiva.

Ahora hemos tenido más contribuyentes a nuestra base de código principal que tienen roles no técnicos, que todos los ingenieros y contratistas que han contribuido a lo largo de los años.

Ha funcionado?

Como ingeniero en el equipo de producto, puedo concentrar mis esfuerzos en crear funciones que beneficien a nuestros clientes y mover métricas, en lugar de crear más interfaces CRUD. También puedo enviar pruebas A / B más rápido, ya que a menudo podemos omitir las herramientas internas para la versión de prueba a favor de editar datos a través de archivos de datos, para empezar. Cuando lleguemos a la fase de entrega de un proyecto, podemos dedicar tiempo a las interfaces de edición, ya que no solo tendremos una idea del valor de la función, sino también una mejor idea de cómo les gustaría a nuestros usuarios internos interfaces para trabajar.

Tampoco se limita a los archivos de datos; muchas páginas en thread.com son esencialmente HTML estático, páginas como nuestras preguntas frecuentes de entrega, política de devoluciones o términos y condiciones. Al aprender a usar GitHub, nuestro equipo de operaciones puede mantenerlos actualizados sin pedir ayuda. Nuestro equipo de talentos también puede editar nuestro sitio de empleos, reaccionando diariamente a las preguntas comunes que surgen al hablar con los candidatos.

Todo esto significa que los miembros de nuestro equipo fuera del equipo de ingeniería pueden tener mucha más propiedad sobre su trabajo y tener menos fricción para hacer los cambios que su experiencia les dice que es necesario.

¿Cómo lo hacemos?

Lo primero que hacemos es ejecutar tutoriales de GitHub de vez en cuando cuando tenemos algunos principiantes nuevos para enseñar. Cubrimos los conceptos básicos de lo que es un repositorio, comparándolo con los historiales de revisión de documentos en Google Docs, lo que significa confirmar un archivo y qué es una rama. Solo hablamos de estos temas de alto nivel, ya que no cubrimos la interfaz de línea de comandos en nuestro formato de tutorial actual.

A continuación, veremos cómo editar un archivo en la interfaz web de GitHub, cómo escribir un mensaje de confirmación, qué es una solicitud de extracción y qué significa el informe de estado de compilación de Jenkins.

Por último, pedimos a los colaboradores no técnicos que elijan un ingeniero que esté disponible en Slack para presionar el botón de combinación una vez que la construcción esté verde.

Problemas que hemos encontrado

En general, creemos que esta es una gran victoria para el equipo en su conjunto, y estamos planeando continuar la capacitación y alentar a más contribuyentes a medida que crecemos, pero hemos cambiado nuestro proceso ligeramente a medida que esto ha evolucionado.

En primer lugar, hemos utilizado roles de GitHub y ramas bloqueadas para evitar compromisos accidentales con el maestro. Para alguien que no está tan familiarizado con el control de versiones y las ramas en particular, la interfaz web de GitHub no es particularmente clara acerca de cuándo se realiza una confirmación en la rama maestra o en una nueva rama. En Thread, nuestra rama maestra se despliega continuamente sin necesidad de intervención manual, lo que resultó en varios compromisos que rompieron el sitio y causaron el tiempo de inactividad.

En cuanto a todos los problemas de tiempo de inactividad, ejecutamos 5 Whys sin culpa y nos dimos cuenta de que, en retrospectiva, podríamos haber detectado estos problemas con las pruebas unitarias ejecutadas antes del despliegue, es probable que no detectemos todo y, por lo tanto, la introducción de ramas protegidas para alentar la revisión del código fue un peso manera de resolver el problema

En segundo lugar, algo en respuesta a este problema, hemos comenzado a escribir algunas pruebas unitarias que simplemente verifican la estructura de los datos en los archivos de datos, o para verificar que todos nuestros archivos de plantilla de Django se analicen con éxito como plantillas válidas. Particularmente en el caso de los archivos de datos, estos normalmente no serían algo que esperaríamos probar, pero como ahora queremos que los archivos sean editables por personas sin un conocimiento del código, pueden ser útiles para detectar errores simples .

Por último, como normalmente estamos usando Python para nuestros archivos de datos, descubrimos que la sintaxis no es particularmente intuitiva y puede tomar un tiempo acostumbrarse. Para abordar esto, hemos escrito documentación con un poco más de detalle que si estuviera escrita para un ingeniero. Esta documentación también está en el repositorio y es editable por todos, por lo que alentamos a los no ingenieros a actualizar y aclarar las instrucciones a medida que aprenden, y a enseñarse mutuamente cómo editar ciertas partes del sitio.

Avanzando

Consideramos que este experimento fue un éxito y lo continuaremos en el futuro previsible. Cuando estamos diseñando archivos de datos para que sean editables, intentaremos incluir instrucciones detalladas en los archivos mismos, posiblemente incluyendo ejemplos de copia / pegado.

Ya intentamos que nuestras fallas de prueba tengan mensajes de error informativos con detalles sobre cómo solucionar dónde podemos, pero debido a la complejidad de interpretar el resultado de la prueba, actualmente no exponemos a Jenkins a miembros del equipo no técnicos, aunque técnicamente pueden inicie sesión con inicio de sesión único. Esta es quizás la próxima oportunidad que tenemos para mejorar la experiencia de contribución y algo que podríamos probar en el próximo lote de nuevos entrantes que pasan por el tutorial.

Para finalizar, recomiendo a todos los desarrolladores que vean si hay oportunidades en sus empresas para que los miembros del equipo no técnicos contribuyan a sus bases de código. Hay beneficios para la productividad en ambos lados, más empatía entre los equipos y un sentimiento más fuerte de propiedad sobre el trabajo para aquellos que ya no dependen de los desarrolladores para hacer cambios por ellos. La fricción reducida también significa ciclos de retroalimentación más cortos, que pueden ser transformadores para lo que otros pueden lograr en su trabajo, todo sin el alto costo del tiempo de desarrollo en las interfaces de edición.