domingo, diciembre 13, 2015

¿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.

jueves, noviembre 19, 2015

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? 

martes, septiembre 29, 2015

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.

viernes, agosto 28, 2015

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.

jueves, agosto 06, 2015

¿Qué es un Programador Senior?

Junior-Developer-vs-Senior-Developer-e1408641226868Hace 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

miércoles, agosto 05, 2015

¿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".

erase

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.

martes, julio 28, 2015

¿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…

programadores-artistas

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.

jueves, julio 02, 2015

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.

presentar 

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

lunes, junio 22, 2015

Banderas rojas en las ofertas de empleo

Sad man waving a red flag gesturing defeat 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.

lunes, mayo 04, 2015

Dev3Cast - El (mal) estado de animo

angry-at-computer"Cuando logras terminar los pendientes sales sintiéndote bien; pero cuando algo nomás no te sale y ya tienes que irte, terminas con un poco de frustración y puede afectar tu actitud por el resto del día…". 

Hace poco platicamos (Gabriel Flores y yo)  sobre el estado de ánimo después del trabajo. Comentamos sobre las causas, una vez que pasa como remediarlo y también de como podríamos prevenir esa frustración.

Escucha la conversación en el podcast dev3cast.