No hagamos repositorios para el acceso a datos

Este artículo está pensado sobre todo para el desarrollo usando el .NET Framework. Quizás aplique para los demás también, ya que casi cada Framework tiene su ORM.

Hace ya varios años que leí la opinión de Ayende Rahien acerca de que el patrón repository era el nuevo singleton. Tiempo después Jimmy Bogard también escribió sobre alternativas.

A mi entender el patrón repository consiste en abstraer el acceso a datos para que el resto del código no tenga que lidiar con los detalles del acceso a datos (conexiones, consultas, SQL, etc) al momento de acceder a colecciones de datos.

Con  el creciente uso de ORMs el patrón repository ya no es necesario. Ahora podemos usar algo como Entity Framework y dejar que se encargue de esos detalles para los que construíamos un repositorio. Entity Framework (o cualquier ORM) hacen eso y más sin que tengamos que escribir tanto código de "plomería". Escribo este post porque aun veo a programadores que intentan usar el patrón repositorio aún y cuando están usando un ORM.

No veo la utilidad de abstraer la abstracción del ORM (como EF) bajo el patrón repository. No es necesario, es querer apegarse a un patrón de diseño solo porque antes se usaba. Sí, se usaba porque era necesario; pero ya no lo es. La meta no es usar patrones, la meta es tener software funcionando que sea fácil de modificar.

Escribí un poco sobre esto cuando traté el tema de la arquitectura en capas, aunque el artículo no se trataba precisamente del patrón repositorio.

El código no es lo más importante

Aunque me gusta mucho trabajar en el código, debo reconocer que no es lo más importante. No es para lo que nos contratan. Lo usamos como una herramienta para lograr un objetivo: tener software funcionando. Eso es lo que espera el usuario o cliente de nosotros. De nada sirve el código "elegante" si no hay software resolviendo problemas.

En ocasiones olvidamos que la meta no es lograr cierta arquitectura,  poder utilizar ese framework,  lenguaje que está de moda o familiarizarnos con cierta tecnología. La meta es resolver un problema. Y hacerlo de la manera más eficiente, es decir, que no vaya a generar otro problema después.

Tampoco se trata de no darle importancia al código y hacer un cochinero

Aunque el código no es la meta y no es lo más importante, es necesario escribir código de calidad y evitar la deuda técnica. En ocasiones, por tratar de dar una solución "rápida" al negocio, escribimos código que resuelve el problema de momento; pero que si lo dejamos así sería difícil darle mantenimiento, sería complicado modificarlo o adaptarlo a nuevas necesidades. A esto le llamamos "Deuda Técnica", ya que como toda deuda, al principio te saca del apuro; pero tarde o temprano tendremos que pagarla y eso nos va a costar más entre más tiempo pase.

Aunque el código no es para lo que nos contratan, al ser nuestra herramienta principal de trabajo debemos mantenerlo limpio y fácil de modificar. Pero no perdamos de vista el objetivo: tener software funcionando, resolviendo problemas del mundo real.

Errores al Realizar Estimaciones

Casi siempre antes de iniciar un proyecto, es necesario saber cuanto tiempo nos vamos a tardar. Esto es para saber si realmente vale la pena hacerlo o no. Cuando el proyecto es personal no es tan complicado calcular, bueno por lo menos no es un riesgo; pero cuando es un proyecto que se va a cobrar y el cliente o jefe quiere saber si vale la pena realizarlo, a veces esa presión no nos deja estimarlo bien. Muchas veces los errores son cosas que pasan seguido y se pueden evitar si las identificamos.

El primer error es no querer estimar, es común escuchar o pensar "yo no sé estimar" y ese es nuestro pretexto para no ser responsables del estimado. Es normal no atinarle al tiempo que se lleva una tarea, sobre todo si es la primera vez que estimamos cuanto tiempo se lleva algo. Estimar es una habilidad que se obtiene practicando. Si queremos ser mejores estimando, debemos estimar más. Entre más lo evitemos, menos aprendemos a realizarlo.

