Esa gente que se pasea por mi oficina

Trabajar en casa es una oportunidad, un reto y hay a quien le gusta y a quien no.

Hay muchas versiones sobre si es un paraíso o un infierno. Hoy quiero contar algunas verdades porque ni es un paraíso ni tampoco un infierno pero si pide un cambio de mentalidad cuando lo empiezas a hacer.

Horarios
La fantasía mayor que hay con respecto al trabajo en casa es que uno puede trabajar en cualquier horario sin problemas y hacer la vida que quiera porque no hay horarios... ERROR!!!

Trabajar sin horarios es llamar al caos sobre todo porque no creamos la presión de completar los trabajos en determinado tiempo y sin esa presión solemos distraernos bastante con otras cosas porque "Ahora me pongo y lo hago" y mientras el día avanza y avanza.

Los horarios son importantes y cumplirlos mas. Sobre todo para poder disfrutar del resto del día sin pensar que aun tengo que hacer esto o aquello.

Disciplina
Esto es nuevo para muchos de nosotros cuando trabajamos en casa. Porque eso nos viene impuesto con el trabajo presencial.
Ahora somos nuestro propio jefe y eso no es nada fácil de hacer de buenas a primeras. No solo la imposicion de horarios es importante, deberíamos tener objetivos, imponernos castigos (y cumplirlos), bonificaciones por logros alcanzados, metas alcanzables pero no infantiles (ser serios en estos puntos nos hará mas eficaces), optimizacion de nuestro tiempo y evitar las distracciones (sobre todo las propias).

Familia
Un tema difícil. Hay momentos que la familia debe respetar nuestro espacio como si no estuviéramos ahí. Estamos trabajando, sin embargo nuestros horarios deberían adaptarse al ritmo familiar (horas de colegio, comidas, etc.) y aprovechar a ser mas activo en la vida familiar sin que eso nos impida hacer nuestra labor y cumplir unas horas de trabajo eficaces para poder rendir adecuadamente. La clave: (el siguiente punto)

Organizacion 
La organizacion es algo tan personal que existen mil teorías de como llevarla a cabo. Yo creo sinceramente que las formulas existentes son guias para luego realizar nuestro propio método nacido de nuestra experiencia personal.
Los horarios familiares (despertar de los hijos, escuela, la hora de comer, horarios de la pareja, etc.) Nos pueden ayudar a iniciar un sistema óptimo en el cual podremos "negociar" los tiempos necesarios para poder llevar a cabo nuestra labor.



Como nos ven
Trabajar en casa tiene (aun hoy en día) una imagen un poco confusa para la gente que no lo hace.
Escucharas gente que te dice que tienes mucha suerte, que es una buena oportunidad, etc y gente que te dirá que trabajar en casa no es trabajar...
La mayoría tiene un preconcepto (equivocado al 90%) de lo que es trabajar en casa y se forman una opinión poco fundamentada de lo que significa.
En ese punto hay que tener paciencia a veces y recordar que aunque aun hay una cantidad creciente de personas que trabajan así es una manera bastante nueva de trabajar y que tampoco es posible en todas las profesiones así que mucho nos pondrán la imagen de vagos (cosa que suena a envidia). Recordar: Paciencia.

¿Porque el titulo de este post? Porque trabajar en casa tiene un problema y es el desconectar.
Desconectar DEBE hacerse vivas en familia, solo o como sea.
Por eso los coworking han crecido, mucha gente prefiere alquilar una oficina compartida y no tener el trabajo directamente en su casa. Otros en cambio tienen una habitación / rincón / parte de la casa ambientada para trabajar.

Lo cierto es que hay que crear un cierto ambiente laboral en una zona de la casa para marcar una diferencia con el resto para que cuando no estemos en esa zona dejemos de pensar en trabajar...

Si no lo hacemos corremos el peligro de que estemos donde estemos de la casa todo lo asociemos a nuestro trabajo sin desconectar del todo y que al final y poco a poco cometamos el imperdonable error de ver a las personas que conviven con nosotros como "Esa gente que se pasea por mi oficina".

PHP is not dead

Releyendo la declaración de intenciones de este blog recordé uno de los objetivos de este blog que no es otro que compartir soluciones a problemas concretos que surgen mientras afrontamos un desarrollo.

