Me "ghostearon" como asesor externo

El término "ghostear" es la verbalización de la palabra ghost en inglés que significa fantasma. Y normalmente aplica cuando en una comunicación no presencial, ejemplo correos, mensajería, redes sociales, etc., de manera súbita tu interlocutor  literalmente desaparece del mapa, haciendo que todo  intento de contacto se pierda en el infinito.

Literalmente te hacen un > /dev/null

Bueno, les cuento la historia.
Nota al margen: Ojala no se aburran porque yo no creo en la historia corta, me voy a dar mil vueltas, voy a explicar mil cosas antes, y seguro va a parecer que me olvidé de lo que tenía que contar.

Algún tiempo atrás (en una galaxia muy lejana) me contacta un ex-compañero de trabajo, a quien le hice  más de un par de asesorías. La típica "¿en qué estás?" y "¿qué disposición tienes para  un trabajo extra?". La verdad es que el espíritu del mercenario nunca me ha abandonado, y el desafío se veía entretenido. Días después me contacta la jefa de proyecto que trabaja con él y me dice que "me vendieron" como alguien que puede solucionar cualquier problema. Debo confesar que la falsa humildad evita que yo me venda de esa manera, sin embargo mi arrogancia interna sabe que la maldita combinación de  inquietud intelectual y TOC normalmente  conducen a soluciones.

Trás un par de conversaciones acordamos una tarifa  x HH y me presentaron formalmente el desafío: Un sistema de facturación electrónica, cuyo backend está en Java con Spring Boot y el frontend en Angular.
Mi misión (que obviamente decidí aceptar) corregir/mejorar/hacer funcionar el formulario principal en la aplicacion Angular. Mi intervención sería solamente en el front. 

Diagnóstico inicial

Trás una revisión del código me quedaron claras varias cosas:

1. Quienes estuvieron a cargo de  hacer las definiciones iniciales no conocen bien las capacidades del framework (Angular).
2. La escuela inicial es Java, y si bien es cierto hay similitudes conceptuales entre la programación Java y Typescript, hay diferencias. No es llegar y traducir las estructuras. Hay cosas que se resuelven de otras maneras (GOTO 1)
3. Delegaron el desarrollo de partes sensibles de la aplicación a pollos digo.... desarrolladores menos  experimentados, ergo el desastre que empecé a ver en el código:
• Repetición de funciones.
• Funciones con múltiples responsabilidades (al bosillo la S de SOLID).
  
• Cero comprensión de los requerimientos, derivando en código  enredado, desordenado y complicado para requerimientos sencillos (golpeando a la fuerza con un martillo siempre se puede meter una pelota en el espacio de un cubo).
• Cero estándares de programación, desde la manera de nombrar las variables y funciones. indentación, tipo de comillas, etc.
• Cero documentación, sobretodo en aquellas partes "complejas".
• Desconocimiento importante de los conceptos básicos de OOP. 
• Desconocimiento de patrones de diseño.
  
• UN SÓLO gran componente con TODA la lógica de negocio en él. Más de 800 líneas de código, toda una obra de arte.
• Ausencia de una política clara de control de versiones. Usan git, así como  usamos calcetines.
  

Iban a ser jornadas de muuuucha diversión.

Cuando pesan las decisiones del pasado

Y no a mi en este caso. 

Empecemos:
Angular no es un framework sencillo. Tampoco es que sea taaaan complicado, pero no es sencillo, hay una base de OOP importante, y se le saca provecho en proyecto complejos (como el de este equipo), y más aún cuando hay conocimiento del framework.

Por ejemplo, uno de los pecados mortales que encontré, escribieron, o más bien arrastraron un servicio completo que extiende el HttpClient y agrega el token JWT de cada petición. ¡Sí! va a funcionar, pero... el HttpClient de Angular tiene soporte para los Interceptors, que van a actuar como middleware y pueden modificar las peticiones, no es necesario usar un httpGet propio que  agregue el token JWT a los headers. Lo peor de todo no fue tanto que lo arrastraran, sino que para peor, NO lo usaron en ningún lado y que cada una de las peticiones del sistema agregaba a mano el token.

Otro pecado mortal, servicios viejito, servicios... Salvo algunas contadas excepciones, claramente desarrolladas por otro pajarito (al menos eso decía el git log) TODAS las peticiones estaban dentro del giga-componente.

A ver, muy a grosso modo (siempre en el contexto de Angular):

• Componente: Unidad modular, habitualmente "tonta", sólo se encarga de desplegar información y reaccionar a ciertos eventos. No tiene lógica de negocio.
• Servicio: Es quien se encarga del "trabajo sucio". Los servicios saben que es lo que se tiene que hacer. Aquí hago una pequeña distinción, porque saber que se tiene que hacer es diferente a saber como hacerlo. Entonces tenemos 2 tipos de servicios que caerían en esta definición:
  
  • Facade: Fachada, que sabe que se tiene que hacer
  • Servicio (implementación específica): Sabe como hay que hacer loque se tiene que hacer.
    Y si, los 2 son servicios...
    

Y aquí seguro explotaron algunos cerebros, las cosas dejan de ser sencillas. Ya nada es como el tutorial de la PokeAPI o como el proyecto del Bootcamp.

Pero no sufran tanto, voy con un ejemplo.
Supongamos que su componente tiene que traerse datos desde "algún lugar", la respuesta que  reciben y saben procesar siempre tiene la misma forma (tipo de datos conocido), solo cambia el "desde donde" se van a traer los datos. Entonces el instinto te dice:

"Ahhhh! un servicio que tenga 2 metodos:

1. getDataHttp()
2. getDataLocal()"

Y si, va a funcionar, pero se acuerdan de la  O de SOLID, Open-closed principle abierto a la extensión, cerrado a la modificación, vale decir que si el comité creativo se le ocurren 20 origenes de datos diferentes, o te llenas de funciones  o te llenas de ifs.

Lo más razonable en términos de arquitectura es ver una implementación tipo Strategy o Factory, donde todo el resultado de tener un conexteto acotado

Nos fuimos a la B... no compa, me hubiera dedicado a la pastelería...

Y acá si me pongo a desarrollar el tema puedo escribir demasiado, SOLID da para  mucho.

Bueno, de SOLID el desarrollo base las pelotas. La idea me dio la sensación que fue buena, pero en la medida que pasó el tiempo y que no supieron mantener la consistencia en el código (y de paso de mantenerse al día cono cómo se desarrollaban los proyectos en cada nueva versión de Angular) los destrozos eran algo de esperar.

Entonces nuevamente se juntan los ingredientes claves para que Santa cobre caro y tenga  pega el desarrollo de un proyecto se empiece a volver caótico:

1. Bases mal definidas
2. Escaso conocimiento en el Framework
3. Equipo poco/mal capacitado

Si todo lo que pudiste decidir mal; por que no sabías o no te  supiste asesorar, o derechamente no te asesoraste ni investigaste; lo decidiste mal,  y seguiste una formula "conocida" que funcionó alguna vez, de seguro todas esas malas decisiones te van a cobrar factura después.

¿Qué fue lo que hice?

Literalmente lo de la imagen. El formulario principal era inicialmente un caos del que era cosa de gastarse unos minutos, dibujarlo a mano en papel y darse cuenta que se podía separar en componentes mucha más sencillos. 

Claro que alrededor tocó generar nuevos tipos de datos, definir servicios, extirpar funcionalidades, optimizar algunos procesos, ordenar el código, ordenar el código... Cuando visualicé la separación lógica para esto empecé a recortar el original, cada  "bloque" en su propio componente. Documentación adecuada, explicaciones a ciertas implementaciones oscuras, poco a poco  fue tomando sentido.

Pero no estuvo exento de dolores de cabeza, cosas que me hicieron pensar "¿Pero porqué este animalito  lo hizo así si <explicación razonable que hasta ChatGPT  indica sin fallas>?"

El plazo de entrega  era acotado, me demandó una jornada continua de 12 horas de programación, y finalmente  pospusieron esa reunión. Hubo algo de espacio extra para afinar detalles y de paso me pidieron "un extra".

El extra

Necesitaban que el generador de documentos funcionara. 

Contexto:
Los documentos tributarios electrónicos (DTE) pueden ser de diferentes tipos, factura, factura exenta, factura de exportación, boleta, nota de crédito, nota de débito y más de alguno que se me debe estar olvidando. Cada uno de estos tipos de  DTE se identifica con un código específico, y si bien comparten en forma muchas de las propiedades del documento, también difieren en algunas propiedades, según sea el tipo de documento. Eso ¿les da algún indicio de  por donde puede ir la cosa?

Vamos por parte:

1. Documentos "parecidos en forma"
2. Documentos "parecidos, pero con ciertas diferencias"
3. Documentos identificables según su tipo

Mi opinión se vuelve  algo sesgada (biased) al respecto, pero

¿tiene pinta de OOP o no tiene pinta de OOP? 

Y acá me pusieron pila, la idea era hacer un generador relativamente simple, relativamente fácil de entender y extender, pero por sobretodo una implementación elegante/medianamente elegante (aunque considerando la base casi cualquier cosa era mejora).

Entonces generé un estructura parecida a esta:

Entonces a través de un Factory rescataba la implementación  especifica para el documento que  quería generar. La interfaz del Documento me  indicaba los métodos que cada implementación  debía implementar. Eso más un Builder para poder generar instancias de cada documento usando los datos de cada sección del formulario, y  un Adapter para poder ajustarlos en forma para que el objeto sea "compatible" con lo que sabe manejar el backend.