Otro error al estimar es el ser muy optimista. Esto es pensar que todo va a salir bien a la primera. O que las cosas no van a cambiar. Cuando estamos trabajando en un proyecto de software, las cosas "nunca" van de acuerdo al diseño original (por algo lo llamamos desarrollo). Cuando estimamos debemos tomar en cuenta que lo más probable es que nuestra primera propuesta de solución no sea la adecuada. Siempre hay que agregar el "colchón" por si las dudas.

Ser muy pesimista es un error también, generalmente pasa después de que tuvimos problemas en proyectos anteriores por ser muy optimistas. Aquí el síntoma es que le ponemos tanto "colchón" a las tareas que puede parecer que el proyecto no vale la pena desarrollarlo por todo el tiempo que se llevaría. Encontrar el balance viene con la práctica.

Para poder saber el tiempo que nos lleva realizar un proyecto debemos poder definir las tareas  necesarias para completarlo. Otro error frecuente es no descomponer el proyecto en tareas concretas. A veces por no ponernos a pensar un momento a que se refiere cada tarea, podemos llevarnos una sorpresa al momento de realizarla y darnos cuenta que en realidad se lleva menos o más tiempo del que habíamos pensado. Es importante estimar cada parte del proyecto.

El último error de mi lista es no revisar que tan cerca estuvimos del estimado original una vez que terminemos cada tarea y el proyecto. Para poder aprender necesitamos saber que tan cerca o lejos estuvimos y entender el porqué. Esto nos va a ayudar a tomar esos factores en cuenta la próxima vez.

Enseñar menos para que aprendan más

Hace años empecé a dar clases de programación por las noches. El sistema que utilizan en la universidad donde trabajo es por cuatrimestres. Es decir, en lugar de dos cursos por año (semestres). Los alumnos toman tres cursos por año de cuatro meses cada uno. Esto provoca que los temas tengan que verse con cierta urgencia, porque "siempre" estamos contra reloj.

Una crítica constante de los estudiantes había sido que voy muy rápido, lo cual yo justificaba por el hecho de que en cuatro meses debía enseñarles muchos conceptos.  Eso sí, terminaba el curso a tiempo; pero muchos conceptos apenas y los tocaba. Los conceptos básicos no los practicábamos lo suficiente.

Para algunas personas esta forma exprés funciona, ya que practican por su cuenta y llegan a conocer los conceptos a detalle una vez que llega la necesidad. Sentía que parte de mi función era solo dárselos a conocer, exponerlos a las técnicas o tecnologías y después ellos/ellas vieran por su cuenta que partes tomar. Aplicar lo nuevo lleva su tiempo y en un cuatrimestre tiempo es lo que no tenemos.

Ahora lo que me ha funcionado es enseñar menos y repetirlo varias veces. Escribiendo varios ejercicios que ejecutan los mismos conceptos una y otra vez. Ya que estos se dominan, entonces empezar a introducir nuevos conceptos. Esto hace que algunos conceptos no alcance a enseñarles, lo cual no me gusta del todo. Quizás a alguien le podría haber servido conocer que existe cierta técnica; pero he notado que aunque estoy enseñando menos la mayoría está aprendiendo más. Por lo menos los grupos van más parejos. Al ser más repetitivo, los alumnos más avanzados pueden aburrirse un poco; aunque también les ayuda a su confianza poder realizar los ejercicios con facilidad en lugar de ir apresurados con los nuevos temas.

Ahora enseño menos, con más repeticiones (en forma de ejercicios) para aprender más.

¿Para qué conocer otras tecnologías?

Aunque no trabajemos con otras tecnologías es bueno conocerlas. Podemos aplicar conceptos que son comunes en otros entornos. No tenemos que conocerlo a detalle; pero sí saber de qué se trata. Al hacer eso nos daremos cuenta que quizás ya existan implementaciones de aquellos conceptos en nuestro entorno que probablemente no los aprovechamos por desconocer cómo se usan.

