Reto 100 Days of Code. La experiencia vivida a 25 días.

El reto de #100DaysOfCode está hecho sobre todo (pero no en exclusiva) para novatos que se inician en el mundo del código.

La idea principal es que se acostumbren a codificar por lo menos una hora diaria llevando adelante un proyecto en el lenguaje que deseen aprender.

Hasta aquí la teoría. Ahora hablemos de lo bueno y malo.

Comencé el reto en un lenguaje en el cual no soy novato (digamos que no estoy al inicio mejor) JavaScript. He creado un side-project que quiero llevar a cabo y me he adherido al reto. ¿Porque?

1- Soy un desastre en disciplina. 

2- No consigo ponerme horarios estables. 

3- En cuanto el proyecto avanza un poco pierdo las ganas y se me ocurre uno más "genial" y voy a por él.

Sin acción no hay realización.

Mi idea era comprometerme a llevar a cabo un side-project y comprobar que ese compromiso me obligaría a ser constante. Por eso inicie el reto.

He hablado con otras personas para saber la experiencia y algunas cosas que sacamos en conclusión:

 * Se vuelve más serio y real el estudio / proyecto que estes realizando.

 * Te crea el compromiso diario (hay quien incluye el fin de semana. Yo diría que codificar sábado y domingo es mala costumbre. Pero como casi todo en este reto es decisión personal)

* Conecta a la gente que recién empieza con otras personas y le da cierta visibilidad en las redes sociales (es lo que veo en Twitter)

* Se puede tuitear el desanimo, el entusiasmo, las dudas. El hashtag es retuiteado por bots y personas. Muchas veces responden a los tuits quitando la sensación de "soledad" que caracteriza los proyectos personales.

Detalles:

* En GitHub hay que mantener dos repositorios. Uno es una bitácora y el otro el código. La organización de la bitácora queda un poco criterio de cada uno pero al clonarlo tenemos plantillas de ejemplos en varios idiomas.

El otro lado de la moneda:

* La sensación de soledad no se quita del todo. Si hay un cierto movimiento cuando se publica el tuit con el hashtag pero en Twitter como en el slack de 100DaysOfcode la actividad es tibia si la hay.

* Puede provocar cierta obsesión si te lo tomas demasiado en serio y crear un estrés excesivo.

* Por otro lado si no lo haces con la seriedad suficiente como no hay controles ni presiones externas acabaras abandonando.

* Es difícil que con solo una hora diaria realmente logres avanzar en los proyectos siempre ya que hay problemas que te llevaran más tiempo. Enfrentado a este problema la resolución de seguir o no es personal y dependerá de como nos organizamos.

Mi consejo: 

* Si eres novato en cualquier lenguaje y lo quieres aprender hazlo. 

* Si por el contrario tienes un side project pero nunca encuentras el tiempo hazlo.

* Si necesitas que alguien te esté recordando que debes cumplir no lo hagas. 

* Si necesitas continuo apoyo mejor no hacerlo porque sentirás cierto desasosiego.

Mis Cambios:
Adapte el proyecto a mis necesidades aplicando ciertos cambios. Por ejemplo decidí que por ser más "veterano" no debía dar la sensación de que no hay vida cuando se programa. Por eso decidí no hacer el reto los sábados ni domingos. A menos no hacer los tuits, si codifico o no ya es según el tiempo pero elimine la obligación esos días (ojo, esto alarga el tiempo del reto)

Cada persona es un mundo y hacer el reto no es algo que conlleve gastos ni nada parecido. 

Yo diría que es bueno probar que tal. Tomarlo como una motivación y si llega a ser estresante entonces no continúes. Sobre todo porque para estrés ya vale la vida diaria.

P.D.: Por razones laborales tuve que para el proyecto el día 25. Reiniciaré de 0 de nuevo para lograr mis objetivos pero el reto no debe estar nunca por delante de la familia o el trabajo. Si tienes tiempo para realizarlo puede ser una buena experiencia pero si vas limitado de tiempo no es aconsejable agregar más estrés a tu vida.

Kubuntu, ¿hacia la humanidad?

