Lo mas tarde que puedas.
Explico por qué en el siguiente artículo
Continuar leyendo «¿Cuándo debería aprender design patterns?»Lo mas tarde que puedas.
Explico por qué en el siguiente artículo
Continuar leyendo «¿Cuándo debería aprender design patterns?»Si el junior está en la empresa es para producir ganancias para la empresa. O sea que mi rol como senior, es lograr que el junior tome ownership del proyecto rápido. Y es posible que cuando el junior de cierto grado de satisfacción al cliente, el management de la empresa desasigne al senior de la tarea de darle apoyo a ese junior aun cuando los conceptos no los tenga claros y sea una bomba de tiempo.
Igualmente, no me parece descabellado el dejarle de dar apoyo (eso es lo que lo transforma en semisenior – Cuando ya se empiezan a fastidiar cuando les tratas de explicar).
Hoy los frameworks suben su nivel de abstraccion y cada vez todo (incluso los Senior) entendemos menos lo que está pasando detrás, salvo cuando ocurre un problema y hay que diagnosticar. Pero el 80 % de las cosas las hacemos con recursos que tanto a los técnicos como a los comerciales les gusta decir que la tecnología los resuelve con «magia»… haciendo referencia a que está debajo del nivel de abstracción que la herramienta nos provee.
Por otra parte… si le explico al junior algo que no me preguntó o que no necesita para un entregable… es más probable que no me escuche… y que esté repasando mentalmente la agenda del fin de semana mientras asiente cada 28 segundos.
Por lo tanto … creo que sólo los juniors que tengan interés propio buscarán los conceptos y los descubrirán por sí mismos cuando el zapato les apriete, y los que no progresarán mucho más saltando de empresa en empresa… hasta conseguir algún puesto de gestión donde se sentirán más cómodos si están más perdidos con lo técnico.
Quiero siempre recordar que «nadie nos paga por programar sino por producir entregables».
Para mi opinión lo mejor que puedes hacer después de aprender lo básico es ir a una plataforma de trabajo como Upwork y buscar trabajos en tu lenguaje de programación y tratar de encontrar trabajos que te parecen que te gustaría hacer.
Continuar leyendo «¿Qué debo aprender después de lo básico en programación?»Hay una falacia en esta pregunta. Dado que no es preciso que un programador «escriba» sólo 30 o 50 líneas de código por día. Supongamos que sean 30.
Esto es como evaluar a un cientifico que descubre una fórmula por la cantidad de mililitros que manipula comparado con los litros que un albañil puede llevar en un balde.
Una respuesta diferente a la que muchos presentan.
Si te fijas a quién puede interesarle tu seniority, sabrás lo que es un experto.
Antes de empezar quiero mencionar que es una falacia medir la experiencia en años realizando un trabajo. Podríamos decir que en algunos casos los años son una condición necesaria pero no suficiente… otorgando la mayor importancia al paso del tiempo. Pero no le podemos asignar en términos reales más que eso.
En este artículo presento «una» razón, No «LA» razón pero creo que es una de las más válidas e influyentes a la hora de decidir.
Igualmente, el pifiarle en las estimaciones, por la edad, el orgullo, la autoestima y la inexperiencia creo que es la base económica de muchas consultoras, dado que le hacen estimar a los desarrolladores, saben que estiman mal, y después los tienen corriendo vez tras vez para cumplir.
Además de las mencionadas, quisiera mencionar 2 extremos, que por ser comunes pasan a ser promedio.