Hacerlo bien es difícil

Como se ve en mis entradas, hace tiempo vengo reflexionando sobre cuestiones paralelas al desarrollo, pero que no son tan técnicas sino sobre el proceso de construcción de software. Soy una persona desordenada, que buscar organizar mejor sus tiempos para cumplir sus objetivos (Justamente algo que vengo reflexionando y pensando hace un tiempo es sobre la administración del tiempo)

Hoy me encuentro probando (por el hecho de conocer) el stack proporcionado por .Net Core, ya que nunca hice una prueba completa. Estoy construyendo una api que sirva como servicio para manejo de archivos (https://github.com/robertoavilla/FileBagWebApi), en donde uno puede registrar su aplicación y agregar archivos para esa aplicación, separados por «categorías» y «sub categorías» (Internamente «Tipo de Entidad» y «Tipo de Archivo»), en donde un archivo tiene una categoría y puede tener una sub categoría. Además de que sirva como práctica, pienso aplicarlo a mi mayor proyecto, que es el Sistema de Administración para Grupos Scouts, brujulaweb. en donde necesito asociar archivos a distintas «Entidades» del sistema.

El historial de github no me va a dejar mentir, esta api la inicie hace mucho tiempo y la voy abandonando porque siento que el tiempo invertido en ella es mucho. ¿Por qué? Porque invierto muchas horas pero avanzo poco. Es ahí donde entra esta reflexión. ¿Por que siento que avanzo poco?

Veo que cada paso que doy, cada linea que doy, me detengo a pensar mucho. En este preciso momento (y solo me detuve para escribir este post) me encuentro leyendo sobre la mejor forma de versionar la api, (leyendo el artículo https://www.xmatters.com/blog/devops/blog-four-rest-api-versioning-strategies/, el cual la verdad me parece muy bueno). ¿Por qué simplemente no me pongo en modo robot y escribo código y más código, terminando en menos tiempo? Porque la experiencia me enseño que hacer eso lo único que genera es código rápidamente a un costo muy alto: Es difícil de mantener y actualizar. Llegamos lo antes posible al primer milestone, pero cuando queramos llegar al segundo, será complicado. Y mientras mas avanzamos, mas complicado será. Y ni hablemos de la corrección de errores. Llegará un momento en el que queremos borrar nuestro proyecto y empezarlo de cero. O peor, abandonarlo.

Es por ello que debemos convencernos de que no estamos tardando demasiado en llegar a un objetivo. Estamos invirtiendo ese tiempo en hacerlo bien. Y hacerlo bien, es difícil

 

¿Por qué cuesta tanto aprovechar el tiempo?

En épocas de coronavirus pronto nos encontramos con una gran cantidad de tiempo disponible. Al menos en Argentina, con la declaración de Cuarentena General tenemos al menos 8 días (ocho!!!) libres entre fines de semana y feriados. Pero aún así, me encuentro con que no logro aprovechar el tiempo.

¿Por que cuando tenemos tiempo disponible no hacemos todo lo que teníamos planeado?

Tengo algunas ideas, que las plasmo para intentar contrarrestar los efectos negativos.

  • Estamos «programados» para hacer lo menos posible: Hace un tiempo escuchaba que una neuróloga mencionaba que nuestro cerebro está programado para utilizar la menor energía posible. Es por ello que creo que una de las cuestiones es que tenemos que vencer ese mecanismo de «LowCost» que tiene nuestro cerebro
  • Tenemos miedo al fracaso: Aunque queramos triunfar en algo, hacer ese software que tanto queremos construir, nuestro miedo al fracaso nos frena.
  • Miramos el panorama general del problema y nos abrumamos con tanto trabajo por delante: Si bien podemos tener en claro a donde queremos llegar, al ver la gran cantidad de trabajo que tenemos por hacer nos agobiamos y abandonamos. (Quizás también por el punto 1)

¿Cómo puedo combatir cada uno de estos puntos?

  • Debemos asignarnos un tiempo para nuestro objetivo. Si estamos estancados, normalmente nos boicoteamos y dejamos el proyecto por la mitad, retomando días, semanas e incluso meses después
  • Perdamos miedo al fracaso. Es muy fácil decirlo pero difícil hacerlo. Pensemos que si no logramos el objetivo propuesto al menos aprendimos que ese no era el camino. Y seguramente aprendimos muchos detalles tecnológicos en el camino.
  • Debemos planificar todas las tareas que tenemos que hacer. Esto es clave para poder sacar de la mente todo lo que necesitamos para llegar al objetivo y luego poder ir viendo por partes y no a un todo.

Imagen: Business vector created by katemangostar – www.freepik.com

Después == Nunca

Como muchos programadores, normalmente soy víctima de una frase… «Cuando tenga tiempo lo corrijo». Desde el inicio de nuestra carrera, nos enseñan una premisa que si bien tiene cierta verdad, nos llena de temor a modificar nuestro código: Si funciona, no lo toques.

Es así como cargamos a nuestras espaldas el miedo a «romper todo». Es algo lógico que cuando estas aprendiendo si tocas algo que funcionaba, deja de hacerlo (No es solo un prejuicio. El desconocimiento del código y no saber que hace lleva a que seamos propensos a cometer errores). Entonces, si esta premisa en cierta parte está bien en ciertos momentos, ¿porque seguimos teniéndola años después?

Podríamos pensar principalmente que el mayor miedo es romper algo que ya funcionaba y recibir alguna llamada de atención. Ciertamente, si el cliente obtiene una falla que impida la operatoria normal, se va a acordar de toda nuestra familia. Pero acaso, ¿No existe un ciclo de pruebas al menos? ¿No deberíamos nosotros mismos hacer pruebas de aceptación antes de entregar los cambios? Creo que tenemos suficiente experiencia para cambiar una estructura compleja por algo mas simple podemos hacerlo. Pero no lo hacemos a pesar de que sabemos que ciertos refactors no romperan nuestro codigo.

Dejemos ese miedo a romper atras. Rompamos, arreglemos, mejoremos, avancemos.

NdeA: Lo más gracioso de todo, es que este articulo comence a escribirlo hace ya 4 meses y nunca lo continué. Es por ello que me pareció importante retomar la escritura del blog a partir de este punto.

El código me molesta

Estas ultimas semanas (o más de un mes, para ser preciso), tuve una tormenta de conocimientos, en donde caía todo rápido e intentaba mantener todo en la mente, claramente sin éxito.

En pos de organizar mi nuevo camino de aprendizaje, me puse a pensar dicho camino. Es decir, como empezar, con que continuar, etc… En definitiva, organizarme. Me encontré que con la lectura del libro «Clean Code: A Handbook of Agile Software Craftsmanship» de Robert C. Martin un nuevo mundo se abría ante mis ojos, una nueva forma de pensar el código: escribir código para programadores, no para computadoras.

Sin ahondar en detalles de lo que contiene el libro (que seguramente sea merecedor de miles de posts), me encontré con el primer paso de este nuevo camino en mi desarrollo profesional. Ese primer paso llegó solo, sin buscarlo, pero con una fuerza abrumadora que me esta ayudando a organizar mi mente. Ese primer paso, esa idea, esa sensación es que todo el código que escribí hace un tiempo me molesta, me incomoda.

¿Que quiero decir con esto? Es la sensación de que algo está mal en el código. Si, hace lo que debería hacer, cumple con los criterios de aceptación, pero aún está mal. ¿Por qué? Porque no puedo leerlo como una narración. No puedo leerlo como si estuviera contándome una historia. Y eso es lo que quiero. Quiero que leer mi código sea como leer un libro (Quienes leyeron el libro saben a que me refiero) y que no haya que hacer ningún esfuerzo para entenderlo.

Creo que esta sensación es fantástica, siento como si tuviera las puertas abiertas a un campo soleado, invitándome a un mundo nuevo en donde todo se ve mas claro.

Es hora de cruzar esa puerta.

Vísteme despacio que estoy apurado

Pensando en como encarar este Post, se me vino a la mente la frase que ahora lo titula. Dicha frase fue atribuida a varias figuras de la historia, como puede ser Fernando VII, Napoleon Bonaparte o Carlos III. La realidad es que sea quien fuera el autor, fue adoptada como una frase de uso popular.

Pero, ¿por que la frase? ¿que tiene que ver con la informática? En estos días me fui dando cuenta que la gran mayoría de los puntos necesarios para mi crecimiento profesional, siempre necesito iniciar el camino de aprendizaje con el siguiente principio:

Si querés hacerlo bien, tenes que hacerlo despacio.

Hace días vengo consultando con colegas sobre como crecer en profesionalismo sin tener un entorno que te obligue a hacerlo. Es muy fácil aprender buenas prácticas cuando tenes un buen profesor. Pero, ¿cómo lo haces cuando querés encararlo sólo?

Lo primero que me encontré es que, contrario a lo que normalmente las empresas piden, no parece ser tan importante interiorizarte tanto en una tecnología sino en las bases del desarrollo de software: Ideas, pensamientos y prácticas que van mas allá de una tecnología en particular. Me topé, solo para citar un ejemplo, con la idea de «Clean Code», el arte de escribir código de fácil interpretación. O como lo nombran de manera aún mas rica en un curso de Pluralsight: «Clean Code: Writing Code for Humans«. Mas allá de los principios que allí mencionan, me encontré con la afirmación de algo que venia pensando hace semanas: Para avanzar en un nivel más profundo de profesionalismo, hay que pensar más antes de ejecutar, lo cual implica detenerse a analizar y tomar la decisión correcta. (Contrario a lo que muchas veces se fomenta que es sentarse y escribir código hasta que funcione)

Luego de unos 12 años en la industria, conozco muchas de mis fortalezas y debilidades, y una de las fortalezas que siempre destaco es mi capacidad de adaptación: No importa el trabajo al que me esté dedicando, puedo tomar el toro por las astas y llevar mi tarea a buen puerto. Pero no es la forma de hacerlo. Si bien muchas veces la situación lo amerita, no es el contexto ideal en el ciclo de vida de un producto. Este vicio disfrazado de virtud genera trabajo de mala calidad, que luego puede resultar inmantenible. Y lamentablemente uno lo aprende por la fuerza.

Es por ello es que el primer principio que considero que debemos seguir para crecer, es ir más lento. La historia nos muestra que luego nunca tenemos tiempo para mejorar lo que por apuro no lo hicimos bien desde el principio. Es por ello que debemos frenar, pensar y recién en última instancia ejecutar.

Asi que… vamos despacio…

Referencias:

  • https://siempreconectado.es/origen-visteme-despacio-que-tengo-prisa%C2%B4/
  • Imagen: https://pixabay.com/en/napoleon-napoleon-bonaparte-33073/
  • https://app.pluralsight.com/library/courses/writing-clean-code-humans/

Nunca dejes de Desafiarte

Durante esta última semana tuve la tarea de crear una API sencilla. Funcionalmente no era nada del otro mundo, hasta podríamos decir que era trivial. El desafío era que no podía utilizar .NET, plataforma en la que trabajo desde hace unos 7 u 8 años.

La mayor parte del tiempo la ocupe en investigar la plataforma que iba a utilizar (JAVA) junto a los frameworks disponibles que me permitan llegar al objetivo en el irrisorio tiempo de 1 semana, teniendo que codificar únicamente en mi tiempo libre (Es decir, a lo sumo 2 o 3 horas libres durante cada día de la semana y unas 6 / 7 horas durante el fin de semana.

Entonces, resumimos en:

  • 30 horas disponibles muy fragmentadas
  • Programado en Java, que no lo utilizo hace unos 10 años
  • API REST, que nunca desarrollé en JAVA
  • MARIADB, que no utilizo desde los tiempos que era MySQL
  • Deploy en AWS, en donde ni siquiera tenia cuenta.

Durante algún momento en que mi cerebro estaba ya quemado y empezando a divagar, me tope con esa frase: «Nunca dejes de aprender». Aunque yo la acompañaría de una frase que me inspiro en la decisión de utilizar JAVA y  durante el resto de la semana:

Nunca dejes de desafiarte

(Por cierto… llegué a completar el objetivo)

Photo de Negocios creado por creativeart

Como evitar la inicialización de bases de datos en Entity Framework

Arranco diciendo que hasta el momento Entity Framework no me termina de convencer. Entregar todas las decisiones a un tercero llamado Microsoft no es algo que me deje tranquilo. Me siento mas cómodo con ADO.NET, ya que se tiene control total de las consultas que se ejecutan en la base de datos. No obstante, reconozco los beneficios de Entity Framework. Las migraciones son, por ejemplo, un gran beneficio en arquitectura Multi – Tenant de base de datos, en donde una migración manual puede ser contraproducente. Otro «beneficio» es que uno no está tan pendiente de lo que se termina haciendo en SQL (Lo cual, como mencione, tampoco me resulta tan agradable, pero me parece aceptable en el caso de las sentencias de manipulación de datos).

Por algún  motivo hay veces que es necesario evitar la creación automática de la base de datos. En mi caso estoy con un sistema que es la migración a web de una version desktop muy rudimentaria y un factor importante es el poco tiempo que puedo dedicarle al mismo al ser un desarrollo ad-honorem pero que a la vez tiene sus plazos. Las opciones que encontré son:

  • Activar migrations y cada cambio que hago generar una migración: No me parece óptimo estando en un ambiente de desarrollo, ademas de tener la experiencia de que en otro proyecto cada vez que hacíamos deploy con una migración teníamos problemas que, para complicarlo aún más, eran fallas silenciosas. (Acá es donde en un entorno normal tendría que dedicarle tiempo a investigación, pero no lo tengo)
  • Recrear la base de datos cada vez que haga un cambio en la estructura (lo cual no me parece conveniente ya que sólo es válido para un ambiente no productivo)
  • Desactivar la creación automática, no utilizar Migrations y manejar todo desde un proyecto de base de datos (Opción elegida)

El código es muy sencillo, simplemente hay que asignarle al atributo Database de la clase DbContext de la cual heredamos un objeto del tipo «NullDatabaseInitializer». De esta manera, evitamos que al instanciar el objeto «Context» se quiera correr la inicialización de la base de datos.

Lo importante no es el código, sino el análisis previo:  No nos casemos con las tecnologías y elijamos de cada una la que mejor se adapte a nuestras necesidades. En mi caso uso Entity Framework para tener un desarrollo más ágil, pero le quito la creación de la base de datos y no activo migrations ya que no me genera un beneficio importante.

Buen Codeo

Presentación

Como una copia a Jose Ferrer de revivir sus tiempos de blog tech, se me «ocurrió» (entre comillas porque evidentemente la idea del blog es robada :P) también armar un blog. Muy pronto me encontré con la primera disyuntiva: ¿para que?. Hay muchas opciones posibles: divulgar investigaciones para que otros puedan aprovecharlas, contar el día a día de la vida de un developer (So boring…), promocionar y publicitar desarrollos propios, y una larga lista de etcéteras.

Ahora viene la parte filosófica. No se si es la crisis de los 30, pero me encuentro en este momento en un proceso de cambios personales de todo tipo en pos de mejorar a nivel general ciertos puntos que no me tienen contento. A nivel profesional (lo que a este espacio concierne) me veo en una etapa en donde quiero comenzar a organizar mis conocimientos, pulirlos y emprolijarlos. Si bien tengo bastante experiencia, en muchos temas toco de oído y siguiendo con la analogía, quiero empezar a conocer a fondo la teoría musical. Es por ello que comencé algunos cursos de «Clean Code», a investigar Best Practices, etc. En definitiva, no creer que solo con la experiencia tengo que quedarme quieto, sino que debo volver a los libros para crecer aun mas (Casi que diría que es mi lema el constante crecimiento profesional)

Es por ello que inicio este blog con objetivos acorde a mis cambios:

  1. Documentar temas que sean de mi interés y quiera tener algún registro de ellos
  2. Documentar POCs que en algún momento investigue y no quiera que terminen perdidas en algún disco por ahí (Ya se me rompieron varios)
  3. Organizar algunos proyectos que tengo vivos (o que quisiera tenerlos).
  4. Desarrollar ideas para aplicar a proyectos.
  5. Sentirme libre de publicar OTs relacionadas al desarrollo profesional 🙂

En definitiva, este blog va a ser una especie de «Diario Intimo Profesional». Espero que de paso a alguien le interese lo que publico y no sentirme tan solo entre estas letritas 🙂

Espero poder organizarme y dedicarle tiempo, porque en definitiva, tiempo es lo que a veces nos falta…

  • GIF: gifer.com