Hace años casi todo el desarrollo de software en el que trabajaba era ASP. NET Web Forms. Con esa tecnología podía lograr casi todos los proyectos que me pedían. En aquel tiempo se puso de moda Ruby On Rails; pero hacerlo correr en Windows era muy complicado. De cualquier forma, como era algo que muchas de las personas que sigo (en el internet) lo mencionaban, me propuse conocerlo. Aplicar lo nuevo lleva su tiempo por lo que quería estar preparado. Hacer un hola mundo y después unos proyectos sencillos, como ejercicio, para conocer el Framework.

Aunque no fui a trabajar tiempo completo en proyectos de Ruby on Rails, esa experiencia me sirvió para ASP.NET, ya que basándose en esas ideas se desarrolló ASP.NETMVC. Cuando se lanzó el framework ya tenía un poco de ventaja, porque ya conocía el patrón MVC en Web gracias a que conocía otras tecnologías. Lo mismo pasó con Nuget, por ejemplo, el concepto de un administrador de paquetes no era común en .NET pero sí en otros ambientes. Conocer cómo trabajan esos otros entornos, nos ayuda a mejorar y a estar preparados para lo que venga.

 

Ahora ASP.NET 5 es una versión completamente nueva, que está principalmente basada en nodejs, el haber trabajado en nodejs (aunque no pagara mi sueldo) me ayuda a entender las decisiones tomadas al desarrollar la nueva versión de ASP.NET y me facilita aplicar los conceptos necesarios para aprovechar mejor el marco de aplicaciones. Así hay varios ejemplos de un lado a otro, algunas características de C#, por ejemplo, se agregarán a JavaScript.

Como programadores podemos especializarnos en ciertas tecnologías para el desarrollo de software, sin embargo es conveniente poner atención a lo que sucede en otras comunidades de desarrollo de software, podemos aprender conceptos y técnicas que podríamos aplicar a nuestra especialidad. También podríamos descubrir que nos gustan otros lenguajes o plataformas y que ahora nos quisieramos especializar en ellos.

La experiencia

Hace poco escribí sobre lo que es un programador senior. Algo que no anoté como característica fue la experiencia como tal, aunque esas características te las da la experiencia. La mayoría tienden a medir la experiencia en años; pero la experiencia no es solo la cantidad de tiempo que llevas usando cierta tecnología, importan los diferentes retos a los que te has enfrentado a lo largo del tiempo que llevas usándola.

Además de los años trabajando se necesita que esos años hayan sido en diferentes escenarios, que se haya aplicado la tecnología para resolver diversos problemas. Si solo has trabajado en un proyecto en los últimos años, tú experiencia puede ser parcial por solo haberte enfrentado a un problema en particular.

También es necesario haber usado las diferentes versiones de la tecnología en la que estás trabajando. Continuando con el ejemplo de llevar años trabajando en el mismo proyecto. Podríamos decir que el programador tiene experiencia en la tecnología si se ha enfrentado a retos actualizando la aplicación a las nuevas versiones.

El hablar de experiencia me recuerda al negocio de Starbucks, el café es más caro que en otros lugares; pero uno no va solo por el café, sino por la experiencia. Del mismo modo cuando se selecciona a un programador experimentado para un proyecto, no se hace solo por los años que lleva programando, sino por los diferentes retos a los que se ha enfrentado al trabajar en diversos escenarios.

Artículos relacionados:
Aplicar lo nuevo lleva su tiempo
La práctica hace al maestro 
¿Qué es un programador senior? 

Debemos dar estimados

Unos de los aspectos importantes para decidir si un proyecto se aprueba o no es conocer lo que va a costar y cuánto tiempo va a tomar el desarrollo. Como programador me gustaría no tener que realizar estimaciones de cuanto me voy a tardar, me gustaría solo programar y ya. "Estará listo cuando esté listo" es una de las respuestas favoritas. Sin embargo como consumidor, cuando solicito un servicio, me gusta saber cuánto se van a tardar y cuánto me va a costar.

