Archivo de la etiqueta: carrera

8 verdades que aprendí cuando me despidieron de un trabajo como Software Engineer

Steve Buccini, escribiendo en su blog:

La única cosa que deseaba más que nada después de que me corrieran, incluso más que cualquier otro trabajo, era que alguien levantara la mano y hablara en términos simples, honestamente y con toda franquesa. Ese es mi objetivo con esta pieza.

Que te corran de un trabajo es un evento importante en tu carrera profesional. Casi me atrevería a decir que es un rito de paso. Irónicamente, poco se habla de esto en la industria.

Steve comparte 8 cosas que aprendió de la experiencia:

  1. Que te corran es una experiencia profundamente solitaria
  2. Va a tomar más de lo que piensas
  3. La cantidad de entrevistas que tienes no son necesariamente un reflejo de qué tan deseable eres como profesional
  4. Tendrás que hacer cosas que no quieres hacer
  5. La mayoría de los ofrecimientos para ayudarte son respuestas reflexivas
  6. La honestidad solamente te puede perjudicar
  7. Probablemente, deberías de rechazar esa oferta de trabajo
  8. Aprenderás más de que te corran que de lo que hiciste en tu trabajo

Si te tomas el tiempo de leer la pieza completa, probablemente estés de acuerdo conmigo: hay algunos dejos de resentimiento y frustración en el lenguaje. Me gustaría que tomaras esto en consideración si es que decides tomar estos aprendizajes de corazón.

Resalto el aprendizaje número 8 de Steve: Aprenderás más de que te corran que de lo que hiciste en el trabajo. Comenta:

Después de que me corrieran, mi principal emoción era una de alivio. No me lo esperaba. Estaba en aprietos: COVID estaba con toda la fuerza y ya no tenía seguro, el mercado de valores estaba cayéndose y tenía poco efectivo, vivía fuera de mi país y estaban cerrando las fronteras. ¿Por qué sentiría alivio? Porque sabía que no me gustaba mi trabajo, pero no tenía el valor de renunciar para cuando la pandemia llegó. Me hicieron un favor al aventarme por la borda.

Mi deseo es que, como Steve, tú eventualmente aprendas que detenerte a preguntarte qué es lo que realmente quieres, y actuar por ello, no es un acto de egoísmo, sino de valentía. Solo espero que no te tengan que correr para que lo entiendas.

¿Cómo le hacen los que no pueden usar Git en su trabajo?

Un usuario de Reddit escribe:

Esta mañana, gasté 3 horas reescribiendo lo que hice ayer, porque mi compañero lo eliminó accidentalmente en la carpeta de Windows Server que usamos para desarrollar. No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git. ¿Alguno de ustedes ha trabajado en algún lugar así y encontrado una manera de sobrellevarlo?

Obviamente, las respuestas recomendándole que huyera de ahí lo más rápido posible no se hicieron esperar.

Hace casi 22 años, Joel Spolsky publicó en su blog su popular checklist para determinar si un equipo de desarrollo de software es bueno o no: 12 Pasos Hacia Mejor Código. La primera pregunta es: ¿Tu equipo usa manejador de versiones?

Aunque es fácil caer en la tentación de burlarse del creador del hilo en Reddit, me gustaría reflexionar sobre su situación.

Recordando que muchas personas crecimos con la idealización del trabajo duro, no es difícil ver cómo esa forma de pensar podría llevarnos a la progresión lógica de que cualquier cosa que le haga al programador la vida más fácil significaría que entonces la empresa no lo está aprovechando al máximo. Estoy seguro de que podrás identificar alguna persona en tu vida (probablemente alguien mayor, o “de la vieja guardia”) que defendería esta retórica. “Los programadores de verdad compilan su propio IDE.” Esto es lo que pasa cuando personas con esta mentalidad dirigen empresas.

(Dándoles el beneficio de la duda: es probable que esta persona esté trabajando en una industria donde únicamente se pueden utilizar tecnologías aprobadas y validadas por algún tipo de organismo o estándar. En este caso, entendería que, por regulación, no estuviera permitido que usaran tecnologías de código abierto.)

Por otro lado, es probable que el autor original del hilo simplemente se encuentre rodeado de gente que ignora la existencia de los controladores de versiones, así como sus beneficios. Un par de veces en mi vida me he encontrado con personas que encuentran abrumadora la idea de tener que aprender otra tecnología (Git) además del lenguaje de programación en el que están especializándose. Así que simplemente hacen lo que pueden con lo que saben: ponen su código en Dropbox, Google Drive, y listo. No es hasta que salen problemas que el valor de usar controladores de versiones se vuelve aparente.

La parte clave de su mensaje es esta:

No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git.

Apostaría que la persona que escribió esto encaja en el siguiente perfil: alguien joven, al inicio de su carrera en software, con grandes aspiraciones, en su primer trabajo formal. Probablemente, la empresa sea de una industria vieja (finanzas, construcción, legales, donde las cosas se hacen por regulación) que se está intentando renovar, y lo están haciendo contratando programadores, pero sin crear una cultura de desarrollo de software.

No conozco al autor del hilo, pero no me sorprendería si tuviera una carrera próspera en su futuro. Después de todo, está demostrando una capacidad que (desafortunadamente) no todos tienen: la de cuestionar el statu quo. No se está quejando, está haciendo una pregunta para educarse y crecer. Está buscando datos, consejos y soluciones.

Algunas lecciones que me gustaría que todos nos lleváramos de esta experiencia:

  1. No en todas las empresas se puede desarrollar software. Ve esta porción de una de mis charlas para entender más sobre esto.
  2. Algunas empresas solamente quieren programadores, no desarrolladores.
  3. Desarrollar software es mucho más que escribir código.
  4. Se vale preguntar, cuestionar y decidir si la situación en la que estás es en la que quieres estar.