Eso más mucha magia de Typescript, que también es algo que me llama demasiado la atención, y dentro de todo experticias que siempre fueron necesarias en este desarrollo.

Todo documentado, código "bonito" (y no porque lo diga yo), hasta un video les hice para explicar el proceso de la implementación. Claro que no profundicé en los patrones de diseño usados, eso literalmente da para un curso de  un semestre de universidad, y revisando el video un par de veces (no porque me guste el eco de como resuena mi propia voz) el video no es taaaaaaaan simple de entender, no sin una base medianamente sólida de OOP.

Quemé  más de un par de neuronas en el proceso.

Finalmente -> me "ghostearon"

Después de  caerse de espaldas con la factura que les mandé, porque no les salió barato (siendo que me aceptaron el precio x HH y que trabajé efectivamente cada hora que cobré) me consultaron si podía generarles un "proyecto base".

¿Qué sería este "proyecto base"?

De acuerdo a las mismas palabras de la JP "es un proyecto que tenga lo básico para poder empezar un proyecto, incluyendo buenas prácticas, etc."

Independiente de si trabajana o no en desarrollo de software es claro que TODOS los proyectos son diferentes, por mucho que estén basados en el starter-project, que de alguna manera busca ser esto.

Respecto a los starter-project, la idea no es mala, pero si tienes un triste precedente  de que aún con  ciertos lineamientos (buenos o malos, eso da lo mismo) de estructura de proyectos, tu equipo hizo un desastre, entonces por muy buenas prácticas que quieras poner en este starter-project  van a dejar el caos igual. Seamos realistas, por iniciativa propia un equipo rara vez se dedica a entender y aprender de  las buenas prácticas de un starter-project; habitualmente es un programemos encima a lo brutito, y si no hay un área de arquitectura que audite el desarrollo o una cultura de peer reviewing, no hay manera de sostener una arquitectura limpia.

Propuse en cambio capacitar al equipo, enseñarles  cómo se deben hacer las cosas, o quizás no exactamente el "cómo" que  puede resultar una posición impositiva, sino más bien qué enfoque se debe adoptar para poder llegar a una buena solución de software (mantenible, escalable, entendible, elegante...). sostuve mi propuesta con los argumentos que ya mencioné.

Y literalmente fue lo último que supe de esta empresa.
Llegó a ser  irónico pués  me  quitaron los accesos a los proyectos en git, salvo uno, y  ni siquiera me contestaron cuando se los indiqué.

¿De quién fue la culpa? (no eres tu soy yo...)

Mi 1er sospechoso es un poco la cultura de empresa, y esa mala valoración que le dan al trabajo y tiempo experto. Aquí yo sé que cobré caro, es la tarifa consultor habitual que suelo cobrar, precisamente porque me encargo que el producto que entrego valga lo que cuesta. 

Aquí tengo el ejemplo donde en cierta oportunidad quisieron negociar mi tarifa  x HH de consultoría  de manera equivalente a la HH a contrato de plazo fijo. En esa oportunidad mi cara de ¿cómo te lo explico sin que te sientas ofendido? fue épica.

Y mi 2do sospechoso fue  una frase final dentro del video donde explicaba la implementación del generador de documentos. Si volvemos atrás en este artículo nos daremos cuenta que  el generador es básicamernte contexto teórico, no hay nada que sea exclusivamente de frontend, por lo que puede ser  fácilmente aplicado al backend y lo más seguro es que  tenga los mismos beneficios relativos a la arquitectura de la solución.

Textualmente dije "...en vez de llenarnos de ifs, utilizamos  orientación a objetos como corresponde, hacemos distintas implementaciones y se nos simplifica infinitamente la existencia."

Me salió del alma ese cierre para el video. Ese tipo de verdades sin anestesia que no nos gusta escuchar sin decoración bonita.

Decirles a desarrolladores senior que programan en Java que no saben OOP y que no saben de  patrones de diseño es tan ají en el culo como decirle a un taxista que no sabe manejar... bien...

Arquitectura de software puertas afuera

 

Hace ya algunas semanas que me cambié de trabajo.
Los motivos de alguna manera se fueron desglosando desde hace algún tiempo, y obviamente desde la parte de arriba de la pirámide hay cosas entre que se desconocían, que nunca se vieron (o no se quisieron dar cuenta), o que simplemente no se entienden, en fácil sería bueno que analizaran porque se va la gente y en que parte de la historia los stock options perdieron su atractivo inicial y su poder de retención.

Voy a reciclar un artículo que  ha envejecido bastante bien (no ha dejado de perder sentido): La necesaria mirada hacia adentro de la propia organización

La cosa es que entre las cosas que tuve que hacer antes de mi salida, aparte de tener que entrevistar a mi futuro reemplazo y revisar desafíos técnicos, fue proponer un plan de trabajo futuro, porque "me siguen necesitando" sea para  atender consultas varias o para optimizar algunas cosas, pensemos que el "desarrollador senior" de la empresa "que se encargaba de sacar los cachos (desafíos con dificultad mayor a la habitual, y que nadie quiere hacer)" ya no está, y alguien tiene que encargarse de "hacer lo mismo".
Después de una breve negociación llegamos  a un acuerdo que de alguna manera busca ser conveniente para todas las partes. No es un número de horas fijas al mes, el valor HH es menor a mi "precio habitual" pero mayor al propuesto inicialmente; lo que si hay un límite máximo de horas al mes, y precisamente por eso es conveniente para las 2 partes.

Por un lado no me  voy a inventar horas ni sobrecargarme con horas de trabajo, por el otro se pagan solamente las horas consumidas. Es como un plan de telefonía móvil, pero de los viejos, o con tarjetas de minutos.

El escenario de "ponerse precio" nunca ha sido  sencillo. Lo que no se debe perder de vista es que la HH fuera de un contexto de contrato jornada completa debiera ser mayor a la HH bajo contrato.

Hasta el momento aquí no hay nada de arquitectura.

La cosa es que de las tareas que me han sido encomendadas, no hay mucho de lo que no haya hecho en mi tiempo bajo contrato jornada completa. Y estas actividades más que apuntar a la resolución de bugs, apuntan a la la toma de ciertas decisiones de como debiera resolverse un problema, o bien optimizaciones generales a ciertos procesos de los sistemas de la organización, así como a la atención de consultas de temas que pueden exceder la complejidad habitual.
Al final es algo como una consultoría interna con matices de arquitectura de software.

Aquí es donde empezaron ciertos cuestionamientos existenciales respecto a lo que estoy haciendo, y  respecto a como veo el camino que está tomando la organización que  dejo detrás:

• La organización crece, y el crecimiento nunca debe ser interpretado como algo negativo, salvo cuando descuidas tu activo más valioso, que NO son tus datos, NI tampoco tus aplicaciones, sino las personas que  le dan valor a tu organización. Si como líder olvidaste eso, estas condenado a perder gente, y como me dijeron en otra empresa en la que trabajé "Son los buenos los que se terminan yendo".
• Quedan cabos sueltos, o cosas de las que nadie  se va a encargar, y no por falta de capacidad, ni porque se  carezca de las competencias adecuadas. Solamente porque nadie tuvo la voluntad para involucrarse en ciertos procesos, o si queremos ser menos pesimistas en la repartición de culpas responsabilidades, ha sido el día a día el que ganó esta batalla en la que ojalá hubiera alguien más que se dedicara a cubrir requerimientos de la organización que no son otro bug en el sistema.
  Entre estas:
• Actualización y mantención de SW anexo a los desarrollos locales, utilizado para algunas parte  "no tan críticas del sistema".
• Actualización de las versiones de las librerías utilizadas en el desarrollo. De aquí lo que más sufre es Angular, que se va a quedar un buen tiempo  estancado en la versión 15, ya que  demanda que haya otras librerías que se actualicen previamente.
• Actualización de las herramientas utilizadas en el Monorepo. De alguna manera relacionado con lo anterior.
• Control de calidad del desarrollo, buenas prácticas, etc. El tiradero de orejas claramente va a disminuir, porque no hay un área, o simplemente alguien que esté constantemente velando por esto.
• Promoción interna, a modo de publicidad gratuita. Yo siempre dije que la organización estaba haciendo cosas interesantes que iban al menos un par de pasos más adelante que varias de las organizaciones que me ha tocado conocer. Difícilmente habrá artículos técnicos que promocionen lo que están haciendo. ¿Podría hacerlo? ciertamente, pero esa no es la pregunta correcta...
• Desarrollo de nuevas librerías de uso general para simplificar el desarrollo futuro. Sin ir más lejos, un mantenedor de formularios dinámicos. Ese es uno de los grandes temas que se dejó pendiente. 
• Automatización de tareas recurrentes, sea mediante  algún script o desarrollo de alguna herramienta.
• Charlas de buenas prácticas, o show-off de proyectos, librerías o simplemente cosas que tecnológicamente tengan alguna relación con lo que se hace, o que puedan servir en algún desarrollo.

Entonces ¿la organización realmente necesita de un desarrollador senior? ¿o de un arquitecto de SW?
Y aquí es donde voy a opinar en más de un par de párrafos.

¿Qué necesita una organización?

¿Desarrolladores seniors? ¿un arquitecto de software? ¿un área de "arquitectura/infraestructura" (o invento afin)? 

Según yo, una organización que basa su funcionamiento en sistemas de SW que hayan sido desarrollados internamente y que pretenda escalar (léase por lo bajo como atender más clientes), NECESITA que alguien defina el cómo debiera solucionarse el desarrollo, siempre  aspirando a no hacer más complejo el ejemplo de tutorial o del curso online, sino sentarse y pensar en como hacer una mejor implementación, sobretodo si el problema dejó de ser simple.

