¿Eres buen o mal desarrollador? Natural Developers

Podrían ser los Asturian Developers pero no quiero que ni los Soul Developers ni el gentelman Félix se sientan desterrados 😉

Naturalistas del código, explican la realidad con objetividad, desde lo más filosófico a lo más simple. Sencillos sin ser simples, complejos sin llegar a ser complicados. Naturalidad sin dobleces, la esencia de los Natural Developers.  

Érase una vez… una chica, un columpio y 40 minutos de espera para coger un bus.

Sheila Fernández: Avilesina residente en Madrid. Fan de la sidra y la fabada como buena Asturiana que es. Adicta a las series de TV y viajante incansable. Siempre descubriendo nuevas aficiones, su nuevo descubrimiento: un puzzle de 3000 piezas. Como en la vida, las piezas irán encajando.

Con respecto a la afirmación: “Good developer will never feel his code is good enough, and will always continue to clean and fix. Good developer always strives to create elegant solutions but understands that his job is to deliver value to customers. Bad developer thinks only about the elegance of his code and leave the job of delivering value to others” Sheila considera que depende de las circunstancias y de la persona. Entrando más en detalle nos comenta:

A casi todos nos gusta desarrollar buen código, pero por lo general siempre estás atado a una fecha de entrega que no suele ser muy acorde a lo que uno mismo considera necesario para terminar el trabajo. En muchas ocasiones, por ir corto de tiempo tienes que tirar por la solución menos elegante pero sí más rápida. Y es una pena, porque el buen código es mucho más legible y mantenible.

Por desgracia, las personas encargadas de hablar con el cliente y definir una fecha de entrega, no suelen hablar con los analistas y programadores, para ver hasta dónde podemos llegar. El resultado es que vuelven de una reunión y te dicen que dentro de un mes tienes que entregar el trabajo de tres meses, y su solución para llegar es siempre añadir más recursos, lo cuál casi siempre es contraproducente. No entienden que explicar el proyecto, cómo está montado y las tecnologías que se usan a un cierto número de personas, además de la curva de aprendizaje de esas personas para estar trabajando a pleno rendimiento, es un tiempo mucho mayor que si lo desarrollaran las personas que componen el equipo, los cuáles ya están siendo 100% productivos. Por lo que finalmente, acabas perdiendo más tiempo, y muy pocas veces se consigue llegar a la fecha estipulada.

Para que esto cambie, creo que debería existir más diálogo entre ambas partes, y un cambio de mentalidad por parte de jefes/directores de proyecto.

“Freedom For The Spin Country”

Daniel González: Natural de El Espín viviendo en Madrid. Exprimiendo la manzana de Apple para hacer sidra. Cocinillas, sus bizcochos son conocidos en toda España.

Citamos textualmente del artículo “Good Developer, Bad Developer“:   

“Good developer understands the complete architecture of the product. Bad developer knows only the components he’s written. Good developer fully understands the technologies that are used within the product. He understands what they are used for, and how they work internally”

Daniel da su opinión sobre este punto:

Cuando escoges la profesión de desarrollador (si es que se puede llamar así), aceptas que tu vida va a ser un constante cambio y que siempre vivirás en reciclaje. Todo el mundo te dice que tu crecimiento y aprendizaje debe ser constante, que te plantees como un reto el aprender de aquellas tecnologías que en cada momento sean punteras, estén de moda y puedan ayudar a que tu trabajo sea más agradable.

Ahora abramos la coctelera y mezclemos lo siguiente:

  • Trabaja con tecnologías en constante evolución. Ahora son las tablets, antes fueron los teléfonos móviles, antes los ordenadores portátiles, antes los PCs…. Todo viene del ábaco, antes solamente había madera y hierro, ahora tenemos chips superpotentes y software al que le falta poco para evolucionar a una inteligencia artificial completa.
  • Trabaja con diferentes tipos de lenguajes y culturas de desarrollo. En la carrera aprendes muchos lenguajes (C, Java, HTML, Javascript, XML…) cada uno orientado a una rama de la profesión, parecidos pero diferentes, combinables. Cuando te plantas en el mundo real te hacen falta todos y ninguno al mismo tiempo. Java se divide en miles de frameworks. .NET en diversas versiones. Aparecen lenguajes nuevos.
  • Trabajas para un sector. Si comienzas en el sector de la banca aprendes de éste, si es en el de los seguros, seguros,  si es sanidad, sanidad,  transportes, turismo, deportes, medios de comunicación… todos con partes iguales, pero diferentes.
  • Trabajas para una empresa. Eso implica aceptar la política de organización, horarios (horas extra que sacas de tu tiempo personal), filosofía, definición técnica de los responsables, arquitecturas propias, frameworks, etc.
  • Trabajas en una ciudad. Muchos de nosotros venimos de núcleos pequeños y nos encontramos en ciudades grandes, lugares donde el tiempo es oro. Transportes eternos, tráfico, huelgas, alto coste de la vida.

Cuando agitas toda esta mezcla, obtienes una persona con control sobre muchas cosas de gran diversidad, enfocado a una cosa en concreto: sus tareas en su trabajo y que dispone del tiempo justo para su propio disfrute. Depende después de cada persona y que hacer con el (poco) tiempo libre que le quede, si decide romper con la rutina, o si por el contrario es un apasionado de su profesión. En este segundo caso, además se puede dividir en si está cansado de tratar con lo mismo siempre (aquello que ve en su rutina diaria) y quiere ver cosas nuevas, o si por el contrario le encanta tanto su trabajo que es capaz de seguir trabajando y aplicando sus nuevos conocimientos.

En definitiva, personalmente creo que no es mejor programador aquel que lee más libros, lee más artículos, sabe más de la tecnología de la que es experto, escribe libros, da conferencias, cursos… esto lo puede hacer cualquiera. Sin embargo, aquellos que demuestran su compromiso, pasión, entrega, dedicación, esfuerzo en su trabajo y además son capaces de contagiar a los que les rodean con ello, haciendo que todos seamos mejores desarrolladores, ellos si son buenos desarrolladores, y buenos profesionales.

Me quedo con dos titulares:

Debería existir más diálogo entre ambas partes, y un cambio de mentalidad por parte de jefes/directores de proyecto”

“Aquellos que demuestran su compromiso, pasión, entrega, dedicación, esfuerzo en su trabajo y además son capaces de contagiar a los que les rodean con ello, haciendo que todos seamos mejores desarrolladores, ellos si son buenos desarrolladores, y buenos profesionales”  

Si queréis curiosear más sobre Daniel, su vida, su gente, sus sitios, haced una parada por su blog: Freedom For The Spin Country.

Sheila, Dani, mil gracias por colaborar, ¡me presta mucho! 🙂