El nombre que le pones a las cosas sí importa

“En las ciencias de la computación, hay únicamente dos problemas difíciles de responder: la invalidación de un caché, y cómo nombrar cosas.” — Phil Karlton

La cultura del Internet después modificó este refrán para incluir errores de enumeración de índices, pero esa es otra historia.

La realidad es que Phil tenía mucha razón: decidir cómo nombrar las entidades que manipulamos al programar es una de las tareas más difíciles de nuestra profesión. No por nada es tan común ver variables, métodos, clases, funciones, o cualquier otro elemento de programas, con nombres genéricos, como x, builder o manager.

Algunos argumentan que invertir tiempo en nombrar los componentes de un programa de manera coherente es una pérdida de tiempo. Las veces que he participado en discusiones donde se intenta impulsar la idea de que alguien debería poder diferenciar una variable X de otra simplemente por el nivel de sangría del código son demasiadas. Creo que desafortunadamente esto es otra muestra de lo inusual que es el sentido de compasión en la industria de la tecnología.

Al igual que agregar documentación completa a tus proyectos, usar nombres descriptivos y semánticamente correctos es un acto de compasión.

El lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día. Al compilador no le importa el nombre de tu variable, pero a la persona que va a leer y contribuir a tu código sí. Y como siempre, es importante recalcar que esa persona puedes ser tú mismo, años después.

Utilizar nombres descriptivos y semánticamente correctos para los componentes de tu programa no solamente hace más accesible la lectura de tu código. También te ayuda a razonar mejor sobre la solución que estás implementando. En algunos casos, hasta te podría salvar, potencialmente, de introducir vulnerabilidades de seguridad críticas.

Conforme he ganado experiencia colaborando en esta industria, he encontrado una relación, casi directa, entre el nivel de atención a la nomenclatura y semántica de los componentes de un programa y su fiabilidad.

Después de todo, me pregunto: si no te tomaste el tiempo de nombrar algo de una manera correcta y con sentido, ¿realmente habrás entendido el problema que estás intentando resolver?

Razones comunes para que los desarrolladores busquen nuevos empleos

StackOverflow compartió en su blog los resultados de una encuesta que aplicaron a 500 desarrolladores de software. La idea era encontrar los factores que  actualmente están jugando un papel importante en el mercado laboral de desarrolladores.

Las respuestas podrían parecer obvias para cualquier persona que trabaje en el medio. Sin embargo, creo que es buena idea analizarlas un poco más allá simplemente compartir el número de personas que prefieren tal cosa en lugar de otra.

Los resultados

Why are you looking for, or open to, a new job? 65% Better salary/pa, 39% wanting to work with new technologies, 36% Better work /life balance, 35% Growth or leadership opportunities

Para buscar nuevas oportunidades, 65 % lo hacen por un incremento de salario. Esto no debería de sorprenderle a nadie. En los últimos meses, sobre todo, se ha visto un incremento sustancial en la inflación de los salarios para personas que trabajamos en software. Hay varios factores que podrían estar influyendo en esto: la pandemia, la devaluación de la moneda, que cada vez hay empresas con más recursos para “quemar”.

Al momento de considerar empresas para unirse, el 56 % quieren que la empresa le ponga atención al developer experienceEste dato sí me sorprendió, pero tiene sentido. Conforme los retos se van haciendo más complejos y los equipos se van haciendo más distribuidos, lo que quieren los desarrolladores es que las empresas realmente inviertan en la infraestructura para soportar sus esfuerzos.

Hace unos años, la discusión sobre el developer experience era relativamente sencilla, porque había un alto grado de probabilidades de que los problemas se mitigaran simplemente eligiendo el cliente de git adecuado para el equipo. Hoy en día, los desarrolladores esperan que haya una infraestructura para colaborar, empujar código a producción, resolver conflictos, recabar datos, y más. Y no solo eso, sino que esperan que haya un equipo encargado de soportar dicha infraestructura.

Aquellas empresas que reparen en invertir en mejorar y facilitar el trabajo de los desarrolladores la van a tener muy difícil contratando reteniendo talento.

Lo que hace que una empresa sea poco atractiva tiene que ver con el nivel de micromanagement de la organización. Me sorprendió conocer que hay algunas organizaciones prohíben a sus desarrolladores usar Stack Overflow. Fuera de eso, la mayoría de los desarrolladores están de acuerdo en que lo que quieren es que la cultura de la empresa no esté basada en el control y la desconfianza.

También me sorprendió la tercera razón más popular que hace que una empresa no sea atractiva para un desarrollador: que no tengan los recursos para darle confianza en su trabajo. ¿A qué se refiere esto? Algunas ideas:

  • Que no haya un proceso de retroalimentación establecido
  • Opacidad en el proceso de toma de decisiones
  • Una estructura organizacional demasiado plana
  • Y, retomando el punto anterior, indiferencia por el developer experience

La reputación de la empresa es primordial para el descubrimiento inicial de oportunidades. De acuerdo con los resultados de la encuesta, 47 % de los desarrolladores toman más en serio las recomendaciones de oportunidades que vienen de su red personal (familiares y amigos) que cualquier otro medio. Hace poco escribí sobre este fenómeno:

Es mucho más importante, para tu desarrollo profesional y tu superación personal, estar con las personas correctas, que en la compañía con el nombre más conocido.

Bien dicen que la publicidad de boca en boca es la más efectiva.

Conclusiones