Y eso normalmente es lo que hace un arquitecto de SW, ojalá en coordinación con los líderes de equipo, quienes normalmente son desarrolladores senior.

Aquí podría surgir otra pregunta, ¿este tipo de organización (mediana empresa con olor a startup), necesita un arquitecto de SW?
Y la respuesta es complicada. Quizás con la llegada de un senior, que viene con una experiencia y una visión mucho más acabada de ciertos flujos, la organización "se ordene", al menos en el sentido del desarrollo. De seguro va a ser  un poco menos "echarle para adelante" y pensar un poco más las cosas antes de sentarse a  vomitar líneas de código y a copiar ejemplos de StackOverflow; quizás... 

Ya sobrevivieron una etapa sin alguien que los ordenara, obviamente eso  se tradujo en código legacy, y una deuda técnica espantosa, pero "echarle pa' delante" funciona, igual que afirmar el acelerador de un auto con un alambre. Funciona...

Volviendo a mis dilemas existenciales, y a ciertas conclusiones que ya he sacado, lo más seguro es que  esta empresa nunca haya necesitado un arquitecto de software, ni un desarrollador senior con  demasiada experiencia.

Claramente no necesitaban, y probablemente nunca necesiten un evangelizador de software que  escriba artículos de que tan interesantes pueden ser los desarrollos internos. Menos a alguien que a través de esos artículos intente convencer a quienes postulen al área de desarrollo  que esta es la empresa en la que pueden crecer profesionalmente. El nivel de valor agregado que esto en particular agrega a una organización va a depender principalmente de cuanto les interesa destacar en el círculo de desarrollo de SW en el que se mueven, o si eventualmente te interesa  destacar en un círculo más grande.

Una vez que probaron tener a alguien experimentado probablemente se despierte esa "comezón" de tener a alguien que te diga "por ahí no, que hay muchas piedras y espinas" y que te mande por un camino más largo, de seguro más empinado, pero con cierta garantía de  poder llegar a destino sin muchos contratiempos, y con la suficiente energía para poder seguir adelante.
O probablemente no, y todos sigan picando piedras igual que siempre.

Es de aquellas cosas donde,  en lo personal, no me queda tan claro que tan compatible con el negocio sea darle cierto énfasis a la calidad del desarrollo de SW. A mi parecer sería lamentable que el time to market siempre fuera prioritario por sobre la calidad del producto entregado, y que tener algo bien hecho sea solamente parte de la esperanza  positiva del flujo de desarrollo. Aquí es donde se sopesa  el  hacer algo bien hecho en 1 semana vs sacar a flote una espantosidad en 3  días; ¿qué tan caro sale no hacer las cosas bien hechas? 

Quizás, bajo determinados enfoques,  hacer las cosas bien esté demasiado sobrevalorado y realmente no valga la pena el esfuerzo.

Entonces lo que quizás siempre  fue mejor era tener un arquitecto de  software puertas afuera, alguien fuera de  empresa a quien puedas consultar sólo cuando consideras que es estrictamente necesario; y asumir el costo de esta consultoría externa.

Con la absoluta  ausencia de humildad de este artículo: 

• ¿Cómo veo mi futuro? Espero que no sea una muerte lenta con buen sueldo, tal y como me  comentó un colega. Pero el salario es competitivo internacionalmente,  y es se nota más porque en general el empresario chileno prefiere profesionales menos experimentados que ojalá salgan baratos. Un gran amigo me dijo que trabajar para una empresa extranjera era algo que yo debí haber hecho hace muchos años atrás.
• ¿Cómo veo el futuro de la organización que dejo a un lado? Les toca un camino de maduración posiblemente algo agreste, lleno de aprendizaje. Ojalá las jefaturas se involucren con lo que se hace, sino esa desconexión les va a penar y pesar. Falta cambiar el lente para mirar desde una perspectiva diferente a la de una jefatura ya que no todo es "el negocio".

Enamoramiento y desencanto laboral

Amo mi trabajo... la pregunta es cuanto dura el enamoramiento

Muchos de los artículos que he escrito apuntan al como me gustaría; dejemos inmediatamente claro que es una cosa personal y no algo que necesariamente  vaya a ocurrir; que una empresa "reaccionara" después de que se va gente. Pero ¿qué pasa cuando el escenario se  invierte? y a esto voy cuando es la empresa la que por diferentes motivos debe desvincular  funcionarios.

Pongámonos en el contexto  actual Febrero 2023, o derechamente finales de 2022, inicios 2023; muy a grosso modo.

• Pandemia (el COVID sigue activo por si se habían olvidado)
• Guerra en Ucrania (mi opinión hacia los rusos no es precisamente lo mejor)
• Economía mundial en recesión

Elon Musk, Robert Kiyosaki entre muchos otros ya han anunciado que el 2023 se nos viene duro, así que no es sorpresa lo que ha sucedido en muchas empresas, no sólo en Latino-américa, sino a nivel mundial.

Ya vimos lo que pasó con Betterfly, que al final fue un "better fly", literalmente dejaron volar al 30% de su planilla de funcionarios (o colaboradores, como les gusta decir a las empresas de la nueva era), una catástrofe que fue muy bien adornada con la dolida carta de su CEO.

Digamos que los movimientos de gente, en cualquier organización, los quieras mucho, poquito o nada, te sumen o no te sumen, los movimientos de gente inquietan a las tropas. Esa incertidumbre de no saber que es lo que puede suceder mañana, sobretodo cuando los equipos se desarman, es uno de los caminos al burnout.

Burnout...

Entonces, como  una de las consecuencias de este movimiento de tropas, todo ese enamoramiento, todo eso que  te encantó, aparte del jugoso sueldo y los beneficios, todo eso que te motivo a estar trabajando donde estás, todo eso que te motivaba a despertar animadamente  cada mañana para ir al trabajo, se empieza a desvanecer.

Burnout..., te "empezaste a quemar" con tu trabajo, ganas de hacer nada, absoluta desmotivación, tu ánimo baja, tu actitud cambia negativamente, empiezas a cuestionar si los valores de la empresa están efectivamente alineados con los tuyos, te preguntas si ese discurso de las áreas de bienestar y RRHH (que a veces no existen) es de verdad o es la chapa para que se vea lindo. Eso pasa cuando los equipos se empiezan a  desarmar, sea porque se van yendo de a poco o porque los van yendo de a poco.

Si a eso le sumamos jefaturas inexpertas, o resultados de una meritocracia (o incluso parentesco), o cuyo liderazgo esté sostenido no por el carisma sino por el miedo que infunden "es que el/ella es el/la jefe/a". Cuántos se han callado denuncias sobre jefes abusadores por temor a quedarse sin trabajo, o incluso por represalias tipo bajarles las comisiones de ventas (por ejemplo). En ese sentido hay jefes a los que  no les importa liderar equipos, sino simplemente dirigir subalternos, y la diferencia es mucho menos sutil de lo que parece. Y claro, puede que como empresa necesites un tigre, pero mínimo esperar que ese tigre no se coma a tu gente (o que te genere otro tipo de problemas).

Y finalmente el discurso. En lo personal, la consistencia en el discurso es algo que valoro demasiado. Si me dices que se va a mantener blanco, te voy a creer, pero si me pintas todo negro después, pasan varias cosas:

• Empezando, mi confianza en ti (pensemos en la confianza que puedo sentir hacia una organización) se va al carajo. 
• Todo lo que me digas pierde credibilidad.
• Me empiezo a quemar más. Y quemarse con alguien no es bueno, por lo bajo, te hace perder objetividad, entre otras cosas.
• Me siento traicionado.

Tratando de  explicarlo con un ejemplo:

Es como cuando eras pequeño y le decías a tu mamá que querías un helado y te decía que no porque "no tenemos dinero para comprar helado", y esa misma semana tu mamá llega con un par de zapatos nuevos que se había comprado.

Da lo mismo si había una reserva de dinero para los zapatos de mamá, o si los zapatos sí  estuvieran en la lista de necesidades y prioridades (no así el helado). La cosa es que te  dijeron que no había dinero y resulta que sí había dinero.

No digo que laboralmente sea diferente. 

Probablemente hayan mil y un antecedentes que "el pueblo" no maneja, y las decisiones que se tomen efectivamente  tengan un soporte sólido que sólo manejan las jefaturas (básicamente de quien dependen las decisiones finales). Pero si para sostener que la empresa debe reducir personal, el argumento es que estás fuera de presupuesto, o que tenemos que ajustarnos el cinturón por la recesión, no puedes en esa misma semana estar contratando gente, o incluso tener posiciones abiertas ¿no qué estábamos reduciendo personal porqué no hay presupuesto?

En el caso que  ejemplifico, puede que efectivamente las nuevas contrataciones estén debidamente justificadas, sin embargo ¿cuál es el mensaje que le entregas al resto de tu organización? 

Déjame responderlo: Tu discurso es inconsistente. Da lo mismo que sea incompleto porque no  quisiste, no puedes, o incluso porque simplemente olvidaste mencionar los puntos de excepción; tu discurso ES inconsistente; dijiste algo, hicieron exactamente lo contrario.

Y eso te quema. Prepararse para ese escenario en que alguien (en algunos casos un mismo) tendrá que absorber y asumir todo aquello que se podía asignar a quienes ya no van a formar parte de tu equipo también quema. 