Por ejemplo, cuando llevo el carro al taller mecánico, me gusta saber qué le van a hacer, cuánto me va a costar y el tiempo. Aun sin saber de mecánica, debo saber si vale la pena arreglarlo o quizás me conviene andar en taxi por un tiempo, incluso ver la opción de vender ese carro y comprar otro.

Lo mismo pasa cuando planeamos realizar trabajos de construcción, por ejemplo, alguna ampliación en la casa. Antes de conocer los detalles me gustaría saber cómo cuánto cuesta, para ver si estoy listo para tener esa inversión. No puedo simplemente crear historias de usuario para la nueva habitación, pedirle al equipo de construcción que empiece y que diario me vayan platicando qué hicieron el día anterior, lo que harán hoy y los obstáculos que han encontrado. Y mientras, yo pagar cada semana y esperar que me avisen cuando esté listo.

Si contrato a alguien que va empezando quizás no sepa cuánto se lleve terminar una construcción. Por su falta de experiencia no me hará las preguntas necesarias para poder hacer un análisis, crear un diseño para determinar el tiempo y costo. Si contrato a un profesional yo espero que sepa recabar toda la información necesaria para poder realizar el análisis, diseño y presentarme un proyecto con el tiempo y costo estimado. 

Lo mismo esperan nuestros clientes si contratan a un profesional. Una vez que nos exponen su necesidad nosotros debemos de realizar las preguntas necesarias para poder realizar un análisis, crear un diseño y estimar el tiempo y costo del proyecto.

El profesional es el experto en el tema. Es la persona capacitada para tomar las mejores decisiones en el proyecto. Es por eso que es el profesional quien debe ser responsable de que el proyecto se termine en tiempo y dentro de presupuesto. No debemos dejar que el cliente, que no necesariamente conoce como se desarrolla el proyecto, corra el riesgo de nuestras decisiones profesionales. Tampoco debemos esperar que siga pagando retrasos de proyecto debido a nuestras malas decisiones.

A veces como programadores nos da miedo presentar un presupuesto a un cliente, preferimos cobrarle por hora para no correr riesgos; pero como profesionales debemos ser nosotros los responsables del proyecto.

Puede haber imprevistos, por eso se debe tomar un tiempo para "lo que pudiera pasar". Además se puede ir ajustando el estimado conforme haya cambios en los requerimientos. No por eso debemos evitar la responsabilidad y comprometernos a entregar algo en tiempo y forma.

Desventajas de Trabajar Desde Casa

Tengo varios años trabajando desde casa, me gusta mucho y para mí tiene muchas ventajas; pero debo admitir que también tiene algunas desventajas y a veces es necesario estar en la oficina. Creo que son más las ventajas; pero esta vez quiero escribir sobre algunas de las desventajas que he tenido al trabajar desde casa.

Ruido… y no necesariamente ruido de la casa. Porque aunque esté solo en casa, los vecinos se encargan de hacer ruido. A veces el vecino que pone música para que toda la cuadra lo escuche, perros ladrando, el vecino pide una pizza y tarda en salir con el repartidor, vendedores tocando a la puerta, gritos, etc. Esto hace que muchas de las veces tenga que trabajar con las ventanas cerradas. Aun con las ventanas cerradas algunos ruidos externos se escuchan y son muy molestos sobre todo al momento de tener juntas.

Interrupciones externas, también pasan cuando no se trabaja desde casa. Llega gente y te interrumpe. Pueden manejarse las interrupciones por familiares; pero también las hay por personas ajenas a la casa. Vendedores, cartero, en fin todo aquel que llega a tocar y pues no es como en la oficina que alguien más se encarga de atenderlos.

Siempre estás en el trabajo, a veces es difícil separar cuando estás trabajando o cuando debes de simplemente disfrutar estar en casa. Como no hay una separación física es común tener esa sensación de que siempre sales tarde del trabajo, que te la pasas en la oficina todo el día. Al inicio del día es una ventaja despertar y ya estar en el trabajo; pero al final del día sientes que no te puedes ir.