Acostumbrado a las críticas no tengo reparo en anunciar que el lenguaje principal que manejo en mis desarrollos es PHP.
Eso no quiere decir que no haya probado o considerado las múltiples alternativas que tenemos a día de hoy: Java, Ruby, Python, algo de Microsoft... Grandes lenguajes y maravillosos frameworks detrás de cada uno de ellos sin duda, todos ellos válidos y con características que los hacen únicos para resolver situaciones específicas.

Respeto es la palabra que quiero remarcar en este escrito, pues si bien los candidatos son grandes proyectos en la web hay un solo rey. Es el lenguaje que cada año gana el premio al mas odiado. Es la cara de los meme de programadores y el chiste fácil entre estudiantes de tercero. Pero los números no engañan: a día de hoy PHP es usado en el 79% de los sitios de internet directa o indirectamente. 4 de cada 5 páginas que visitamos en la web hacen uso de este lenguaje y es una realidad.

¿La decadencia de PHP?

Es cierto que en los círculos de programadores backend se ha intentado dar por muerto a este lenguaje en mas de una ocasión.
No podemos obviar que durante mucho tiempo ha sido el lenguaje mas usado a la hora de desarrollar servicios web, y eso tiene pros y contras: como baza se puede aportar la enorme comunidad que alimenta la red de soporte al lenguaje y a todos los frameworks y librerías que han catapultado a PHP a ser el líder en cuanto a desarrollo web por parte de servidor se refiere. ¿Su punto débil? Paradogicamente es la facilidad con la que cualquier programador puede usar el lenguaje. Si bien permite que programadores con poco conocimientos puedan hacer uso de su potencia (a priori esto se podría considerar una cualidad positiva) muchos programadores opinan que estos trabajos (y en muchos casos con razón) no superan los mínimos estándares de calidad. ¿Un poco raro no? En mi opinión culpar a PHP de que haya programadores noveles intentando hacerse paso es similar a culpar al castellano por permitir que (ponga aquí al grupo o cantante que más odie) cante o escriba sus canciones. No somos tan radicales, ¿verdad?




Nunca es tarde si la dicha es buena

Las previsiones siempre son malas para PHP. No hay temporada que no aparezca como uno de los lenguajes mas odiados por los programadores. Teniendo en cuenta su campo de acción (aplicaciones web) y su uso (79%) cuesta entender esos resultados negativos. No seré yo el que diga que esas estadísticas no son reales, pero de serlo estamos hablando de una gran comunidad de programadores que dicen odiar su trabajo. En cualquier caso, es posible que esta gente que año tras año vota a PHP como lenguaje mas odiado no conozca algunas características del mismo:

-Es código abierto. Puedes usarlo y modificarlo a tu gusto sin dar cuentas a nadie.
-Su comunidad. El 80% de las webs están escritas en PHP. No tendrás problemas en encontrar sitios o gente que hablen de este lenguaje.
-Su rendimiento. Es cierto que las versiones anteriores de PHP eras más lentas que sus competidores. A día de hoy con la última versión estable (7.3) no hay nada que envidiar a los demás lenguajes. ¡A estas alturas es incluso más rápido que NodeJS!


¿Y ahora qué?

Yo no quiero convencer a nadie. En proyectos de alta concurrencia uso NodeJS. He tenido que programar en .NET por exigencias del guión. Y tengo que reconocer que no ha sido tan traumático como pensaba. Ese no el mensaje que quiero trasmitir. Los lenguajes de programación, los frameworks, los IDES...son solo herramientas para desarrollar nuestro trabajo. Es bonito encariñarse o defender el medio de nuestro sustento pero los fanatismos, como en otros contextos, restan mas que suman.

Mi lenguaje principal es PHP. A veces me siento orgulloso del código que pico pero no tengo nadie con quien compartirlo. Cada día aprendo cosas nuevas, tanto del lenguaje como de las buenas prácticas. También me ocurren cosas raras, y se quedan en el olvido. Es por eso que este post es el inicio de un nuevo hilo de post dedicados a recopilar curiosidades y anécdotas relacionadas con PHP que espero sean de ayuda o recordatorio a ese 80% de programadores web que usamos este lenguaje.


La imagen usada de morguefile.com pertenenciente  a Jackileigh: https://morguefile.com/creative/jackileigh/1/all

Qué es ser un desarrollador agile

Antes de nada quiero dejar claro que no hablo desde el conocimiento acreditado de la materia, hablo principalmente desde la experiencia de pasar a metodologías agile y ver cómo se ha experimentado el cambio a mi alrededor. El fin de hacerlo es dar un punto de partida al debate o al menos a la reflexión individual sobre qué implica esa forma de trabajar en lo que respecta a los desarrolladores. No cambia nuestro nombre, seguimos siendo equipo de desarrollo, pero ¿hemos pensado si cambian nuestras funciones?

