Reflexiones

Evita aprender como un dogma

Evita aprender como un dogma
En: Reflexiones

Uno de los mayores errores que podemos cometer como desarrolladores es aprender como un dogma.

En nuestro sector no existe la verdad absoluta, normalmente todo depende del contexto y experiencia de cada uno.

En mis cursos

Yo tengo un curso de Clean Architecture y otro curso de testing que imparto en empresas y también realizo ediciones en abierto.

En estas formaciones me gusta empezar contando mi historia de como llegué a estas prácticas, porque las utilizo y cuando.

Me gusta enseñar diferentes implementaciones según el lenguaje o la tecnología, el motivo de cuando utilizo ciertas prácticas y cuando no las utilizo según la experiencia que yo he tenido.

Enseño proyectos en diferentes tecnologías tanto proyectos personales como reales de clientes muy importantes donde el código es open source y por lo tanto no hay problema en enseñarlo.

No me gusta enseñar arquitectura de software y testing como un dogma sino como herramientas que pueden puedeen ser utilizadas y pueden tener diferentes implementaciones según el lenguaje, la tecnología o el contexto no tecnológico.

Me gusta enseñar estas prácticas como principios de arquitectura, testing y animo a los alumnos a que busquen las implementaciones que mejor que se ajustan a sus equipos, empresas, lenguajes, proyectos, en definitiva su contexto.

Prácticas que ayudan

Entender la base detrás de librerías o frameworks

Habitualmente por no reinventar la rueda usamos librerías que nos aportan una solución a ciertos problemas y eso no es malo.

Lo que creo que es malo es que las utilicemos sin conocer la base del problema que resuelven y como lo resuelven.

Cuando estamos en la base de aprendizaje de una tecnología nueva, paradigma, patrones o lenguaje nuevo, creo que lo más nos va a enriquecer es aprenderlo sin librerías.

En mis cursos por ejemplo, los ejercicios animo a que los alumnos los hagan sin utilizar ninguna librería.

En los ejercicios de los cursos se trabaja la inyección de dependencias y los dobles de test, pero recomiendo hacerlo manualmente para que entiendan bien el problema y las posibles soluciones.

Al utilizar librerías estamos usando una implementación concreta de una solución al problema.

Me encuentro habitualmente que hay desarrolladores que desconocen cual es el problema que la librería resuelve y que existen otras posibles implementaciones.

En este caso se aprende a usar la librería como un dogma e incluso solo saben solucionar el problema con esa libraría en concreto, lo cual es un problema.

Claro que yo también utilizo librerías pero primero me gusta aprender sin ellas y en algunas ocasiones no llego a utilizar ninguna porque para lo que necesito, me es suficiente con la implementación manual.

Otras muchas veces acabo utilizando librerías porque me aportan mucho para el problema que tengo que resolver.

Leer código de otras personas

Una práctica con la que se aprende mucho y que hace que te cuestiones lo que sabes es leer código de otras personas.

No tiene que limitarse a compañeros de una misma empresa, que también, sino leer código en GitHub, o dónde sea, de otras empresas o compañeros del sector.

Pair programming

A estas alturas siguen existiendo muchas empresas y también muchos compañeros desarrolladores (no nos engañemos) que no creen en el pair programming.

Sin embargo, es una práctica con la que se comparte muchisimo conocimiento y que ayuda por lado, a la propiedad colectiva del código. Y por otro a evitar aprendidajes como dogma.

Abrir tu mente con humildad

Por mucha o poca experiencia que tengas siempre hay alguién que sabe más que tú de cualquier tema y alguién que sabe menos que tú de cualquier tema.

Por mucho o poco que estudies o tengas experiencia eso no va a cambiar, evolucionas como desarrollador pero siempre hay alguién que va a saber más que tú.

Cuando asumas eso, serás libre de aprender y enseñar con humildad.

Enfrentarse a cada situación, problema a resolver, bug, tarea o proyecto con humildad puede ser una de la mayores virtudes que puede tener un desarrollador.

Humildad para buscar la mejor estrategía para resolverlo aunque esto conlleve salir de tu zona de confort y tener que pedir ayuda a un compañero con más experiencia en esa materia o dedicar tiempo a formarte sobre algo que no conoces o creeías conocer bien.

Pero no solo existe la humildad para aprender también para enseñar. Se puede aprender también de alumnos que asisten a un curso. No hay curso que imparta que no me lleve un aprendizaje de los alumnos o hagan que me cuestine o reflexione sobre algo que ya sé.

Evitar Forofismos

Vivimos en una sociedad de forofismos, en el deporte, en la política y en el desarrollo de software.

Si te enfadas o te sienta mal que alguién cuestione o ponga en duda algo que tu utilizas ya sea librería, lenguaje, arquitectura o patrón puede ser un sintoma de que lo has aprendido como un dogma.

Es mucho más saludable intentar entender el punto de vista del otro. A lo mejor te sorprendes y aprendes contextos donde aquello que usas como un dogma no aplica o aplica con matices.

Contexto

El contexto afecta a cualquier creencia o conocimiento que tengas.

En mis cursos también suelo empezar diciendo que todo lo que les voy a contar depende totalmente del contexto, que esta basado en mi experiencia y en lo que he aprendido de otras personas.

Toda decisión, práctica, patrón, librería trata de solucionar un problema dentro de un contexto y cada una de estas soluciones pueden no aplicar en todos los contextos.

Conclusiones

Despues de 20 años de experiencia creando software, aprender como un dogma creo que es una de las peores prácticas que se pueden realizar como desarrollador.

Dudar, cuestionar lo aprendido, entender el contexto y adaptarse al cambio nos permite evolucionar como desarrolladores.

Más de XurxoDev
¡Genial! Te has inscrito con éxito.
Bienvenido de nuevo! Has iniciado sesión correctamente.
Te has suscrito correctamente a XurxoDev.
Su enlace ha caducado.
¡Éxito! Comprueba en tu correo electrónico el enlace mágico para iniciar sesión.
Éxito! Su información de facturación ha sido actualizada.
Su facturación no se actualizó.