Tiendo a postergar las salidas. Por ejemplo cuando tengo que salir ya sea a realizar un trámite, un pago, al banco o lo que sea, prefiero evitarlo y seguir en casa. Como que me acostumbro a estar en casa y salir es más pesado. Como cuando pierdes condición física por no correr y luego hacer deporte te da más flojera.

El trabajar desde casa también tiene las desventajas de trabajar remoto, estas no son necesariamente desventajas por estar desde casa. Ya que ocurren aunque estés en una oficina que no sea la misma donde está el resto del equipo. Estas pueden ser: falta de comunicación con el equipo, es más complicado apoyar en detalles técnicos, entre otros. Los retos que se tienen con el trabajo remoto, sobre todo cuando se necesita interactuar con varios equipos, hacen que a veces sea necesaria la visita a la oficina de la empresa.

¿Qué es un Programador Senior?

Hace tiempo en una reunión con uno de nuestros clientes se hablaba de la posibilidad de asignar algunos programadores senior al proyecto que se estaba discutiendo. Una de las personas en la junta preguntó: “¿Cuáles son los criterios que usan para saber si un programador es senior?” La pregunta me puso a pensar en que realmente no tenemos una definición formal para clasificar a un programador como Senior; pero si podemos reconocerlo cuando lo vemos. Lo reconocemos por sus características.  

Es autónomo y sabe trabajar en equipo. Con autónomo me refiero a que no necesita que alguien le esté ayudando constantemente para poder realizar su trabajo. Ya sea porque no tiene la experiencia o conocimiento en programación o porque no conoce el dominio del problema. Puede que la persona sea buena programando pero nunca ha trabajado en una industria en particular y por lo tanto quizás con frecuencia requiera ayuda para temas relacionados con la industria. En ese caso se le puede considerar JR al programador aunque tenga ya experiencia programando, por lo menos al principio mientras puede trabajar sin ayuda constante. También es necesario que sepa trabajar como parte de un equipo, para ello es necesario haber trabajado en otros equipos y así saber cómo aprovecharlo. Se sabe coordinar con sus compañeros de equipo.

Entiende como ayuda al negocio. Está es una característica que se sale un poco del aspecto técnico y a la vez está relacionado con el punto anterior. Un programador senior entiende que para la mayoría de los clientes la meta no es el software en sí. El software es una herramienta que ayudará al negocio a realizar mejor su trabajo. En este aspecto el programador junior solo se preocupa por que el software funcione. El programador senior aporta a la solución, no solo ejecuta.

Sabe medir el riesgo. Al ser independiente y entender como ayuda al negocio es capaz de tomar decisiones sobre el desarrollo de software tomando en cuenta el impacto que tendrán en costo y tiempo de entrega del proyecto. No se deja llevar por "el factor cool" o por ser lo nuevo. Sino que considera cual es la mejor opción para el proyecto.

Puede guiar a los demás. El programador senior puede enseñar a nuevos programadores, puede explicarles las necesidades del negocio, enseñar los aspectos técnicos de la plataforma o entorno de desarrollo y aportar ideas para establecer las reglas al momento de trabajar en equipo. Puede ser un mentor y guiar a programadores JR en su camino a convertirse en mejores programadores.

No hay umbral fijo para saber cuándo un programador es JR, Mid o Senior. Estos son aspectos que dependen de persona a persona.

Me gustaría conocer otras características u otras formas de definir a un programador Senior, envíame tus ideas a blog@developeando.com

¿Y si lo reescribimos?

Llevaba varias semanas trabajando en las modificaciones y correcciones del proyecto. Era una herramienta iniciada por un programador que ya no trabajaba en la empresa. Un día simplemente ya no se presentó a trabajar. Por lo que no podíamos contactarlo para que nos explicara las decisiones tomadas o el porqué de ellas. El cliente estaba preocupado porque estábamos ya fuera del tiempo de entrega. Para mí como programador era frustrante tener que corregir ese proyecto, pero no quería que mi frustración me llevara a tomar una decisión equivocada que resultara en tiempo perdido tratando de rehacer algo para lo que ya no había tiempo disponible. "Los menos cambios al código fuente, en el menor tiempo posible..." me decía a mi mismo, esa era la meta.