En una metodología tradicional en cascada (bien entendida, no en la que se quiere todo para ayer y nadie hace una mínima reflexión) el proyecto pasa por una fase de análisis en la que hay distintas "cabezas pensantes". Generalmente, si se trata de un proyecto o empresa de cierta envergadura, el equipo estará jerarquizado y en esta fase intervendrá el jefe de proyecto, junto con un arquitecto técnico y quizá alguien del equipo de calidad o de UX o similares. Todos estos generalmente no serán luego parte activa del equipo sino que habrán generado toda una documentación, infrastructura y bases y se encargarán de dirigir o revisar los aspectos propios de cada área. ¿Que le queda al equipo de desarrollo? Picar código. ¿Que se espera de ellos? Que lo piquen.

Quiza he simplificado mucho. En esto, como en casi todo, hay mil matices, formas y circunstancias. Pero, en general, de un equipo de desarrollo tradicional, lo que se espera es que construya el producto tal cual se pensó en el tiempo que se estimó. Para ello el jefe de equipo se encargará de controlar y organizar, adquiriendo la responsabilidad última del proyecto y llevandose los palos o los aplausos segun vaya la cosa. Por otro lado cada desarrollador se responsabilizará de la parte de la aplicación que le toque trabajar.

En agile (bien entendido también, no como un simple faseo del proyecto en N proyectos cascada) las jerarquías se difuminan. El proyecto se divide en "pequeños cachitos" que no habrán pasado por esa gran fase de análisis. En el momento de planificarlos se analizarán entre todos y la idea es que todos aporten para sacar la solución más adecuada. Esto implica el primer cambio en los desarrolladores porque, para que su intervención sea real y productiva necesitan:
1. Conocimiento tanto funcional como técnico de todos los ámbitos del desarrollo para, poco a poco, ser capaces de aportar más y mejor y detectar antes las dificultades o impedimentos.
2. Habilidades sociales y capacidad dialéctica para proponer y exponer de manera clara tanto a personas del ámbito técnico como no técnico.
3. Capacidad de escucha activa, de dialogo, asertividad y empatía para que, en conjunto se lleguen a soluciones válidas y a acuerdos sobre cómo llevarlas adelante.

Evidentemente al inicio no tendrá la misma aportación un junior que un senior o una persona que lleva años trabajando aplicación que alguien que acaba de llegar. Hay que limar esas diferencias, ahora bien: ¿queremos? ¿Queremos conocer los entresijos de la facturación para hacer la aplicacion de gestión si nosotros somos seniors que estamos investigando la tecnología molona que vamos a emplear? ¿nos apetece escuchar la opinión del nuevo sobre otra librería para hacer la descarga de ficheros distinta de la que nosotros dominamos? Como junior, a mi que me digan qué tengo que hacer, que no cobro para responsabilizarme de tanto.

Ese es otro punto clave: la responsabilidad. Y es que si todos hemos aportado para dar esa solucion, la hemos estimado, la hemos analizado y nos comprometemos con ella, entonces todos somos los responsables de lo bien o lo mal que vaya, ¿no?

Cuando todo va bien, esto gusta: no hay uno llevandose las alabanzas como jefe mientras que otros son los que se han pegado con ello. Si a alguien le surge alguna dificultad no es "su" problema, es de todos y es responsabilidad de todos que salga adelante. Se tiene un equipo de verdad, en el que, como en los equipos de futbol o baloncesto, cada jugador desde sus direfencias aporta al conjunto y se siente parte de él. O todos ganan o todos pierden.

Sin embargo ¿que pasa cuando vienen mal dadas? Entonces esa responsabilidad no apetece tanto y era mejor cuando el jefe de proyecto "aislaba" los problemas o al menos volcaba el problema en el responsable de esa parte. "¡Si yo de ese tema no toqué nada!", "Yo ya dije en la planificación que eso llevaba más tiempo", "Lo tenía que haber hecho yo que me conozco mejor esa parte", "Yo hice lo que me dijisteis" y otras tantas frases empiezan a surgir. Todo son "balones fuera" y dedos acusatorios. O lo que seguramente es peor: silencios. Porque la palabra revela cosas pero el silencio vale sólo por lo que oculta. Y lo que oculta es que nos falta la característica principal del equipo: CONFIANZA. Confiar en que los compañeros son profesionales, en su compromiso, en que las criticas son constructivas y hacia el equipo y no personales y con intencion de "dejar mal". Confiar en que se puede hacer mejor entre todos. Confiar en que todos tienen algo que aportarme y quieren hacerlo. Confiar en que nosotros tenemos algo que aportar y podemos hacerlo.