El mercado laboral está más “caliente” que nunca. Y veo que muchas de las conversaciones al rededor del tema se enfocan en cómo se puede hacer para contratar más personas, pero lo que leo entre líneas de estas respuestas es que deberíamos estar hablando mucho, mucho más de cómo retener el talento que ya tenemos en nuestras compañías.

Si pudiera hacer sugerencias accionables para 1) retener al talento que tienes y 2) hacer tu compañía más atractiva para otros desarrolladores, te diría, en orden de importancia:

  • Invierte en facilitar el trabajo de tu equipo. Desarrolla infraestructura que ayude a que tus desarrolladores se puedan enfocar más en el qué, y no el cómo de hacer su trabajo. Pule los procesos de desarrollo, despliegue y revisión de código. Establece procesos claros par resolver conflictos.
  • Mejora tu cultura de colaboración. Promueve el dar y recibir feedback de manera orgánica y constante. Asegúrate de que los desarrolladores tienen la visibilidad necesaria para tomar decisiones y hacerse responsables de sus acciones. Empodera a tu equipo.
  • Hazlos sentir orgullosos de trabajar en tu compañía. 
  • Súbeles el sueldo. Índice de inflación anual, multiplicado por 2. Al menos.

6 lecciones aprendidas en 6 años trabajando en tecnología

Esta es una traducción de Six lessons from six years in tech.

En 2015, llegué a San Francisco y pensé que había encontrado mi hogar para siempre. Cuatro empresas más tarde (Microsoft, Bain, Snapchat, Faire), ya no creo en un hogar para siempre. Pero sí creo en las lecciones ganadas con esfuerzo.

Aquí hay seis que se destacan. 

Adoración al fundador

Es fácil quedarse deslumbrado cuando conoces a personas detrás de negocios multimillonarios. 

Lo que sigue normalmente es una completa decepción. Los fundadores genios pueden ser excepcionales en algunos aspectos, pero tienden a ser excepcionalmente malos en otros, como administrar personas y realmente preocuparse por ellas. 

Sin embargo, los adoramos como superhéroes. De hecho, cada vez que alguien se hace conocido, intentamos emular todo lo que hace: lo bueno, lo malo y lo horrible.

El equilibrio y el talento extremo rara vez coexisten. En lugar de depender de un genio a quien emular, aprende lo mejor de cada persona con la que trabajas.

El caos es el estado natural de las cosas

Detrás de las escenas de cada empresa idolatrada hay en realidad un desastre que funciona libremente. Las cosas que quieres que se resuelvan, no están ni cerca de ser prioridad. Las personas que esperas que sean eficaces no lo son. Este último es especialmente cierto en las empresas más grandes. ¿Cómo es esto posible?

  1. La mayoría de las empresas funcionan a pesar de sí mismas; en todo caso, ¡es una señal de un modelo de negocio sólido! Cuando muchas cosas salen mal, pero el negocio prosigue, es cuando sabes que has encontrado oro.
  2. Su problema es tu oportunidad; Si resuelves sus problemas más importantes y haces que tu equipo se vea bien, rápidamente te establecerás como un jugador valioso.
  3. En medio de incendios interminables, puede optar por desanimarse o trabajar para descubrir las semillas de nuevas ideas.

La disfunción es el estado natural de las cosas. Te contrataron para mejorar las cosas, aunque sea un poco.

El modelo de negocios determina la cultura

Muéstrame su modelo de negocios y te mostraré su cultura. Cuando leí esto por primera vez, todo hizo clic. Siempre me he preguntado por qué la vida dentro de una empresa es tan diferente de sus valores anunciados. Esa diferencia es el incentivo para hacer crecer el negocio. 

Cuando el modelo de negocio son los anuncios, ninguna misión puede escapar a la gravedad de capturar los ojos a toda costa. Cuando el modelo de negocio consiste en vender nuevos proyectos, los mejores en ventas suben a la cima, incluso si tienen grandes defectos de carácter. Cuando el modelo de negocio es el volumen de transacciones, todos están incentivados para que la gente compre más y repetidamente.

La cultura es derribada por lo que se tolera. Y es extremadamente conveniente tolerar a un idiota cuando tienen una maestría única en hacer crecer el negocio.

La buena noticia es que puedes profundizar en un modelo de negocio antes de comprometerte con una emresa. Investiga.

Cada fortaleza es también una debilidad

Nombra tu mayor fortaleza. Luego lanza una moneda. Si sale cara, tu fuerza te ayuda. Si sale cruz, su fuerza se convierte en un lastre.

¿Suena absurdo? Bueno, ¡sucede en la vida real! El lanzamiento de la moneda es tu ambiente profesional.

Por ejemplo, enfocarse en los detalles es una fortaleza cuando eres un colaborador individual. Pero cuando te distrae del panorama general como gerente, se convierte en un lastre. Incluso la determinación puede ser una responsabilidad cuando se persigue una empresa condenada al fracaso.

Dado que cualquier fuerza puede funcionar en tu contra, he encontrado dos cursos de acción confiables: 

  1. Busca entornos que valoren tus fortalezas y toleren sus responsabilidades 
  2. Modula tus fortalezas con base en tu entorno (esto es mucho más difícil)

El horizonte temporal lo cambia todo

Todo el mundo quiere ganar dinero y tener razón. La pregunta es ¿cuál es tu horizonte de visibilidad en tiempo?

Si son los próximos 2-3 años, es mejor que trabajes en FAANG. Si son los próximos 10 años o más, te va a ir bien si consideras hacerte un jugador valioso en una compañía grande, a largo plazo.

El trabajo duro no es suficiente. Incluso ser “genial” no es suficiente. Lo que se recompensa en un universo de abundancia es lo contrario: la escasez. Ser bueno en cosas que otras personas no son.