Ya me había pasado antes, tener esa idea en la cabeza cada que veía el código fuente "¿Y si lo reescribimos? Sería más fácil en lugar de tratar de corregir esto... ¡No, no hay tiempo! Tardaría días para lograr que haga lo que ya hace". Así pasaron semanas, hasta que un día no pude soportar más esa sensación, lo decidí. "Esta semana no habrá avance, será para re-escribir lo que ya está hecho".

Fue un riesgo decidir reescribir, podría haber terminado con algo igual de complejo a lo que tenía o con nuevos errores, además me habría quemado una semana más de desarrollo en algo que se tiraría a la basura. Si de por sí ya estaba atrasado el proyecto (ya me veían feo), una semana tirada sería muy malo. Afortunadamente no fue así. Aunque no lo terminé en una semana; el código fuente se veía más "solido", era fácil de extender. Al cabo de unas semanas ya se podían agregar las nuevas características fácilmente, la interfaz de usuario se veía mejor (eso siempre ayuda a que el usuario aprecie los cambios). Ahora de lo que me arrepentía era de no haberlo reescrito antes, de no haber tomado el riesgo y rescribirlo desde que descubrí que la deuda técnica era mucha, el miedo a perder tiempo me había hecho perder mucho más, sin contar la frustración y estrés que había sentido esas semanas.

Ahora la pregunta que me hago es ¿cuándo es buena idea reescribir? Como para casi todo, la respuesta ahora es: "depende". Quisiera poder contestar la pregunta con algo más preciso; pero aún no he encontrado la fórmula. Como programador, al recibir código fuente de otra persona podemos sentir las ganas de reescribirlo, solo por el síndrome de no inventado aquí. Esto nos puede retrasar un proyecto y costar dinero/esfuerzo sin ningún beneficio; pero otras veces, como lo que me pasó, es algo que puede beneficiar al proyecto. Saber cuándo es buena idea es algo que aún sigo definiendo.

Entender claramente las causas y estimar el impacto es clave para tomar la decisión de reescribir. Una vez tomada la decisión se puede empezar por definir interfaces y realizar la implementación usando (copiando) el código existente (con los ajustes necesarios). Eso evita que reescribas todo a la vez. Una vez teniendo el proyecto corriendo podemos cambiar las implementaciones, dividiéndolas quizás en más componentes reutilizables, etcétera… ese ya es otro tema.

A veces es más fácil reescribir en lugar de tratar de arreglar, otras veces rescribir es caro sin ningún beneficio real. Distinguir es la cuestión. ¿Tienes una idea, sugerencia o pregunta? Envíala a blog@developeando.com.

¿Programar es arte?

He escuchado varias veces que programar es un arte. Es cierto que el código tiene algo de la personalidad del programador; pero de eso a llamarlo arte…

Hay muchas definiciones de lo que es arte, algunas lo definen simplemente como algo bien hecho; pero muchas otras hablan del aspecto estético y de la expresión del artista a través de su trabajo. Creo que por eso es que se le ha llamado arte a la programación, de alguna forma nos expresamos usando un lenguaje de programación. Además puede haber varios estilos para resolver el mismo problema. Algunos son más elegantes que otros y muchas veces la elegancia se basa solo en aspectos subjetivos, al igual que la belleza del arte.

El objetivo de la programación es distinto al del arte. El arte busca la expresión del artista, transmitir sentimientos, lograr un placer estético en el observador. La programación, por otro lado, busca la solución a un problema y al mismo tiempo hacerlo de una manera simple, ocultando la complejidad para el fácil mantenimiento del programa. Esa es la razón por la que considero que programar no es arte, ya que no busca la expresión del programador, sino la solución a un problema determinado.