Quema el siquiera pensar que los niveles superiores de la pirámide organizacional (imagen sacada de este otro artículo mio) están considerando muy por encima el impacto de desarmar los equipos (más si lo sumamos a la inconsistencia del discurso). Quema más pensar que probablemente les interese un carajo el impacto de desarmar un equipo porque "es parte del crecimiento de la empresa". Quema...

Y entrar en esa fase de desencanto, duele por dentro,  quema, y quemarse  no es bueno. He estado ahí.

¿Será que es el momento de dar vuelta la página? y pongo las cosas en la balanza, y me resisto a evaluar esa opción, y espero no sea un error...

Ofertas laborales: Lo siento, no tengo tiempo para responder tu desafío técnico

 

Cuánto sentido me hace este artículo que leí hace poco:  

Why I Don’t Have Time For Your Coding Challenge

A la fecha llevo 1 año y 5 meses trabajando para una empresa, y parte del flujo de contratación de desarrolladores involucra una prueba técnica. No es nada de la Nasa, pero tampoco es trivial.

Cuando recién postulé, paralelo lo hice a  otra empresa y, tras una entrevista personal, pedían resolver un desafío técnico que me tomó cerca de  7 horas resolver.

Por una cosa personal me dije responder el desafío y hacerlo con todo lo recomendado:

• Buenas prácticas
• Documentación
• Código versionado
• y otras originalidades que se me ocurrieron en el camino

la idea era que aún cuando estaba, a sabiendas, cumpliendo sólo el 50% de lo requerido, mi postulación destacara al menos por sobre la media. Y el resultado, me informaron que pasé a una nueva entrevista, para la cual nunca me llamaron. 7 horas de trabajo gratis, sólo para el regocijo personal de haber hecho algo bien hecho... Ni siquiera un feedback de porque no resultó (en realidad  aún no se de ninguna empresa que  entregue feedback a aquellos entrevistados que no fueron seleccionados).

Como ya mencioné, la empresa para la cuál trabajo también hace este tipo de pruebas de selección. Y por esos misterios que a veces resulta mejor no saber, en mi caso bastó con presentar y explicar algunos de los litros y litros de código que había hecho. Mi actual jefe me hizo pregunta de la prueba técnica, y si mal no recuerdo le di al menos 3 formas para resolver el problema.

Ahora que ya llevo tiempo en la empresa, y ahora que lo pienso también, en realidad no tengo tiempo para desafíos técnicos. Y es sencillamente porque, a menos que en realidad me interese  demasiado la posición a la que estoy postulando, difícilmente hay salarios que valgan tanto la pena como para sacrificar tiempo de familia, ocio y descanso. 

Pensemos objetivamente (ojalá  toque un empleador leyendo esto): 

1. Un postulante ya trabaja en el área, seguramente  toda la semana viendo lo mismo ¿pedirle qué siga codificando fuera de horario?
2. Un postulante está buscando trabajo, y lo más seguro es que tenga al menos 3 o 4 postulaciones en curso. Lo más seguro es que al menos 2 de las áreas  creativas  ya estén solicitando que se respondan  desafíos técnicos. ¿Punto 1 multiplicado por n?
   Estamos claros que esto no es problema de ninguna empresa, pero esto no transmite  precisamente la mejor de la imágenes respecto a la cultural empresarial, si te piden que  para postular   sacrifiques  tiempo propio, ¿qué puedes esperar si te contratan?
3. Hubo una época que proliferaron ofertas de la India para responder tu test técnico para entrar a Facebook, Amazon, y Google,  era algo así como "x 60 USD  te aseguro que  quedas seleccionado". Un desafío técnico "para la casa" no da garantías que quien postula efectivamente lo haya resuelto, y aprender a explicar  código ajeno puede no ser  trivial, pero tampoco es  ciencia de cohetes.
4. Una entrevista técnica bien hecha (por alguien del área técnica) debiera ser suficiente para juzgar las competencias de un candidato. Resolver un desafío  de código breve in-situ es incluso ilustrativo del cómo piensa cada candidato para resolver un problema, esto es ¿cómo resolverías blah...? pseudo código, diagramas, etc.
5. Las entrevistas, en general, tienen intrínsecamente un factor intimidatorio, y buena parte de quienes hemos escogido este camino, somos de naturaleza más bien tímida (se pasa con los años...).  Dicho esto, si quiero conocer a alguien, mejor pedirle que hable de las cosas que ha hecho, con las que está familiarizado y de las que le resulta  natural hablar. Qué te expliquen código, o te muestren proyectos propios o en los que hayan participado es mucho más ilustrativo de las competencias de un candidato que forzarlo a resolver una prueba técnica.
6. Alguien tiene que revisar las pruebas técnicas. Supongamos un escenario imaginario optimista, más de 100 candidatos en total, y de esos 100 más de 40 respondieron la prueba técnica (de nuevo, optimista...). Yo fui ayudante de un curso de computación en una universidad, cursos de más de 40 alumnos, me tomaba una semana revisar los trabajos para la casa. 
   La empresa ya destinó tiempo para las entrevistas, ¿porqué mejor no aprovechar de buena manera ese mismo tiempo?
7. Si un candidato pasa el desafío técnico, es contratado y no rinde como se espera; como empleador; lo vas a terminar despidiendo igual. Los 3 meses a prueba antes del contrato indefinido no son un costo ni un riesgo que no se haya considerado, y los desafíos técnicos no van a disminuir la probabilidad que te equivoques en una contratación.

Y así podría estar mucho rato escribiendo sobre el tema. Los desafíos técnicos no son la forma adecuada para seleccionar desarrolladores. Hoy en día a menos que seas un estudiante  sin mucho que hacer en tu tiempo libre, te dediques a participar activamente en hackatones como si fuera un deporte, o que tu hobby sea escribir código (hay casos raros a sí de extremos), el costo personal de  responder un desafío técnico es muy alto, tiempo que nadie te paga, y que no vas a recuperar.

En lo personal una entrevista que la lleva completamente un reclutador sin conocimientos técnicos, y que además implica una prueba técnica, me levanta las alertas inmediatamente. Lo más probable es que no sea la oferta que estoy buscando (o que  deba mirar), y probablemente tampoco tenga  una oferta salarial atractiva.
Normalmente (sé que no es bueno generalizar, pero son años de experiencia viendo lo mismo, de una u otra forma)  las empresas cuyos procesos de selección van casi completamente definidos por una prueba técnica son empresas con olor a auto nuevo, que buscan al "recién egresado más competente y más barato de la actual generación". Ahí los viejos mañosos, caros y sobre-calificados, no tenemos cabida, y por eso se agradece cuando una empresa se arriesga con uno y valora la experiencia de eso que han llamado "ingeniero de desarrollo senior".

Crónica de una muerte anunciada

Se veía venir, mi desmotivación estaba aumentando insanamente mi habitual hostilidad por sobre los niveles socialmente aceptables. Así que una vez que una de mis varias postulaciones prosperó, renuncié a mi trabajo.

Yo lo veo como el cierre de un ciclo, las favorables condiciones que "me enamoraron" en un comienzo cambiaron a tal grado que se respiraba malestar e incomodidad. Pero en la cima de pirámide siempre serán incapaces de mirar de manera crítica más allá de sus pestañas, porque incluso sus narices sería que miraran demasiado lejos. Lo dicho, empresa familiar donde quienes toman las decisiones sobre temas técnicos no son del área, y el gerente TI jamás se empoderó de su cargo (y por cierto tampoco es ingeniero informático sino eléctrico...)

Entonces analizo hacia atrás y miro al futuro. Un nuevo desafío, donde una vez más rememoro ese episodio donde se dijo que "hay cosas que no se transan", o en este caso cosas que no se pueden pagar con dinero.
Efectivamente se lee como una contradicción a uno de mis últimos artículos, pero todo se trata de plata y al final no se trata de plata. Como ya han señalado demasiados autores, uno no renuncia a su trabajo, uno renuncia a su jefe. Pero hay señores feudales que no van a aprender a gerenciar/liderar  equipos como se debiera hacer, alimentar el bolsillo es siempre más importante que hacer buena gestión, y digo gestión de proyectos, de recursos y por sobre todo humana. Al menos para mi resulta inconcebible que una empresa se maneje desde el desconocimiento de los proyectos en curso, el estado de estos proyectos, y con una priorización basada en el "tengo que facturar", o en cual es el cliente que está llamando al gerente. Sin embargo la parte triste de la historia es que parece que esa estrategia funciona.

En un viaje al extranjero, conversando con un chofer de Uber me quedo grabada una frase que dijo "La gente ya no se preocupa por la gente" ("People don't care about people"). Y en países tercermundistas aspiracionales como Chile, lo vemos a diario, sobretodo como empleados. No hay (lo sé, estoy generalizando...) preocupación real por los trabajadores.

Me fui desilusionado, desilusionado al ver que como en 5 años la misma empresa no haya aprendido absolutamente nada en cuanto a gestión de proyecto informáticos, cero avance en las tecnologías utilizadas, el archipiélago de islas uni-personales en el equipo de desarrollo persiste, cero crecimiento profesional (los años van a pasar y vas a seguir picando las mismas piedras) y por sobre todo un  retroceso en torno a la gestión del recurso más importante en una empresa: las personas; quienes siguen ahí no porque sea la mejor de las empresas, sino porque no pagan mal. Como dice el secreto a voces en la empresa "Se notó demasiado el cambio de mano" y no para bien.