Tu ventaja a largo plazo proviene de tener un conjunto único de habilidades y relaciones. Trabajar en FAANG significa que estás entre más de 500.000 personas en el mismo barco. Buen viento en las velas, pero aun así necesitas estar involucrado en el día a día.

¿Cómo se obtienen habilidades y relaciones únicas? Por definición, no hay un camino fijo, pero existen algunos principios atemporales: 

  1. Encuentra lo que es divertido para ti, pero difícil para la mayoría de la gente: tu entusiasmo te mantendrá en el juego y te hará ganar puntos de reconocimiento.
  2. Prueba el muestreo de carreras de alta velocidad desde el principio; esto te brinda una perspectiva inusual sobre lo que las personas necesitan y en lo tú eres bueno. 
  3. Consume y trabaja en cosas que son inusuales para las personas con ty experiencia, creando tu propia pila de talentos

En la escuela, la mayoría de nosotros intentamos jugar el mismo juego que todos los demás, tratando desesperadamente de encajar. En el mundo real, y especialmente en la tecnología, el poder proviene de ser diferente.  

Suerte accidental

La tecnología está llena de suerte accidental. Conozco a varios multimillonarios (de papel). Algunos de ellos trabajaron muy duro, todos ellos estaban en el lugar correcto en el momento correcto. Todos ellos tuvieron ventajas en modelos de negocio increíbles. 

Irónicamente, cuanto más sólido sea el modelo de negocio, menos confrontará las realidades de sus propias habilidades. Un modelo de negocio sólido es como un viento silencioso, pero constante que sopla en tu dirección. Amplifica toda buena decisión y suaviza el golpe de cada mala decisión.

Si bien estas experiencias se ven impresionantes, aprenderás más trabajando en cosas que no funcionan por defecto. Cuando las cosas funcionan mágicamente, es fácil atribuirlo al talento y al trabajo duro. Cuando las cosas no lo hacen, te ves obligado a moverte más rápido, probar más cosas y confrontar suposiciones erróneas.

Los aprendizajes vienen del dolor y reflexión. Desordenado durante el proceso, pero gratificante al final.

Las 4 cosas que haría si estuviera iniciando mi carrera en 2022

Una de las preguntas más recurrentes de mis lectores, sobre todo de los que están llegando a software de otras industrias es: ¿qué harías si estuvieras al inicio de tu carrera?

La he contestado tanto, que mejor decidí crear un recurso gratuito de una vez por todas.


Descárgalo aquí.

Espero que te sirva.

No, no podemos tener una llamada para eso

Después de casi dos años de que el trabajo remoto se volviera la norma, hay algunas organizaciones que siguen intentando simular el trabajo en oficina desde casa.

Es el pan de cada día intentar sacarle la vuelta a las llamadas completamente innecesarias.

Seguramente este video te ayudará a articular mucho mejor el por qué no puedes tener “una llamada rápida” la próxima vez que alguien te lo pida. Por coherencia, el autor también publicó la charla como un artículo que puedes leer en 15 minutos en vez de aventarte 45 minutos de video.

Tip: Todos tenemos diferentes fortalezas y debilidades. Para algunas personas, romper los viejos hábitos de comunicación síncrona es algo tan difícil como respirar bajo el agua. “Old habits die hard”, dijo Mick Jagger. La próxima vez que alguien te pida una llamada para algo que no creas es necesario, recuerda que no lo hace por molestarte. Eduquemos con el ejemplo y con compasión.

Enlace: https://www.youtube.com/watch?v=NVnci3tyDa4

Las dos dimensiones del trabajo, y cómo puedes usarlas a tu favor

Todo trabajo tiene dos dimensiones. Tienes que estar consciente de esto si quieres maximizar tu impacto en cualquiera que sea tu responsabilidad.

  • La dimensión operacional o práctica.
  • La dimensión política o de poder.

Mientras más rápido logres reconciliar este hecho, más sencillo será navegar tu día a día en una organización. Te quiero contar un poco de cada una de estas dimensiones, para que entiendas cómo la puedes usar a tu favor.

Dimensión operacional

Esta dimensión es práctica, porque se enfoca en el “qué”. Te pagan por programar, por diseñar o por enseñar.

Lo más importante en esta dimensión es tu craft: que mejores tu técnica, que desarrolles sistemas de productividad para que tu producción sea mucho más eficiente y prolífica. Lograr identificar qué tipo de música te ayuda a escribir mejor código es un claro ejemplo de esto. Saber que tienes que desayunar para poder concentrarte también.

La mayoría de personas estamos familiarizados con esta dimensión del trabajo porque es la que nos enseñan en las escuelas y los cursos. Los problemas que se presentan en esta dimensión son técnicos y tangibles. Se pueden resolver con un Pull Request, o haciendo una modificación a procesos de la organización.

Dentro del gran esquema de las cosas, los problemas en la dimensión operacional son problemas sencillos por su misma naturaleza práctica. Y aunque esto puede parecer algo positivo, existe un riesgo latente para las personas que únicamente se enfocan en dominar la dimensión operacional de su trabajo: quedarse haciendo lo mismo durante toda su vida.

En esta dimensión, lo que te preocupa es resolver el problema. No importa si par hacerlo necesitas colaborar, aprender una nueva tecnología o hacer algo que no estaba en tu contrato.

Dimensión política

Aquí es donde la cosa se pone buena, porque dejamos de preocuparnos por la exactitud de las soluciones, y nos empezamos a preocupar por cómo tal o cual solución nos hace sentir.

Al contrario de la dimensión práctica, con la política no muchos estamos conscientes de que existe. Desafortunadamente, de esta dimensión se habla poco en las escuelas y cursos, y muchas personas simplemente le ponen la etiqueta de que “así son los trabajos”.