Seguro que me dejo más cualidades importantes, pero como decía, esto es solo un punto de partida a la reflexión. Ahora es el turno de que, quien quiera, se mire su ombligo y el de su equipo. ¿Sois agile? ¿Creeis que se valoran estas características en vuestro equipo? ¿Echáis algo en falta?

Rápido es antónimo de bien

Quizá no es un buen día para escribir porque hoy es de esos días en que programar SÍ es una mierda. Un ex-compañero me diría que, después de 5 años en esto, es lógica esta sensación de hartazgo. Que ya me toca padecer "el síndrome del jardinero ausente". Este síndrome es ese que se produce cuando uno se quema con las miserias de esta profesión y piensa "yo me tenía que haber hecho jardinero" o, en los casos más extremos del síndrome, "como me toque un dinerillo me voy a comprar una finca en el pueblo abandonado más remoto y voy a vivir de mi propio huerto ecológico". Con el tiempo vi que hay quien cambia jardinero por pastelero o panadero. Y luego estoy yo que, siendo más de asfalto que un semáforo y poco hábil para las artes culinarias, nunca sé la profesión a la que asociar el síndrome aunque creo que sé notar los síntomas.

Acabo de buscar, por dar algo de rigor al texto, si hay alguna base científica a problema. He de decir que la búsqueda solo ha dado como resultado la entrada del blog en el que este compañero le puso nombre al síndrome. A lo mejor aquí hay un filón sobre el que investigar para alguna de esas universidades que hace informes surrealistas y absurdos que nadie sabe quién habrá solicitado.¿Lo proponemos?¿Os sentís o habéis sentido "jardineros ausentes"?

El caso es que, mientras intento alejar al pequeño jardinero que me atormenta, me pregunto cuáles son los motivos por los que, en esto del desarrollo de software, siempre se opta por hacerlo mal para hacerlo (supuestamente) rápido. Supongo que no es un mal solo de nuestra profesión, que en otras también pasa. Pero el mal de muchos ni me consuela ni mucho menos me ayuda a comprender.

Pongamos un ejemplo fuera de nuestro ámbito. Imaginemos que los obreros que contratamos para una reforma en casa dicen al jefe de obra que alicatar la cocina lleva 6 días en vez de los 3 previstos. Puede ser porque han encontrado un problema estructural en un muro, porque el pedido de material se retrasa o simplemente porque cuando dijeron el tiempo que se tardaba partían de la base de que era una cocina de 7 metros cuadrados y la realidad mide 67 (que no es mi caso, no os creáis). Para empezar no me imagino a los obreros planteándole "soluciones" al jefe, en plan:

- No tenemos material pero tu tranquilo, sabemos que tiene que estar mañana así que colocamos el que nos sobró de la última obra por encima, simulando que es el que pidió el cliente. Tú no te preocupes que mañana tu tienes la foto de la cocina "ya acabada" y luego ya se cambia, si no se tarda nada.

Tampoco me imagino al jefe (o como ahora gusta más, el líder) diciéndoles: 

-Pues tiene que ser en 3 días cueste lo que cueste. Y esto no se le puede decir al cliente. ¡Que va a pensar de mi ... digoooo... de nosotros si le digo que nos lleva el doble de tiempo! Y si hay que "hacer un esfuerzo" pues se hace, pero en la nómina nada, ya veremos cómo se compensa. ¿El problema estructural del muro dices?.... Eso lo vamos arreglando luego en los ratos libres que tengamos cuando vayamos poniendo el fregadero y la nevera, que seguro que ahí hay un hueco. Además me dijisteis que poner la nevera llevaba dos horas pero seguro que en una hora la tenéis instalada, que sois unos exagerados... El caso es que no nos puede parar lo del muro ahora, hay que seguir adelante. 

¿Alguien se lo imagina? Porque seguro que si cambiamos "problema en el muro" por "error en el core de la aplicación" y pasamos de "simular que está puesto usando el material de la obra anterior" a "simular con datos a pincho la carga en el front para la demo" no nos suena tan raro. Y menos el echar horas gratis. Es que "el cliente lo quiere ya".

