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