La dimensión política se trata del ego. Si en la dimensión práctica lo más importante es el “qué”, en la dimensión política lo que más importa ese el “cómo” y el “quién”.

Esta dimensión del trabajo es un poco más complicada. Los problemas que se originan son mucho más sutiles de detectar, y no se pueden arreglar con un Pull Request. Me atrevería a decir que todos hemos sentido esa impotencia de no sentirnos reconocidos, y de haber sido humillados por otro miembro de nuestro equipo. ¿Esa vez que te fueron a acusar con tu jefe porque no dejaste de hacer algo para ayudar con algo que no estaba en tus prioridades? Política.

En esta dimensión es más importante el reconocimiento, el poder y el status. Las personas que operan en esta dimensión no es suficiente saber que se llegó a la meta: necesitan saber que se llegó a la meta gracias a ellos. Un miembro de la organización que se enfoca en la política, se convierte en jefe. Alguien que aprende a balancear la política con la operación, se convierte en un líder. Porque sabe que lo más importante es apoyar a su equipo a tener buenos resultados. Y eso puede significa crear espacios para que otras personas puedan tomar las riendas de la situación en algún momento.

Donde convergen las dos: el día a día

Todos los empleos están compuestas por ambas dimensiones. Como todo en extremo, tener un trabajo 100% operativo o 100% político, puede ser algo poco ideal.

El balance que te propongo es el siguiente: busca maneras de nutrir la dimensión práctica de tu trabajo, y busca maneras de mantener tu dimensión política a raya. El esfuerzo por mejorar tu carrera profesional no debería de estar únicamente concentrada en una de las dimensiones de tu trabajo.

  • Si ignoras lo político, corres el riesgo de quedarte estancado en tu carrera.
  • Si ignoras lo práctico, corres el riesgo de avanzar en tu carrera pero sin sustento alguno. Como los políticos que llegan a un cargo público sin tener la más mínima conciencia de las consecuencias de sus decisiones.

Por más que intentes enfocarte únicamente en agregar valor a través de tu trabajo, necesitas tener en cuenta que hay un componente político que tienes que resolver. Hazte consciente de esta realidad, y trabaja para encontrar ese balance que te funcione. Lo demás es detalle de implementación.

Cosas que no te enseñaron en la escuela, pero debes saber para trabajar en la industria del software

A continuación te comparto cosas que no te enseñaron en la escuela, pero que debes de saber si quieres trabajar en la industria del software.

  1. Tú te pones tus propias metas. En la escuela tenías la comodidad de llevar un “plan de estudios”. Sabías lo que seguía en cada paso. Acá afuera nadie va a entregarte un plan de estudios para tu carrera profesional. Tienes que definirlo por ti misma.
  2. No tienes que pedir permisos. ¿Quieres aplicar para un trabajo? ¿Te urge cambiar de tecnología? ¿Te gustaría ganar en dólares y vivir en LATAM? ¿Tu sueño es trabajar para un unicornio? ¿Lo que quieres es pasar más tiempo con tu familia? Date. Nadie te detiene.
  3. Debes de tomar decisiones por tu cuenta. En la escuela te condicionaban a aprender una metodología preestablecida. Salirte del protocolo era castigado. En la vida real tienes que aprender a tomar decisiones y a hacerte responsables de sus consecuencias. Nada más.
  4. Puedes irte en cualquier momento. Tenía un profe que se quejaba de los alumnos diciendo “es que ustedes creen que las cosas van a ser como ustedes quieran”. ¿Y por qué no? Si estás en un trabajo o situación que no te favorece, ¿para qué te quedas? No te pongas la camiseta.
  5. Se espera que sepas colaborar, no que te sepas todos los lenguajes de programación del mundo. Saber más lenguajes de programación solo significa que sabes más lenguajes de programación. Aprende a resolver problemas colaborando — técnicos, de negocio, de usuario.
  6. Saber hacer la pregunta correcta es más importante que ser una enciclopedia de conocimiento. Expandiendo en el punto anterior un poco. “No es la respuesta de StackOverflow, es que sepas lo que tienes que Googlear para encontrarla.”
  7. Programar es un medio para resolver problemas, no un fin. Sí, yo sé que es bien divertido programar. Te aconsejaría que no te clavaras únicamente en eso. Puedes programar toda la vida y no resolver ningún tipo de problema. Y te van a pagar por resolver problemas.
  8. Una solución que es correcta el día de hoy, mañana puede ser considerada ineficiente. Yo creo que en software no hay soluciones “exactas”, sino soluciones “ideales para la situación actual, con el conocimiento que tenemos”.
  9. Existen lenguajes más aptos para resolver ciertos tipos de problemas. Hay desde “lenguaje especializado” que es complicado de aprender, pero te dará soluciones compactas, a “lenguaje genérico” que es fácil de aprender, pero será lejos del ideal para resolver todo.
  10. Mientras más “escalas” de posición, se trata menos del código y más de las personas. Las habilidades más valiosas de alguien considerado “Sr.” son las sociales y de liderazgo. Gente que programe “bien” hay un montón.
  11. Necesitas una red de apoyo. Sí o sí. Rodéate de gente que te quiera ver crecer y que comparta tus principios y valores.
  12. Aprende a valorar tu trabajo. Costo ≠ Valor.  No cobres por el esfuerzo físico que lleva hacer una tarea. Cobra por el valor del problema que estás resolviendo.

Originalmente compartí este hilo en Twitter, donde también puedes seguirme.

Cómo trazar tu futuro en el desarrollo de software y alcanzar tus objetivos