Hay quienes opinan que la programación es una artesanía, lo cual me parece un termino interesante. Hace tiempo platicamos sobre la artesanía de software en el Dev3Cast.

¿Tienes algún comentario? Mándame un correo a blog@developeando.com.

Presentar en un grupo de usuarios

Un grupo de usuarios es una comunidad de programadores (o similares) que se reúnen aproximadamente una vez al mes para hablar de tecnología. La mayoría de las veces hay un invitado que presenta ante los demás algún tema de interés para el grupo.

Las reuniones de los grupos de usuario son en persona porque, aunque hay presentaciones que pudieran atenderse en línea, estas son solo un pretexto para reunirnos.

 

Los grupos de usuario son un pasatiempo, aun así considero que hay ciertas ventajas al dar alguna presentación: 

• Conoces más del tema: cuando me preparo para presentar, aunque ya conozca el tema, tengo que revisar la documentación y buscar cómo resolver posibles preguntas que tendrían durante la presentación. Esto hace que me familiarice más con el tema y así, al presentar aprendo. A veces pasa que alguien de entre los asistentes tiene experiencia en el tema o en un escenario en particular, esto me ayuda a tener otra perspectiva sobre como resolver el problema u otra forma de usar la tecnología.
• Conoces gente: he conocido a varias personas al asistir constantemente a las reuniones de los grupos de usuario, algunos se han convertido en buenos amigos, con los cuales (además de hablar de otros temas) puedo comentar cosas de tecnología sin sonar tan nerd. Al conocer gente, han surgidos oportunidades de empleo o de negocio, que aunque no se tratan de eso las reuniones, las oportunidades son reales.
• La gente te conoce: este punto está relacionado con el anterior. Aquí la ventaja es que las personas te conocen a ti como un profesional en lo que haces. Vas creando algo de reputación. La gente te ve como una figura de autoridad sobre el tema o (por lo menos) que puedes dominarlo.
• Aprendes a expresarte mejor: al tratar de explicar el tema a varias personas que quizás no todas tengan la misma perspectiva o experiencia que tú; tienes que tratar de explicarte con diferentes palabras. Si alguien no entiende de un modo no puedes repetir lo mismo y esperar que de repente lo entienda. Por lo que debes buscar otra forma de explicarlo. Esta habilidad de explicarte mejor no es algo que suceda al instante, requiere práctica. Presentar seguido ayuda a expresarte mejor.
• Adquieres confianza: al estudiar un tema y compartirlo con los demás, sientes que realmente dominas un tema y esa confianza puede reflejarse en tu trabajo, incluso en cómo te diriges a los demás. En cierto modo, presentar valida para ti mismo que conoces del tema.

Aun y con estas ventajas, puede que (aunque tienes el conocimiento) no te animas a presentar en un grupo de usuarios. Algunas de las razones que he conocido:

• Falta de interés para compartir o flojera: no a todos les gusta reunirse con otro programadores o hablar de programación y eso está bien. A otros solo les gusta escuchar o sienten que no tienen el tiempo de preparar una presentación. No se necesita de mucho para presentar, se trata simplemente de hablar de lo que haces en tu trabajo (si te dedicas a programar) o de lo que haces cuando programas. Si lo que tienes es flojera entonces no hay mucho que se pueda hacer.
• Miedo a hablar en público: "todos" nos ponemos nerviosos al presentar, la mejor forma de quitarse ese miedo es simplemente presentando. Darte cuenta que el peor escenario no es tan malo, además de ser poco probable. Y si llegara a pasar, siempre puedes intentar presentar después y corregir lo que haya salido mal.
• Sientes que no sabes lo suficiente: crees que al presentar se van a dar cuenta de que no eres tan bueno, que "eres un impostor o un fraude". Esto le puede pasar a todos, incluso si tu trabajo consiste en programar y recibes un sueldo por ello. Un grupo de usuarios no es una gran conferencia, tampoco un seminario o diplomado, la idea es solo platicar sobre tecnología. Te recomendaría que al presentar seas sincero y decir lo que sabes, los problemas que has solucionado y en lo que estas batallando. Los asistentes, por lo general, aprecian la sinceridad y tratan de ayudarte a mejorar.

