No hablemos solamente por pereza

Al iniciar un proyecto es más fácil conocer las necesidades del cliente teniendo una junta en persona (o por lo menos virtualmente, voz y quizás video). De ese modo cuando leemos el documento con los requerimientos o detalles de lo que se necesita se puede entender fácilmente a que se refiere cuando habla de ciertos conceptos.  La conversación con voz ayuda a reducir los malentendidos. Sin embargo también es fácil de olvidar los detalles después de la junta. Además de la junta en “persona” es bueno tener todo lo que se trato por escrito, ya sea en notas o una minuta para poder consultar lo que se habló.

Durante el desarrollo del proyecto puede haber detalles que discutir… y es de esos casos de los que quiero hablar (escribir, mejor dicho [escrito]).

Me ha pasado que me llega un correo preguntándome cuando podemos hablar. Propongo una fecha y hora, quedamos en llamarnos y momentos antes de la junta se tiene que posponer porque alguno de los dos ya no pudo. Se mueve la junta, total que pasa una semana y por fin tenemos la llamada. Al estar en la llamada, me doy cuenta que si desde el primer correo me hubieran escrito lo que necesitaba de mi, para ahora probablemente ya tuviera listo lo que se necesita y pudiera contestar mejor a sus preguntas. Además de que no hubiera tenido que reservar el tiempo para la junta (además del tiempo perdido en ponernos de acuerdo).

En ocasiones tengo mensajes instantáneos del tipo “Hola Mario”. Que no puedo atender al momento, después de buen tiempo contesto con un “hola” también; pero la otra persona ahora esta ocupada. Ya para cuando me contesta, espera que estemos los 2 en la conversación para ahora sí explicarme lo que necesito saber o para preguntarme lo que necesita saber. ¿Por qué no escribirlo desde el principio? o ¿Por qué no simplemente mandar un correo con lo que se necesita?

He pensado que esto ocurre por pereza para ordenar las ideas y expresarlas de una manera escrita. Es más fácil hablar y hablar sin ordenar los pensamientos y que la otra persona sea quien lo organice y le de sentido. He visto la pereza incluso para mandar el correo para hablar, con títulos como “Llamada”,  “Mario”, “Pregunta”. Ni siquiera se menciona el tema sobre el que quieren hablar.

No seamos flojos para pensar, no hablemos sólo por pereza. Organicemos las ideas de tal forma que podamos expresarlas en un mensaje escrito y evitar tanto ida y vuelta de mensajes sin contenido.

El programador desarrolla software

Cuando personas no técnicas me preguntan a qué me dedico y les contesto: "Desarrollador de software". Por lo general no entienden exactamente que  hago en mi trabajo. Muchas veces termino diciendo que soy programador o que escribo programas para computadora. Últimamente ya solo digo "programador". Sé que para muchos el programador no es lo mismo que el desarrollador de software. Pero pensándolo bien… ¿Será algo que al resto del mundo no le importa? ¿Realmente hay una diferencia?

Leyendo blogs he encontrado diferencias entre ambos términos. Se dice que el programador es la persona que escribe el código (nomas) y el desarrollador hace algo más. Según el desarrollador de software tiene otras habilidades además de escribir código. Se involucra en todo el proceso, como análisis, diseño, evaluar marcos de trabajo (Frameworks), lenguajes, arquitectura, etcétera. ¿Acaso el programador no tiene esas habilidades?

Según la Real Academia de la lengua, el programador es la persona que elabora programas de ordenador. En español de México diría que elabora programas de computadora. Ahora la pregunta es ¿Cómo se elabora un programa de computadora?

Un programa se elabora en incrementos, es decir, un programa puede ir cambiando con el tiempo, agregándole características. No se construye de la misma forma en que se construye un edificio, por ejemplo. No se hace una casa pequeña y después se modifica para convertirla en un rascacielos.  Pero un programa puede crearse para una necesidad pequeña y después modificarse para que haga una cosa más. Por eso no decimos construcción, sino desarrollo de software. No es por las habilidades de la persona que lo desarrolla. Es por la forma en que se elaboran los programas.

Según la RAE la palabra desarrollador ni existe.  Por lo tanto el desarrollo de software es dirigido por el programador. Porque es el programador la persona encargada de elaborar el programa. Quizás la necesidad de llamarnos “desarrolladores” es para sentir que hacemos algo más que solo escribir código. Y es cierto que hacemos algo más. Lo hacemos porque somos programadores y elaborar un programa requiere de varias actividades.

Hay de programadores a programadores, los hay con mucha preparación, habilidades, profesionalismo y también los que leyeron un manual e hicieron unos programas para ellos mismos, los que solo copian y pegan código del internet. Algunos solo conocen un lenguaje de programación o un IDE. No por eso nos vamos a llamar de una manera diferente. Así como hay constructores que hacen rascacielos y otros que solo casas para mascotas. Si te dedicas a elaborar programas, eres un programador. Si no te gusta que te digan programador y prefieres que te llamen desarrollador (palabra que no existe), esta bien, yo también lo hacia; pero recuerda que un(a) programador(a) se dedica a desarrollar software.