Para las personas que pensamos de manera lógica es tan divertido programar, que tendemos a enfocarnos únicamente en ello.

El prospecto de aprender una nueva tecnología o herramienta es suficiente para que la adrenalina nos mantenga despiertos hasta altas horas de la madrugada. Pero cuidado: no caigas en el shiny new toy syndrome.

Es válido aprender por mera curiosidad. Después de todo, así es como muchos descubren sus verdaderas pasiones. Sin embargo, hay una delgada línea entre explorar ideas con el objetivo de ganar nuevas perspectivas y ser complacientes.

Yo dibujaría esa línea en el punto en que el tiempo que pasas aprendiendo cierta tecnología se convierte en potencial y esfuerzo desperdiciado. Por ejemplo, yo sabía desde un inicio que quería trabajar haciendo iOS de bajo nivel. ¿Me habría servido ponerme a estudiar Kubernetes?

Probablemente sí, para conocer la herramienta y entender las implicaciones. Pero no tanto como para haber buscado una certificación, o invertir tiempo y dinero en un curso para dominarlo.

Para alguien con Cerebro de Programador™ puede resultar bastante complicado ver un poco más allá de la parte práctica y técnica — programar. La idea de definir qué es lo que quieres hacer probablemente te parezca completamente ajena. Y con razón — la industria te ha hecho creer que tu tarea es resolver tickets. No es hasta que te topas con la necesidad de poner los pies en la tierra y decidir qué es lo que realmente quieres hacer, que se comienza a poner interesante.

Aunque no es sencillo, definir para qué quieres aprender tal o cual tecnología es un proceso asequible. Lo único que necesitas es un poco de dedicación, y autocompasión.

La manera más sencilla que te puedo compartir para resolver este problema es que diseñes tu progresión de carrera — y lo hagas lo antes posible.

Para comenzar, plantéate las siguientes preguntas:

  • ¿Qué tipo de problemas te gustaría resolver?
  • ¿En qué industria?
  • ¿Rodeado de qué tipo de personas?

Una vez que tengas tus respuestas, tendrás una estrella norte para seguir. Ahora tu tarea es hacer ingeniería inversa, y buscar las herramientas, experiencias y contactos que necesitarás para llegar a ella.

Haz este ejercicio cada 3 o 5 años.

GitHub Copilot: si solamente sabes programar, tu carrera tiene fecha de caducidad

Hay personas en esta industria que reducen su trabajo a algo meramente mecánico: escribir código.

Lo que uno como desarrollador de software está buscando constantemente es la automatización de tareas mecánicas y manuales. La ironía es que, en sí, programar también es una tarea mecánica y manual. Y como tal, eventualmente también será automatizada.

Hace unos días GitHub presentó Copilot — un servicio que prácticamente programa por ti. Lo único que tienes que hacer es describir a grandes rasgos qué es lo que quieres hacer. Copilot genera el código que tú habrías escrito.

Naturalmente los memes no se hicieron esperar. Tampoco las discusiones sobre si el código que está generando esta herramienta cumple con licencias de distribución adecuadas. Pero muy pocas personas se pusieron a ver lo que acababa de pasar: los soft skills en desarrolladores de software acaba de volverse mucho más valiosos.

La tendencia es clara. La verdadera ventaja competitiva para un desarrollador de software no será la parte técnica, sino las habilidades interpersonales.

Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los “programadores” ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar.

Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc.

Si estás en la industria del software y piensas que tu único trabajo es programar, heads up. Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales.

La falsa seguridad de los desarrolladores de software

Probablemente te llueven ofertas de trabajo en LinkedIn — simplemente por listar el lenguaje de programación de moda como una de tus habilidades. Si es así: cuidado, esa seguridad que sientes es falsa.

Saber más lenguajes, tecnologías y metodologías no significa que tienes mejores prospectos para crecer profesionalmente.

Una trampa común para las personas que van iniciando en desarrollo de software es creer que su valor real en esta industria es el stack de tecnología que dominan. Así como yo, tú probablemente en algún momento sentiste orgullo en decir que desarrollabas X tecnología, y nada más. Pero te tengo que decir algo: el stack tecnológico, por más variado, amplio, profundo y dinámico que sea, es meramente un detalle de implementación. Cualquiera puede aprender cualquier lenguaje de programación, y volverse suficientemente bueno, con suficiente dedicación.

Una carrera profesional, al contrario de un simple trabajo, no se construye de manera lógica, lineal o transaccional.

Todos los carpinteros saben usar martillos, serruchos, sierras. ¿Por qué hay carpinteros más exitosos que otros? ¿Es porque saben usar el martillo mejor con más estilo? ¿O porque agarran el serrucho de una manera muy particular?

El carpintero más exitoso, que se da el lujo de decir con qué clientes sí quiere trabajar; aquel que es reconocido por la manera en que materializa su visión de cómo se debería de ver un mueble, no llegó a esa posición por tener el mejor martillo. Ese carpintero se dio cuenta de que lo que realmente importa (y por lo que le pagaban) era todo lo demás. Entregar a tiempo, cumplir su palabra, saber negociar… no ser el mejor usando una herramienta en particular, sino saber qué herramienta usar para lograr su objetivo.

¿Cuándo fue la última vez que escuchaste alguien en una posición importante en esta industria presentarse listando las tecnologías que dominan? Y aquí estamos muchos, creyendo que llegaremos lejísimos y tendremos una carrera siendo nada más un “Ruby Developer”.

Desarrolladores de Ruby encuentras en todos lados. Un verdadero profesional de la industria que sepa Ruby es algo mucho más raro.

7 razones por las que tu carrera en desarrollo de software no ha despegado