Y podría seguir descargándome, pero no. Simplemente voy a concluir que como la mayoría de las segundas partes (a excepción del Imperio contraataca) este capítulo fue algo decepcionante.
Pero así es el rock & roll del ingeniero de software, es iluso esperar que todo sea felicidad y éxito; es  casi como esperar que todo funcione bien a la primera.

Cambio de trabajo: Un año después

Y bueno, ha pasado un año (en realidad algunos días más) desde que decidí cambiarme de trabajo. Lo típico, el análisis de porque me fui y que ha sido de eso.

El porqué me fui, ya no es misterio, entre la incertidumbre de no saber si el próximo mes iba a haber algún proyecto, entre seguir siendo el ingeniero frontend más caro dentro de la empresa, y seguir haciendo "nada útil",  y ver un "cambio". En estricto rigor fue algo más como un "cambio de aire" que otra cosa, ya que volví a una empresa donde ya había trabajado.

¿Y la promesa? (otra promesa, no las del chiste "fino") Nuevos proyectos, nuevos desarrollos, varias cosas en las que mis especialidades calzan perfectamente.
Y ¿es cierto? Si, claro. Pero al final no se trata de crecimiento profesional, ni de espacios para investigación, ni de un buen computador para trabajar. Tampoco de ser parte de un equipo de excelencia, donde el nivel técnico fuera muy alto; si fuera por eso hubiera seguido picando piedra donde mismo.

Al final se trata de lucas, dinero, chinchin, cash. Si el sueldo es bueno, y las condiciones de trabajo se ajustan al margen que uno está dispuesto a negociar, el espíritu del mercenario despierta. Si tu oferta es buena, no me estás vendiendo humo, y las condiciones son a lo menos comparables a mis condiciones actuales, conversemos. Laboralmente, por feo que se lea el ser tan honesto, todos tenemos un precio, por el cual ningún compromiso laboral, ninguna camiseta de la empresa, ni gorro corporativo, ni elegante uniforme de trabajo, valen el quedarse. Las oportunidades raramente golpean tu puerta 2 veces, y no es y llegar dejarlas pasar de largo.

Pero eso fue mi año laboral, raro, donde mucho sigue igual, mucho debiera haber cambiado para mejor, pero a la larga lo mismo de hace 5 años atrás donde la empresa familiar sigue siendo familiar, y donde el área de desarrollo es un República independiente.

¿Y el año que dejé atrás? Como le mencioné a un ex-compañero, que ya no trabaja ahí, la torre de Yenga se derrumba. Por lo que alcancé a ver antes de decidir terminar el contacto con ese grupo al que tanto cariño le tuve, han sabido sobrevivir. Pero en un año y al menos 3 personas menos en ese equipo, me queda claro que allá más arriba, no aprendieron nada. Las tropas siempre inquietas, y sobretodo disconformes por no saber que pasa en el Olimpo. Si claro, el Olimpo maneja las cosas entre Dioses, pero nosotros los pobres mortales que a la larga nos encargamos de "parar la olla" como dice nuestro lider técnico (cof cof wannabee), tenemos que al menos saber si los Dioses exigen un sacrificio.

Eso sumado a quienes constantemente dicen que quieren emprender un nuevo camino profesional. Las tropas están inquietas, y a los buenos soldados hay que cuidarlos; eso no debiera ser difícil de entender, aprender y asimilar.

¿Fue una buena decisión? Siempre es buena decisión moverse, ojalá no demasiado seguido para que los psicólogos laborales no empiecen a inventarse una lectura entre líneas. Siempre es bueno si ese movimiento te permite una reinvención financiera, digamos pasar de excavador sepulturero a caminante blanco.

Mi consejo (no solicitado, por cierto) para sus propios años laborales: Hagan lo que consideren mejor para ustedes. Si creen que quedándose donde están estan mejor, quédense. Si creen que necesitan aceptar esa oferta de Tesla, váyanse. Si creen que merecen descansar unas cuantas jornadas, HÁGANLO. Pero OJO, nunca dije que lo mejor para ustedes sea lo correcto, a veces eso también hay que saber transarlo (aunque hay cosas que no se transan).
Vean la proyección a futuro de las ofertas que se les presentan, a veces la genial y súper cachilupi startup con sala de juegos es una empresa donde respiras el perfume de la fecha de expiración; o donde todo es muy bonito, cultura de empresa, metodologías, pero te casas con el sueldo que pediste (y con tu cargo, y con el computador que te pasan).

Cuando los quieran retener con el clásico discurso de "Te igualo el sueldo que te ofrecen, pero quédate" simplemente cuestiónense porque no les subieron el sueldo cuando  lo pidieron y les ofrecen subirlo ahora que se van. Estadísticamente, si aceptan esa oferta y se quedaran, al final igual terminan lléndose.

Y después de este desborde de honestidad, probablemente Bobba Fett sea un candidato más atractivo que yo para ciertas empresas.

La necesaria mirada hacia adentro de la propia organización

by https://www.flickr.com/photos/144152028@N08/33772074972

Mañana se cumple exactamente un mes desde que dejé mi antiguo trabajo. Por esas cosas del destino ahora estoy en una empresa que ya conocí, sacando cuentas he vuelto después de 5 años.
No puedo negar que ahora me siento bastante más cómodo, la dinámica de trabajar por proyectos versus trabajar en torno a un producto que está posicionado en el mercado hace más de 20 años es muy diferente. Proporcionalmente hablamos de una empresa con un área de desarrollo mucho más pequeña, por ende mucho más especializada, contra una empresa que es derechamente de desarrollo, donde el área encargada es bastante más grande, y consecuentemente más heterogénea. Pero no quiero referirme a eso, sino a una reflexión que tuve antes de cambiarme de trabajo.

Desde el punto de vista de la empresa, ahora se fue uno (en rigor hace un mes), un recurso menos, un elemento reemplazable, con más o menos dificultad, pero siempre reemplazable. La pregunta a hacerse desde dentro es ¿porqué? ¿qué pasa en MI organización, que la gente piensa en irse a otra empresa?
El que tan indispensables somos depende de las estrategias de cada empresa. Si cada desarrollador es "dueño y señor" de los desarrollos que se le encomiendan, y si no existe un equipo de más de un solo hombre (o mujer) encargado, entonces se vuelve más complicado reemplazar a alguien que se va. Pero ¿porqué se va la gente?

¿Mejores condiciones? ¿salarios más atractivos? ¿mejores proyectos? ¿mayor proyección profesional?
A mi parecer, y un poco lo que personalmente me motivó, es una mezcla de factores, donde claramente el salario fue el 1er elemento a considerar, pero no el único.
Cuando día tras día la rutina de ir a trabajar se empieza a volver tortuosa por la percepción de una falta generalizada de voluntad por hacer cosas, y cuando empiezas a darte cuenta de una inusual venta de humo, de la que alguien (probablemente uno) tendrá que hacerse cargo, con requerimientos imposibles y en plazos irreales, entonces hay algo que dispara todas las alertas en tu interior. Si a eso sumas que la organización difícilmente ajustaría las condiciones y el equipo conforme a estos nuevos "desafíos", o simplemente ves que  te estás condenando profesionalmente a "seguir picando piedras", las señales no pueden ser más claras.

Entonces desde dentro probablemente van a ver todo bonito y tu partida será injustificada. Aquí es donde es importante no perder la objetividad.
¿Qué está pasando en MI organización? Si tu administración es desde el desconocimiento, entonces puedes esperar que muchos se vayan y no vas a entender porqué. La mirada hacia adentro debe ser crítica y siempre objetiva. No es pecado ni mal visto bajar del Olimpo a ver que pasa en la Tierra.

Las tropas no se mueven si no hay un liderazgo claro, pero tampoco dejan los puestos de batalla por nada.

Nota: Este artículo probablemente se lea como una contradicción (en algún grado) a este otro artículo . Si y no. Como mencionaba más arriba, las condiciones (entorno) pueden ser  muy buenas y atractivas, incluso mejores que las de cualquier otra empresa, y seguramente es eso lo que va a ver un jefe. Pero la informática es dinámica, y no se alimenta sólo de juguetes, vestimenta informal, pizza, café, golosinas y bebidas energéticas. El problema esencial es cuando el líder no se da cuenta (o no quiere darse cuenta) que las tropas están inquietas, ya sea por ese constante picar piedra o simplemente por la incertidumbre frente al futuro; y frente a eso por muy buenas que sean las condiciones del entorno la gente se va a ir.

Desarrollo ágil y metodologías

Ya había comentado mis observaciones relativas a las metodologías de desarrollo. Bueno, aquí hay alguien con bastante más experiencia y reputación, y un poco más extremista que yo, quien también tiene apreciaciones similares:

One Hacker Way - Eric Meijer

Y obviamente acompañado del interesante artículo Erik Meijer: “Software is eating the world”

Metodologías de desarrollo ¿Ser o no ser?, he ahí la cuestión

Este mes comencé una "nueva aventura/desafío laboral" en otra empresa. Viniendo de una modalidad de trabajo bastante salvaje, llegar a una empresa donde el uso de metodologías de desarrollo es intenso ha sido un cambio no menor. La experiencia ha sido bastante diferente a lo acostumbrado.

En mis trabajos anteriores si bien nos preocupábamos de una u otra manera de llevar un control de versiones, y llevar algún registro de actividades, todo el desarrollo se realizó de manera "salvaje". Salvaje en el sentido que más que el control sobre las actividades a realizar, lo que importa, y casi lo único que importa, es cumplir con las entregas finales de código (y no es que con metodologías más estrictas esto sea menos importante). Dicho en fácil, estuve desarrollando "a lo brutito" mucho mucho tiempo. El objetivo era cumplir si o si.