Leer antes de escribir

Es común que una persona que toma un proyecto iniciado por alguien más, critique la manera en como esta hecho. Pasa en muchas profesiones y/u oficios. Trato de no hacerlo (tanto); pero...algunas veces es sorprendente como la persona que escribió el código se complicó la existencia reinventando la rueda. Es decir, creando su propia solución para un problema común. Es aún más sorprendente cuando quien lo hace tiene varios años trabajando en proyectos. Trataré de explicar como evitar ser esa persona que complica el código. Antes, daré un ejemplo de situaciones de este tipo.



Al leer código de alguien más.

En las aplicaciones realizadas en .NET la configuración de la aplicación se guarda en un archivo llamado igual que el ejecutable añadiéndole la extensión ".config". Así si mi ejecutable se llama miAplicación.exe tendré un archivo llamado miAplicación.exe.config  en el mismo directorio. En caso de ser una aplicación web, el archivo se llama web.config. El formato del archivo de configuración es estándar y existen librerías que facilitan la lectura de los valores de configuración.

He estado en proyectos donde la persona que lo inició creó su propio formato de configuración y su propia convención para nombrar los archivos. La aplicación funciona; pero esto hace que se requiera más tiempo para entender lo que hace el código fuente del programa, se tiene más código que mantener a cambio de prácticamente ningún beneficio. La decisión parece estar basada en que no se conocía la manera (.NET ) de hacer las cosas. También lo he visto al usar librerías de acceso a datos, donde el programador original creo una forma de ejecutar los scripts, en lugar de seguir la convención o utilizar las clases que da el marco de trabajo.

¿Por qué alguien que tiene varios años programando no usa lo común? ¿Por qué no sigue la convención? Puede ser por la misma razón por la que algunas personas tienen faltas de ortografía. Por ejemplo yo. Hace tiempo al momento de escribir lo hacía con muchas faltas de ortografía, con el tiempo he aprendido a escribir mejor. Ahora es fácil notar (sin ayuda de un corrector ortográfico) cuando una palabra esta mal escrita. Esto no pasó solo por escribir varios años.

Empecé a notar que las palabras se veían raras, si estaban mal escritas, porque me acostumbré a verlas escritas correctamente al leer texto de otras personas, en libros, blogs, etcétera. El leer me ha ayudado a escribir mejor, a notar cuando algo no anda bien en lo que escribo. Aun sigo equivocándome; pero sé que entre más lea y escriba, reduciré mis faltas de ortografía.


Leyendo código. Foto de Gabriel Flores.

De igual forma leer código de otras personas ayuda a escribir mejor código. Siguiendo con el ejemplo anterior, si el programador hubiera leído el código de varias aplicaciones .NET se hubiera percatado de que la forma en que estaba guardando la configuración no era lo común. Hubiera sentido que su código se veía raro. O tal vez ni si quiera hubiera pensando en reinventar como realizar la configuración de la aplicación y hubiera usado directamente la convención del marco de trabajo.

Para escribir buen código además de tener práctica escribiéndolo, también hay que leer código de otras personas. El no hacerlo puede provocar que hagas algo distinto a la convención o "reinventes la rueda", que puede ser divertido (y servir para aprender) la primera vez; pero a la larga es algo a lo que pocos querrían darle mantenimiento. Si quieres escribir mejor código, práctica y lee código de otros.

Desarrollando en la nube de nitrous

Actualmente la maquina que uso para desarrollo es una laptop con un disco duro de 100 GB por lo que no tengo mucho espacio para instalar todo lo que quiera. Trato de instalar solo lo necesario para mi trabajo. Por eso no me gustó la idea, cuando en el proyecto que estaba trabajando necesité instalar Postgresql. Mi maquina actualmente ya tiene Firebird, Interbase, MS SQL Server, MySQL y el cliente de Oracle.

Recordé que hace tiempo había trabajado con nitrous.io por recomendación de un amigo. Así que creé una maquina nueva, la que había usado antes ya no la necesitaba (por ahora). Seleccioné el ambiente de nodejs e instalé Postgresql. Y así en unos minutos ya tenia una maquina con Linux, git, node y postgresql, gratis y lista para empezar a desarrollar.

Existen formas de usar tu editor local y sincronizar archivos; pero opté por usar el editor y la consola en línea. Es una ventana en el navegador donde esta un editor de texto con un árbol mostrando tus archivos y una ventana con la terminal. Con eso es suficiente para empezar a trabajar sin necesidad de tener archivos locales, ni software instalado localmente.

Después de un buen rato de estar trabajando en el proyecto, incluso olvidé que estaba trabajando en el navegador. El servicio es gratis si usas una maquina modesta. Puedo acumular "puntos" que llaman unidades de N2O y hacer mi maquina mejor, ya sea pagando o si alguien se registra usándome como referencia.