Si estás leyendo esto es probable que te sientas estancado o estancada. Sí, has estado desarrollando software, tal vez profesionalmente, por algún tiempo. Pero ese breakthrough aún no llega.

Aquí hay 7 cosas que estás haciendo, y que te están metiendo el pie sin que te des cuenta.

  1. No tienes bien definido qué quieres hacer, o en quién te quieres convertir. Te gustaría dominar cierta tecnología, pero no tienes claro por qué, ni para qué usarás ese dominio una vez que lo obtengas. Básicamente estás aprendiendo por aprender.
  2. Estás construyendo en aislamiento. Crees que la solución es más importante que el proceso, cuando en realidad en el desarrollo del problema es donde se encuentran los verdaderos aprendizajes. Nada crece en un vacío.
  3. Estás acumulando conocimiento. Le das más valor a aprender cosas nuevas, que a aplicarlas y experimentar. En algún momento tienes que cerrar tus 200 cursos de Platzi y ponerte a resolver problemas reales. goto: 1.
  4. Te quedas con la textura de las discusiones, e ignoras el bigger picture. ¿Qué importa más, si ganó tu propuesta o si la solución acordada impacta de manera positiva al equipo?
  5. Le das demasiada importancia a los detalles de implementación. Sí, es importante el framework que quieres usar, o la arquitectura con la que quieres resolver el problema. Pero nada es más importante que resolver el problema a la mano.
  6. Aún le tienes miedo a tu ego. No quieres fallar en público, le temes a compartir tu proceso, y prefieres llegar con soluciones ya armadas. Crees que la opacidad de tus respuestas es una ventaja, porque te hace esencial. En realidad te hace un punto de fallo dentro del equipo.
  7. Estás aplicando demasiada lógica. Tratas a las personas con la misma frialdad con la que diseñas algoritmos. No es sorpresa que la tengas difícil a la hora de generar capital social.

Haz pequeños ajustes en estas 7 áreas, y verás cómo por arte de magia las oportunidades de crecimiento profesional comienzan a aparecer ante ti.

La diferencia entre el freelancing y el trabajo remoto

Se dice que alguien hace freelancing, o que es contratista, cuando la relación con el cliente tiene fecha de expiración. Se trabaja por proyecto, y puede que al terminar la encomienda actual no se vuelva a trabajar con el cliente.

Se dice que alguien trabaja de manera remota cuando la persona tiene un rol definitivo, de largo plazo, dentro de una organización.

Un freelancer rara vez puede influenciar a la organización, pues se le contrató para un trabajo en particular. Sus contribuciones están acotadas al dominio del problema actual que tiene el cliente.

Sin embargo, una de las implicaciones más importantes de la diferencia entre ser freelancer y un trabajador remoto es realmente cuál es tu trabajo.

Aunque parezca raro, la principal habilidad que un freelancer debe de desarrollar no es aquella por la que lo están contratando. Es la de ponerle precio a sus contribuciones y, aún más importante, la de cobrar.

Aprendiendo a valorar y cobrar por tu trabajo

Un error común que todos cometemos nuestras primeras veces haciendo freelancing es creer que todo va a salir bien. Que entendimos la idea del cliente, y que nos aceptará nuestras soluciones sin ediciones.

Pensamos que la transacción concluirá en tiempo y forma. Cuando la realidad es que cuando tomamos un proyecto de freelancing, es casi seguro que durante la marcha saldrán imprevistos que alterarán el costo, tiempo, o complejidad del proyecto.

Teniendo esto en cuenta, ¿cómo abordar la creación de un presupuesto de un trabajo, en tiempo y dinero?

Recientemente alguien me preguntó esto por correo electrónico. Esta persona acababa de tener su primera experiencia con un proyecto que no salió como esperaba.

¿Qué posibles soluciones u opciones darle al cliente para que salgamos en buenos tratos? Por último, supongo que es casi imposible no caer en este tipo de situaciones, pero ¿habrá una manera de disminuir el riesgo a que sucedan?

La diferencia entre el trabajo remoto y el freelancing es que, en realidad, el trabajo del freelancer es dominar el arte de realizar estimaciones y cobrarle al cliente.

Para bien o para mal, vas a tener que lidiar con muchos proyectos y clientes antes de que te conozcas lo suficiente como para determinar cuál es tu punto justo en cuanto a estimaciones. Desafortunadamente, esta es una habilidad que no puedes aprender en un libro, o experimentar en cabeza ajena. Vas a tener que hacerlo muchas veces hasta que entiendas cuáles son tus límites.

¿Cómo estimar proyectos para clientes?

No hay una solución definitiva para este problema. Por naturaleza, cuando tomas un proyecto nuevo no sabrás con qué te vas a encontrar. Así que, más que pensar en una solución particular para este problema, propongo pensar en términos de un marco de trabajo que puedas usar para lidiar con estas situaciones.

El marco de trabajo que más me ha funcionado, en particular, es el de “ser eficiente comunicando”. Sobrecomunica. No te esperes a la fecha de entrega para avisar que algo no va a estar listo. Da todos los detalles en cuanto los tengas disponibles.

Maneja las expectativas de manera correcta.

Esto te hará parecer mucho más profesional con tus clientes, y te ayudará a ganar una reputación que en el futuro te dará una ventaja competitiva sobre otros contratistas.

Ganando experiencia

Algo que le digo a las personas que trabajan conmigo es “enfócate en el proceso, no en los resultados”. Trabajar en modalidad de freelancing es complejo, y no es para todos. Pero puede ser bastante redituable para aquellas personas que saben cómo navegar sus altibajos. Enfocarte en el proceso, y no en el resultado de un proyecto en particular, te ayudará a aprender más sobre tu práctica, y cómo le puedes sacar más provecho.

