Become a Better Developer, Beyond Coding
•Download as PPTX, PDF•
1 like•104 views
Slide presented at Campus Party 2017 - Guadalajara Mexico
Recommended
More Related Content
Recently uploaded
Recently uploaded (14)
Featured
Featured (20)
Become a Better Developer, Beyond Coding
- 1. Who am I? Janet Maldonado Sr. Frontend Engineer | Engagement Lead Sutter Health 10+ years of experience @rianet Front-Bay Meetup
- 2. become a better Developer beyond Coding By Janet Maldonado @rianet
- 6. don’t break any window
- 9. does it make sense?
- 11. make others life easier
- 12. commit to your deadline
- 13. forget the employee role treat as client
- 14. Wrap - Up Success Talent Problem Solving Courage
- 15. El que es perico donde quiera es verde @rianet
- 16. Sometimes even the best hunter can’t catch the prey… @rianet
Editor's Notes
- Hola Guadalaajara! Gracias a talent woman por invitarme a ser parte de este foro. Que gusto volver a ver caras conocidas, gracias por venir y para los que no me conocen yo soy Janet Maldonado, Ingeniera en Sistemas computacionales con mas de 10 anos de experiencia en el desarrollo de software. Los ultimos 2 anos los he pasado trabajando en Silicon Valley. Actualmente trabajo para Sutter Health, el segundo proveedor de servicios de salud mas grande del norte de California. Mi rol ahi es Sr. Frontend Engineer y dirijo un equipo de ingenieros de frontend, donde nuestra mision es desarrollar applicaciones para mejorar la calidad de atencion a pacientes y proponer soluciones a diferentes problemas en la industria medica mediante software. Me pueden encontrar en twitter como @rianet y tmb soy fundadora del meetup front-bay donde regularmente hacemos webcasts de temas relacionados a frontend y tecnologia.
- El tema del que quiero hablarles esta tarde es como convertirte en un mejor desarrollador de software mas alla de la programacion. Quiero hablarles de la experiencia que he tenido a lo largo de estos anos trabajando con todo tipo de ingenieros, de frontend, backend, fullstack, disenadores, testers hasta google developer experts. Y creanme a todos se nos van las cabras. A veces podremos hacer el codigo mas elegante, usando las arquitecturas mas sofisticados, aplicando las mejores practicas en la industria, pero que creen, a veces no es suficiente o no lo es todo para ser percibido como un profesional. Quiero traer a la mesa cuales son esas habilidades, mindsets y comportamientos que a veces no prestamos mucha atencion y que no nos ensenan en ninguna universidad. La idea de mi charla se ve reflejada con esta imagen, como ir de opaco a brillante.
- Quiero hablarles de como a veces nuestro trabajo es percibido justo como en la imagen de la izquierda, pero que puedes hacer para que te veas como el de la derecho.
- De como ir de lo caotico a lo ordenado
- De como ser la mejor version de ti mismo, jaja, (bueeno, creo que ya entendieron el punto) jaja
- El primer punto que quiero tocar es el de las ventanas rotas. Uh? Que tienen que ver ventanas rotas con ser un mejor desarrollador de software? Hay una teria muy interesante que puede ser aplicada realmente a cualquier ambito. Se trata de la teoria academica de ventanas rotas, donde hicieron experimentos sociales dejando carros abandonados con ventanas rotas en diferentes puntos de NYC y que sucedio?, curiosamente, emperazon a romper mas ventanas, a vandalizer, se genero mas desorden, caos incluso incidencias criminales. Lo cual me hace sentido porque secede lo mismo en otros aspectos, como en tu propia casa, si empiezas a dejar la ropa tirada en el piso, la cama sin tender, la basura hasta el tope, pronto estaras rodeado de caos. Cierto? Exactamente lo mismo pasa con nuestros repositorios de codigo. No rompas ninguna ventana, si llegas a un equipo, analiza lo que estan haciendo, sigue los patrones y mejores practicas, apegate a las nomenclaturas, estructuras de archivos, una cosa tan simple como usar la misma identacion en en codigo hace la diferencia sin entrar en la guerra si 2 o 4 espacios, eh?, jaja. Por otro lado si en tu lugar de trabajo no existen convenciones, ni reglas, ni guias que seguir armalas, es tu momento de brillar. Hay muchos recursos en linea con guias de mejores practicas segun el lenguaje de programacion y el stack que utilices.
- Probablemente voy a sonar como una mama, pero si, este punto se trata sobre lavar tus platos sucios. A que me refiero? Ejemplo concreto: El developer peppe pecas, tenia una historia de usuario para implementar una grafica de barras donde comparar ingresos y gastos para una visualizacion de un banco en linea. El chavo probo d3, flot.js, chart.js y que creen? al final solo utilize uno y se le olvido remover las dependencias que no utilizo. A eso me refiero con lavar tus platos sucios, cuida tu codigo, remueve dependencias no usadas, console logs, es muy comun que estemos utilizando diferentes tecnicas para resolver un problema, pero regresa en ese momento a borrar variables, clases, funciones que no se usan o cualquer cosa ‘hardcodeada’. Ya hay muchas herramientas que nos ponen estos problemas en evidencia como cualquier “linting” a nuestro codigo. Como puedes minimizar este problema?, si estas trabajando con git flow y pull requests de tus ramas de codigo (y si no deberias usarlos), revisa tu propio codigo antes de mandar tu PR, no importa el sabor de git que uses, siempre tendras la seccion para revisar el codigo que agregas, borras o modificas. Tomate esos 5 minutos extra para revisalo, encontraras cosas que se te habian olvidado. Asegurate de siempre hacerlo, porque si no alguien mas hara ese trabajo, te van a regresar su codigo, regresaras a modificar lo que ya habiar “terminado” y te va afectar en como eres percibido. Trata de eliminar ese overhead tomando esos 5 min extra para revisarte.
- Muchas veces en el mundo del software nos toca trabajar con personas o clientes que no entienden de cosas tecnicas, donde muchas veces terminamos en la mano con requerimientos no tienen sentido. Un verdadero expert se pone en los zapatos de usuario, trata de entender el context, la audiencia de tu aplicacion y el problema que tratas de resolver. Hay una pregunta te puedes hacer para evitar tragos amargos de desarrollar funcionalidades inutiles. La proxima vez que tengas un requerimiento en mano, recuerda esta imagen y preguntate estoy construyendo esa puerta a ningun lado? Si no tiene sentido levanta la mano, a tiempo. Demuestra que eres el expert, que tu estas de lado del usuario final y que tu estas interesado en entregar un producto functional.
- Me pase un rato tratando de encontrar una imagen que pudiera describir este punto mejor que mis palabras y esta fue la major que encontre. Jaja Muchos podran argumentar que esta torta o lonche cumple su function para alimentarnos y que probablemente hasta rica esta, pero “el amor entra por los ojos” Lo mismo pasa con nuestras aplicaciones, no es suficiente que cumplan con su function, incluso pueden estar programadas con el codigo mas limpio, por los programadores mas rocktar en el area, peeero, si no alineaste ese boton esos 5 pixels a la derecho para que estuviera alineado con el resto del contenido; porque se te olvido, no lo viste o peor aun porque te dio flojera moverle al CSS. Te va a afectar, porque tu trabajo sera percibido como de baja calidad. Si trabajas con diseniadores, excelente, apegate a sus mocks, y si no, no te queda de otra mas que el consejo de las abuelas “hay que ser curiosito”. No le restes importancia al look and feel de lastus apps porque al final lo que vende de todo product es su presentacion.
- Hazle la vida facil a otros. En mi primer trabajo en el silicon valley conoci a un chavo, era ingeriero de calidad. Me causo una gran impression la primera vez que lo escuche en una junta de scrum, super serio y correcto “Abro el incidente 534, 535 y 536, ya estan resueltos y en Pull Request”. Mi cabeza exploto, “OMGm no quiero trabajar con otro tipo de testers en la vida” jajaja el chavo no solo enontraba defectos sino que los resolvia, hazle la vida facil a otros, a eso me refiero.. No temas ir un paso mas adelante. Quieres ese titulo de tech lead, de program manager, de senior developer? Empieza actuando como tal. No esperes singun ascenso, titulo, cambio de rol, ni que nadie te diga que hacer, ni como actuar. Analiza tu Proyecto y hazte dueno de el o de alguna parte. De esta manera cualquier tarea o reto lo cumpliras porque el Proyecto ya es tuyo. Te haras necesario y adivina que? Sera demasiado costoso no tenerte en tu equipo. Estaras agregando valor, porque haces que las cosas sucedan y no solo eso estaras ganando la confianza de todo el equipo, de tus manager y de los stakeholders en general.
- Apegate a tu tiempo de entrega Este punto es el mas complicado de todos . A la mayoria de nosotros, novatos o expertos nos falla.Aqui entran muchos temas que tienen que ver con el manejo del tiempo, la utilizacion de metodologias agiles, pero tambien nuestra capacidad de enfocarnos en nuestras tareas, en un mundo donde las notificaciones de twitter, facebook, linkedin, Instagram, tinder estan a la orden del dia. Pero ademas es super importante romper con el stigma sarraigado en nuestra cultura Mexicana del “como buen mexicano todo al ultimo”. Como minimizarlo, no lo dejes todo a lo ultimo, jaja, y alza la mano a tiempo. Ejemplo: Un dia el major de los desarrolladores del equipo, (con sus miles de nombramientos y certificaciones) tenia que entregar cierta funcionalidad x dia. Segun sus reportes de actividades diarias todo iba viento en popa. Y que paso? Si, si. 5 a las 12 para entregar reporta que aun no ha terminado y peor aun, empieza a culpar que tuvo que refactorizar codifo que los Jr. developer habia escrito. Alza la mano a tiempo, en todo Proyecto pasan imprevistos, es normal. Pero alza la mano, para eso son tus minutos en tus juntas de estatus, para anunciar tus bloqueos o lo que te esta deteniendo de avanzar o entregar. La gente entiende cuando le explicas que no vas a poder terminar, cuando lo haces con tiempo, cuando explicas hey el tiempo es muy poco para resolver x, y z. La gente no entiende cuando les dices que no has terminado 5 a las 12 y peor aun te vas a ver pesimo e inmaduro si pones excusas asi seas el major desarrollador del equipo.
- Este es mi punto favorito y se trata de quitarte el chip mental del rol de empleado para ser percibido como un professional de las ligas mayores. Y como logras quitarte el ese chip, pues tratando tu trabajo como un cliente donde tu eres la marca. Un dia un ex-companero de trabajo me comento cuando estaba en un proceso de reclutamiento: “Janet, es que si yo tuviera que contratarme, no me pagaria lo que me estan pagando, es demasiado, jajaja”. Chistoso pero vi reflejado el sindrome de impostor de inmediado, ese donde tenemos la sensacion de no estar a la altura, de no ser lo suficientemente buenos. Hay que olvidarse de esto, confia en ti mismo y en tu capacidad de resolver problemas. Seguramente siempre habra alguien mejor que tu, cosas nuevas por aprender y mas en este campo donde cada segundo dia hay una nueva herramienta para usar, subete a la ola, pero siempre trata tu trabajo como un cliente y en tu mente preguntate, yo compraria esto? Yo pagaria x por esto? Si la respuesta es no, es que hay espacio para mejorar.
- No rompas ventanas, lava tus platos, levanta la mano, recuerda no convertirte en el tren descarrilado. El mensaje que realmente quiero transmitir esta reflejada en esta grafica. El talent y el expertise son importantes; la capacidad para resolver problemas te llevara lejos. Pero lo que realmente hara que te muevas de donde estas, a donde quieres estar, es el coraje, el coraje para aventarse.
- Y para despedirme solo les quiero recordarles algo: El que es perico donde quiera es verde. Aqui, en China y el Silicon Valley. Solo hay que animarse! Gracias.