Metodologías

En esta empresa, muy ligado al alto nivel de los profesionales del equipo con el que debo trabajar, así como también la envergadura del proyecto en curso, la planificación y las metodologías son vitales:

• Se realiza una planificación para la semana. Un conjunto de tareas que debiera estar resuelto en un plazo dado. La fecha tope normalmente no debiera exceder  de una semana de trabajo (5 días).
• Cada mañana se realiza una "breve" (a veces no tan breve) reunión, a priori no más de 3 minutos por persona. Todos de pie debemos contar que hicimos en la jornada anterior, y cuál es nuestra planificación para el día de hoy. Se deben levantar las alertas necesarias  sobre aquello que pueda dificultar el desarrollo.
• Cada viernes, idealmente en la mañana, se realiza una sesión de demo en la que se presenta al equipo algún resultado visible de las actividades realizadas en la semana.
• Las actividades se ordenan en un tablero Kanban en el cual cada tarea se va moviendo de columna conforme al estado de la misma. Las columnas son:
• Por hacer
• En desarrollo
• Detenido
• Resuelto
• Cerrado
• Cada bloque de código tiene que contar con su correspondiente set de prueba. El Test Driven Development (TDD) amerita un artículo aparte (próximamente en este mismo canal).

Uno de los focos principales es la autogestión del equipo, por lo que cada integrante hace sus propias estimaciones de tiempo.
Y el nivel de control sobre el equipo de desarrollo es claro, siempre sabes que están haciendo todos.

Lo positivo

• El equipo tiene una visión general de todo lo que está pasando. Se lo involucra en las actividades de la empresa, lo que SIEMPRE es bueno.
• Se logra un nivel de orden para las actividades de cada integrante del equipo.
• Se puede dimensionar el costo en tiempo para el desarrollo de un proyecto.
• Se van afinando, progresivamente, los procesos de desarrollo.

Lo no tan bueno (desde la humilde perspectiva del autor)

Mi gran reparo respecto a la aplicación de estas metodologías apunta hacia el tiempo.
Hacer una reunión diaria, de pie, en un equipo de más de 5 personas puede tomar por lo bajo 30 minutos. Similarmente hacer una sesión de sesiones de demo, podría extenderse al orden de una hora.

En relación al registro de actividades y atenerse a las directrices que se definan incluso para los comentarios al subir código a un repositorio de versiones tampoco es  una tarea directa.

Y sobre los sets de pruebas, estos deben considerarse como un desarrollo anexo, que se suma al tiempo normal de desarrollo. Suele suceder que la detección y corrección de errores (bugs) puede resultar muy rápida, sin embargo la construcción de los set de pruebas muchas veces puede demorar bastante, y muchas veces no tienes como dimensionarlo de manera adecuada.

Tengo cierta claridad sobre la duración de los períodos reales de productividad diaria, habitualmente no más de 5 o 6 horas en una jornada de 8 horas, sin embargo contar con un hora menos para resolver mis tareas planificadas (y me refiero exclusivamente a mi experiencia) pesa.

En un trabajo anterior mi jefe decidió involucrarme en reuniones con cliente, a veces 2 horas al día. Paralelamente yo tenía asignadas ciertas actividades de desarrollo, con fechas de entrega planificadas. Esos días por fuerza tuve que recuperar las horas que literalmente perdí por estar metido en reuniones.

¿Ser o no ser? (o ¿cuándo usar metodologías?)

La respuesta debiera ser siempre. Debiera ser...
Desde mi aún inexperto punto de vista, como en muchos otros casos, la respuesta será un gran depende. Las ventajas son bastante claras sobre no usar metodologías. Sin embargo, su uso estará definido desde la misma filosofía de la empresa hasta el tipo de proyectos que se está desarrollando.

• Tratar de imponer el uso de metodologías en una empresa que ha sobrevivido en estado salvaje puede tener un costo más alto que el beneficio en el corto y mediano plazo tras incorporarlas. Hay empresas que simplemente no valoran hacer las cosas bien, basta con hacerlas (tristemente las hay...).
• En proyectos "pequeños" desarrollados por ejercitos de un solo hombre es discutible (y sólo discutible) si vale la pena incluir el desgaste natural asociado a incorporar metodologías.

Personalmente creo que la decisión pasa por la apreciación que tenga cada lider de desarrollo respecto al recurso tiempo, y de que manera puede hacer mejor gestión de este.
Pero sí, hay mucha ganancia en usar metodologías, sólo hay que encontrar la combinación correcta, en la medida que civilice un poco los procesos de desarrollo

¿Qué tan frágil es tu organización?

Hace aproximadamente un mes atrás conversaba con mi ahora ex-jefe sobre que tan frágil es una organización. Básicamente porque mi rol en la empresa tenía cada vez más responsabilidades, y en caso de irme reemplazarme no sería tan sencillo. Hoy estoy trabajando en otra empresa, y créanme que la últimas semanas en mi antiguo trabajo fueron intensas.

Un artículo atrás hablaba del costo de la especialización, y la importancia de poder desempeñarse como un profesional versátil (busquen por fullstack developer para más referencias al respecto).
Si bien es cierto un fullstack developer resulta muy valioso para la organización, es también un riesgo, tan grande como su valor como profesional, puesto que inevitablemente habrá muchas tareas que le serán confiadas. Muchas veces, por no decir la mayoría, este tipo de profesional será el único quien se puede hacer cargo de muchas de las ya mencionadas tareas, o bien será el único que las puede resolver de manera rápida y eficiente.

Cuando se dió esta conversación con mi antiguo jefe, me señaló que si yo me iba, le sería muy difícil encontrar a alguien que pudiera cubrir mi posición. Similarmente si se iba otro compañero que se ha involucrado más en actividades de gestión que de desarrollo, la empresa se tambalea.
Paradojalmente unas semanas después recibí una oferta de aquellas que no esperas que se repitan, y la acepté. Es complejo ver como la empresa en la que has trabajado tiene que empezar a considerar el plan B para todas las actividades en las que estabas involucrado.

¿Ustedes tiene un plan B en caso de?

¿Qué tan frágil es tu organización?

Habitualmente se dice que una organización es tan fuerte como su eslabón más débil, pero ¿qué tan frágil es?
La fragilidad de una organización, empresa, e incluso emprendimientos ligados al desarrollo viene dada por cuántos son los soportes que sostienen las actividades clave/sensibles/de vital importancia, y cuanto es el riesgo que se debe asumir si alguno de estos pilares ya no está en el equipo.

Por ejemplo: Un emprendimiento cuyo norte es entregar un producto de software no debiera depender de una sola persona para hacerse cargo del desarrollo (o de la parte TI si quieren ampliar el concepto). Si esta persona decidiera no seguir, si no hay como reemplazar sus experticias, es probable que tengan que replantear el emprendimiento en si.

Si miramos a las empresas como el juego de la Yenga, la fragilidad podría verse como  cuantos palitos puedes sacar antes que la torre de derrumbe. Mejor aún, dependerá además de que tan abajo o arriba estén los palitos que sacas (obviando el hecho que una torre no representa precisamente una pirámide organizacional).

Y claramente hay muchísimos otros factores que influyen.

El costo de la especialización

A principio de mes el equipo sufrió una baja. Un compañero que habían contratado por su experticia en Java optaba por una mucho mejor oportunidad laboral. Esto me hizo pensar, para bien y para mal no tan bién, en el costo real de la especialización.

Para proteger la identidad de los inocentes, denominaré M a este  ex-compañero.
M fue contratado por su experticia en Java, además de cierta experiencia en el área de salud. Lo entrevistó mi jefe. Pasaron aproximadamente 3 meses antes que M pudiera dedicarse a desarrollar en Java, los primeros meses fue necesario que colaborara en tareas de análisis y documentación, y que apoyara ciertos temas de base de datos.

M es un especialista en Java, particularmente en el framework Spring. Sus conocimientos en el contexto teórico son destacables. Y sería, M SABE Java y Spring. El resto de las áreas no le resultan desconocidas, sin embargo al no ser su especialidad, delegarle cualquier tarea constituía un riesgo de tener que revisar exhaustivamente el trabajo, o incluso hacerlo de nuevo.

OK, estamos claros que 3 meses fuera de tu zona de confort  pueden desmotivar a cualquiera, pero independiente de eso, por sobre todas las cosas debes ser profesional. En el peor caso, que tu disconformidad no se note, o bien conversarlo con la jefatura.

¿Qué tiene que  ver esta historia con el costo de la especialidad?

M es un especialista, y lo fue en un equipo pequeño. En un equipo pequeño ser un especialista tiene un costo muy alto (para bien y para mal no tan bien). Un equipo pequeño requiere profesionales versátiles, que puedan desempeñarse de buena manera en cualquier rol que se les asigne. En este caso, esperé mucho más de M, más que  únicamente su especialidad, y aún en su experticia.
Esto es un costo no despreciable para un profesional .

Su partida dejó al equipo sin un especialista al que se podían delegar tareas muy precisas, y se podía esperar que se resolvieran de buena manera.
Esto es un costo no despreciable para una empresa.

En una empresa con un equipo más grande es esperable tener múltiples especialistas, por lo que la versatilidad, se bien se agradece, puede no ser estrictamente necesaria.

¿Es bueno convertirse en un especialista?

Tratando de ser objetivo, la respuesta es un gran depende.