Sin embargo, con el ejemplo de la obra, quiero pensar que, como a mí, sí os suena a exageración. No imagino como usuales estas conversaciones, porque lo que parece obvio que lo que pasaría es:
1. El problema estructural del muro una vez alicatado se hace 100 veces más complicado de arreglar y eso si es que se puede. Este problema se va a quedar ahí y lo que se dirá para justificar esa decisión es que, con suerte, para cuando alguien se entere "será problema de otro". Y al final, no hay suerte.
2. En el caso del material reutilizado y sobrepuesto para salir del paso, la realidad es que va a notarse en cuanto el dueño venga a verlo y toque o nos pida la foto desde otro perfil. ¿Consecuencia? Cliente cabreado que desconfía de nuestro trabajo, menos receptivo a nuestras sugerencias y explicaciones. Más crítico con lo que hacemos y más desconfiado. 
3. Sobre "hacer un esfuerzo", también conocido como "echar horas por la cara", para llegar a tiempo ¿qué se puede decir?. Las prisas nunca son buenas consejeras. Se pierde interés, concentración, y así, en un despiste, se taladra donde no se debe y ... más problemas.

Todo para evitar decirle a quién nos contrató que necesitamos más tiempo.¿Qué pasa si somos el dueño del piso y nos dice el responsable de la obra que necesita 3 días más? Si expone los motivos de forma clara, lógica y siendo transparente, ¿va a ser tan problemático?¿No vamos a entender que ha surgido un imprevisto en el muro difícil de identificar previamente y que no se debe ignorar? Si se ha visto un trabajo adecuado hasta la fecha, ¿vamos a pensar que se está inventando el problema para sacarnos más pasta? Si no tiene el material, ¿no vamos a entender que no se puede avanzar? Es verdad que se deberían haber manejado unos márgenes de tiempo contando con ciertos riesgos. Pero antes de romper todo acuerdo, ¿no intentaremos buscar una solución que permita a ambas partes encajar el problema del mejor modo? Para nosotros, con la obra en marcha, tampoco es tan fácil romper con todo, volver a pedir presupuestos, meterse en pleitos para recuperar el dinero... Y si sale todo adelante a través de una relación sana y transparente y el resultado es de calidad, ¿no acabaremos satisfechos a pesar de los altibajos en el proceso?¿No vamos a recomendar la empresa a otros?

Y aun así, todos tiramos con el apaño en vez de ir a por la solución más completa. Los desarrolladores, porque no nos consideren vagos o torpes, por ser resolutivos o porque simplemente nos hemos rendido a que nunca haya tiempo para hacerlo bien. El jefe-lider (o scrum master/product owner), por evitar afrontar problemas, porque ya va todo demasiado cogido con pinzas y ya se han tenido que plantear demasiadas excusas y, según avanza el tiempo, porque hay "presiones de arriba", ya que el cliente está al borde de la explosión de cólera, va a llamar a otra empresa y, además de no pagar la parte hecha, va a reclamar una indemnización que nos va a llevar a la bancarrota, por lo menos.

Al final, el resumen es siempre el mismo: el yo de hoy disimula sus errores, lanza el problema para otro lado y el yo del mañana lidiará con él si vuelve. Al de hoy, no le importa qué va a volver y en forma de monstruo mayor. Lo que importa es que el pequeño monstruo actual se solucione rápido. Y rápido debe ser antónimo de bien...




Un café para el becario

Disclaimer: todas las ideas y opiniones vertidas en este post son fruto de mi experiencia personal

A pesar de llevar toda la vida trasteando con ordenadores, no fue hasta la edad de 25 años en la que decidí (o me vi empujado) a cambiar mi carrera profesional y enforcarla al mierdoso maravilloso mundo de la informática. Durante los dos años de FP (ASIR) aprendí muchísimas cosas así como refresqué conocimientos de mis andaduras autodidactas. El segundo curso lo empecé con ilusión, pues al menos en mi centro el índice de contratación al finalizar el módulo era muy alto, y elegí realizar las prácticas obligatorias en una empresa de desarrollo de software.

Esos 3 meses fueron sin duda los que provocaron que dejase un poco de lado la administración de sistemas y me enfocase en la programación. Fuimos 3 los que empezaron (alumnos de distintos centros) y siendo una empresa pequeña (solamente 2 empleados que se dedicaban al desarrollo propiamente dicho) me sorprendió la atención que recibimos. Dudas resultas con paciencia, pair programming, confianza a la hora de trabajar con clientes finales...