Se lamentó

Llegué algo tarde a la presentación. Traté de poner atención para de alguna forma ponerme al corriente con el tema. En eso el presentador dijo una grosería, para enfatizar su punto de vista. Me pareció gracioso y reí junto con el resto de la audiencia. Después de unas cuantas palabras, otra grosería y luego otra y así sucesivamente... rápidamente dejo de ser gracioso y empezó a molestarme en cierto modo.

Polo Polo. 

No me siento ofendido cuando algún presentador usa groserías. Hay ocasiones que pueden hacer un chiste más gracioso, si se usa en el momento correcto. El problema es cuando el chiste es la grosería en sí. Eso fue lo que sentí en esa presentación. Pudo el problema ser que llegué tarde y no entendí el contexto. Realmente quería aprender del tema, sentía que las groserías (para hacer la platica "real", "graciosa", etc.) se metían en mi camino.

Cada quien tiene su estilo para presentar y hay audiencia para cada uno. En lo personal no me gustó ese estilo, creo que por el hecho que lo siento como un recurso "barato" sobre todo cuando se usan en exceso. Aunque para decir groserías también se requiere algo de gracia, digamos talento. Creo que no era el lugar ni el momento. Una que otra, de vez en cuando, puede hacer que te mantengas alerta en el platica. Sin embargo, también pueden usarse otros recursos para  mantener al público enganchado.

Lamento que haya quienes no se tomen ese tiempo para expresar, de una manera respetuosa, su punto de vista a los asistentes. Aun así valoro y agradezco (a todos) por el tiempo que invierten en desarrollar un tema y presentarlo a los demás.

Acceso directo al Package Manager Console

Desde hace tiempo, al trabajar en proyectos .NET me es necesario tener a la mano la Package Manager Console abierta (también conocida como Nuget). Ya sea para instalar paquetes en el proyecto(s)  o para correr comandos de los paquetes (sobre todo de Entity Framework, al trabajar con migraciones).
Procuro, como muchos desarrolladores, no usar  el ratón al momento de programar. Al usar con Visual Studio, "todo" se puede hacer solo usando el teclado. Para abrir la consola de nuget no he encontrado un acceso directo por defecto. Si quiero ver la consola, debo navegar por los menús con el teclado.



Presionar ALT + T, N, O. ¡Son muchas teclas!

Una vez abierto puedo usar CTRL + TAB y con las flechas seleccionarlo, es tardado.

 

Afortunadamente VisualStudio nos permite crear nuestros propios accesos directos. Para la consola de nuget (Package Manager Console) agrego CTRL + ALT + N como acceso directo. Así rápidamente puedo correr los comandos de las migraciones al trabajar con Entity Framework.

Para agregar el acceso directo: en el menú Tools, abro Options. Selecciono Keyboard en el menú de la izquierda, busco PackageManagerConsole, lo selecciono y presiono el nuevo acceso directo en el cuadro de texto. OK y listo. Ya tengo un acceso directo a la consola de nuget.

Tener este shortcut mejora mi flujo de trabajo...

Mejor en persona

En varias ocasiones al estar haciendo algo de difusión sobre las reuniones de los grupos de usuarios (en particular con tijuana.js). Me han sugerido que transmitamos o grabemos las presentaciones para poder verlas sin asistir a la reunión. He considerado esa opción aunque no le he dado seguimiento. Principalmente porque no lo veo como una prioridad para la organización del grupo. Incluso he llegado a pensar que tal vez no sea buena idea.

 

Para mí, la meta del grupo es ser un lugar donde personas con un interés común (JavaScript en el caso de tijuana.js) se reúnan para compartir conocimiento, ideas, experiencias, etcétera; es decir, donde se puede hablar de eso que tienen en común. También, es un espacio para conocer a "colegas" de la región.

Como parte de esa meta, uno de los objetivos del grupo es tener una presentación de calidad cada mes para que tanto asistentes como presentador puedan aprender, comentar, discutir y estar al tanto de los temas. Tomando esto en cuenta se podría pensar que al grabar las sesiones se beneficia al grupo porque podría lograr que el conocimiento se compartiera con más gente. Aunque se cumpliría con el objetivo quizás eso no contribuye a que se cumpla con la meta del grupo.  Las presentaciones son un medio, no un fin, son para tener algo de que platicar en la reunión. Sin asistentes no habría razón para la existencia del grupo. En cuanto al material visto en las reuniones, si de verdad te es importante tenerlo, es fácil encontrarlo en línea. Puede ser en el blog del mismo presentador o en sitios similares.

 

En conclusión, no es prioridad grabar las presentaciones de los grupos porque considero que no ayuda a la meta: reunirnos, conocer “colegas” de la región, comer pizza, tomar sodas y hablar de tecnología cada mes.