Siempre será bueno desarrollar experticia en un área. De hecho haciendo una introspección, todos nosotros dominamos ciertas materias mucho mejor que otras.

Por otro lado, siempre será bueno manejar, conocer, o simplemente defenderse en varias materias, sin necesariamente ser un experto. Ser versátil entrega una visión más amplia para enfocar los problemas (en general, no solamente en informática).
Claro que, al igual que los jugadores de fútbol, difícilmente habrá uno que juegue bien en todas las posiciones, pero nuevamente al igual que los jugadores de fútbol, los entrenadores del equipo lo agradecen, sobretodo cuando otro jugador falla.

También dependerá del tipo de equipo en el que se desea trabajar, o hacer carrera, el tamaño de la empresa u organización, y cual es su proyección profesional.
Un especialista por fuerza requiere de un equipo que lo complemente. Alguien demasiado versátil puede fácilmente transformarse en un "ejército de un sólo hombre", lo que, por conocimiento de causa y propia experiencia, bajo ninguna perspectiva es saludable.

Lo más importante, independiente del camino que decidan seguir, especialista o no, no traten de engañarse con títulos, experticias, o especialidades que no ejercieron. El papel, los currículum vitae y LinkedIn aguantan mucho, pero siempre hay alguien que verifica si realmente fueron un Arquitecto Java en su trabajo anterior.

Yo vs emprendimientos TI

Inicialmente iba a ser un artículo lleno de argumentos y explicaciones. Era sobre mi propio enfoque y el porqué de mi incompatibilidad con los emprendimientos. Al final el éxito de un emprendimiento se resume en una sola cosa: 

SACRIFICIO.

Hace algún tiempo tuve la oportunidad de conversar en extenso con un suizo, residente en Chile. La conversación con este exitoso empresario del rubro inmobiliario pronto derivó en su visión sobre los emprendimientos en Chile.
Me comentó sobre una experiencia que tuvo con unos amigos de él. Tenían una idea muy buena, auspiciosa en cuanto al mercado y a las potenciales ganancias a obtener. Él con su experiencia les señaló:

"La idea es buena, tiene potencial, pero para poder llevarla a cabo tienen que destinar al menos 10 horas diarias para trabajar en ella."

Se podrán imaginar que la réplica fue que no podían destinar 10 horas diarias de trabajo, ya que todos los involucrados podían entregar dedicación parcial al proyecto, debido a que trabajaban jornada completa.

Me arriesgo a decir que un alto porcentaje de los emprendimientos que quedan en nada (léase sólo en la idea y las buenas intenciones) se debe a que los integrantes no pueden destinar el tiempo necesario para trabajar en el proyecto.
Lamentablemente los emprendimientos no pueden llevarse a cabo a ritmo propio o cuando tengas ganas/puedas de dedicar tiempo a ello.

Finalmente todo se reduce a SACRIFICIO. ¿Cuánto estás dispuesto a sacrificar?:

• ¿Sacrificarías no ver a las personas que amas? 
• ¿Sacrificarías horas de sueño y descanso? 
• ¿Sacrificarías dejar de ganar una remuneración por hacer lo mismo (o similar)? Nota: Puse dejar de ganar y no perder, hay una sutil diferencia.
• ¿Sacrificarías rendir en tu trabajo actual por dedicar tiempo a tu emprendimiento? y de paso asumir el costo que esto puede significar (normalmente ser despedido).

Y quedo corto en este listado. Responder NO a cualquiera de estas preguntas ya es un riesgo que no estás dispuesto a tomar.

¿Cuánto estás dispuesto a sacrificar?

¿Cuánto?

En mi caso las cuentas eran negativas, demasiadas responsabilidades en mi quehacer cotidiano, repercusiones familiares, costo de oportunidad descompensado y una que por donde la mirara tenía demasiado peso. Después de una jornada de 8 horas diarias frente a un computador, resolviendo problemas de las más variadas especies, física y mentalmente termino disminuido para seguir haciendo lo mismo en casa (fuera de horario).

Hay que ser sincero con uno mismo y no tratar de auto-convencerse con falsas ilusiones. Las charlas TED y de la universidad suenan muy lindas y convincentes, pero llevarlas a la práctica dependerá de realidad personal de cada uno.

Entrevistas de trabajo y pruebas de conocimientos técnicos (parte II) - Amazon

Siguiendo con la secuencia de artículos, en esta oportunidad me referiré a mi propia experiencia de entrevistas de trabajos con Amazon. Aparte de satisfacer la curiosidad de muchos amigos que estuvieron atentos a como me iba (en serio ¡gracias  todos ustedes! :) ), espero que mucho de lo que voy a escribir sirva de consejo para otras personas que vayan a enfrentar entrevistas con  Amazon.

La primera vez que me entrevistaron me contactaron por Linked In, esto fue a fines de Abril de 2013, mi suegra había fallecido recién, y la verdad mi estado de ánimo estaba afectado, fuera de la ansiedad natural de enfrentar a una prueba con una de las empresas más importantes del mundo.
La prueba en si fue escrita, 3 preguntas de Diseño Orientado a Objetos (OOD) y Codificación, y consideraban tus respuestas  siempre y cuando las hubieras contestado en 65 minutos o menos.

1. La primera  pregunta fue de diseño orientado a objetos. El requerimiento era modelar (y dentro de lo posible implementar) un software de diseño gráfico, algo así como Inkscape o MS Paint. No era difícil, pero era una pregunta larga, te podías complicar tanto como quisieras.
   

   Let's say we're developing a vector graphics application. It will allow the user to create lines, rectangles, circles, text, etc. and manipulate them independently - move them, resize them, etc. Design an object model for this application. (How would you model the representation of the document in an object oriented language? What classes would you define? What methods would you have? What would your API look like?)

2. La segunda pregunta fue de algoritmos y estructuras de datos. Se debía implementar un método que mostrara en pantalla el listado de amigos directos o por nivel (amigos de mis amigos) de una red social, y así sucesivamente. El problema real era como recorrer un árbol por nivel.
   

   Code printSocialGraph(Member m). Direct friends of m are Level 1 friends. Friends of friends are level 2 friends.....and so on
   Print level 1 friends first. Then print level 2 friends....and so on

3. La tercera pregunta era de programación de algoritmos eficientes. Pedían una implementación eficiente para calcular un ene-ésimo número de Fibonacci. Lo más "obvio" era haber implementado una especie de pila con memoria para futuras ejecuciones (o algo así), o usar alguna ecuación matemática avanzada para este  cálculo. Por un tema de tiempo hice la implementación recursiva tradicional, y lo más seguro que mal...
   

   Write an efficient function that returns the n’th Fibonacci number (There are many ways to solve this problem. Please write the most efficient method possible). Each Fibonacci number is the sum of the last two. The first 10 are: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55.
   long getNthFibonacci(long i) { ... }

Las cosas importantes que rescato de aquí:

• Prepararse para manejo de tiempo
• Repasar patrones de diseño
• Manejar las estructuras de datos básicas, árboles sobretodo y manejar los algoritmos para recorrerlos.
• Leer y entender algunos algoritmos de computación distribuida

Según he leído, la evaluación es bastante estricta en cuanto a la sintaxis, se espera poder copiar y pegar el código que hayan generado y que compile correctamente. Y una cosa que me llamó la atención es que la plataforma que utilizan para la prueba técnica literalmente graba el como vas respondiendo, probablemente para entender los procesos mentales detrás de cada respuesta.

En la segunda oportunidad me contactaron directamente a mi correo, seguramente debido a que ya tenían mi currículum de la oportunidad anterior. Ahora la entrevista sería telefónica, de 1 hora, y se me solicitaba tener acceso a internet y compartir una pantalla para escribir código colaborativo.

Después de una fallida entrevista, debido a mala conexión telefónica (moraleja, para llamadas internacionales NUNCA dar el celular, o línea fija o Skype (o similar)), logré que agendáramos la entrevista para otro día.
Llegado el día D, me entrevisté con el jefe del equipo de desarrollo al que postularía.

La entrevista se desarrollo de esta manera:

• Mohan me contó un poco que es lo que hacía en  Amazon  me fue preguntando sobre mi experiencia laboral reciente. Tengan presente cuál fue su trabajo más desafiante e interesante. Yo me equivoqué y cité una experiencia más del montón que destacable, era otro el proyecto sobre el que  me tuve que explayar.
• Al momento de la parte de preguntas técnicas comenzamos con generalidades. Al respecto, tengan frescos los conceptos de OOP, UML y estructuras de datos. Yo me enredé innecesariamente al intentar definir conceptos básicos. Afortunadamente Mohan (mi entrevistador) supo interpretar mi enredo y, quizás sin intención, guiarme hacia la respuesta correcta. No teman dar ejemplos, pero procuren que sean los ejemplos adecuados.
• Luego prosigueron las preguntas relativas a patrones de diseño. Mohan me preguntó sobre que patrones me resultaban familiares y cuales había utilizado recientemente. Esta fue la pregunta trampa. Mencioné conocer y haber trabajado con los patrones Singleton, Proxy, Command, MVC, y entre esos haber utilizado más recientemente el Singleton.
  Aquí pueden perderse o coronarse. Me hizo implementar el patrón Singleton, y aún bajo las traiciones de mi memoria, y muchos alcances de errores que me mencionó detectar, lo logré sacar. Ojo el patrón Singleton, así de paquete no es "thread safe" (i.e. múltiples threads llamando la clase en el mismo instante exacto no aseguran que el singleton funcione como es esperado), por lo que hay que sincronizarlo. Esto también fue parte de la entrevista. Yo no recordé la sintaxis de como sincronizar la llamada.