En este artículo, Curtis Hebert comparte su experiencia con un freelancer novato. Leerlo te puede ayudar a comprender cómo se ve todo desde el otro lado de la mesa.

Después de todo, si no costara trabajo, la experiencia no se ganaría.

Cómo destacar tu currículum en el mundo del desarrollo de software

Lo he dicho en algunas ocasiones, en mi pódcast y en mis seminarios web: si juegas bien tus cartas, tu currículum solamente lo necesitarás la primera vez que busques empleo. Al inicio de tu carrera.

Aun así, probablemente te verás en la necesidad de mandar un CV, currículum, carta de vida, o como le digas, a una empresa para solicitar empleo. Y por eso te quiero regalar un consejo como alguien que constantemente revisa currículums de candidatos: cuéntame una historia.

Al contarme una historia, tu currículum te hará ver muchísimo más atractivo, y podremos entablar una conversación. Si todo sale bien, te ofreceré un empleo.

Te explico.

No digas lo obvio

Imagina conmigo la siguiente situación: entro a una tienda de deportes porque quiero comprar una bicicleta. ¿Crees que alguien me va a convencer de comprar una bicicleta diciéndome que tiene dos ruedas?

Por supuesto que no.

Sucede exactamente igual con un currículum. Cuando aplicas a una posición que requiere habilidades especiales, y dentro de tu CV solamente listas que sabes esas habilidades, no estás diciendo nada. No me estás llamando la atención. No te estás diferenciando.

¿Qué te hace diferente?

Ahora imagina que el vendedor se toma el tiempo de preguntarme para qué quiero una bicicleta, si ya tengo experiencia, y demás. ¿Qué pasaría si aprovecha esa información? Me ofrecería una bicicleta que me ayudará a cumplir mi meta de hacer ciclismo de montaña. Me contaría cómo el marco de fibra de carbono es más ligero pero más resistente, y por qué eso es bueno para mí. Haría una demostración de por qué el tamaño de la rueda de esta bicicleta en particular me ayudará a cansarme menos.

El vendedor entendió mis necesidades, y creó una historia al rededor de ellas para vender el producto. Jugó bien sus cartas, y el resultado es que yo salí de la tienda con mi bicicleta nueva.

Te invito a cuestionarte si realmente listar que sabes usar Photoshop e Illustrator le agregan valor a tu propuesta como diseñador gráfico. O si decir que sabes hacer balances de cuentas te diferencia como contador.

 

Cómo contar una historia en tu currículum

En mi artículo ¿A los 36 ya soy muy viejo para buscar trabajo en TI?, compartí lo siguiente:

Te aconsejaría tomar nota de cuáles sí son tus habilidades que te distinguen, y aprender a venderlas mejor a empresas que sí busquen lo que tienes que ofrecer.

Regla #1 del marketing: conoce a tu cliente. ?

Es una pena que las escuelas actualmente hagan ver la creación de un currículum como algo burocrático, cuando en realidad es 100 % marketing. Recuerda, el marketing se trata simplemente de vender.

Y la regla #1 del marketing es conocer a tu cliente.

Volvamos al escenario del vendedor de bicicletas. Yo quería comprar una bicicleta para hacer ciclismo de montaña. ¿Crees que habría comprado una bicicleta en esa tienda si me hubieran ofrecido una bicicleta de pista? Obviamente no. Pero el vendedor hizo algo crucial: investigó cuáles eran mis necesidades.

¿Sabes qué es lo que quiere la empresa para la que estás aplicando? Porque por ahí deberías comenzar. Y una vez que sabes por qué están buscando nuevos integrantes para su equipo, puedes comenzar a crear una propuesta de valor adecuada.

En este punto debería de comenzar a hacerte sentido lo que te digo. No simplemente listes tus habilidades. Evita decir cosas obvias. Enfócate en vender tu historia, y responder las siguientes preguntas:

  • ¿En dónde culminan tus habilidades?
  • ¿Cómo las has usado antes?
  • ¿Qué resultados favorables hubo?

Habiendo dicho esto, a continuación te muestro cómo puedes traducir una lista de habilidades en un párrafo que hará que tu currículum sobresalga.

 

  • Proceso creativo: esto es lo que te hace diferente. Tienes un proceso creativo, y gracias a él es que eres tan prolífico con tus contribuciones.
  • Tanto gráfico, como web y de correo: les estás diciendo que tus habilidades de diseño son multidisciplinarias. Implicas que conoces varias herramientas y sabes cómo utilizarlas para su propósito específico.
  • Incrementar sus ventas en un 35 %: esto es lo que ata con moño tu historia. Es por esto que todas tus habilidades son relevantes para la empresa. En este caso, les estás diciendo por qué te deberían contratar. Contigo en el equipo aumentan sus probabilidades de vender más.

El conjunto de esos tres factores, aderezados con datos particulares de tu perfil, es la historia que te va a hacer sobresalir.

Esto es casi una plantilla. Úsala a tu conveniencia.

Notas finales

Recuerda que un buen currículum no hará que te contraten. La idea de un currículum es entablar una conversación. Vender la idea de por qué vale la pena enviarte un correo pidiéndote una llamada. Hacerte parecer lo suficientemente interesante para que cuando te hablen, te pregunten por tu proceso creativo, no por comandos de Photoshop.

Pero sobre todo, ten en cuenta que el mejor currículum no es el que se envía, es el que se demuestra. Como dije al inicio, si juegas bien tus cartas, tus contribuciones, aportaciones, experiencia, y colegas hablarán por ti.

Que tu trabajo sea excelente.