*/Disclamer Alert: La siguiente entrada deriva de mi experiencia personal con esta distribución, no pretendo crear un paragon de cual distro es mejor/*


“TOC; trastorno obsesivo compulsivo con los pequeño detalles que nos tocan los huevos.”

Leyendo entre las cositas que siempre veo en el canal de Slack y sobre las aventuras de @infogon preparandose para la hackaton, me entero de que anda probando una distro de linux “Kubuntu”, hmmm interesante pense, haciendo un poco de reseach lo primero que encuentro es esta pequeña cita de nuestra querida wiki sobre la palabra “kubuntu”

“Es un derivado oficial de Ubuntu y su nombre significa "hacia la humanidad" en el idioma bemba, y se deriva de ubuntu ("humanidad").”

Vale, hasta en el titulo de la página oficial leemos “Kubuntu | Friendly Computing”, Dejan muy en claro que son user friendly y con una interfaz super mona, que te promete ser mas productivo, conectarte la tostadora de la cocina por bluetooth y hacerte todas las tareas del colegio, me quedo la curiosidad de comprobar que tan verdad era esto.

Por lo general, siempre he usado por temas de trabajo la version Gnome 16, que es con la cual trabaja un SDK sobre el que hacemos algunos desarrollos junto con una compañia rusa y es la que nos exigen, supongo que por tema de librerías (no lo dejan muy en claro, son rusos, es así y ya está, usted no pregunte.) Pero el otro dia por andar haciendo algunas cositas raras experimentando terminó corrompiendo la mayor parte de la partición entera de mi linux, dañando el sistema operativo completamente, “RAYOS” pensé, "seria una buena excusa para salir a probar ese famoso pedacito de HUMANIDAD que tanto prometen".

Instalando… tomo mis precauciones y separo la particion /home, (practica recomendada para todos los que cambian de distro frecuentemente), cosa que no tenia previemente hecha y me toco guardar archivos manualmente.

Vale, hasta ahora lo primero que me encuentro es el tipico botón de inicio con logo imitando a windows, “Vale tío, puedes hacer un OS desde cero e imitas a la competencia”, eso siempre me a chocado, pero no nos armemos prejucios, mirare un poco mañana en la mañana, cierro la tapa de mi notebook para descansar.

Cuando la destapo al día siguiente para mi sorpresa lo primero que me encuentro es con esto:

“Bonita bienvenida humana” pense, abro mi terminal, me logueo por consola, ok, no prejuzguemos aun no realizo los updates necesarios y así que se corregirá con ello, efectivamente listo todo, me dispongo a amoldar el computador a mi criterio o viceversa, lo que pase primero.

En el file explorer mi primera impresión fue una explosión de colores de carnaval destructivas a la vista, juro que conté por lo menos los 7 colores del arcoiris entre ventana y ventana.

Vale, voy a cambiar el fondo de pantalla, click derecho y me encuentro con más menus de opciones que cabina de avión, de verdad me empiezo a encontrar con una curva de aprendizaje “no very user friendly”. A la derecha en la barra de tareas recuerdo haber visto más iconos que en un aeropuerto así que supe que me tomaría un tiempito conocerlo a fondo.

Primer Round, intentar mandar un simple correo: configuro mi correo correctamente con el “Kmail” nunca lo había probado hasta ahora, se empieza a llenar la bandeja de entrada, intento de mandar un mail super urgente y se queda allí en la bandeja de outbox sin pasar a la de salida, simplemente viéndome, como si se riera de mí. ¿Habré puesto mal alguna configuración? ¿Me equivocaría yo? Busco como por una hora sobre el tema pero ninguna información. Dejalo asi, no perdamos tiempo con ello y resuelve mandando el mail del movil, mientras descargo mi IDE.

Voy a prepararme un café, cuando vuelvo y regreso al computador de la suspensión veo que lanza como unos rayos cósmicos, esta vez para darme la bienvenida, ingreso mi pass y para mi sorpresa los caracteres de los títulos de los archivos en mi escritorio desaparecen, en lugar de ello veo manchas de los mismos rayos cósmicos que aparecieron recién, lo mismo por los títulos en el menú de inicio que solo aparecían como manchas negras en los textos, problemas con la interfaz de usuario pense, respiro profundo, hubiera continuado tranquilo si mi TOC me lo permitiera, prefiero reiniciar y ver si el problema se corrige.

Ok, se corrige el problema y al abrir mi mail, sorpresa, salen los 24 correos de prueba que estaba mandando. Pareciera que no es muy compatible con la suspensión del equipo.

Listo, vamos manos a la obra, por lo general uso dos monitores, pero en mi TOC, siempre con mi sistema operativo anterior ubico el display de la izquierda solo un poco más arriba, en esta disposicion.

perfecto pense, cuando me propongo a maximizar una ventana en el display derecho subiendola al tope me encuentro con que la ventana literalmente se va a la mierda y desaparece en frente de mis ojos, al parecer creando un espacio invisible en esta area.

Pero como es posible que una funcion basica que ya funcionaba bien previamente la hayan intentado de resolver con un parapeto visual, y apenas tengo un par de horas conociendo la UI.

Vale tio, no pasa nada, pongamos los dos displays uno al lado del otro, a pesar de que los monitores no estan alineados.

Pasan un par de días y me voy encontrando detalles tras detalles, los mails a veces salian, a veces no, lo resolvi cambiando el cliente a mi fiel "evolution" que usaba ya en gnome. En los momento cuando se restaura la suspención, simplemente pienso que me esta guiñando un ojo con sus rayos de colores donde ya no solo desaparecia las letras en el menu de inicio si no hasta en el boton "login".

Un día, repentinamente compilando con el codeblocks, se quedo allí.. la ventana congelada, ya me habia pasado antes... allí se quedo, viendome... kill -9... se quedo allí la ventana... bueno media ventana porque en realidad se veian como trozos del IDE con mi codigo... Reinicio completamente... codigo roto... tuve que volver a construir los archivos nuevamente por segunda vez, porque era la segunda vez que me pasaba.


mensaje directo a mi colega en el otro escritorio de la oficina.

Ramirez, ¿aun tienes la imagen esa del gnome que mandaron los rusos?
Sí ¿por que?
¿Me podrias crear una imagen?
¿Que paso con el kubuntu ese que te recomendaron?
Nada, nada... de pronto me dieron ganas de nuevo de volver a lo viejo.


Todos alguna vez, los que habremos convividos con algun diseñador gráfico o con algun frontend hemos escuchado la famosa ley que habla del "- = +" hasta ahora gnome me habia cumplido muy bien con esa ley y habia olvidado lo bien y comodo que se siente al dar click derecho y...

Menos mal que separe mi carpeta de /home desde un principio, me dio la facilidad de volver con todos mis archivos de usario, tanto asi que se vino entre el logo de usuario el logo del maldito Kubuntu.

Lo dejaré alli simpaticamente para guardar un recuerdo de esa experiencia desagradable, mientras me tomo un vodka rusa para tranquilizar los nervios alterados por mi TOC y el vivir de ese pedacito "hacia la humanidad".

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

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.

Huyendo del marketing

Siempre estoy buscando mejorar pero muchas veces estoy perdido.
Tanta publicidad y marketing cuando sale algo nuevo en programación no hacen mas que distraer la atención del objetivo de mejorar.

BigData, Tensoflow, IA, Augmented Reality, MicroServicios, serverless, graphql, Deep Learning, Blockchain, y un larguísimo etc. de términos y opciones que existen y que cuando surgen con la panacea de todos los problemas del mundo.

Al final estoy con mi ordenador, mi IDE, y mis lineas de código y lo veo pobre. Me da la sensación que todo el mundo ahí fuera esta en una ola de cambios y novedades que no llego a comprender.

Pero al final hay que mirar todo eso de cerca y preguntarse: ¿Realmente me sirve esto a mi o a mis clientes? Claro que muchas de las opciones son útiles pero en determinados casos de uso y otras están lejos de ser realmente realizables en proyectos comunes del día a día (al menos por ahora).

Sin embargo siento el agobio, la fuerte necesidad de saber qué son, cómo se usan, aprender las posibilidades (Aquí es donde mas marketing hay y  menos realidad), y sobre todo investigar el uso REAL de esa tecnología en particular.

Y resulta que muchas de ellas son irrealizables en proyectos pequeños, o incluso son una desventaja para un proyecto web determinado.

Así termino aprendiendo un montón de cosas que me llenan la cabeza de cosas fantásticas y cuando vuelvo a mi código, ese proyecto de mi cliente, me parece poco. Noto como me cuesta seguir con el código porque no es "ESO" tan fantástico que se usa ahora...

Ilusión. Eso es lo que es el marketing aplicado a estos términos. Si antes de Internet la ignorancia era un problema ahora lo es la saturación de información.

Si a veces te sientes abrumado por TODO lo maravilloso que hay ahí fuera y que no esta a tu alcance por falta de tiempo, tranquilo, hay mucho humo orientado a que las empresas inviertan para poder sacar adelante realmente la tecnología prometida.

No te dejes llevar por el marketing y no dejes de amar el código que escribes... (Eso es lo que me repito cada día como un mantra, espero que algún día funcione).

¿Opiniones?

¿Te ayudo? Enséñame como

Aquí vamos a tocar un poco las sensibilidades porque la experiencia que a veces tenemos la olvidamos con facilidad cuando progresamos en una profesión y también es verdad que a medida que avanzamos vemos cosas que antes no.

El tema: cuando alguien tiene la voluntad de ayudar pero no el conocimiento y el tiempo apremia.

Yo he sido un inútil, en muchas profesiones, la mía incluida. Siempre he tenido voluntad de ayudar pero a veces mi voluntad es lo que entorpece el trabajo.

Me explicare de forma sencilla.Yo hago FullStack por necesidad por en realidad soy de back. Y en front ahora mismo hay diferentes frameworks js y css. El problema de estos frameworks es la curva de aprendizaje frente al tiempo que luego nos ahorran en programación.

Es importante en este punto la especialización (o por lo menos así lo creo yo) por lo que uno profundiza en determinados frameworks y deja otros de lado. Y se avanza, lento o rápido, pero se avanza.

Ahora resulta que estas en medio de un proyecto usando un par de frameworks (js y css) desde hace un año, con un back (php) que poco a poco conoces aun más.

Pero en ese proyecto se suma una persona con conocimientos básicos de programación. Bien, genial. Mas gente sumada al proyecto. Ahora iremos mas ¿rápido? y aquí esta el problema.

Programar es una carrera contra reloj muchas veces donde el tiempo que le dedicas lo debes balancear entre aprender cosas nuevas (que te harán programar mejor), escribir código, resolver problemas (no todo es código) y eso que llaman "vida diaria".

Pues bien. Tenemos aquí a una persona con muy buena voluntad (si no fuera así la dejo en un rincón haciendo tareas rutinarias... De esas siempre hay) pero con el conocimiento justo o menos.

Sin buscar culpables porque no los hay, tenemos que buscar un tiempo para enseñar a esa persona el proyecto para que pueda ayudarnos a avanzar pero... ¿Vale la pena? Y aquí viene la herida de sensibilidades: A veces si, a veces no.

Porque todo el tiempo es inversión y como dice mi madre: "Mucho ayuda el que no estorba". Por lo que a veces debemos dejar a esa persona en "Stand By". Pero que lo hagamos no nos da derecho a mirarle por encima del hombro porque como dije al principio: a veces olvidamos que hemos estado en ese lugar que ahora le toca a otro. ¿Recuerdas? Ver todo el mundo sabiendo que hacer y uno como perdido,sin saber para donde tirar.

Paciencia a ambas partes y que los que saben no se sientan por encima y los que no saben que se pongan las pilas a aprender.

Y si no es en este proyecto, porque no se puede, nos vemos en el siguiente.... Vete preparando ¿no?

El técnico para todo

Programación:  Ese arte / ciencia que es tan difícil de explicar a veces de que se trata realmente a la gente que no esta relacionada con esta profesión.

Es que muchas veces nuestro trabajo no es "fácil de ver" sobre todo cuando se trata de resolver oscuros problemas en lugares recónditos del código.

Al final se crea un halo de intriga alrededor nuestro que hace que la gente que nos rodea a veces mistifique nuestra profesión.

Y pasamos a veces de "Se pasa todo el día sentado 'al ordenador'", dicho lo de 'al ordenador' con ciertas reticencias, a ser unos genios que entendemos cosas "super complejas".

Un día llega un familiar y te deja un móvil de aquellos antiguos que ya no hay para que le instales las aplicaciones mas modernas, o te dicen que mañana te pases por tal sitio a mirar un motor de nevera que no funciona o te dejan algún electrodoméstico medio destruido para que lo arregles "porque tú sabes de estas cosas"

Es extraño que cuando viene el técnico del cable nadie le pida que también mire los cables del router a ver si están bien conectados pero nosotros pasamos a ser técnicos para todo.

Y a veces fomentamos la vagancia y dependencia. Porque sí. Porque nos gusta ser útiles y que nos necesiten.
"¿Me configuras esto del móvil?" "¿Me limpias el pc?" "Es que no sé leer los correos"...

El problema de eso es cuando se dispara la voz. Uno le ayuda a un amigo y/o familiar, este le dice a otro, el vecino nos pregunta si sabemos y así en poquito tiempo tenemos "fans" de nuestra genialidad (porque siempre está el "porque tú sabes") que de petición en petición nos consumen el tiempo y la energía.

Y como decir que no sin ser borde. Es complicado. Yo por lo pronto explico todo lo que hago para otros, lo deshago y le pido a la persona que lo rehaga (todo esto cuando es posible) estoy el doble de tiempo con esa persona pero pueden pasar dos cosas:
* Aprende a hacerlo (Lo cual es bueno para los dos)
* No me vuelve a consultar porque "le hago hacer el trabajo"

Lo cierto es que ni aun así (y créanme cuando dijo que se ser muy borde cuando hace falta) logro hacer entender a la gente que me rodea en el día a día que no sé (y la verdad no me interesa saberlo) entrar a cuentas de facebook sin contraseñas, crear una app de moda en un fin de semana o crear la nueva red social del futuro pero que sigo siendo bueno en mi trabajo.

Me pregunto si en muchas profesiones pasan por lo mismo.