Terminado el periodo de prácticas estuve unos meses trabajando como asalariado, pero al poco tiempo cambié de empresa. Pasé de una empresa con 3 desarrolladores web a otra con 12 empleados que programaban para distintas plataformas. También había algún que otro becario.

Con el tiempo, llegó el periodo en el que se puede solicitar a universidades o centros de secundaria estudiantes para que empezasen a saborear las mieles de la programación. Mi jefe me preguntó si necesitaba a alguien para que me echase una mano en el área de desarrollo web y recordando mi maravillosa experiencia le dije que sí. En ese momento tenía mucha carga de trabajo y tenía la certeza de que un becario aliviaría mi pesada carga. Error.

Sin culpar al estudiante, me vi encerrado en una espiral de preguntas constantes, errores inesperados y mucho trabajo. No pude ser el mentor que yo mismo tuve y la paciencia se perdía conforme se acercaban las fechas de entrega de proyecto. No había tiempo para charlas amigables y bueno, al fin y al cabo, yo era el único que tenía algo que perder.

Creo que algo que compartimos todos es que las prácticas en una empresa de IT son distintas a otros sectores. En todos los casos que conozco se ha delegado cierta responsabilidad desde el primer día y las empresas quieren sacar rendimiento inmediato del estudiante (cosa que veo totalmente lícita) pero esto no siempre sucede así.

Esa experiencia me hizo pensar en mi propio periodo de prácticas y en cómo pueden variar de un lugar a otro. A día de hoy soy incapaz de definir las variables que provocan una experiencia satisfactoria: ¿el tamaño de la empresa? ¿la actitud del mentor? ¿del estudiante? ¿la carga de trabajo?

Y vosotros, ¿qué pensáis de la figura del becario?

Propósitos del año

Todavía estamos a comienzo de año. Una de las dos épocas, con el mes de septiembre, en el que nos dedicamos a enumerar los buenos propósitos que queremos realizar a partir de ese momento. En PEUM, unos cuantos valientes, o insensatos, según se mire, nos atrevimos, hace algo más de un año, a hacer un listado de lo que íbamos a intentar hacer en 2018. Enlace.

Sin más preámbulo, paso a relatar mis andanzas intentando completar mis objetivos para el año pasado:

Eventos

Asistir a los siguientes eventos:

  • Bilbostack
Por cuarta vez, asistí a este evento. Experiencia excelente. La agenda no me pareció, en un principio, de un interés muy elevado pero me sorprendió para bien. Aprendí sobre Vue y, sobre todo, sobre procesos que siguen en diferentes empresas. Hablé con gente de distintas partes del país y que trabajaban con distintas tecnologías. Inmejorable ambiente. Muy recomendable.
  • Pamplona Software Craftsmanship
Intenté ir pero le vi dos problemas. Uno, lo difícil que era el conseguir entradas. Al salir a la venta duraron un suspiro. Dos, el elevado precio de las mismas. Más que como un evento está orientado como un fin de semana de actividades relacionadas con la tecnología. Charlas, talleres, etc... Muy interesante pero algo más complicado para mi asistir de lo que pensaba. Cómo contraposición pude asistir a la Dotnet conference de Madrid. Evento centrado en tecnologías Microsoft, la tecnología que más he usado. Buena organización, buenos ponentes y buenas conversaciones con compañeros de diferentes empresas.

Participar en alguna Kata o demostración práctica de:
  • Dottnetters
Pude asistir a 2 concretamente. Una de Xamarin y otra de Devops. Muy bien las 2. Eran de iniciación, aprendí mucho y me lo pasé muy bien.

Tecnología

Adquirir conocimientos teóricos e implementar proyectos con ejemplos sobre:

  • Novedades del lenguaje C# desde la versión 5
  • .NET Core
Actualizar repositorio de Github con ellos

Aquí es donde menos éxito he tenido. He pasado muy por encima de todas estas cuestiones. He tenido buenas intenciones pero, por falta de concretar unas tareas para realizas, ha quedado a medias.

Metodología

Aplicar a todos los proyectos particulares y en la medida de lo posible, profesionales:

  • Testing
En la empresa en la que trabajé la mayor parte del año hubo una revisión en la metodología de trabajo y se promovió, activamente, el uso de test automáticos. La experiencia personal fue muy positiva. Aprendí muchísimo con la práctica.

Completar en los plazos establecidos:

  • Curso sobre agilidad y Lean de Miríadax.net.
Completado en plazos. No recuero que aprendiera muchos conceptos pero sí me sirvió para reforzar conocimientos que ya había adquirido anteriormente.

Libros

