1. Deja el ego en la puerta
Los desarrolladores tienen egos inflados. Es un hecho. ¿Pero por qué? Yo diría que cualquiera que se tome en serio su profesión se considera una especie de persona de arte. Sí, no cantamos frente a millones y no dibujamos "Mona Lisa", pero a veces escribimos código que resuelve problemas complejos de manera tan eficiente y elegante que no podemos evitar estar orgullosos de nuestro trabajo. Creo que el desarrollador, por su enfoque de los problemas, es tanto un hombre de arte como un matemático. Como tal, tendemos a rastrear el código como una madre osa alrededor de su descendencia. Lo escribimos, lo amamos y lo odiamos cuando la gente a nuestro alrededor discute sobre lo incorrecto que es el código o no.
Por otro lado, todavía no ha ayudado a nadie. Amamos nuestro trabajo, pero debemos entender que estamos resolviendo problemas. Al discutir nuestras ideas y soluciones con otras personas, puede surgir una mejor alternativa. No hay nada malo. De hecho, la colaboración tiende a producir mejores soluciones. He observado todo tipo de ego, pero nunca he visto una situación en la que el ego funcione para un desarrollador.
¿Qué consejo puedo dar? Desde el momento en que empiece a trabajar como desarrollador, deje su ego en la puerta. Trágatelo y escucha lo que otras personas tienen que decir sobre tu trabajo. Acepte que las mejores ideas pueden no estar en su cabeza y que pueden mejorar su profesionalismo. Solo ganarás si escuchas los comentarios.
2. Los idiomas son una herramienta. ¿Solo conoces el martillo? Entonces todos los problemas son como uñas
Deja de llamarte desarrollador de Java o desarrollador de JavaScript. Sí, hay lenguajes que te gustan por su sintaxis o capacidades. Esto es completamente normal. Sin embargo, ganas si pasas algún tiempo estudiando otra cosa. Aprender nuevos idiomas, especialmente si siguen un paradigma diferente al que está acostumbrado, puede abrir su mente a diferentes enfoques para la resolución de problemas.
Ni siquiera sé lo importante que es esto: aprender nuevos idiomas y aplicarlos beneficiará tus habilidades. Leí el libro Seven Languages in Seven Weeks hace unos años y me abrió muchas opciones solo porque mostraba las formas de resolver problemas que están disponibles en otros idiomas.
Somos desarrolladores. Sabemos cómo resolver problemas con el código. No te limites. Mire más allá de los límites, piense fuera de la caja, aprenda otras opciones, idiomas y soluciones. Incluso si no lo hace por mucho tiempo, volverá a su herramienta familiar con ideas frescas y un pensamiento más amplio.
3. No se trata de memorizar algoritmos, sino de encontrarlos
Algunos desarrolladores novatos piensan que necesitan conocer los algoritmos de memoria, por lo que se sienten mal en el momento en que se dan cuenta de que han comenzado a olvidar cómo escribir un bucle for. Esto no solo es normal. Yo diría que incluso es útil. Simplemente tenemos demasiado que recordar. Pero esto también es innecesario. Necesitamos aceptar que Internet es solo otra herramienta tan necesaria como nuestro IDE para encontrar respuestas.
Todos hacemos esto. Y si te hace sentir mal, no pierdas el tiempo con ese sentimiento. Simplemente busque en Google la respuesta y comprenda su problema. Piensa sobre esto. Cada idioma tiene formas similares, pero ligeramente diferentes, de implementar el patrón Observer. ¿Qué es más útil? ¿Comprender para qué sirve un patrón y qué problemas resuelve, o recordar cómo implementarlo en cada idioma con el que trabaja?
Si sabe que el patrón resolverá su problema, entonces ya lo ha resuelto. Todo lo demás es solo una búsqueda de la mejor manera de implementarlo en Google. Esta búsqueda no le quita respeto a usted, su trabajo o su experiencia. Lo mismo se aplica a cualquier otra búsqueda. Concéntrese en lo importante, en resolver el problema y deje que Google empuje su memoria. Por eso existe.
4.
O más bien, que tiene a estudio durante toda su carrera. La decisión de seguir los últimos desarrollos de la industria depende de usted. Pero es mejor hacer esto si desea hacer coincidir.
Los idiomas y las tecnologías están evolucionando, y eso es perfectamente normal. Por supuesto, algunos ecosistemas cambian más rápido que otros, y mantenerse al día con ellos puede parecer una tarea titánica, pero concéntrese en las cosas importantes, recuerde que solo es un ser humano y no puede saberlo todo. Por lo tanto, si necesita aprender una cosa, le sugiero que aprenda a aprender.
Sé que esto puede parecer una tontería, pero tal vez el desarrollador tenga esta habilidad número uno. Debemos aprender a aprender nuevas habilidades rápidamente. De lo contrario, corre el riesgo de obtener la etiqueta "desactualizada".
Aquí es donde entran en juego algunas de las otras lecciones de este artículo. Variabilidad, cambio, nuevos desafíos, falta de ego: todo esto lo ayudará a aprender y ampliar su gama de habilidades. Cuanto más lo practiques, mejor. Eventualmente, se dará cuenta de que todos los idiomas son similares. Comenzarás a ver sus raíces comunes y podrás trabajar con cualquiera de ellos. Todo lo que tienes que hacer es leer un par de cosas clave. A lo largo de tu carrera, estudiarás:
- Nuevos idiomas.
- Nuevos (y viejos) paradigmas de programación.
- Nuevos enfoques de trabajo.
- Nuevas formas de resolver problemas.
- Nuevas formas de interactuar con los compañeros de equipo.
- Nuevos enfoques para revisar y probar su código.
Si no está listo para ser un estudiante eterno, considere si esa carrera es para usted. Tenga en cuenta que no dije: "Váyase inmediatamente", sino que considere si está listo para abrir su mente al aprendizaje continuo.
5. Funciona mejor que lo ideal
Como gerente, he escuchado esto demasiadas veces. Pero como desarrolladores, tendemos a pensar que el código debería ser perfecto antes del lanzamiento. Y esto no solo es falso, sino potencialmente un problema. La optimización temprana es un problema porque terminas gastando mucho tiempo y esfuerzo en cosas que pueden no necesitar optimización. Y en algunas situaciones, al realizar esta optimización, hace suposiciones que rompen la funcionalidad.
Así que concéntrese en el trabajo por hacer y el problema que está tratando de resolver. Después de resolver el problema, pruébelo, repita los resultados y vea lo que piensa su equipo sobre su solución, incluso si ya puede ver formas de mejorarla. Si va a pasar dos días más perfeccionando el código, pero podría entrar en producción ahora mismo, es probable que esté en producción ahora mismo.
Al final, resuelves el problema. Cuanto más rápido solucione el problema, mejor para sus usuarios.
6.Haga que el código funcione, luego optimice
Según algunos de los puntos anteriores, no caiga en el agujero negro de la optimización inicial. Incluso si piensa que hará que el código sea rápido, una vez que se publique (si es que alguna vez lo hace), encontrará que el efecto de dilatación del tiempo es real.
Su primera prioridad como desarrollador de software que escribe una nueva característica o corrige un error es hacer que funcione, sin importar cuán feo se vea el código o cuán ineficiente sea la solución. Si el código funciona, acaba de demostrar que es posible escribir código. Esta es la mitad de la batalla.
El segundo paso es la optimización. Este paso es opcional. Detalles que algunas personas tienden a olvidar. El tiempo que tiene a su disposición para optimizar su código depende de muchas variables que a veces no controla. Así que concéntrese en hacer que el código funcione y luego averigüe si realmente tiene tiempo para optimizarlo.
Optimizar temprano significa optimizar su código a medida que lo escribe. Esta es una práctica peligrosa porque cuando optimizamos, hacemos suposiciones sobre el tiempo de ejecución, los requisitos de datos, los requisitos de memoria y otros factores que aún no hemos visto en acción. Cualquier suposición de este tipo puede ser incorrecta y, al final, introducirá errores en su lógica.
Piense en el flujo de trabajo TDD:
- Escriba una prueba para comprender todo lo que debe hacerse para su función (la prueba fallará).
- Escribe tu código para que pase la prueba.
- Ahora preocúpese por optimizar su código.
Se requiere el segundo paso. Primero debe ocuparse de la prueba, lo que significa que la función está funcionando. A la prueba no le importa que use tres declaraciones if anidadas en los algoritmos. Esto será importante, quizás en la etapa de revisión del código.
7. El último 10% del proyecto toma el 90% del tiempo
Esto es especialmente importante si trabaja solo, pero los equipos también sufren por no entender bien este pequeño detalle matemático. Cualquiera que haya completado un proyecto dirá lo mismo (y, francamente, este no es solo el caso en nuestra industria) Primero, se apresura a analizar muchos detalles para pensar en ellos más tarde.
Y esto es completamente normal. Tendemos a centrarnos principalmente en funciones grandes, dejando pequeños detalles o incluso errores conocidos hasta el final. Sin embargo, debes luchar contra ellos, y aquí aparece un 90% adicional. Tiene que probar, corregir el código, volver a probar, enseñar a los usuarios cómo manejar la solución, enviar la versión final de la solución, etc. Por supuesto, todo depende del contexto, quién es tu cliente y muchos otros factores, pero siempre hay algo. Así que recuerde, cuando crea que casi ha terminado con el código, probablemente olvidó algo.
8. Cuando estás en un equipo, necesitas abstracción.
La codificación se trata del comportamiento de las abstracciones. Al abstraer la lógica general, podemos reutilizarla en otros lugares, pero al principio olvidamos la importancia de las abstracciones. Aquí está mi regla personal: si el código se repite en dos lugares, se envía a una función (método, módulo); entiendes la idea. Si dos repeticiones le parecen un número pequeño, tenga en cuenta que puede haber otros lugares en el futuro para aplicar el código que acaba de abstraer. Y al abstraer el código de inmediato, tendrá acceso a él de inmediato.
La abstracción está escalando. Una pieza de lógica abstracta se puede usar muchas veces con un mínimo esfuerzo, mientras que copiar y pegar (aunque es fácil de hacer): cuanto más lo use, más esfuerzo requiere. Piense en lo que sucede si, debido a un error, necesita cambiar una parte de la lógica que se repite 5 veces. Para corregir un error, literalmente cambia la misma parte del código 5 veces.
La misma lógica se aplica a las tareas diarias. Si hace algo más de una vez, probablemente se pueda automatizar de alguna manera. Esta es la clave de la eficiencia, así que busque la repetición no solo en su código, sino también en sus acciones. Si automatiza una tarea que toma 10 minutos al día, ahorrará 5 horas en un mes.
9. Los proyectos secundarios son opcionales, pero pueden ayudar
Algunos dicen que si quieres ser un desarrollador exitoso, necesitas proyectos paralelos. No creo que esto sea cierto. Personalmente conozco a muchos grandes desarrolladores que solo escriben código en el trabajo, "de 9 a 17". Para ser honesto, los admiro. Son maestros en su oficio y en su tiempo libre, haciendo otra cosa, disfrutan de la vida. No hay absolutamente nada de malo en eso. Sin embargo, a veces es necesario practicar más. A veces siente que se está quedando atrás de sus colegas; aquí y ayudar a proyectos paralelos.
No estoy hablando de una revolución en la industria: desarrollar un marco con millones de usuarios. Escríbelo si quieres, pero estoy hablando de copiar los proyectos de otra persona para aprender de ellos. También estoy hablando de contribuir a los proyectos de otras personas, corregir errores y agregar funcionalidad.
Puede escribir proyectos paralelos para experimentar otros aspectos del desarrollo que normalmente no tocaría. Si escribe pruebas unitarias 8 horas al día, podría pensar en escribir algo desde cero o desarrollar alguna funcionalidad. Si está cansado de trabajar solo, contribuya al proyecto existente de otras personas y experimente lo que significa coordinar su trabajo con otros. Puede escribir un proyecto paralelo para mejorar su nivel de habilidad abordando las debilidades. Pero, de nuevo, no sienta que necesita trabajar en ellos con una barra de actividad verde de Github para ser considerado un desarrollador serio. Esto es una tontería.
Conclusión
Aquí están mis 9 lecciones difíciles como desarrollador durante los últimos 18 años. Con suerte, al compartir mi experiencia, he arrojado algo de luz sobre su carrera futura o actual. ¿Ha aprendido algo más que le gustaría compartir? Me encantaría saber de ti en los comentarios, me encantaría aprender algo de ti.
- Formación profesional en ciencia de datos
- Formación de analista de datos
Otras profesiones y cursos
- -
- Java-
- Frontend-
- C++
- Unity
- iOS-
- Android-
- «Python -»
- «Machine Learning Pro + Deep Learning»
- Machine Learning
- « Machine Learning Data Science»
- JavaScript
- DevOps