Si estás trabajando en algún proyecto y has tenido que resolver problemas; entonces ya eres un buen candidato para presentar en un grupo de usuarios. Toma en cuenta que:

• La idea es reunirse y compartir experiencias, no nos reunimos para evaluarte como presentador.
• Como asistentes, sabemos que eres un programador, no un animador o comediante que tiene que divertirnos.
• La gente no va con la idea de burlarse del presentador.
• La mayoría de los asistentes están dispuestos a ayudarte si te atoras en la presentación o si falla el demo.
• Si todo te sale muy mal, en el peor de los casos, no pasa nada. No tienes que preocuparte por tener que regresarles su dinero, no es como si hubieran pagado por un curso o seminario.

Mientras seas una buena persona, no veo como pueda ser mala idea que presentes. Si te gusta la tecnología y platicar del tema, acércate a un grupo de usuarios. Siempre estamos buscando presentadores.

Platiqué de este tema con Gabriel Flores en el podcast dev3cast. Escucha el episodio.

¿Te gustaría comentar? Envíame un correo a blog@developeando.com

Banderas rojas en las ofertas de empleo

Es común ver en algunos grupos de usuarios que aparezcan ofertas de empleo. Hay algunas que llaman la atención por las características que piden de los candidatos al puesto. Son características que te hacen pensar dos veces si realmente quieres trabajar ahí. O por lo menos te hace preguntar y poner atención en la razón de ese requisito.

Las hemos llamado “banderas rojas”. No son necesariamente malas, solo las vemos como un posible peligro. Puede que en realidad sea una buena oferta de empleo; pero también puede ser que te des cuenta que ese puesto o empresa no es lo que buscas.  A continuación menciono algunas de esas “banderas rojas”:

Se solicita Programador Jr. con experiencia: Esta es una de las clásicas banderas rojas, al leer una oferta con esta descripción me hace pensar que quieren a alguien que haya trabajado antes y que realmente sepa hacer el trabajo. Por eso la parte de “con experiencia”; pero al mismo tiempo deja ver que el presupuesto para el sueldo es bajo, como para alguien que no tiene experiencia, de ahí la parte “Programador Jr”. Si quieres trabajar como si supieras con sueldo de como si no supieras, entonces este trabajo es para ti.

Trabajo bajo presión: Aquí me hace pensar que el bienestar del personal no es algo en lo que la empresa piense mucho. Pareciera también que la planeación no es buena. Puede que te den la información incompleta y cuando ya es tarde y por culpa de alguien más piden que termines algo que a lo mejor tú no estimaste. Trabajar bajo presión lo relaciono a estrés, lo cual no es sano. Quizás es una buena oferta y lo hacen para que solo envíen solicitud personas que no le tienen miedo al trabajo aunque este a veces se complique. Si lo tuyo es estresarte quizás este es el empleo para ti.

De 20 a 30 años (o cualquier otro rango de edad): Estamos hablando de puestos que tienen que ver con programar, no es una actividad física que necesita juventud para ser realizada. Entonces ¿por qué esta restricción? Generalmente cuando uno es mayor tiene más compromisos y se da cuenta que la vida es muy corta como para estar siempre en la oficina. Por lo que lo más probable es que no le dediques horas extras al proyecto al que alguien más se comprometió a una fecha de entrega, sin consultarte. Al tener más compromisos no te conformas con un sueldo bajo a cambio de obtener experiencia, algo que quizás harías en tu primer empleo. No estoy seguro del porqué en la restricción de edad; pero definitivamente es algo que quisiera saber antes de considerar aceptar la oferta.

Estas son algunas de las banderas rojas que he visto en las ofertas de empleado.

Hace poco platicamos (Gabriel Flores R. y Yo) de estas banderas y de otras cuestiones a considerar al examinar una oferta de empleo. Puedes escucharla en el dev3cast podcast.