Leer detenidamente e implementar ejemplos, subiéndolos al repositorio de Github, si se ve la posibilidad:

  • Code Complete
  • The Senior Software Enginer
Ambos leídos. Como casi todos los libros técnicos, es mejor tomárselos como consulta que leerlos de principio a fin. El primero de ellos es, como su nombre indica, muy completo. Los ejemplos quizá han quedado algo obsoletos pero el contenido sigue vigente. El segundo está centrado en metodologías, comunicación y tareas altamente relacionadas con el trabajo en equipo. Muy bueno, muy bien explicado.

Pese a no estar planificado, querría destacar mi participación en la PEUM Conf y en el podcast de Daniel Primo, Web Reactiva. En ambas actividades me lo pasé muy bien y creo que sirvió para mejorar mi capacidad comunicativa.

El balance del año es positivo. Casi todos los objetivos completados. Para este año 2019 no quiero hacer un listado que me ate, voy a fluir más. Ya estoy apuntado en la Bilbostack. He cambiado de trabajo, con todo lo que ello supone. Me he apuntado a clases de inglés. Me estoy interesando en nuevas tecnologías, nuevas para mí. Por ejemplo en Angular. En general, no faltan cosas por hacer. Espero poder compartir mis avances con vosotros el año que viene y que sirvan para establecer conversaciones en las que comentar la dirección a la que quiere ir cada uno. Por último, me gustaría invitar a los compañeros que también escribieron sus propósitos a que compartieran sus experiencias.

Qué caro me lo vendes!

El precio es una de las cosas más difícil de hacer para mi.

Lo es y lo será siempre. ¿Porque? porque soy muy mal comercial.

Y eso que tengo claro que "barato" y "caro" son conceptos relativos a cómo vendes las cosas.

La idea principal es sencilla de ver cuando manejamos el mismo precio para dos ordenadores con características bastante diferentes.
Por ejemplo 500 € es mucho si hablamos de un ordenador pentium, con 2Gb de RAM, disco duro 200Gb, sin monitor ni teclado, ni ratón. Y es poco para un ordenador con el ultimo procesador, 32Gb de RAM, disco duro SSD de 1Gb,  y mantendremos que no incluya monitor, teclado ni ratón. (esto escrito en Enero de 2019, que sabemos que sale alguna novedad y esto rápidamente queda desfasado 😁 ).

¿Qué diferencia una cosa de otra? Está claro que las características son abismalmente diferentes. Esto es simplemente un ejemplo de lo relativo de "caro" y "barato"

Lamentablemente a veces no podemos ser tan específicos en las diferenciaciones ya que cuando tratamos con mucho de nuestros clientes no tienen ni idea (aunque muchos digan que si) de las ventajas de las herramientas que usamos frente a otros que usan herramientas menos eficientes o incluso dudosos programas de maquetado rápido para cobrar mucho menos (por un producto de calidad inferior)

Así que esta diferenciación nos vale cuando nuestro cliente tiene nociones (en mi caso eso es muy de vez en cuando).

Entonces, ¿qué debemos hacer? ¿Cuál sería la solución mas lógica?

Estamos tan acostumbrados a hablar de marcas y empresas sin mirar la marca más importante de todas: Nosotros mismos.

Y esto es valido como empleado, como autónomo o como quiera que desarrolles tu trabajo. A lo mejor es hora de dejar de mirar hacia fuera y mirarnos a nosotros como una marca.

Pongamonos en el lugar del cliente y miremosnos. ¿Nos contrataríamos solo por lo que vemos u ofrecemos? ¿Estamos dando la confianza suficiente? ¿Tenemos la imagen adecuada? Y ojo, a esta última pregunta que no se trata de que uno se "uniforme" como otros para conseguir lo mismo (Ojalá fuera tan fácil, la verdad), sino que se trata de que dentro de lo lógico mantengamos la coherencia de nuestra personalidad a la par que podamos transmitir seguridad, confianza, coherencia, etc.

En cuanto a lo que ofrecemos últimamente se esta poniendo un poco complicado ya que ahora todo el mundo te hace firmar contratos de confidencialidad que nos llevan a que muchas veces no podamos tener material de trabajos hechos (o si pero con mucho mas cuidado).

