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.