• Finalmente la parte técnica terminó con una pregunta tipo, y digo tipo porque recuerdo haberla visto en varios otros lados:
  

  Se tiene un archivo con líneas de texto con una palabra por línea. cada palabra puede ser un anagrama de otra, vale decir esta compuesta por las mismas letras que otra palabra pero en distinto orden. Ejemplos:
  { opt, pot, top }, { apt, tap, pat }, { casa, saca }
  Se pide determinar que grupos de palabras son anagramas entre si.

Esta pregunta clásica la razoné de la siguiente manera:

1. Agrupar las palabras según su largo (en caracteres) ya que entre palabras de igual longitud existe mayor probabilidad que sean anagramas entre ellas.
2. Recorrer este nuevo listado agrupado haciendo un chequeo de equivalencia para cada nueva palabra rescatada. Aquí mi idea apuntó hacia un "hashmap de múltiples llaves" (ERROR garrafal, eso no es un hashmap, y si lo fuera no es eficiente). Mohan me perdonó lo de las múltiples llaves, señalándome que efectivamente la cosa iba por un hashmap, y me dió como "hint" que ordenara las palabras. En un principio pense en ordenar todas las palabras, pero eso no tenía mucho sentido, hasta que ejemplificó:

• apt ordenado (alfabéticamente) es apt
• tap ordenado (alfabéticamente) es apt
• pat ordenado (alfabéticamente) es apt

Entonces la solución salta a la vista, hashmap donde la llave es la palabra ordenada.

Nuevamente me traicionaron la ansiedad, los nervios y el tiempo. Resolví el problema en seudocódigo, y finalmente me dijo si tenía preguntas. lo único que atiné a preguntar fue "¿Cómo es trabajar en Amazon? ¿es como resolver estos tests?" A lo que respondió que si, efectivamente su trabajo a diario es optimizar los procesos de  Amazon  sobretodo los procesos de distribución de paquetes para resolver los envíos minimizando costos tanto para clientes como para la empresa.

Cosas que rescato, y voy a repetir mucho de lo que mencioné más arriba:

• Asegúrense de establecer un canal de comunicación confiable, NUNCA por teléfono móvil.
• Tengan presente cuál fue su trabajo más desafiante e interesante.
• Tengan frescos los conceptos de OOP, UML y estructuras de datos.
• Tengan frescas las implementaciones de patrones de diseño simple (o en su defecto algún cheat sheet a mano).
• No tengan miedo a preguntar.
• Siempre seguros de lo que están diciendo, incluso al reconocer que no saben.

Consideren que la persona que los va a entrevistar tiene un nivel técnico muy alto, así que no le van a poder mentir sin que se de cuenta, muy acorde a los estándares de la empresa.
 Amazon exige profesionales de un nivel técnico MUY alto, con fuerte dominio en patrones de diseño y algoritmos, y sobretodo en algoritmos. No basta saber un poco de todo, o ser un especialista en determinada tecnología (sea herramienta, lenguaje de programación o arquitectura). Las pruebas DEMANDAN preparación A CONCIENCIA.
Y esto es porque el nivel de empresa que ha alcanzado Amazon, EXIGE excelencia, y la única forma de mantener ese nivel es con PROFESIONALES DE 1er NIVEL.

No es la típica entrevista donde con suerte sabes que te pueden preguntar. Todo está disponible para que puedas prepararte de la mejor manera:

• Cargo al que postulas, o la base desde la que te van a medir.
• Amazon Values que es básicamente lo que esperan de ti (en términos no técnicos)
• Pauta de preparación con la que uno debiera estudiar
• Recomendaciones generales para la entrevista

Yo no soy un tipo que "se peine" con algoritmos, mi fuerte ha sido resolver el día a día y tratar de hacerlo de la mejor manera. Por eso me siento honrado que una empresa como  Amazon me haya dado una oportunidad y haya destinado una hora de sus valiosos recursos en entrevistarme.

Como dijo un colega "El NO ya lo tienes", así que nada se perdía con intentarlo. Ustedes ya tienen más información de como enfrentar a este monstruo.

Nota a Mayo de 2020: Sí, estoy claro que pasados 7 años muchas cosas han cambiado. Sin embargo no puedo no dejar este enlace con ciertas apreciaciones que como joven desarrollador no investigué en su oportunidad. Lo feo de trabajar como desarrollador en Amazon: https://gist.github.com/bricker/cb811b3b86d767124801 Simplemente léanlo.

Pauta de preparación para pruebas técnicas de Amazon

Estas es la pauta de preparación que te hace llegar Amazon cuando postulas. Básicamente es lo que se espera uno debiera preparar.
¿Saben de otra empresa qué haga lo mismo? Yo no, y he hablado con muchas empresas. Este es el tipo de cosas que marca la diferencia entre las grandes empresas y el resto.

Work hard. Have fun. Make history.

Amazon.com/Careers

Thank you for the interest in Amazon.com and taking the time to speak with us about some of the exciting opportunities that we have available.  We’ve put this document together to help give you an idea of what types of knowledge we expect some level of familiarity with.

Preparing for Your Interview

At Amazon.com we’re looking for talented engineers that can apply the knowledge that they’ve learned in school and in industry to solving some of the world’s most complicated software problems.  As such, our interviews are mainly focused on how well you can use your acquired knowledge to solve real world (or in some cases not so real world) problems.  Below is a list of broad areas that we expect people to be familiar with.  It’s certainly not required that you memorize all of the information outlined below, but this should serve as a helpful reference guide for the types of things you might want to brush up on before interviewing with Amazon.com.

Programming Languages

We do not require that you know any specific language before interviewing for a technical position at Amazon.com, but familiarity with a prominent object oriented language is generally a prerequisite for success.  Not only should you be familiar with the syntax of a language like C++, Java, or C#, you should also know some of the language nuances such as how memory management works, what some of the most commonly used collections or libraries are, etc.  You should be able to compare languages and talk about the tradeoffs between using language X vs. language Y.

Additionally, it’s considered a plus to be familiar with some scripting language such as perl, ruby, awk, etc.  It’s also nice to know the basics of regular expression as they are now a mainstay in both the object oriented and scripting worlds.

Data Structures

Most of the work we do involves storing and providing access to data in efficient ways.  This necessitates a very strong background in standard data structures.  You should know what each of these data structures is and how they’re implemented; what their runtimes are for common operations; and under what circumstances it would be beneficial to use one.  The below are in no particular order.

Array

Linked List

Tree (Tree, Binary Tree, Binary Search Tree, Red-Black Tree, etc.)

Heap

Hash Table

Stack

Queue

Trie

Graph (both directed and undirected)

Algorithms

It’s also important to know efficient ways manipulate data.  One great way of doing this is brushing up on some common algorithms.  We’ll expect that you can apply and discuss the tradeoffs between some commonly used algorithms.

Sorting

Bubble Sort

Merge Sort

Quick Sort

Radix/Bucket Sort

Traversals (On multiple data structures)

                Depth First Search

                Breadth First Search

Coding

Expect to be asked to code syntactically correct code – no pseudo code.  If you’re a bit rusty coding without an IDE or coding in a specific language, it’s probably a good idea to dust off the cobwebs and get comfortable coding with pen and paper.  The most important thing a software engineer does at Amazon.com is write scalable, stable, robust, and well tested code.  These are going to be the main criteria by which your code will be evaluated, so make sure that you check for edge cases and common error inputs as well as the “happy paths” through the code.

Object Oriented Design

Good design is paramount to extensible, bug free, and long living code.  It’s possible to solve a software problem in an almost limitless number of ways, but when software needs to be robust and extensible, it’s important to know some common techniques that help with this.  Using object oriented design best practices is one way to build lasting software.  You should have a working knowledge of a few common and useful design patterns (singleton, factory, adapter, bridge, visitor, command, proxy, observer, etc.) as well as know how to write software in an object oriented way with appropriate use of inheritance and aggregation.

Databases

Most of the software that we write is backed by a database somewhere.  A lot of the challenges we face come in to play when interfacing with existing data models and when designing new data models.  You should know the basics of how relational databases work, how to design relational database schemas, as well as how to write basic SQL queries against a database.

Distributed Computing

Our systems at Amazon.com usually have to work under very strict tolerances at high load.  While we have some internal tools that help us with scaling it’s important to have an understanding of a few basic distributed computing concepts.  Having an understanding of topics such as map-reduce, service oriented architectures, distributed caching, load balancing, etc. will help you in formulating answers to some of the more complicated distributed architecture questions you might encounter.

Internet Topics

This is Amazon.com, we’re an online company and we expect our engineers to be familiar with, at least, the basics of how the internet works.  You might want to brush up on how internet browsers do what they do, DNS lookups, what TCP/IP and HTTP are, sockets, etc.  We’re not looking for network engineering types of qualifications, but a solid understanding of the fundamentals of how the web works is a requirement.

Operating Systems

You won’t need to know how to build your own operating system, but you should be familiar with some OS topics that can affect code performance, such as memory management, processes, threads, synchronization, paging, multithreading, deadlocks (causes, detection, avoidance).

Nota a Mayo de 2020: Sí, estoy claro que pasados 7 años muchas cosas han cambiado. Sin embargo no puedo no dejar este enlace con ciertas apreciaciones que como joven desarrollador no investigué en su oportunidad. Lo feo de trabajar como desarrollador en Amazon: https://gist.github.com/bricker/cb811b3b86d767124801 Simplemente léanlo.