7 lecciones que he aprendido en Mozilla -

¿Sabes cuál es la señal de un buen trabajo? Usted aprende. Mucho. Y rápido. Y lo mejor de todo es que sus empleadores y sus colegas lo alientan y fomentan. Ese ha sido el caso en mis (casi) tres años en Mozilla. Mozilla continúa sacando lo mejor de mí y empujándome a hacer más y mejor. Las siguientes son siete de las docenas de lecciones que aprendes en Mozilla.

Índice de contenidos
  1. Barco. Barco. Barco.
  2. Está bien admitir la derrota
  3. Está bien ser el novato
  4. Escribir código “básico” en sitios grandes sigue siendo un desafío e importante
  5. Está bien dejar el trabajo
  6. La localización importa
  7. La gente usa los rastreadores de errores de manera diferente

Barco. Barco. Barco.

Nunca había oído hablar de “implementación continua” hasta que llegué a Mozilla; siempre había trabajado en proyectos para sprints y luego proporcionó una versión etiquetada con git de las mejoras del sprint determinado. El problema era que los errores en la etiqueta anterior se agregaban a la siguiente etiqueta y, por lo tanto, pasaban algunas semanas sin que el error se solucionara en producción, aunque el error se había solucionado en el tronco poco después de su informe. Impulsar la producción varias veces al día promueve la sensación de fluidez y le permite corregir errores AHORA en lugar de hacerlo a intervalos establecidos. La implementación continua también garantiza que los desarrolladores no esperen hasta creer que una función está completa al 100% antes de impulsarla; ¡Muchas veces el 90% es suficiente para una primera ejecución!

Está bien admitir la derrota

“Admitir la derrota” es un poco duro, pero Mozilla me enseñó que estaba bien decir “¿Sabes qué? Esto no funcionará” o “Podemos hacerlo mejor” y luego empezar de nuevo. Empezar de nuevo es un proceso desgarrador, pero los desarrolladores no son perfectos, no podemos prever todos los problemas posibles y empezar de nuevo es mejor que implementar una solución que siempre tendrá agujeros. He visto muchos proyectos y tareas en Mozilla reiniciarse y mejorar exponencialmente. Persona fue abandonada para cuentas de Firefox, se eliminó la aplicación Firefox original para iOS, etc. Al final, es importante tener un producto sólido y no una bola de cinta adhesiva, y tirar la cinta para que el producto final esté bien.

Está bien ser el novato

Lo último que quieres que te marquen cuando llegas a un nuevo trabajo es un “novato”, y dado que Mozilla está un paso por delante del 99% de las tiendas web que existen, hay muchas posibilidades de que al menos llegues sintiéndote como el novato durante algún tiempo. Lo que descubrí en Mozilla es que está bien ser novato. ¿Por qué? Porque todo el mundo quiere ayudarte a convertirte en un novato y luego en un experto, porque todo contribuye a ayudar a la causa general. Tengo que creer que ese es el caso en la mayoría de las organizaciones. Si alguna vez te hacen sentir tonto o inferior por saber menos, estás en el lugar equivocado. Está bien ser un novato, al menos por un tiempo.

Escribir código “básico” en sitios grandes sigue siendo un desafío e importante

Me dicen que minimizo mis logros en Mozilla; es decir, algo que considero básico no es tan fácil como creo. Cuando señalo que no he hecho nada lo suficientemente significativo en Mozilla, la gente señala que completé el rediseño de MDN. Siempre respondo con "un desarrollador de 2 o 3 años podría haber hecho eso". Lo que no tomo en cuenta es la responsabilidad: cometer un error y millones de desarrolladores en todo el mundo habrían visto esos errores. Entonces, a pesar de no tener AJAX en MDN, el hecho de que no bloqueé nada importante fue un logro en sí mismo.

Está bien dejar el trabajo

En el pasado me han tildado de adicto al trabajo y, aunque tímidamente lucho contra esa etiqueta, probablemente sea cierto. Después de todo, llegué a donde estoy hoy, pero trabajo horas extras por mi cuenta en todos los trabajos que he tenido. Cuando nació mi hijo en marzo de 2013, comencé a necesitar salir del trabajo un poco “temprano” y la culpa de hacerlo me estaba comiendo viva. Todavía estaba haciendo mis 40 horas, pero no podía aceptar el hecho de no estar ahí todo el tiempo, especialmente en una organización global con empleados trabajando a todas horas. Con la ayuda de mi jefe me di cuenta de que está bien juzgar cada día por sus logros en lugar de por un reloj; después de todo, corregir un error de prioridad grave en 15 minutos es más importante que 10 errores de prioridad baja en un día.

La localización importa

Habiendo trabajado con Dojo Toolkit en el pasado, sabía que la localización siempre fue un factor, pero pasar a Mozilla fue una enorme llamada de atención de que la localización era esencial. Mozilla no solo tiene empleados en todos los países, sino que también tiene contribuyentes y usuarios en aún más países, por lo que si pierde un mensaje localizado en el código, lo sabrá rápidamente.

La gente usa los rastreadores de errores de manera diferente

Cualquier Mozillian que haya trabajado conmigo se reirá de este. Siempre he conocido los rastreadores de errores como listas definitivas de “VAMOS A HACER ESTO”, pero otros usan los rastreadores de errores como muros de ideas, publicaciones de sugerencias esperanzadoras y publicaciones de quejas de preferencias personales. He aprendido a no tomar las listas de errores como un evangelio y, en cambio, centrarme en las listas priorizadas proporcionadas por los gerentes de proyecto. Este ha sido un cambio realmente difícil para mí, pero casi 3 años después me he dado cuenta de este hecho.

Te podría interesar...

Deja una respuesta

Subir