Pero solo unas cuantas capturas de pantalla y unos cuantos links lo hace todo el mundo. Así que deberíamos buscar diferenciación.
Algunas ideas:

  • Publicar contenido relativo a nuestros trabajos (tutoriales, scripts, posts temáticos), en Español e inglés por lo menos sería lo ideal y en blogs variados (Alguno propio no estaría mal).
  • Crear código publico (por ejemplo en repositorios de github, gitlab o similares) que se pueda utilizar como muestrario de nuestras aptitudes.
  • Hacer cursos que nos den conocimiento y/o acreditaciones. (O libros en su defecto)
  • Participar en comunidades de gente afín a las tecnologías que usamos. (Aprenderemos mucho de aciertos y errores que nos ayudaran además del conocimiento técnico)
  •  Optimizar las redes sociales para obtener contactos útiles (No digo eliminar los amigos pero si reducir el "ruido" y buscar mas perfiles que puedan servir como contacto futuro o de empresas que nos interesan).
  • Buscar un poco de la historia de esas personas que han logrado éxito y nos impresionan (todos tenemos mitos, gurús, dioses, o como quieran decirle), y aprender de su camino (lo relevante y útil, si miramos mas de una persona mejor).
  • Vivir en el justo equilibrio entre "soy Dios" y "No valgo para nada".
  • Colaborar en repositorios públicos relacionados con tus herramientas. (Las colaboraciones de github (por ejemplo) mantienen el perfil de los autores de todas las Pull Request aceptadas).
    Es un poco difícil, o imposible tener todo rápidamente o incluso a largo plazo porque tenemos que trabajar, vivir, dormir, comer y otras cosas que no hace falta detallar. Así que es una lista de ideas, o sea, ni esta todo lo que es útil ni todo lo que esta ahí es útil a todo el mundo. Son cosas que le dan solidez en mayor o menor medida a nuestra marca personal.

    Hay otras cosas que decir pero son mas de sentido común:
    • Mantener la misma imagen de perfil en todos los servicios, redes sociales y lugares donde nos hemos registrado (sobre todo públicos)
    • Mantener el mismo Nick en todos los registros.(es solo una cuestión de coherencia que a veces es difícil de mantener porque alguien se nos adelanto)
    • Si eres desarrollador Web tener una pagina personal (aunque luego todo el mundo te busque en redes sociales de trabajo es un poco contradictorio trabajar en esto y no tener una pagina propia (puse contradictorio porque la mayoría lo hacemos cuando podemos y no es raro que este detalle se pase por alto) )
    • un largo etc. (Que se me termina el post).
    Si solo podemos cobrar barato seguramente tenemos alguno de estos problemas:
    • Nuestra imagen no ofrece confianza.
    • Nuestro nicho de mercado es inadecuado.
    • Le dedicamos demasiado tiempo a los proyectos (por perfeccionarlo, porque no conocemos la tecnología que usamos cómo debiéramos).
    • Hacemos cosas que no son de nuestra competencia y no estamos cobrando ese tiempo.
    • Nos falta oragnizacion.
    Las mentiras que nos decimos comúnmente:
    • Cobro barato porque es el precio de mercado.  -> ¿De qué mercado y cómo nos desmarcamos de ese mercado? 
    • Otros tienen mejores contactos -> Haz tus contactos a través de redes sociales, chats de comunicación, foros, etc. de a poco pero con constancia. Se puede.
    • Nadie me conoce -> Cámbialo mejorando tu marca personal, mantén coherencia en tus artículos y perfiles. Hazte tu pagina personal cuidando el Seo.

     Y por ultimo creo que estos son los peores pecados capitales que dañaran nuestra imagen:
    • No cumplir los plazos del cliente.
    • No comunicarnos con nuestro cliente / jefe.
    • No tener una comunicación fluida con nuestros colaboradores.
    • Meterse en proyectos que no son nuestra especialidad.
    • Usar tecnología que apenas conocemos para sustituir tecnología con la que sacamos las cosas más rápido por la ansiedad de usarlo "ya".
    Una última idea final: La competencia siempre lo hace mal. No digo todo pero algo siempre podría hacerlo mejor o directamente lo hace mal. En ese punto debemos destacar y usarlo como comparación, ese punto y todas las debilidades que encontremos. Aunque solo seamos empleados debemos pensar como empresa. Después de todo la competencia crece y hay que mantenerse como "un producto que se compraría sin mirar el precio".

    Y hasta aquí este conjunto de ideas que podéis comentar. Os dejo y espero nos sigan leyendo en los siguientes posts. 


    Esa gente que se pasea por mi oficina

    Trabajar en casa es una oportunidad, un reto y hay a quien le gusta y a quien no. Hay muchas versiones sobre si es un paraíso o un infiern...