Cómo aprender a programar y obtener un trabajo de desarrollador [Libro completo]

Cómo aprender a programar y conseguir un trabajo de desarrollador [Libro completo]

Si quieres aprender a programar y conseguir un trabajo como desarrollador, estás en el lugar correcto. Este libro te mostrará cómo.

Y sí, este es el libro completo – de forma gratuita – aquí mismo en esta página de freeCodeCamp.

Actualización 20 de octubre de 2023: He grabado una versión de audiolibro COMPLETO y GRATUITO de este libro, que publiqué como episodio #100 de The freeCodeCamp Podcast. Puedes buscarlo en tu reproductor de podcasts favorito. Asegúrate de suscribirte. También lo he incrustado a continuación para tu comodidad.

https://play.libsyn.com/embed/episode/id/28380047/height/192/theme/modern/size/large/thumbnail/yes/custom-color/2a4061/time-start/00:00:00/playlist-height/200/direction/backward/download/yes

Hace unos años, una de las 5 editoriales más importantes de Nueva York se puso en contacto conmigo para un trato de libro. Me reuní con ellos, pero no tenía tiempo para escribir un libro.

Bueno, finalmente tuve tiempo. Y decidí simplemente publicar este libro de forma gratuita, aquí mismo en freeCodeCamp.

La información quiere ser libre, ¿verdad? 🙂

Te llevará algunas horas leer todo esto. Pero esto es todo. Mis ideas sobre cómo aprender a programar y conseguir un trabajo como desarrollador.

Aprendí todo esto mientras:

• aprendía a programar en mis 30
• luego trabajaba como ingeniero de software
• luego dirigía freeCodeCamp.org durante los últimos 8 años. Hoy en día, más de un millón de personas visitan este sitio web cada día para aprender matemáticas, programación e informática.

Era un profesor de inglés que nunca había programado antes. Y fui capaz de aprender suficiente programación para conseguir mi primer trabajo como desarrollador de software en solo un año.

Todo sin gastar dinero en libros o cursos.

(Sí gasté dinero en viajar a ciudades cercanas y participar en eventos tecnológicos. Y como verás más adelante en el libro, ese dinero valió la pena.)

Después de trabajar como ingeniero de software durante algunos años, me sentí preparado. Quería enseñar a otras personas cómo hacer esta transición profesional también.

Construí varias herramientas de educación tecnológica que nadie estaba interesado en usar. Pero luego, un fin de semana, construí freeCodeCamp.org. Rápidamente se formó una comunidad vibrante a su alrededor.

En el camino, todos nos ayudamos mutuamente. Y hoy en día, personas de todo el mundo han utilizado freeCodeCamp para prepararse para su primer trabajo en tecnología.

Puedes estar pensando: No sé si tengo tiempo para leer todo este libro.

No te preocupes. Puedes marcarlo como favorito. Puedes volver a él y leerlo en tantas sesiones como necesites.

Y puedes compartirlo en redes sociales. Compartir: “mira este libro que estoy leyendo” y enlazarlo es una forma sorprendentemente efectiva de convencerte a ti mismo de terminar de leer un libro.

Digo esto porque no estoy tratando de venderte este libro. Ya “compraste” este libro cuando abriste esta página web. Ahora mi objetivo es asegurarte que valdrá la pena invertir tu tiempo en terminar de leer este libro. 😉

Prometo ser respetuoso con tu tiempo. No hay exageraciones ni cosas superfluas aquí, solo consejos directos y prácticos.

Haré todo lo posible para incluir la mayor cantidad de información en cada capítulo de este libro.

Por cierto: ¿dónde está la tabla de contenidos?

Ah. Aquí está:

Tabla de Contenidos

1. Prefacio: ¿Para quién es este libro?
2. Resumen ejecutivo de 500 palabras
3. Capítulo 1: Cómo desarrollar tus habilidades
4. Capítulo 2: Cómo construir tu red de contactos
5. Capítulo 3: Cómo construir tu reputación
6. Capítulo 4: Cómo ser remunerado por programar – Clientes freelance y búsqueda de empleo
7. Capítulo 5: Cómo tener éxito en tu primer trabajo como desarrollador
8. Epílogo: Tú puedes lograrlo

Prefacio: ¿Para quién es este libro?

Este libro es para cualquier persona que esté considerando una carrera en el desarrollo de software.

Si estás buscando una carrera flexible, bien remunerada y que involucre una gran cantidad de resolución creativa de problemas, es posible que el desarrollo de software sea para ti.

Por supuesto, cada uno de nosotros aborda nuestro propio viaje de programación con ciertos recursos: tiempo, dinero y oportunidad.

Tal vez seas mayor y tengas hijos o familiares mayores a tu cargo. Por lo tanto, puedes tener menos tiempo.

O tal vez seas más joven y hayas tenido menos tiempo para acumular ahorros o adquirir habilidades que aumenten tus ingresos. Por lo tanto, puedes tener menos dinero.

Y puede que vivas lejos de las principales ciudades tecnológicas como San Francisco, Berlín, Tokio o Bengaluru.

O tal vez vivas con discapacidades, físicas o mentales. El ageísmo, el racismo y el sexismo son reales. El estatus migratorio puede complicar la búsqueda de empleo. Lo mismo ocurre con los antecedentes penales.

Por lo tanto, puedes tener menos oportunidad.

Aprender a programar y obtener un trabajo como desarrollador va a ser más difícil para algunas personas que para otras. Cada persona aborda este desafío desde su propio punto de partida, con los recursos que tiene a mano.

Pero no importa desde dónde empieces, en términos de tiempo, dinero y oportunidad, haré todo lo posible para darte consejos prácticos.

En otras palabras: no te preocupes, estás en el lugar correcto.

Una nota rápida sobre la terminología

Cuando use nuevos términos, haré todo lo posible por definirlos.

Pero hay algunos términos que utilizaré todo el tiempo.

Usaré las palabras “programación” y “codificación” indistintamente.

Usaré la palabra “aplicación” como se pretendía, como sinónimo de cualquier tipo de aplicación, sin importar si se ejecuta en un teléfono, una computadora portátil, una consola de juegos o un refrigerador. (Lo siento, Steve Jobs. El iPhone no tiene el monopolio de la palabra “app”.)

También utilizaré las palabras “ingeniero de software” y “desarrollador de software” indistintamente.

Puede encontrarse con personas en tecnología que tengan problemas con esto. Como si la ingeniería de software fuera un campo elegante y sofisticado con un legado de varios siglos, como la ingeniería mecánica o la ingeniería civil. Quién sabe, tal vez eso sea cierto para tus nietos. Pero todavía estamos en los primeros días del desarrollo de software como campo.

Solo dejaré esta cita aquí, en caso de que te sientas incómodo llamándote ingeniero de software:

“Si los constructores construyeran edificios de la forma en que los programadores escriben programas, el primer pájaro carpintero que apareciera destruiría la civilización”. – Gerald Weinberg, Programador, Autor y Profesor Universitario

¿Alguien puede aprender a programar?

Sí. Creo que cualquier persona suficientemente motivada puede aprender a programar. Al final del día, aprender a programar es un desafío de motivación, no una cuestión de aptitud.

En las sabanas de África, donde los primeros humanos vivieron durante miles de años antes de expandirse a Europa, Asia y las Américas, ¿había computadoras?

Las habilidades de programación nunca fueron algo que se seleccionara a lo largo de los milenios. Las computadoras como las conocemos (computadoras de escritorio, portátiles, teléfonos inteligentes) surgieron en los años 80, 90 y 00.

Sí, creo que la aptitud juega un papel. Pero al final del día, cualquier persona que quiera convertirse en un desarrollador profesional tendrá que pasar tiempo frente al teclado.

La gran mayoría de las personas que intentan aprender a programar se frustrarán y abandonarán.

Yo ciertamente lo hice. Me frustré y me di por vencido. Varias veces.

Pero al igual que otras personas que eventualmente tuvieron éxito, volví después de unos días y lo intenté de nuevo.

Digo todo esto porque quiero reconocer: aprender a programar y obtener un trabajo como desarrollador es difícil. Y es aún más difícil para algunas personas que para otras, debido a las circunstancias.

No pretendo haber enfrentado una verdadera adversidad al aprender a programar. Sí, tenía más de 30 años y no tenía antecedentes formales en programación o ciencias de la computación. Pero considera esto:

Crecí en una familia de clase media en Estados Unidos, soy estadounidense de cuarta generación y hablo inglés en casa. Fui a la universidad. Mi padre fue a la universidad. Y su padre fue a la universidad. (Sus padres antes que él eran granjeros suecos).

Me beneficié de un tipo de privilegio intergeneracional. Un impulso que algunas familias logran con el tiempo cuando no son desgarradas por la guerra, la hambruna o la esclavitud.

Así que este es mi gran aviso para ti: no soy alguna figura motivacional para impulsarte a superar la adversidad.

Si necesitas inspiración, hay un montón de personas en la comunidad de desarrolladores que han superado adversidades reales. Puedes buscarlas.

No estoy tratando de elevar el campo del desarrollo de software. No voy a pintar cuadros de utopías de ciencia ficción que pueden ocurrir si todos aprenden a programar.

En cambio, simplemente te daré consejos prácticos sobre cómo adquirir estas habilidades. Y cómo puedes conseguir un buen trabajo para mantener a tu familia.

No hay nada de malo en aprender a programar porque quieres un buen trabajo estable.

No hay nada de malo en aprender a programar para iniciar un negocio.

Puede que encuentres personas que digan que debes ser tan apasionado por la programación que sueñes con ello. Que salgas de tu trabajo a tiempo completo y pases todo el fin de semana contribuyendo a proyectos de código abierto.

Conozco personas que son tan apasionadas por la programación. Pero también conozco a muchas personas que, después de terminar una semana de trabajo duro, solo quieren pasar tiempo en la naturaleza o jugar juegos de mesa con amigos.

Las personas generalmente disfrutan haciendo cosas en las que son buenas. Y puedes desarrollar un nivel razonable de pasión por la programación simplemente mejorando en programación.

En resumen: ¿para quién es este libro? Para cualquiera que quiera mejorar en programación y conseguir un trabajo como desarrollador. Eso es todo.

No necesitas autodenominarte “geek”, ser introvertido o un activista ideológicamente impulsado. O cualquiera de esos estereotipos.

Está bien si lo eres. Pero no es necesario.

Así que si eso eres tú, si te tomas en serio aprender a programar lo suficientemente bien como para que te paguen por programar, este libro es para ti.

Y debes comenzar leyendo este resumen rápido del libro y luego leer el resto.

Resumen Ejecutivo de 500 palabras

Aprender a programar es difícil. Conseguir un trabajo como desarrollador de software es aún más difícil. Pero para muchas personas, vale la pena el esfuerzo.

La programación es un campo bien remunerado, intelectualmente desafiante y creativamente gratificante. Hay una clara progresión profesional por delante: desarrollador senior, líder técnico, gerente de ingeniería, CTO y tal vez incluso CEO.

Puedes encontrar trabajo en casi cualquier industria. Aproximadamente dos tercios de los trabajos de desarrollo están fuera de lo que tradicionalmente llamamos “tecnología”: en agricultura, manufactura, gobierno e industrias de servicios como banca y atención médica.

Si te preocupa que tu trabajo pueda ser automatizado antes de que te jubiles, considera esto: la programación es el acto de automatizar cosas. Es decir, por definición, es la última carrera que se automatizará por completo.

La automatización afectará a la programación. Ya lo ha hecho. Durante décadas.

Herramientas de IA generativa como GPT-4 y Copilot pueden ayudarnos a pasar de la Programación Imperativa, donde le dices a las computadoras exactamente qué hacer, a la Programación Declarativa, donde les das objetivos de más alto nivel a las computadoras. En otras palabras: programación al estilo de Star Trek.

Aunque ahora tenemos calculadoras, aún debes aprender matemáticas. Y aunque ahora tenemos herramientas de IA que pueden escribir código, aún debes aprender programación.

¿Te he convencido de que la programación es una carrera para ti?

Genial. Aquí te explico cómo ingresar al campo.

Desarrolla tus habilidades

Necesitas aprender:

• Desarrollo Front-end: HTML, CSS, JavaScript
• Desarrollo Back-end: SQL, Git, Linux y Servidores Web
• Computación Científica: Python y sus muchas bibliotecas

Todas estas son tecnologías maduras, con más de 20 años de antigüedad. Casi con toda seguridad, usarás la mayoría de estas herramientas, sin importar la empresa para la que trabajes.

La mejor manera de aprender estas herramientas es construyendo proyectos. Intenta programar al menos algo todos los días. Si sigues el plan de estudios gratuito de freeCodeCamp de principio a fin, aprenderás todo esto y construirás docenas de proyectos.

Construye tu red de contactos

Gran parte de conseguir un trabajo se basa en quién conoces.

Está bien si eres introvertido, pero debes ampliar tus límites.

Crea cuentas en GitHub, Twitter, LinkedIn y Discord.

Ve a meetups y conferencias tecnológicas. Viaja si es necesario. (La mayor parte de tu presupuesto de “aprender a programar” debería destinarse a viajes y boletos de eventos, no a libros y cursos.)

Saluda a las personas que están solas. Deja que los demás hablen la mayor parte del tiempo y escucha realmente. Recuerda los nombres de las personas.

Agrega personas en LinkedIn, síguelas en Twitter y asiste a las fiestas después de los eventos.

Construye tu reputación.

Comparte breves demostraciones en video de tus proyectos.

Sigue solicitando hablar en conferencias cada vez más grandes.

Pasa tiempo en hackerspaces y ayuda a personas que son aún más nuevas en la programación que tú.

Contribuye a proyectos de código abierto. El trabajo es similar al desarrollo de software profesional.

Construye tus habilidades, red y reputación al mismo tiempo. No te permitas procrastinar en las partes más difíciles.

En lugar de solicitar empleos por la “puerta principal”, utiliza tu red para conseguir entrevistas de trabajo por la “puerta lateral”. Los reclutadores también pueden ayudar.

Continúa haciendo entrevistas hasta que empieces a recibir ofertas de trabajo. Sin embargo, no necesitas aceptar la primera oferta que recibas. Sé paciente.

Tu primer trabajo como desarrollador será el más difícil. Intenta quedarte ahí al menos 2 años y básicamente, gana dinero mientras aprendes.

El verdadero aprendizaje comienza una vez que estás en el trabajo, trabajando junto a un equipo y con grandes bases de código heredadas.

Lo más importante, duerme y haz ejercicio.

Cualquier persona suficientemente motivada puede aprender a programar lo suficientemente bien como para conseguir un empleo como desarrollador.

Es solo una cuestión de qué tan mal lo quieres y cuán persistente puedes ser en la búsqueda de empleo.

Recuerda: tú puedes lograrlo.

Este libro está dedicado a la comunidad global de freeCodeCamp.

Gracias a todos ustedes que han apoyado nuestra organización benéfica y nuestra misión durante los últimos 8 años.

Es a través de su voluntariado y su filantropía que hemos podido ayudar a tantas personas a aprender a programar y obtener su primer trabajo como desarrolladores.

La comunidad ha crecido mucho desde el humilde proyecto de código abierto que lancé por primera vez en 2014. Ahora soy solo una pequeña parte de esta comunidad global.

Es un privilegio seguir aquí, trabajando junto a todos ustedes. Juntos, enfrentamos los problemas fundamentales de nuestro tiempo: acceso a la información, acceso a la educación y acceso a las herramientas que están moldeando el futuro.

Aún estamos en los primeros días. No tengo ilusiones de que todos aprenderán a programar durante mi vida. Pero al igual que la Biblia de Gutenberg aceleró la alfabetización en 1455, podemos continuar acelerando la alfabetización tecnológica a través de recursos gratuitos y abiertos de aprendizaje.

Nuevamente, gracias a todos.

Y gracias especiales a Abbey Rennemeyer por su retroalimentación editorial, y a Estefanía Cassingena Navone por el diseño de la portada del libro.

Y ahora, el libro.

Capítulo 1: Cómo construir tus habilidades

“Cada artista fue primero un principiante.” ― Ralph Waldo Emerson

El camino para aprender a programar es largo.

Para mí, fue uno ambiguo.

Pero no tiene que ser así para ti.

En este capítulo, compartiré algunas estrategias para aprender a programar de la manera más fluida posible.

En primer lugar, permíteme contarte cómo aprendí a programar en 2011.

Luego compartiré lo que aprendí de este proceso.

Te mostraré cómo aprender de manera mucho más eficiente de lo que yo lo hice.

Tiempo de historia: ¿Cómo un maestro en sus treinta aprendió a programar por su cuenta?

Yo era un maestro que dirigía una escuela de inglés. Teníamos alrededor de 100 estudiantes adultos que habían viajado a California desde todo el mundo. Estaban aprendiendo inglés avanzado para poder ingresar a la universidad.

A la mayoría de los maestros de nuestra escuela les encantaba enseñar. Les encantaba pasar tiempo con los estudiantes en la ciudad y ayudarles a mejorar su inglés conversacional.

Lo que a estos maestros no les gustaba era el papeleo: informes de asistencia, informes de calificaciones, papeleo de inmigración.

Quería que nuestros maestros pudieran pasar más tiempo con los estudiantes y menos tiempo encadenados a sus escritorios haciendo papeleo.

Pero, ¿qué sabía yo de computadoras?

¿Programación? ¿No se necesitaba ser inteligente para hacer eso? Apenas podía configurar un router de WiFi. Y era malo en matemáticas.

Bueno, un día simplemente dejé todo eso a un lado y pensé “Sabes qué: voy a intentarlo. ¿Qué tengo que perder?”

Comencé a buscar en Google preguntas como “cómo hacer clic automáticamente en los sitios web” y “cómo importar datos de los sitios web a Excel”.

No me di cuenta en ese momento, pero estaba aprendiendo cómo automatizar flujos de trabajo.

Y así comenzó el aprendizaje. Primero con macros de Excel. Luego con una herramienta llamada AutoHotKey, donde puedes programar tu ratón para que se mueva a ciertas coordenadas de la pantalla, haga clic, copie texto, y luego se mueva a diferentes coordenadas y lo pegue.

Después de unas semanas de experimentar en la oscuridad, descubrí cómo automatizar algunas tareas. Podía abrir una hoja de cálculo de Excel y un sitio web, ejecutar mi script, y luego volver 10 minutos después y la hoja de cálculo estaría completamente poblada.

Era el trabajo de un aficionado. Lo que los desarrolladores llamarían un “hack sucio”. Pero hacía el trabajo.

Usé mis nuevas habilidades de automatización para continuar simplificando la escuela.

Pronto, los profesores apenas tenían que tocar una computadora. Yo estaba haciendo el trabajo de varios profesores, solo con mis habilidades rudimentarias.

Esto tuvo un impacto visible en la escuela. Gran parte de nuestro tiempo se había dedicado al trabajo monótono en la computadora. Y ahora éramos libres.

Los profesores estaban más felices. Pasaban más tiempo con los estudiantes.

Los estudiantes estaban más felices. Le decían a todos sus amigos en su país de origen: “tienes que conocer esta escuela”.

Pronto nos convertimos en una de las escuelas más exitosas de todo el sistema escolar.

Esto me animó aún más. Recuerdo haber pensado: “Tal vez sí pueda aprender a programar”.

Conocía a algunos ingenieros de software de mis noches de juegos de mesa. Tenían formación tradicional, con títulos de Cal Tech, Harvey Mudd y otros famosos programas de ciencias de la computación.

En ese momento, era menos común que las personas de treinta y tantos aprendieran a programar.

Reuní el coraje para compartir mis sueños con algunos de estos amigos.

Quería aprender a programar adecuadamente. Quería poder escribir código para ganarme la vida como ellos. Y tal vez incluso escribir software que pudiera impulsar las escuelas.

Les compartía estos sueños a mis amigos desarrolladores. “Quiero hacer lo que ustedes hacen”.

Pero ellos solo encogían los hombros. Luego decían algo así:

“Bueno, podrías intentarlo. Pero tendrías que beber todo un océano de conocimiento”.

Y: “Es un campo bastante competitivo. ¿Cómo vas a competir con las personas que crecieron programando desde temprana edad?”

Y: “Ya estás bien como profesor. ¿Por qué no te quedas con lo que se te da bien?”

Y eso me desviaba del camino durante algunas semanas. Salía a caminar largamente, buscando respuestas en la noche. Pensaba en mi futuro bajo las estrellas. ¿Estas personas tenían razón? Quiero decir, ellos sabrían, ¿verdad?

Pero cada mañana volvía a mi escritorio. Observaba cómo se ejecutaban mis scripts. Observaba cómo mis informes se compilaban a velocidades sobrehumanas. Observaba cómo mi computadora hacía lo que le pedía.

Una idea me vino a la mente: tal vez estos amigos simplemente trataban de protegerme de desilusiones. Tal vez no conocen a nadie que haya aprendido a programar en sus treinta y tantos. Así que no creen que sea posible.

Es como… durante años, los médicos pensaban que sería imposible que alguien corriera una milla en 4 minutos. Pensaban que el corazón explotaría de correr tan rápido.

Pero luego alguien lo logró. Y su corazón no explotó.

Una vez que Roger Bannister, un estudiante de Oxford de 25 años, rompió esa barrera psicológica, muchas otras personas lo lograron también. Hasta la fecha, más de 1,000 personas han corrido una milla en menos de 4 minutos.

Y no es como si estuviera haciendo algo tan audaz e inédito como correr una milla en 4 minutos aquí. Muchos desarrolladores famosos han logrado enseñarse a programar a lo largo de los años.

Incluso Ada Lovelace se enseñó a sí misma a programar en la década de 1840. Y ella ni siquiera tenía una computadora funcionando. Simplemente entendía cómo funcionaría la computadora de su amigo Charles Babbage en teoría.

Escribió varios de los primeros algoritmos de computadora. Y es ampliamente considerada como la primera programadora de computadoras del mundo. Nadie le enseñó. Porque no había nadie que pudiera enseñarle. Cualquier duda que pudiera haber tenido consigo misma, claramente la superó.

Ahora, no era Ada Lovelace. Solo era un maestro que ya tenía una computadora funcionando, una conexión a Internet decente y la capacidad de buscar en miles de millones de páginas web con Google.

Crackeé mis nudillos y estreché mi mirada. Esto lo iba a lograr.

Atrapado en el Infierno de los Tutoriales

“Si trabajas durante 10 años, ¿obtienes 10 años de experiencia o obtienes 1 año de experiencia 10 veces? Debes reflexionar sobre tus actividades para obtener una experiencia real. Si te comprometes a aprender de forma continua, obtendrás experiencia. Si no lo haces, no importa cuántos años tengas de experiencia.” – Steve McConnell, Ingeniero de Software

Pasé las próximas semanas buscando en Google y haciendo tutoriales aleatorios que encontraba en línea.

Oh mira, un tutorial de Ruby.

Uh-oh, empieza a complicarse. Estoy recibiendo mensajes de error que no se mencionan en el tutorial. Hm… ¿qué está pasando aquí…

Oh mira, un tutorial de Python.

La psicología humana es algo divertida. En el momento en que algo comienza a dificultarse, nos preguntamos: ¿estoy haciendo esto bien?

Tal vez este tutorial está desactualizado. Tal vez su autor no sabía de lo que hablaba. ¿Alguien incluso sigue usando este lenguaje de programación?

Cuando te enfrentas a mensajes de error ambiguos horas después de una sesión de codificación, la hierba en el otro lado empieza a verse mucho más verde.

Me era fácil fingir que había avanzado. Hora de ir a almorzar.

Vería a un amigo en el café. “¿Cómo va tu programación?”, preguntarían.

“Va genial. Ya he codificado 4 horas hoy.”

“Increíble. Me encantaría ver en qué estás trabajando en algún momento.”

“Claro”, diría, sabiendo que no había construido nada. “Pronto”.

Tal vez iría a la biblioteca y sacaría un nuevo libro de JavaScript.

Hay un viejo dicho que dice que comprar libros te da la mejor sensación del mundo. Porque también se siente como si estuvieras comprando el tiempo para leerlos.

Y aquí es precisamente donde me encontré después de unas semanas aprendiendo a programar.

Había leído las primeras 100 páginas de varios libros de programación, pero no había terminado ninguno.

Había escrito las primeras 100 líneas de código de varios tutoriales de programación, pero no había terminado ninguno.

No lo sabía, pero estaba atrapado en un lugar que los desarrolladores llaman cariñosamente “infierno de tutoriales”.

En el infierno de tutoriales saltas de un tutorial a otro, aprendiendo y luego re-aprendiendo las mismas cosas básicas. Pero nunca realmente avanzas más allá de lo fundamental.

Porque ir más allá de lo fundamental? Bueno, eso requiere un trabajo real.

Se Necesita una Comunidad para Formar a un Programador

Aprender a programar absorbía todo mi tiempo libre. Pero no estaba progresando mucho. Ahora podía escribir los caracteres { y * sin mirar el teclado. Pero eso era todo.

Sabía que necesitaba ayuda. Quizás un mentor al estilo de Yoda, que pudiera enseñarme el camino. Sí, si existiera una persona así, seguro que marcaría la diferencia.

Me enteré de un lugar cercano llamado “hackerspace”. Cuando escuché por primera vez el nombre, estaba un poco aprensivo. ¿No hacen cosas ilegales los hackers? Yo era un profesor de inglés al que le gustaba jugar a juegos de mesa. No estaba buscando problemas.

Bueno, llamé al número que aparecía en la lista y hablé con un chico llamado Steve. Nervioso, le pregunté: “Ustedes no hacen nada ilegal, ¿verdad?” Y Steve se rió.

Resulta que la palabra “hack” es lo que él llamaba un término sobrecargado. Sí, “hackear” puede significar ingresar maliciosamente a un sistema de software. Pero “hackear” también puede significar algo más mundano: escribir código de computadora.

Algo puede ser “hacky”, lo que significa que no es una solución elegante. Y sin embargo, puedes tener “un hack ingenioso” – un truco ingenioso para que tu código funcione de manera más eficiente.

En resumen: no tengas miedo del término “hack”.

Yo, por mi parte, apenas uso el término porque es tan confuso. Y creo que recientemente muchos hackerspaces se han dado cuenta de la ambigüedad. Ahora muchos de ellos se llaman “makerspaces”.

Porque eso es de lo que se trata un hackerspace: hacer cosas.

Steve me invitó a visitar el hackerspace el sábado por la tarde. Dijo que varios desarrolladores de la zona estarían allí.

La primera vez que crucé las puertas del Santa Barbara Hackerspace, quedé impresionado.

El lugar olía como a un incendio eléctrico. Sus mesas improvisadas estaban llenas de soldadores, tiras de luces LED, placas de circuito Arduino de aficionados y montones de robots aspiradoras Roomba.

Allí estaba el mismo Steve con el que había hablado por teléfono, y me saludó. Llevaba gafas, el pelo peinado hacia atrás y una barba en forma de perilla. Siempre estaba sonriendo. Y cuando le hacías una pregunta, en lugar de responder rápidamente, asentía y pensaba unos segundos primero.

Steve era un programador apasionado que había estudiado matemáticas y filosofía en la Universidad de California – Santa Barbara. Todavía sentía pasión por esas materias. Pero su verdadera pasión era Python.

Steve encendió el proyector y dio una “charla relámpago” informal. Estaba demostrando una aplicación que había desarrollado que reconocía códigos QR en un video y los reemplazaba por imágenes.

Alguien en la audiencia mostró un código QR en su portátil y lo puso frente a la cámara. La aplicación de Steve reemplazó entonces el código QR por una imagen de una pizza.

Alguien en la audiencia gritó, “¿Puedes hacer que la pizza gire?”

Steve abrió su código en un editor de código llamado Emacs y empezó a hacer cambios en tiempo real. Alternaba entre su editor de código, la línea de comandos y el navegador en el que se ejecutaba la aplicación, actualizando el código sin problemas.

Para mí, esto era magia. No podía creer que Steve hubiera creado esa aplicación en cuestión de horas. Y ahora estaba añadiendo nuevas funcionalidades sobre la marcha, según las solicitudes de la audiencia.

Pensé: “Este tipo es un genio”.

Y esa noche, después de que terminara el evento, él y yo nos quedamos y se lo dije.

Comimos bocadillos juntos. Y le dije: “Podría programar durante toda mi carrera y no ser tan bueno como tú. Estaría encantado si después de 10 años pudiera programar aunque solo la mitad de bien que tú”.

Pero Steve se resistió. Dijo: “No soy nada especial. No te limites. Si sigues programando, podrías superarme fácilmente”.

Ahora, no creí por un segundo las palabras que me dijo. Pero el simple hecho de que lo dijera me dio mariposas en el estómago.

Ahí estaba él: un desarrollador que creía en mí. Me vio, a mí, un profesor cualquiera, la definición misma de un “script kiddie”, y pensó que podría lograrlo.

Steve y yo hablamos hasta altas horas de la noche. Me mostró su ordenador portátil de $200, que incluso según los estándares de 2011 era lamentablemente lento.

“No necesitas un ordenador potente para desarrollar software”, me dijo Steve. “El hardware actual es increíblemente potente. Los ordenadores solo son lentos porque el software abultado que ejecutan los ralentiza. Compra un portátil estándar, borra el disco duro, instala Linux y empieza a programar”.

Tomé nota del modelo del portátil que tenía y pedí exactamente el mismo cuando llegué a casa esa noche.

Después de unos días de depurar mi nuevo ordenador con Stack Overflow, conseguí instalar Ubuntu con éxito. Empecé a aprender a usar el editor de código Emacs. Para el siguiente sábado, ya conocía algunos comandos y estaba listo para presumir de ellos.

Steve asintió en señal de aprobación. Dijo: “Genial. Pero, ¿en qué estás trabajando?”

No entendí lo que quería decir. “Estoy aprendiendo a usar Emacs. Mira esto. Me he aprendido de memoria…”

Pero Steve parecía reflexivo. “Eso está bien, pero necesitas un proyecto. Siempre ten un proyecto. Luego aprende lo que necesitas aprender en el proceso de terminar ese proyecto”.

Además de algunos scripts que había escrito para ayudar a los profesores de mi escuela, nunca había terminado nada. Pero empecé a entender lo que quería decir.

Y me empezó a iluminar. Todo este tiempo había estado atrapado en el infierno de los tutoriales, dando vueltas sin terminar nada.

Steve dijo: “Quiero que construyas un proyecto utilizando HTML5. Y el próximo sábado, quiero que lo presentes en el hackerspace”.

Me quedé horrorizado con sus palabras. Pero me puse recto y dije: “Suena como un plan. Lo haré”.

Nadie Puede Hacer de Ti un Desarrollador Excepto Tú Mismo

“Estoy tratando de liberar tu mente, Neo. Pero solo puedo mostrarte la puerta. Eres tú quien debe atravesarla.” – Morpheus en la película de 1999 The Matrix

A la mañana siguiente, me desperté temprano antes del trabajo y busqué en Google algo como “tutorial de HTML5”. Ya sabía mucho de esto por mi tiempo anterior en el infierno de los tutoriales. Pero en lugar de saltar adelante, simplemente frené y seguí exactamente, escribiendo cada comando.

Normalmente, una vez que terminaba un tutorial, simplemente buscaba otro tutorial. Pero esta vez, empecé a jugar con el código del tutorial. Tenía una idea sencilla para un proyecto. Iba a hacer una página de documentación de HTML5. Y iba a codificarla puramente en HTML5.

Déjame explicarte HTML5 rápidamente. Es simplemente una versión más nueva de HTML, que ha existido desde las primeras páginas web en la década de 1990.

Si un sitio web fuera un cuerpo, HTML sería los huesos. Todo lo demás descansa sobre esos huesos. (Puedes pensar en JavaScript como los músculos y CSS como la piel. Pero volvamos a la historia).

Sabía que en HTML, podías enlazar diferentes partes de la misma página utilizando propiedades de ID. Así que pensé: ¿qué tal si coloco una tabla de contenidos a lo largo del lado izquierdo? Luego, al hacer clic en los diferentes elementos de la izquierda, la página de la derecha se desplazaría hacia abajo para mostrar esos elementos.

En media hora, ya había codificado un prototipo básico.

Pero era hora de ir al trabajo en la escuela. Durante todo el día, solo podía pensar en mi proyecto y en cómo debería terminarlo de la mejor manera.

Corrí a casa, abrí mi laptop y pasé toda la noche codificando.

Copié la documentación oficial (con licencia creative commons) de HTML directamente en mi página, “codificándola” en el HTML.

Luego pasé aproximadamente una hora en CSS, arreglando todo para que se vea bien y utilizando posicionamiento absoluto para mantener la barra lateral en su lugar.

Me aseguré de utilizar tantas de las nuevas etiquetas “semánticas” de HTML5 como pude.

Y ¡boom! Proyecto terminado.

Una ola de logro me invadió. Corrí hacia un campo de fútbol cercano y di vueltas alrededor del campo, celebrando. Lo logré. Terminé un proyecto.

Y decidí en ese mismo momento: a partir de ahora, todo lo que haga será un proyecto. Voy a trabajar hacia algún producto terminado.

Al día siguiente, me acerqué al podio, conecté mi laptop y presenté mi página web de HTML5. Respondí preguntas de los desarrolladores allí sobre HTML5.

A veces me equivocaba y alguien en la audiencia decía: “eso no suena correcto, déjame revisar la documentación”.

La gente no tenía miedo de corregirme. Pero eran educados y solidarios. Ni siquiera se sentía como si me estuvieran corrigiendo, sino como si estuvieran corrigiendo el registro público, para evitar que alguien se vaya con información incorrecta.

No sentí ninguna de la ansiedad que podría haber sentido dando una charla en una reunión de capacitación para profesores.

En cambio, casi sentí que era parte de la audiencia, aprendiendo junto a ellos.

Después de todo, estas herramientas eran nuevas y emergentes. Todos estábamos tratando de entender cómo usarlas juntos.

Después de mi charla, Steve se acercó a mí y dijo: “No está mal”.

Sonreí durante un tiempo incómodamente largo, sin decir nada, simplemente feliz conmigo mismo.

Luego Steve entrecerró los ojos y frunció los labios. Dijo: “Comienza tu próximo proyecto esta noche”.

Lecciones de mi Viaje en la Codificación

Veremos cómo avanza el viaje en la codificación de un joven Quincy en cada uno de los siguientes capítulos. Pero ahora quiero analizar algunas de las lecciones aquí. Y quiero responder algunas de las preguntas que puedas tener.

¿Por qué aprender a codificar es tan difícil?

Aprender cualquier nueva habilidad es difícil. Ya sea driblar una pelota de fútbol, cambiar el aceite de un auto o hablar un nuevo idioma.

Aprender a codificar es difícil por algunas razones particulares. Y algunas de estas son únicas para la codificación.

La primera es que la mayoría de las personas no entienden exactamente qué es la codificación. Bueno, te lo voy a decir.

¿Qué es la codificación?

Codificar es decirle a una computadora qué hacer, de una manera que la computadora pueda entender.

Es eso. Eso es todo lo que realmente es la codificación.

Ahora, no te equivoques. Comunicarse con las computadoras es difícil. Son “tontas” según los estándares humanos. Harán exactamente lo que les digas que hagan. Pero a menos que seas bueno en codificar, probablemente no harán lo que tú quieras que hagan.

Puede que estés pensando: ¿qué pasa con los servidores? ¿Qué pasa con las bases de datos? ¿Qué pasa con las redes?

Al final del día, todo esto está controlado por capas de software. Código. Es código en todo momento. Eventualmente llegas al hardware físico, que mueve los electrones alrededor de las placas de circuito.

En las primeras décadas de la informática, los desarrolladores escribían código que estaba “cerca del metal”: a menudo operaban directamente en el hardware, cambiando bits de 0 a 1 y viceversa.

Pero el desarrollo de software contemporáneo involucra tantas “capas de abstracción”: programas que se ejecutan sobre programas, que solo unas pocas líneas de código JavaScript pueden hacer cosas realmente poderosas.

En los años 60, un “bug” (error) podía ser un insecto que se arrastraba dentro de una computadora del tamaño de una habitación y se quemaba en uno de los circuitos.

Hoy en día, estamos escribiendo código en capas de abstracción por encima del hardware físico.

Eso es programación. Es mucho más fácil de lo que ha sido en el pasado. Y cada año se vuelve más fácil de hacer.

No exagero cuando digo que en unas pocas décadas, programar será tan fácil y común que la mayoría de los jóvenes sabrán cómo hacerlo.

¿Por qué aprender a programar sigue siendo tan difícil después de todos estos años?

Hay tres grandes razones por las que aprender a programar es tan difícil, incluso hoy en día:

1. Las herramientas todavía son primitivas.
2. La mayoría de las personas no son buenas manejando la ambigüedad, y aprender a programar es ambiguo. Las personas se pierden.
3. La mayoría de las personas no son buenas manejando la constante retroalimentación negativa. Y aprender a programar es un mensaje de error tras otro. Las personas se frustran.

Ahora discutiré cada una de estas dificultades con más detalle. Y te daré algunas estrategias prácticas para superar cada una de ellas.

Las herramientas todavía son primitivas

“Computadora. Comenzar nuevo programa. Crear de la siguiente manera. Silla de estación de trabajo. Ahora crear una consola alfanumérica estándar posicionada en la mano izquierda. Ahora una consola de visualización icónica para la mano derecha. Conectar ambas consolas al núcleo de la computadora principal de la Enterprise, utilizando una interfaz de escaneo neural.” – Barclay de Star Trek: The Next Generation, Temporada 4 Episodio 19: “The Nth Degree”

Así es como las personas podrían programar en el futuro. Es un ejemplo de mi programa de televisión de ciencia ficción favorito, Star Trek: The Next Generation.

Todos los personajes de Star Trek pueden programar. Doctores, oficiales de seguridad, pilotos. Incluso el joven Wesley Crusher (interpretado por el actor infantil Wil Wheaton) puede hacer que la computadora de la nave cumpla sus órdenes.

Claro, una de las razones por las que todos pueden programar es que viven en una sociedad post-escasez del siglo XXIV, con acceso a educación gratuita de alta calidad.

Otra razón es que en el futuro, programar será mucho, mucho más fácil. Solo le dices a la computadora exactamente qué hacer y, si eres lo suficientemente preciso, la computadora lo hace.

¿Qué pasa si programar fuera tan fácil como simplemente dar instrucciones a una computadora en inglés simple?

Bueno, ya hemos avanzado significativamente hacia este objetivo. Piensa en nuestras abuelas, corriendo entre computadoras del tamaño de una habitación con montones de tarjetas perforadas.

Solía ser que programar incluso una aplicación simple requería instrucciones meticulosas.

Aquí tienes dos ejemplos de un “Cifrado César”, el clásico proyecto de tarea de ciencias de la computación.

Esto también se conoce como “ROT-13” porque ROTas las letras 13 posiciones hacia adelante. Por ejemplo, A se convierte en N (13 letras después de A), y B se convierte en O (13 letras después de B).

Te mostraré dos ejemplos de este programa.

Primero, aquí está el programa en Lenguaje de Ensamblaje x86:

format 	ELF 	executable 3entry 	start	segmento	legible escribiblebuf	rb	1	segmento	legible ejecutablestart:	mov	eax, 3		; syscall "leer"	mov	ebx, 0		; stdin	mov	ecx, buf	; buffer para leer byte	mov	edx, 1		; len (leer un byte)	int	80h	cmp	eax, 0		; EOF?	jz	exit	xor 	eax, eax	; cargar el carácter leído en eax	mov	al, [buf]	cmp	eax, "A"	; ver si está en ascii a-z o A-Z	jl	print	cmp	eax, "z"	jg	print	cmp	eax, "Z"	jle	rotup	cmp	eax, "a"	jge	rotlow	jmp	printrotup:	sub	eax, "A"-13	; hacer rot 13 para A-Z	cdq	mov	ebx, 26	div	ebx	add	edx, "A"	jmp	rotend	rotlow:	sub	eax, "a"-13	; hacer rot 13 para a-z	cdq	mov	ebx, 26	div	ebx	add	edx, "a"rotend:	mov	[buf], dl	print: 	mov	eax, 4		; syscall write	mov	ebx, 1		; stdout	mov	ecx, buf	; *char	mov	edx, 1		; longitud de la cadena	int	80h	jmp	startexit: 	mov     eax,1		; syscall exit	xor     ebx,ebx		; código de salida	int     80h

Este ejemplo de Lenguaje de Ensamblaje x86 proviene del proyecto Rosetta Code con licencia Creative Commons.

Y aquí está el mismo programa, escrito en Python:

def rot13(texto):    resultado = []    for caracter in texto:        valor_ascii = ord(caracter)        if 'A' <= caracter <= 'Z':            resultado.append(chr((valor_ascii - ord('A') + 13) % 26 + ord('A')))        elif 'a' <= caracter <= 'z':            resultado.append(chr((valor_ascii - ord('a') + 13) % 26 + ord('a')))        else:            resultado.append(caracter)    return ''.join(resultado)if __name__ == "__main__":    texto_entrada = input("Ingrese el texto a codificar/decodificar con ROT-13: ")    print("Texto codificado/decodificado:", rot13(texto_entrada))

Esto es mucho más simple y fácil de leer, ¿verdad?

Este ejemplo de Python viene directamente de GPT-4. Lo incité de la misma manera que el Capitán Picard incitaría a la computadora de la nave en Star Trek.

Esto es exactamente lo que le dije: “Computadora. Nuevo programa. Toma cada letra de la palabra que digo y reemplázala por la letra que aparece 13 posiciones después en el alfabeto inglés. Luego léeme el resultado. La palabra es Banana.”

GPT-4 produjo este código de Python, y luego me leyó el resultado: “Onanan”.

Lo que estamos haciendo aquí se llama Programación Declarativa. Estamos declarando “computadora, debes hacer esto”. Y la computadora es lo suficientemente inteligente como para entender nuestras instrucciones y ejecutarlas.

Ahora, el estilo de codificación que la mayoría de los desarrolladores utilizan hoy en día es la Programación Imperativa. Le estamos diciendo a la computadora exactamente qué hacer, paso a paso. Porque históricamente, las computadoras han sido bastante tontas. Así que hemos tenido que ayudarles a dar un paso tras otro.

El campo del desarrollo de software aún no está maduro.

Pero al igual que las herramientas humanas tempranas avanzaron, desde la piedra hasta el bronce y el hierro, lo mismo está sucediendo con las herramientas de software. Y mucho más rápido.

Probablemente todavía estemos en la edad de bronce de la programación en este momento. Pero es posible que lleguemos a la edad de hierro en nuestra vida. Las herramientas de inteligencia artificial generativas como GPT se están volviendo rápidamente más poderosas y confiables.

La comunidad de desarrolladores aún está dividida sobre qué tan útiles serán las herramientas como GPT para el desarrollo de software.

Por un lado, tienes a los influenciadores empresariales “conviértete en tu propio jefe” que dicen cosas como: “Ya no necesitas aprender a programar. ChatGPT puede escribir todo tu código por ti. Solo necesitas una idea de aplicación”.

Y por otro lado, tienes a los desarrolladores “vieja guardia” con décadas de experiencia en programación, muchos de los cuales son escépticos de que las herramientas como GPT sean realmente útiles para producir código de calidad en producción.

Como con la mayoría de las cosas, la respuesta real probablemente esté en algún punto intermedio.

No tienes que buscar mucho para encontrar videos de YouTube de personas que comienzan con una idea de aplicación y luego piden a ChatGPT el código que necesitan. Algunas personas incluso pueden tomar ese código y unirlo para crear una aplicación que funcione.

Los Modelos de Lenguaje Grandes como GPT-4 son impresionantes, y la velocidad a la que están mejorando es aún más impresionante.

Sin embargo, muchos desarrolladores son escépticos sobre la utilidad final de estas herramientas. Cuestionan si podremos hacer que los IA dejen de “alucinar” información falsa.

Este es el problema fundamental de “Interpretabilidad”. Podrían pasar décadas antes de que realmente entendamos lo que está sucediendo dentro de una IA de caja negra como GPT-4. Y hasta que lo hagamos, deberíamos verificar todo lo que dice y suponer que habrá muchos errores y fallos de seguridad en el código que nos brinda.

Hay una gran diferencia entre poder hacer que una computadora haga algo por ti y realmente entender cómo la computadora lo está haciendo.

Muchas personas pueden operar un automóvil. Pero aún menos pueden reparar un automóvil, y mucho menos diseñar un automóvil nuevo desde cero.

Si quieres poder desarrollar sistemas de software potentes que resuelvan problemas nuevos, y quieres que esos sistemas sean rápidos y seguros, todavía tendrás que aprender a programar correctamente.

Y eso significa lidiar con mucha ambigüedad.

Aprender a programar es un proceso ambiguo

Cuando estás aprendiendo a programar, constantemente te preguntas: “¿Estoy gastando mi tiempo sabiamente? ¿Estoy aprendiendo las herramientas correctas? ¿Estos autores de libros/creadores de cursos realmente saben de lo que están hablando?”

La ambigüedad nubla todas tus sesiones de estudio. “¿Falló mi caso de prueba porque el tutorial está desactualizado y ha habido cambios disruptivos en el marco que estoy usando? ¿O simplemente lo estoy haciendo mal?”

Como mencioné antes con el Infierno del Tutorial, también tienes que lidiar con la enfermedad del “el césped es más verde al otro lado”.

Esto se ve agravado por el hecho de que algunos desarrolladores creen que es inteligente responder preguntas con “RTFM”, que significa “Lea el Maldito Manual”. No es muy útil. ¿Qué manual? ¿Qué sección?

Otro problema es que no sabes lo que no sabes. A menudo ni siquiera puedes articular la pregunta que estás tratando de hacer.

Y si ni siquiera puedes hacer la pregunta correcta, te vas a esforzar.

Esto es especialmente difícil con la programación porque es posible que nadie haya intentado construir exactamente la misma aplicación que estás construyendo.

Y así, algunos de los problemas que encuentres pueden ser sin precedentes. Puede que no haya nadie a quien acudir.

El 15% de las consultas que las personas escriben en Google todos los días nunca han sido buscadas antes. Eso es malo si eres la persona que está escribiendo una de esas.

Mi teoría es que la mayoría de los desarrolladores resolverán un problema y simplemente seguirán adelante, sin documentarlo en ningún lugar. Así que puedes ser uno de los docenas de desarrolladores que ha tenido que inventar su propia solución para el mismo problema exacto.

Y luego, por supuesto, están los viejos hilos de foro y las páginas de StackOverflow.

Cómo no perderte al aprender a programar

La buena noticia es que tanto la competencia como la confianza vienen con la práctica.

Pronto sabrás exactamente qué buscar en Google. Desarrollarás un segundo sentido para cómo se estructura generalmente la documentación y dónde buscar qué. Y sabrás dónde hacer qué preguntas.

Ojalá hubiera una solución más simple para el problema de la ambigüedad. Pero simplemente tienes que aceptarlo. Aprender a programar es un proceso ambiguo. E incluso los desarrolladores experimentados luchan con la ambigüedad.

Después de todo, la programación es la rara profesión en la que puedes reutilizar infinitamente soluciones a problemas que has encontrado previamente.

Así que como desarrollador, siempre estás haciendo algo que nunca has hecho antes.

La gente piensa que el desarrollo de software se trata de escribir código en una computadora. Pero en realidad se trata de aprender.

Gran parte de tu carrera lo pasarás pensando intensamente. O ingresando comandos a ciegas en una consola tratando de entender cómo funciona un sistema.

Y pasarás mucho tiempo en reuniones con otras personas: gerentes, clientes, colegas desarrolladores. Aprendiendo sobre el problema que necesita ser resuelto para que puedas construir una solución.

Ponte cómodo/a con la ambigüedad y llegarás lejos.

Aprender a programar es recibir un mensaje de error tras otro

Muchas personas que están aprendiendo a programar sienten que se encuentran con una pared. El progreso no llega tan rápido como esperan.

Una gran razón para esto: en programación, el ciclo de retroalimentación es mucho más rápido que en otros campos.

En la mayoría de las escuelas, tu profesor te dará tareas, las calificará y te las devolverá. A lo largo de un semestre, es posible que solo tengas una docena de ocasiones en las que recibas retroalimentación.

“Oh no, realmente arruiné ese examen,” podrías decirte a ti mismo. “Necesito estudiar más para el parcial.”

Tal vez tu profesor dejará notas en tinta roja en tu papel para ayudarte a mejorar tu trabajo.

Obtener una mala calificación en un examen o trabajo puede arruinarte el día.

Y así es como generalmente pensamos sobre la retroalimentación como humanos.

Si has pasado mucho tiempo programando, sabes que las computadoras son bastante rápidas. Pueden ejecutar tu código en cuestión de milisegundos.

La mayoría de las veces, tu código se bloqueará.

Si tienes suerte, obtendrás un mensaje de error.

Y si tienes mucha suerte, obtendrás un “stack trace” – todo lo que la computadora estaba intentando hacer cuando encontró el error – junto con un número de línea para la pieza de código que causó que el programa se bloqueara.

Ahora esta es una retroalimentación negativa en tu cara proveniente de una computadora. No todos pueden manejar ver esto una y otra vez todo el día.

Imagina si cada vez que le entregas tu ensayo a tu profesor, él te lo devuelve con una gran “F” escrita en él. Y imagina que esto lo hace antes de que puedas parpadear siquiera. Una y otra vez.

Así es como a veces puede sentir la programación. Quieres agarrar la computadora y gritarle: “¿por qué no entiendes lo que estoy tratando de hacer?”

Cómo no frustrarte

La clave, nuevamente, es la práctica.

Con el tiempo, desarrollarás una tolerancia para los mensajes de error vagos y los “stack traces” que ocupan toda la pantalla.

La programación nunca será más difícil de lo que es cuando recién comienzas.

No solo no sabes lo que estás haciendo, sino que tampoco estás acostumbrado/a a recibir retroalimentación tan impersonal y a gran velocidad.

Así que aquí tienes algunos consejos:

Consejo #1: Saber que no eres malo/a en esto de manera única.

Todos los que aprenden a programar luchan con la frustración de tratar de fusionar mentalmente con una computadora y hacer que te entienda. (Eso es otra referencia a Star Trek.)

Por supuesto, algunas personas comenzaron a programar cuando eran niños. Pueden actuar como si siempre hubieran sido buenos en programación. Pero es muy probable que hayan luchado igual que nosotros, los adultos, y con el tiempo simplemente hayan olvidado las horas de frustración.

Piensa en la computadora como tu amiga, no tu adversaria. Solo te está pidiendo que aclares tus instrucciones.

Consejo #2: Respira.

La reacción natural de muchas personas cuando reciben un mensaje de error es rechinar los dientes. Luego vuelven a su editor de código y comienzan a cambiar el código a ciegas, esperando tener suerte de alguna manera y lograr superarlo.

Esto no funciona. Y te diré por qué.

El universo es complejo. El software es complejo. Es poco probable que simplemente tropees y tengas éxito.

Tal vez hayas oído hablar del Teorema del Mono Infinito. Es un experimento mental en el que imaginas a chimpancés escribiendo en máquinas de escribir.

Si tuvieras una sala de redacción llena de chimpancés haciendo esto, ¿cuánto tiempo pasaría antes de que uno de ellos escribiera la frase “ser o no ser” por pura casualidad?

Digamos que cada chimpancé escribe un carácter aleatorio por segundo. Probablemente tomaría 1 quintillón de años para que uno de ellos escribiera “ser o no ser”. Eso es 10 a la 18ª potencia. Mil billones de billones.

Incluso suponiendo que los chimpancés se mantengan en buena salud y las máquinas de escribir se muestren con regularidad, la galaxia sería un vacío frío y oscuro en el momento en que uno de ellos lograra escribir “ser o no ser”.

¿Por qué les cuento todo esto? Porque no quieren ser uno de esos chimpancés.

En ese tiempo, casi seguro que podrían encontrar la manera de enseñarles a esos chimpancés a escribir palabras en inglés. Probablemente podrían lograr escribir toda la obra de Hamlet, no solo su línea más famosa.

Incluso si de alguna manera tienen suerte y logran superar el error, ¿qué habrán aprendido?

Así que en lugar de desesperarse, es mejor tomar un tiempo. Entender el código. Entender qué está pasando. Y luego corregir el error.

Siempre tómate un tiempo para entender el código que falla. No seas un chimpancé quintillonario (creo que eso significa alguien que tiene 1 quintillón de años, aunque según Google, nadie ha escrito esa palabra antes).

En lugar de intentar ciegamente cosas, esperando superar el mensaje de error, ralentiza.

Respira profundamente. Estírate. Levántate para tomar una bebida caliente.

Tu yo futuro te agradecerá que hayas aprovechado este momento de aprendizaje.

Consejo #3: Utiliza el Depurador de Pato de Goma

Consigue un patito de goma y colócalo junto a tu computadora. Cada vez que encuentres un mensaje de error, intenta explicarle a tu patito de goma qué crees que está sucediendo.

Por supuesto, esto es absurdo. ¿Cómo podría ser útil?

Pero lo es.

El Depurador de Pato de Goma es una excelente herramienta para ralentizarse y analizar el problema en cuestión.

No necesariamente tienes que utilizar un patito de goma. Podrías explicarle tu aplicación de Python a tu cactus mascota. Tu consulta SQL al gato que no deja de saltar sobre tu teclado.

El simple acto de explicar en voz alta lo que estás pensando parece ayudarte a procesar mejor la situación.

¿Cómo aprende la mayoría de la gente a programar?

Ahora hablemos de los caminos tradicionales para conseguir tu primer trabajo como programador.

¿Por qué debería importarte lo que hace todo el mundo? Spoiler: realmente no tienes que hacerlo.

Tú haz lo tuyo.

Dicho esto, es posible que dudes de ti mismo y de las decisiones que has tomado sobre tu aprendizaje. Es posible que añores el camino que no tomaste.

Mi objetivo con esta sección es tranquilizar cualquier ansiedad que puedas tener.

La importancia de los títulos en Ciencias de la Computación

Los títulos universitarios siguen siendo el estándar de oro para prepararse para una carrera en desarrollo de software. Especialmente los títulos de licenciatura en Ciencias de la Computación.

Antes de que empieces a decir “Pero no tengo un título en Ciencias de la Computación” – no te preocupes. No necesitas un título en Ciencias de la Computación para convertirte en un desarrollador.

Pero su utilidad es innegable. Y te explicaré por qué.

En primer lugar, puedes preguntarte: ¿por qué los desarrolladores deberían estudiar ciencias de la computación? Después de todo, uno de los desarrolladores más prominentes de todos los tiempos dijo esto acerca del campo:

“La educación en ciencias de la computación no puede convertir a nadie en un experto programador de la misma manera en que estudiar pinceles y pigmentos puede convertir a alguien en un experto pintor.” – Eric Raymond, Desarrollador, Científico de la Computación y Autor

Tradicionalmente, los departamentos de Ciencias de la Computación eran parte del departamento de matemáticas. Las universidades en las décadas de 1960 y 1970 no sabían bien dónde encajar toda esta computadora.

En otras universidades, la Ciencias de la Computación se consideraba una extensión de la Ingeniería Eléctrica. E incluso hasta hace poco, incluso la Universidad de California – Berkeley, una de las mejores universidades públicas del mundo, solo ofrecía títulos en Ciencias de la Computación como especie de doble especialización con Ingeniería Eléctrica.

Pero la mayoría de las universidades ahora han comprendido la importancia de la Ciencias de la Computación como campo de estudio.

Al momento de escribir esto, las Ciencias de la Computación son la carrera mejor remunerada que puedes elegir. Incluso más que campos enfocados en el dinero, como las Finanzas y la Economía.

Según Glassdoor, los recién graduados en Ciencias de la Computación en Estados Unidos ganan más dinero en su primer trabajo que cualquier otra carrera. 70,000 dólares estadounidenses. Eso es mucho dinero para alguien que acaba de salir de la universidad.

Más que enfermería ($59,000), finanzas ($55,000) y arquitectura ($50,000).

De acuerdo, obtener un título en Ciencias de la Computación puede ayudarte a conseguir un trabajo de nivel de entrada bien remunerado. Eso probablemente no sea una novedad para nadie. Pero, ¿por qué es eso?

Cómo los empleadores perciben los títulos de licenciatura

Tal vez hayas escuchado a algunos grandes empleadores en tecnología decir cosas como “ya no requerimos que los candidatos tengan un título universitario”.

Google lo dijo. Apple lo dijo.

Y les creo. Que ya no requieran títulos universitarios.

Hemos tenido muchos ex alumnos de freeCodeCamp que consiguieron trabajos en estas empresas, algunos de los cuales no tenían títulos universitarios.

Pero es probable que aquellos ex alumnos de freeCodeCamp que obtuvieron esos trabajos tuvieron que ser candidatos extra fuertes para superar el hecho de que no tenían títulos universitarios.

Puedes ver estas ofertas de trabajo como que tienen una variedad de criterios en los que juzgan a los candidatos:

1. Experiencia laboral
2. Educación
3. Portafolio y proyectos
4. ¿Tienen una recomendación de alguien que ya trabaje en la empresa? (Discutiremos cómo construir tu red en profundidad en el Capítulo 2)
5. Otras consideraciones de reputación (discutiremos cómo construir tu reputación en el Capítulo 3)

Para estos empleadores que no requieren un título universitario, la educación es solo una de varias consideraciones. Si eres más fuerte en otras áreas, es posible que opten por entrevistarte, sin importar si siquiera has pisado un aula universitaria.

Solo ten en cuenta que tener un título universitario te facilitará conseguir una entrevista, incluso en estos empleadores “opciones sin título”.

¿Por qué tantos trabajos de desarrollador requieren específicamente un título en Ciencias de la Computación?

Un título es un título, les digo a menudo a la gente. Porque en la mayoría de los casos, lo es.

¿Quieres ingresar a las fuerzas armadas de los Estados Unidos como oficial en lugar de ser un miembro del servicio enlistado? Necesitarás un título universitario, pero cualquier especialidad será válida.

¿Quieres obtener una visa de trabajo para trabajar en el extranjero? Probablemente necesitarás un título universitario, pero cualquier especialidad será válida.

Y para tantas ofertas de trabajo que dicen “se requiere título universitario”: cualquier especialidad será válida.

¿Por qué sucede esto? ¿No importa en absoluto el tema que estudias en la universidad?

Bueno, aquí está mi teoría al respecto: lo que aprendes en la universidad es menos importante que si terminaste la universidad.

Los empleadores intentan seleccionar a personas que puedan encontrar la manera de pasar por este rito de iniciación.

Es cierto que puedes estar en el último puesto de tu clase, repitiendo cursos que no aprobaste y estar en prueba académica la mitad del tiempo. Pero un título es un título.

¿Sabes cómo llaman a un estudiante que termina el último en su clase de medicina? “Doctor”.

Y para la mayoría de los empleadores, lo mismo ocurre.

En muchos casos, los que trabajan en recursos humanos solo están marcando una casilla en su software de filtrado de solicitudes de trabajo. Están filtrando a los solicitantes que no tienen un título. En esos casos, es posible que nunca miren siquiera las solicitudes de trabajo de personas sin títulos.

Nuevamente, no todos los empleadores son así. Pero muchos de ellos sí lo son. Aquí en Estados Unidos, y tal vez incluso más en otros países.

Es una pena, pero así es como funciona el mercado laboral en este momento. Puede cambiar en las próximas décadas. O puede que no.

Por eso siempre aliento a las personas que están en su adolescencia o veintitantos a que consideren seriamente obtener un título universitario.

No por ninguna de las cosas con las que las universidades se promocionan a sí mismas:

• La educación en sí misma. (Puedes tomar cursos de algunas de las mejores universidades en línea de forma gratuita, por lo que esto por sí solo no justifica el alto costo de la matrícula.)
• La “experiencia universitaria” de vivir en una residencia, hacer nuevos amigos y descubrirse a uno mismo. (La mayoría de los estudiantes universitarios de Estados Unidos nunca viven en el campus, por lo que tampoco obtienen esto realmente.)
• Los cursos de educación general que ayudan a convertirte en un “individuo bien formado” (¿Alguna vez has oído hablar de los “Quince del Primer Año”? Esto es, por supuesto, una broma. Pero muchos estudiantes universitarios de primer año suben de peso debido al estrés de la experiencia.)

Nuevamente, el verdadero valor de obtener un título universitario, la verdadera razón por la que los estadounidenses pagan $100,000 o más por 4 años de universidad, es porque muchos empleadores requieren títulos.

Por supuesto, hay otros beneficios de tener un título universitario, como los que mencioné: opciones de carrera militar ampliadas y una mayor facilidad para obtener visas de trabajo.

Uno de estos es: si quieres ser médico, dentista, abogado o profesor, primero necesitarás un título universitario. Luego puedes usar eso para ingresar a la escuela de posgrado.

Vale, esta es mucha información de fondo. Permíteme responder tus preguntas de manera directa.

¿Necesitas un título universitario para trabajar como desarrollador de software?

No. Hay muchos empleadores que te contratarán sin un título universitario.

Obtener una licenciatura hará que sea mucho más fácil conseguir una entrevista con muchos empleadores. Y también puede ayudarte a obtener un salario más alto.

¿Qué hay de las titulaciones de grado asociado? ¿Tienen algún valor?

En teoría, sí. Hay algunos campos en tecnología donde tener un grado asociado puede ser necesario. Y creo que siempre aumenta tus posibilidades de conseguir una entrevista.

Dicho esto, no recomendaría ir a la universidad con el objetivo específico de obtener un grado asociado. Te animaría al 100% a permanecer en la escuela hasta obtener una licenciatura, que es mucho más útil.

Según el Departamento de Educación de los Estados Unidos, a lo largo de tu carrera, tener una licenciatura te permitirá ganar un 31% más que tener únicamente un grado asociado.

Y estoy seguro de que esa diferencia es mucho mayor con una licenciatura en Ciencias de la Computación.

¿Vale la pena ir a la universidad para obtener una licenciatura en una etapa posterior de la vida, si aún no tienes una?

Supongamos que tienes treinta años. Quizás asististe a algunos cursos universitarios. Tal vez completaste los dos primeros años y lograste obtener un grado asociado.

¿Tiene sentido volver a la “escuela” en el sentido formal?

Sí, puede tener sentido hacerlo.

Pero no creo que tenga sentido renunciar a tu trabajo para volver a la escuela a tiempo completo.

El estilo de vida de un estudiante a tiempo completo está realmente diseñado para estudiantes “tradicionales”. Es decir, personas de 18 a 22 años (o un poco más si han servido en el ejército), que aún no han ingresado al mundo laboral más allá de trabajos de verano o después de la secundaria.

Las universidades tradicionales cuestan mucho dinero para asistir, y se asume que los estudiantes pagarán a través de una combinación de becas, fondos familiares y préstamos estudiantiles.

Como adulto trabajador, tendrás menos acceso a estas fuentes de financiamiento. Y igual de importante, tendrás menos tiempo disponible que un recién graduado de la secundaria.

Pero eso no significa que debas renunciar al sueño de obtener una licenciatura.

En lugar de asistir a una universidad tradicional, recomiendo que las personas mayores de 30 años asistan a una de las universidades en línea sin fines de lucro. Dos que tienen buena reputación y cuyos costos son bastante razonables son Western Governor’s University y University of the People.

También puedes encontrar un colegio comunitario local o un programa de extensión universitaria estatal que ofrezca licenciaturas. Muchos de estos programas son en línea. Y algunos de ellos incluso son a tu propio ritmo, para que puedas completar los cursos según tu horario de trabajo lo permita.

Investiga. Si una escuela parece prometedora, te recomiendo buscar a uno de sus exalumnos en LinkedIn y contactarlos. Hazles preguntas sobre su experiencia y si creen que valió la pena.

Recomiendo no endeudarte para financiar tu título. Es mucho mejor asistir a una escuela más económica. Después de todo, un título es un título. Mientras sea de una institución acreditada, debería ser suficiente para la mayoría de los propósitos.

Si ya tienes una licenciatura, ¿tiene sentido volver y obtener una segunda licenciatura en Ciencias de la Computación?

No. Las segundas licenciaturas casi nunca valen la pena en términos de tiempo y dinero.

Si tienes alguna licenciatura, incluso si es en un campo no STEM, ya has obtenido la mayor parte del valor que obtendrás de la universidad.

¿Qué pasa con una Maestría en Ciencias de la Computación?

Estas pueden ser útiles para el avance profesional. Pero debes perseguirlas más adelante, después de que ya estés trabajando como desarrollador.

Muchos empleadores pagarán por la educación continua de sus empleados.

Uno de los programas al que muchos de mis amigos en tecnología han asistido es el programa de Maestría en Ciencias de la Computación de Georgia Tech.

El Departamento de Ciencias de la Computación de Georgia Tech se encuentra entre los mejores de los Estados Unidos. Y este programa de grado no solo es completamente en línea, sino que también es bastante asequible.

Pero no lo recomendaría hacerlo ahora. Enfócate primero en conseguir un trabajo como desarrollador. (Abordaremos ese tema en detalle más adelante en este libro).

¿Los títulos seguirán siendo importantes en el futuro?

Sí, creo que los títulos universitarios seguirán siendo importantes durante décadas, e incluso siglos, por venir.

Los títulos universitarios han existido durante más de 1,000 años.

Muchas de las mejores universidades de los Estados Unidos son más antiguas que el propio país. (Harvard tiene más de 400 años de antigüedad).

La muerte del título universitario está completamente exagerada.

Se ha vuelto popular en ciertos círculos criticar a las universidades y decir que los títulos ya no importan.

Pero si observamos las estadísticas, esto claramente no es cierto. Sí tienen un impacto en las ganancias a lo largo de la vida.

Y, igual de importante, pueden abrir carreras que son más seguras, más estables y en última instancia más satisfactorias.

Claro, puedes ganar excelente dinero trabajando como marinero en alta mar, dando servicio a plataformas petroleras.

Pero también puedes ganar un excelente dinero trabajando como desarrollador en una oficina con control de clima, dando servicio a servidores y parchando bases de código.

Uno de estos trabajos es peligroso y agotador. El otro es un trabajo que podrías hacer cómodamente durante 40 años.

Muchos de los “líderes de pensamiento” que critican a las universidades se han beneficiado ellos mismos de una educación universitaria.

Una razón por la cual pienso que mucha gente piensa que los títulos son “inútiles” es: es difícil separar el aprendizaje del impulso social que recibes.

¿La universidad es solo una forma de señalización de clase, una manera para los ricos de seguir pasando ventajas a sus hijos? Después de todo, tienes 3 veces más probabilidades de encontrar a un niño rico en Harvard que a un niño pobre.

El hecho es: la vida es fundamentalmente injusta. Pero eso no cambia cómo funciona el mercado laboral.

Puedes elegir el modo fácil y terminar un título que te dará más opciones en el futuro.

O puedes elegir el modo difícil, posiblemente ahorrar tiempo y dinero y simplemente ser más selectivo con los empleadores a los que te postulas.

Tengo muchos amigos que han utilizado ambos enfoques con gran éxito.

¿Qué alternativas hay a un título universitario?

He trabajado en educación para adultos durante casi dos décadas, y todavía no he visto un sustituto convincente para un título universitario.

Claro, hay programas de certificación y bootcamps.

Pero estos no tienen el mismo peso para los empleadores. Y rara vez son tan rigurosos.

Nota aparte: cuando digo “programas de certificación”, me refiero a programas en los que asistes a un curso y luego obtienes una certificación al final. Estos tienen un valor limitado. Pero las certificaciones basadas en exámenes de empresas como Amazon y Microsoft son bastante valiosas. Hablaremos más de esto más adelante.

Lo que le digo a la gente es: obtener un título o no obtenerlo, esa es la pregunta.

Conozco a muchas personas que son mecánicos de automóviles, electricistas, o que realizan algún otro oficio, y no tienen una licenciatura. Claramente pueden aprender un conjunto de habilidades, aplicarlas y mantener un empleo.

Conozco a muchas personas que son contadores, asistentes legales y otros “trabajadores del conocimiento” que no tienen una licenciatura. Claramente pueden aprender un conjunto de habilidades, aplicarlas y mantener un empleo.

En muchos casos, estas personas simplemente pueden aprender a programar por su cuenta, utilizando recursos de aprendizaje gratuitos y pasando tiempo con personas de ideas afines.

Algunas de estas personas siempre han tenido la meta personal de regresar y terminar su licenciatura. Esa es una buena razón para hacerlo.

Pero no es para todos.

Si quieres educación formal, ve por el título universitario. Si no quieres educación formal, no te inscribas en ningún programa. Simplemente autodidáctate.

Lo principal que los bootcamps y otros programas de certificación te brindarán es estructura y un poco de presión de grupo. Eso no es malo. Pero ¿vale la pena pagar miles de dólares por eso?

Cómo enseñarte a programar por ti mismo

La mayoría de los desarrolladores son autodidactas. Incluso los desarrolladores que obtuvieron un título de licenciatura en ciencias de la computación a menudo se consideran a sí mismos como “autodidactas” en encuestas de la industria como la encuesta anual de Stack Overflow.

Esto se debe a que aprender a programar es un proceso de por vida. Siempre hay nuevas herramientas que aprender, nuevos legados de código para mapear y nuevos problemas que resolver.

Entonces, ya sea que persigas educación formal o no, ten en cuenta esto: tendrás que ser bueno en aprender por tu cuenta.

¿Qué significa ser un desarrollador “autodidacta”?

No quiero ser pedante, pero cuando me refiero a la autodidáctica, me refiero a aprender por iniciativa propia, aprendiendo fuera de la educación formal.

Muy pocas personas son verdaderamente “autodidactas” en algo. Por ejemplo, Isaac Newton se enseñó a sí mismo Cálculo porque no había libros de Cálculo. Tuvo que descubrirlo e inventarlo a medida que avanzaba.

De manera similar, Ada Lovelace se enseñó a programar. Porque antes que ella no existía la programación. Ella la inventó.

Alguien podría decirte: “No eres realmente autodidacta porque aprendiste de libros o cursos en línea. Así que tuviste maestros”. Y tienen razón, pero solo en el sentido más estrecho.

Si alguien te cuestiona por llamarte autodidacta, solo responde: “Según tus estándares, nadie que no haya sido criado por lobos puede afirmar ser autodidacta en algo.”

Señálales esta sección de este libro y diles: “Quincy anticipó tu esnobismo”. Y luego sigue adelante con tu vida.

Porque vamos, la vida es demasiado corta, ¿verdad?

Tú eres autodidacta.

¿Qué es el aprendizaje autodirigido?

Como autodidacta, vas a seleccionar tus propios recursos de aprendizaje. Vas a elegir qué aprender y de dónde aprenderlo. Esa es la esencia del “aprendizaje autodirigido”.

Pero, ¿cómo sabes si estás aprendiendo las habilidades correctas y aprovechando los recursos adecuados?

Bueno, ahí es donde entra en juego la comunidad.

Existen muchas comunidades de aprendices en todo el mundo, todas ayudándose mutuamente a expandir sus habilidades.

Comunidad es una palabra difícil de definir. ¿Es Tech Twitter una comunidad? ¿Qué hay del foro de freeCodeCamp? ¿O los muchos grupos de Discord y subreddits dedicados a habilidades de programación específicas?

Considero que todas estas son comunidades. Si hay personas que se reúnen regularmente allí y se ayudan mutuamente, lo considero una comunidad.

¿Y qué hay de los eventos en persona? ¿La reunión mensual de desarrolladores de Ruby en Oakland? ¿La reunión de la comunidad de startups de Nueva York? ¿El grupo de usuarios de Linux de Central Texas?

Estas comunidades pueden ser en línea, en persona o una combinación de ambas.

Hablaremos más sobre las comunidades en el capítulo Construye tu Red. Pero la idea principal es: los nuevos amigos que encuentres en estas comunidades pueden ayudarte a reducir tus opciones sobre qué aprender y de qué recursos aprender.

¿Qué lenguaje de programación debería aprender primero?

La respuesta corta es: no importa mucho. Una vez que hayas aprendido bien un lenguaje de programación, es mucho más fácil aprender tu segundo lenguaje.

Existen diferentes tipos de lenguajes de programación, pero en la actualidad la mayoría del desarrollo se hace utilizando “lenguajes de script de alto nivel” como JavaScript y Python. Estos lenguajes sacrifican la eficiencia en bruto que se obtiene de los “lenguajes de programación de bajo nivel” como C. A cambio, obtienen la ventaja de ser mucho más fáciles de usar.

Las computadoras de hoy son miles de millones de veces más rápidas que en las décadas de 1970 y 1980, cuando la mayoría de los programas se escribían en lenguajes como C. Esa potencia compensa con creces la relativa ineficiencia de los lenguajes de script.

Cabe destacar que tanto JavaScript como Python en sí mismos están escritos en C, y ambos son cada vez más rápidos cada año gracias a sus grandes comunidades de colaboradores de código fuente abierto.

Python es un lenguaje potente para la computación científica (Ciencia de Datos y Aprendizaje Automático).

Y JavaScript… bueno, JavaScript puede hacerlo todo. Es el lenguaje de programación navaja suiza definitivo. JavaScript es la cinta adhesiva que mantiene unida la World Wide Web.

“Cualquier aplicación que se pueda escribir en JavaScript, eventualmente se escribirá en JavaScript”. – Ley de Atwood (Jeff Atwood, fundador de Stack Overflow y Discourse)

Puedes programar toda tu carrera en JavaScript y nunca necesitarías aprender un segundo lenguaje. (Dicho esto, más adelante querrás aprender Python y tal vez algunos otros lenguajes también).

Por lo tanto, recomiendo comenzar con JavaScript. No solo es mucho más fácil de usar que lenguajes como Java y C++ – también es más fácil de aprender. Y hay muchas, muchas más ofertas de trabajo para personas que conocen JavaScript.

Las otras habilidades en las que querrás centrarte son HTML y CSS. Si una página web fuera un cuerpo, HTML sería los huesos y CSS sería la piel. (JavaScript sería los músculos, permitiendo que el sitio web se mueva y sea interactivo).

Puedes aprender algo de HTML y CSS en una tarde. Al igual que la mayoría de las herramientas que menciono aquí, son fáciles de aprender, pero difíciles de dominar.

También querrás aprender cómo usar Linux. Linux alimenta la gran mayoría de los servidores del mundo, y pasarás gran parte de tu carrera ejecutando comandos en la línea de comandos de Linux.

Si tienes una Mac, MacOS tiene una terminal que acepta casi todos los mismos comandos que Linux. (MacOS y Linux tienen un ancestro común en Unix).

Pero si estás en un PC con Windows, querrás instalar WSL, que significa Windows Subsystem for Linux. Luego podrás ejecutar comandos de Linux en tu PC. Y si te sientes aventurero, incluso puedes hacer un arranque dual con ambos sistemas operativos Windows y Linux en la misma computadora.

Si vas a instalar Linux en una computadora, te recomiendo comenzar con Ubuntu. Es la distribución de Linux más ampliamente utilizada (y documentada), por lo que debería ser la más indulgente.

No te equivoques, Linux es bastante más difícil de usar que Windows y MacOS. Pero lo que obtienes a cambio de tus esfuerzos es un sistema operativo extremadamente rápido, seguro y altamente personalizable.

Además, nunca más tendrás que pagar por una licencia de sistema operativo. A menos que quieras hacerlo. Red Hat es una compañía multimillonaria a pesar de que su software es de código abierto, porque las empresas pagan por su ayuda en el servicio y soporte de los servidores de Linux.

También querrás aprender Git. Este sistema de control de versiones es cómo los equipos de desarrolladores coordinan sus cambios en un código base.

Puede que hayas oído hablar de GitHub. Es un sitio web que facilita la colaboración de los desarrolladores en proyectos de código abierto. Y amplía aún más algunas de las características de Git. Aprenderás más sobre GitHub en el capítulo Cómo Construir Tu Reputación más adelante.

Querrás aprender SQL y cómo funcionan las bases de datos relacionales. Estas son las herramientas principales de la economía de la información.

También escucharás mucho sobre bases de datos NoSQL (bases de datos no relacionales como bases de datos de gráficos, bases de datos de documentos y almacenes de clave-valor). Puedes aprender más sobre ellas más adelante. Pero primero concéntrate en SQL.

Finalmente, querrás aprender cómo funcionan los servidores web. Comienza con Node.js y Express.js.

Cuando escuches el término “desarrollo de pila completa” se refiere a la integración del frontend (HTML, CSS, JavaScript) con el backend (Linux, bases de datos SQL y Node + Express).

Hay muchas otras herramientas que querrás aprender, como React, NGINX, Docker y bibliotecas de pruebas. Puedes aprenderlas a medida que avanzas.

Pero las habilidades clave en las que debes dedicar el 90% de tu tiempo de aprendizaje previo al trabajo son:

1. HTML
2. CSS
3. JavaScript
4. Linux
5. Git
6. SQL
7. Node.js
8. Express.js

Si aprendes estas herramientas, podrás construir la mayoría de las principales aplicaciones web y móviles. Y estarás calificado para la mayoría de los trabajos de desarrollador nivel inicial. (Por supuesto, muchas descripciones de trabajo incluirán otras herramientas, pero las discutiremos más adelante en el libro.)

Entonces, puede que estés pensando: genial. ¿Cómo aprendo todo esto?

¿Dónde aprendo a programar?

Curioso que preguntes. Hay un currículum completo diseñado por ingenieros de software y profesores experimentados. Está diseñado pensando en adultos ocupados. Y es completamente gratuito y a tu propio ritmo.

Así es. Estoy hablando del currículo principal de freeCodeCamp. Te ayudará a aprender:

• Desarrollo Front End
• Desarrollo Back End
• Matemáticas de Ingeniería
• y Computación Científica (con Python para Ciencia de Datos y Aprendizaje Automático)

Hasta el momento, miles de personas han completado este currículum principal y han conseguido un trabajo como desarrolladores. No necesitaron renunciar a sus trabajos diarios, pedir préstamos, ni correr realmente ningún riesgo aparte de algunos de sus noches y fines de semana.

En la práctica, freeCodeCamp se ha convertido en la ruta predeterminada para la mayoría de las personas que aprenden a programar por su cuenta.

Si nada más, el currículum principal de freeCodeCamp puede ser tu “punto de partida” para el aprendizaje, y puedes expandirte desde allí. Puedes aprender las habilidades fundamentales que la mayoría de los trabajos requieren, y también experimentar con tecnologías que te interesen.

Hay décadas de libros y cursos para aprender. Algunos están disponibles en tu biblioteca pública o a través de servicios de suscripción mensual. (Y es posible que también puedas acceder a algunos de estos servicios de suscripción de forma gratuita a través de tu biblioteca.)

También, freeCodeCamp ahora tiene casi 1,000 cursos completos y gratuitos sobre todo, desde la preparación para la certificación de AWS hasta el desarrollo de aplicaciones móviles y Kali Linux.

Nunca ha sido más fácil aprender programación por tu cuenta.

Desarrollar tus habilidades es una empresa de por vida

Hemos hablado sobre por qué autoenseñarte probablemente es la mejor opción, y cómo hacerlo.

También hemos hablado sobre las alternativas al autoaprendizaje, como obtener una licenciatura en Ciencias de la Computación o una Maestría.

Y hemos hablado sobre cuáles herramientas específicas deberías enfocarte en aprender primero.

Ahora, cambiemos de tema y hablemos sobre cómo construir la segunda parte de tu base: tu red de contactos.

Capítulo 2: Cómo construir tu red de contactos

“Si quieres ir rápido, ve solo. Si quieres llegar lejos, ve acompañado.” – Proverbio africano

“Networking”. Es posible que te estremezcas al escuchar esa palabra.

Networking puede evocar imágenes de incómodas ferias de empleo, con trajes sofocantes, empujando desesperadamente tu currículum a cualquiera que lo acepte.

Networking puede traer a la mente fiestas repletas de alcohol, donde finges estar interesado en un deporte que ni siquiera sigues.

Networking puede hacer que desees “feliz cumpleaños” a personas a las que apenas conoces en LinkedIn, o darle “me gusta” a sus actualizaciones de estado esperando que te noten.

Pero el networking no tiene por qué ser así.

En este capítulo, te contaré todo lo que he aprendido sobre conocer gente. Te mostraré cómo ganar su confianza y ser la primera opción cuando necesiten ayuda.

Porque al final del día, de eso se trata. Ayudar a las personas a resolver sus problemas. Ser útil para las personas.

Te mostraré cómo construir una robusta red personal que te apoyará durante décadas.

Historia: ¿Cómo construyó un profesor en sus 30s una red de contactos en tecnología?

En el último episodio de Historia: Quincy aprendió a programar leyendo libros, viendo cursos gratuitos en línea y pasando tiempo con desarrolladores en el Hackerspace local. Acababa de terminar su primer proyecto y dar su primera charla técnica…

De acuerdo, ahora tenía algunas habilidades básicas de programación. Ahora podía salir de una bolsa de papel proverbial con código.

¿Cuál era el siguiente paso? Después de todo, era completamente ajeno a la tecnología.

Bueno, aunque era nuevo en tecnología, no era nuevo en el trabajo. Durante casi una década me había ganado la vida trabajando en escuelas y enseñando inglés.

Como profesor, me pagaban por compartir conocimientos. Y como desarrollador, me pagarían por escribir código.

Ya sabía una verdad muy importante sobre la naturaleza del trabajo: es a quién conoces.

Conocía el poder de las redes de contactos. Sabía que el camino hacia la oportunidad pasa directamente por los guardianes.

Todo lo que me separaba de un lucrativo empleo como desarrollador era un gerente de contratación que pudiera decir: “Sí, este Quincy parece alguien digno de unirse a nuestro equipo”.

Por supuesto, como ajeno a la tecnología, no conocía la cultura.

La cultura académica es mucho más formal.

Se usa un traje.

Se utilizan terminologías académicas sofisticadas para demostrar que perteneces al “grupo de adentro”.

Buscas formas de mencionar en cada conversación que fuiste a la Universidad X, o que fuiste asistente de enseñanza bajo el Dr. Y, o que publicaste en el Journal of Z.

Las progresiones de carrera son diferentes. Las conferencias son diferentes. Las estructuras de poder son diferentes.

Y no aprecié de inmediato este hecho.

Las primeras veces que fui a eventos tecnológicos, llevaba un traje.

Llevaba copias cuidadosamente dobladas de mi currículum en mi bolsillo en todo momento.

Incluso llevaba tarjetas de presentación. Había ordenado láminas de aluminio anodizado y las había grabado con láser con mi nombre, dirección de correo electrónico e incluso una cita del legendario educador John Dewey:

“Cualquier persona que haya comenzado a pensar pone parte del mundo en peligro.” – John Dewey

Todavía es mi cita favorita hasta el día de hoy.

Pero vamos, era demasiado exagerado.

“Hola, soy Quincy. Aquí tienes mi tarjeta de presentación de aluminio rojo. Lo siento de antemano, podría activar el detector de metales en tu vuelo de regreso.”

Me esforzaba demasiado. Y probablemente era dolorosamente evidente para todos con quienes hablaba.

Fui a Meetup.com y me inscribí para todos los eventos de desarrolladores que pude encontrar. Santa Bárbara es una ciudad pequeña, pero está cerca de Los Ángeles. Así que también me fui en coche a los eventos allí.

Rápidamente me di cuenta y cambié mi traje por jeans y una sudadera con capucha. Y me di cuenta de que nadie más entregaba tarjetas de presentación. Así que dejé de llevarlas encima.

Tomé consejos de los desarrolladores que conocí en el hackerspace: Ser apasionado, pero discreto. Mantén parte de tu entusiasmo reservado.

Y leí muchos libros para entender mejor la cultura de desarrollo.

The Coders at Work es un buen libro de los años 80.

Hackers: Heroes of the Revolution es un buen libro de los años 90.

Para un recurso cultural más contemporáneo, echa un vistazo a la serie de televisión Mr. Robot. Sus personajes son un poco extremos, pero hacen un buen trabajo captando la mentalidad y los modismos de muchos desarrolladores.

Pronto, empecé a hablar menos como un profesor y más como un desarrollador. Ya no destacaba tanto incómodamente.

Varias veces a la semana asistía a eventos locales relacionados con la tecnología. Mi evento favorito ni siquiera era un evento para desarrolladores. Era la Santa Barbara Startup Night. Cada pocas semanas, tenían un evento donde los desarrolladores presentaban sus prototipos. Algunos de los desarrolladores que demostraban su código incluso lograban asegurar financiamiento de inversionistas – personas adineradas que invierten en compañías en etapas tempranas.

El tipo que organizaba el evento se llamaba Mike. Debe haber conocido a todos los desarrolladores y emprendedores de Santa Barbara.

Cuando finalmente me armé de valor para presentarme ante Mike, me quedé impresionado. Era un ultra maratonista con un ritmo cardíaco en reposo en los 40 bajos. Cabello y barba perfectamente recortados. Para mí era el tipo más genial del planeta. Siempre pulido. Siempre respetuoso.

Mike no era “técnico”. Trabajaba como gerente de producto. Y aunque sabía mucho sobre tecnología y diseño de experiencia de usuario, no sabía cómo programar.

A veces los desarrolladores despreciaban a las personas no técnicas. Decían cosas como: “Es solo un hombre de negocios” o “Es un traje”. Pero nunca escuché a nadie decir eso de Mike. Todos lo respetaban.

Fui observando cómo Mike interactuaba con los desarrolladores. Después de todo, yo no estaba tan alejado de ser “no técnico” yo mismo. Solo llevaba unos meses programando.

A menudo, mis viejos hábitos volvían. Durante las conversaciones, tenía la tentación de presumir lo que había aprendido o lo que había construido.

Muchos desarrolladores son modestos acerca de sus habilidades o logros. Podrían decir: “Juego un poco con Python”. Y el inseguro yo abría la boca y decía algo como: “Oh sí. He codificado tantos algoritmos en Python. Escribo Python mientras duermo”.

Luego llegaba a casa y buscaba en Google el nombre de ese desarrollador, y me daba cuenta de que eran un colaborador clave en una importante biblioteca de Python. Y me daba patadas a mí mismo.

Rápidamente aprendí a no vanagloriarme de mis logros o habilidades. Existe una gran posibilidad de que la persona con la que estés hablando sea mucho mejor programador que tú. Pero la mayoría de ellos nunca ofrecería esta información voluntariamente.

No hay nada peor que sacar confiadamente tu computadora portátil, mostrar tu código y que alguien te haga un montón de preguntas a las que no estás preparado para responder.

Mis primeros meses asistiendo a eventos fueron una experiencia humilde. Pero estos eventos me llenaron de energía para seguir avanzando con mis habilidades.

Pronto la gente alrededor del sur de California empezó a reconocerme. Decían: “Siempre te encuentro en estos eventos. ¿Cómo te llamas de nuevo?”

Una noche, un desarrollador dijo: “Sigámonos en Twitter”. Había configurado una cuenta en Twitter a regañadientes unos días antes, pensando que era un sitio web sin sustancia. ¿Cuánto puedes expresar realmente con solo 140 caracteres? Apenas había tuiteado nada. Pero tenía una cuenta de Twitter lista, y ella me siguió.

Eso me inspiró a pasar más tiempo perfeccionando mi presencia en línea. Hice mi perfil de LinkedIn menos formal y más amigable. Observé cómo otros desarrolladores en la comunidad se presentaban a sí mismos en línea.

En cuestión de meses, conocí a personas de muchos campos:

• desarrolladores experimentados
• personas no técnicas o semi-técnicas que trabajaban en compañías de tecnología
• gerentes de contratación y reclutadores
• y lo más importante, mis compañeros que también se encontraban en la mitad de su carrera e intentaban adentrarse en el campo tecnológico

¿Por qué eran los compañeros los más importantes? Seguramente serían los menos capaces de ayudarme a conseguir un trabajo, ¿verdad?

Bueno, déjame contarte un secreto: supongamos que un jefe de contratación incorpora a un nuevo desarrollador, los entrena y resulta ser muy bueno en su trabajo. Ese jefe de contratación va a preguntar: ¿dónde puedo encontrar más personas como tú?

Tus compañeros son una de las piezas más importantes de tu red. Muchas de mis oportunidades como freelance y de entrevistas de trabajo vinieron de personas que comenzaron a aprender a programar al mismo tiempo que yo.

Crecimos juntos. Éramos hermanos y hermanas de armas. Esos lazos son los más fuertes.

De todas formas, toda esta red de contactos a lo largo de los meses daría sus frutos una noche en la que entré al bar de un lujoso hotel en el centro para un evento de desarrolladores.

Pero más sobre eso en el próximo capítulo. Ahora hablemos más sobre el arte y la ciencia de construir tu red de contactos.

¿Realmente importa a quién conoces?

Puede que hayas escuchado la expresión de que el éxito depende “menos de lo que sabes y más de a quién conoces”.

En la práctica, se trata de ambas cosas.

Sí, tus conexiones pueden ayudarte a conseguir el trabajo de tus sueños. Pero si estás fuera de tu capacidad y careces de las habilidades para tener éxito, no te irá bien en ese puesto.

Pero asumamos que estás construyendo proactivamente tus habilidades. Has seguido mis consejos del Capítulo 1. ¿Cuándo es el momento adecuado para empezar a construir tu red de contactos?

El mejor momento para comenzar a construir tu red de contactos es ayer.

Pero no necesitas una máquina del tiempo para hacer esto. Porque ya tienes una red. Probablemente sea mucho más pequeña de lo que te gustaría, pero conoces a personas.

Pueden ser amigos de tu ciudad natal o colegas de tus padres. Cualquier persona que conozcas de tu pasado, por mínimamente que sea, puede ser de ayuda.

Así que el primer paso es hacer un inventario completo de las personas que conoces. No te preocupes, no te estoy pidiendo que te comuniques con nadie todavía, ni que pongas en peligro tus relaciones personales.

Piensa antes de actuar. Formula una estrategia.

Primero, hagamos un inventario de todas las personas que conoces.

Cómo construir una Junta de Red de Contactos Personal

Quieres comenzar creando una lista de personas que conoces.

Podrías hacer esto con una hoja de cálculo o con una herramienta de Gestión de Relaciones con Clientes (CRM) como la que usan los vendedores. Pero eso probablemente sea demasiado para lo que estamos haciendo aquí.

Recomiendo usar una herramienta de tablero Kanban como Trello, que es gratuita.

Vas a crear 5 columnas: “para evaluar”, “para contactar”, “esperando respuesta”, “en contacto reciente” y “no contactar todavía”.

Luego vas a querer crear etiquetas para clasificar a las personas según cómo las conoces. Aquí tienes algunas ideas de etiquetas: “Amigo de la infancia”, “Amigo de la familia”, “Antiguo colega”, “Compañero de clase”, “Amigos de eventos de tecnología”.

Ahora puedes empezar a crear tarjetas. Cada tarjeta puede ser solo su nombre, y si tienes tiempo, puedes agregar una foto.

Aquí está el tablero de Trello que creé para darte una idea de cómo podría verse esta Junta de Red de Contactos Personal. Usé personajes de mi película favorita de la infancia, el clásico de 1989 “Las Tortugas Ninja Adolescentes Mutantes”.

Puedes revisar tus cuentas de redes sociales, incluso tus antiguos anuarios escolares si los tienes, y empezar a añadir personas.

La mayoría de estas personas no van a ser de ninguna ayuda. Pero recomiendo añadirlas por ser exhaustivo. Nunca sabes cuándo recordarás: “oh, fulano consiguió un trabajo en XYZ Corp. Debería contactarlos”.

Este proceso puede llevar uno o dos días. Pero recuerda que es una inversión. Podrás usar este tablero durante el resto de tu carrera.

Puedes pensar “no necesito hacer esto, ya tengo una cuenta de LinkedIn”. Eso podría funcionar bien, pero LinkedIn es una herramienta básica. Aquí quieres maximizar la señal y minimizar el ruido. Por eso te animo a crear este tablero dedicado a tu red de contactos personal.

A medida que agregas personas a tu tablero, puedes etiquetarlas. Tómate un momento para investigar a cada una de estas personas. ¿En qué están trabajando actualmente? ¿Tienen un trabajo? ¿Dirigen una empresa?

Puedes añadir notas a cada tarjeta, a medida que descubres nuevos datos sobre ellos. ¿Recientemente participaron en una carrera para recaudar fondos de 5 km? ¿Recientemente la abuela de alguien celebró su cumpleaños número 90? Estos datos pueden parecer irrelevantes. Pero si la persona los comparte en las redes sociales, significa que estos datos son importantes para ellos.

Haz un esfuerzo por interesarte en las personas. En sus vidas diarias. En sus aspiraciones. Al entender sus motivaciones y metas, tendrás una mayor comprensión de cómo puedes ayudarles.

Y como mencioné anteriormente, la mejor manera de establecer alianzas es ayudando a las personas. Hablaremos más detalladamente sobre esto en un momento.

Para cada una de las personas que agregues a tu Tablero de Redes Personales, considera si vale la pena contactarlas. Luego, colócalas en la columna “por contactar” o “no contactar aún”.

Quizás te preguntes: ¿por qué la columna se llama “no contactar aún“? Porque nunca sabes cuándo puede ser útil conocer a alguien. Nunca des por sentada ninguna amistad o conocido.

Una vez que hayas llenado tu tablero, etiquetado a todos y los hayas ordenado en columnas, estarás listo para comenzar a contactarlos.

Cómo prepararse para el alcance en redes

Lo principal a tener en cuenta al contactar y tratar de causar una impresión: mantente simple.

Las personas están ocupadas y solo pueden recordar tantos datos sobre ti. Quieres resumir quién eres a lo esencial. Y la mejor manera de hacer esto es escribiendo una biografía personal.

Cómo escribir una biografía personal para las redes sociales

Quieres que tu presencia sea consistente en todas tus cuentas de redes sociales.

Así es como me presento:

“Soy Quincy. Soy profesor en freeCodeCamp. Vivo en Dallas, Texas. Puedo ayudarte a aprender a programar.”

Ve y escribe la tuya. Intenta reducirla a 100 caracteres o menos. Trata de evitar usar palabras complicadas o jerga.

Puede ser difícil condensar tu identidad en pocas palabras. Pero este es un proceso importante.

Recuerda: las personas están ocupadas. No necesitan conocer toda tu historia de vida. A medida que vayas conociendo mejor a estas personas, gradualmente podrás compartir detalles sobre quién eres como persona. A medida que te hagan preguntas, podrán conocerte mejor con el tiempo.

Y en ese sentido, necesitas una buena foto de tu rostro sonriente.

Cómo hacer una foto de perfil para redes sociales

Si tienes dinero, simplemente busca a un fotógrafo local y págale para que tome algunas fotos profesionales de tu rostro.

Incluso puede que tengas un amigo que le guste la fotografía y pueda tomarlas de forma gratuita.

Yo me tomé mi foto de perfil yo mismo, usando Photobooth, que viene preinstalado en MacOS. Mi amigo pasó alrededor de 10 minutos arreglando el fondo y las sombras en Photoshop. Tal vez haya dejado mis dientes un poco más blancos. Esto es lo que se ve:

Asegúrate de sonreír con tus ojos, para no parecer un robot. O mejor aún, piensa en algo realmente divertido, como lo hice aquí. Así la sonrisa será genuina.

Toma muchas fotos desde diferentes ángulos y utiliza la que se vea mejor en ti.

Recomiendo usar una foto de perfil que refleje cómo te ves en un día cualquiera. No una foto fuertemente retocada que intente maximizar tu atractivo. Quieres que las personas en los eventos te reconozcan por tu foto. Y no quieres intimidar a las personas con tu belleza. Quieres tranquilizarlas.

Hablando de tranquilizar a las personas: no uses lentes de sol, ni intentes lucir demasiado cool. Quieres parecer amigable y accesible. Una buena prueba para esto es: mira tu foto. Si te hubieras perdido y vieras a esta persona en la calle, ¿te sentirías lo suficientemente valiente como para pedirles indicaciones?

Una vez que hayas elegido tu foto de perfil, úsala en todos lados. Ponla en todas tus cuentas de redes sociales.

Úsalo en tu sitio web personal. Incluso puedes agregar la foto de perfil a tu cuenta de correo electrónico.

Recomiendo usar la misma foto durante años. Cada vez que la cambias, corres el riesgo de que algunas personas no te reconozcan de inmediato. Incluso cambios sutiles en la iluminación, el ángulo o el fondo pueden desconcertar la familiaridad de las personas.

Asegúrate de mantener una versión de alta definición de la foto. De esa manera, las personas pueden usarla para promocionar tu charla en su conferencia o tu aparición como invitado en su podcast. (No te preocupes, con el tiempo, llegarás allí.)

Cómo conectarte con personas de tu pasado

Ahora que tienes tu biografía y tus fotos organizadas, estás listo para comenzar a hablar con las personas.

Hace 15 años, diría que deberías llamar a las personas por teléfono en lugar de enviarles mensajes. Pero la cultura ha cambiado mucho con la llegada de los teléfonos inteligentes. La mayoría de las personas no responderán bien a una llamada telefónica.

De manera similar, no recomiendo invitar a las personas a tomar café o almorzar hasta mucho más tarde en la conversación. Las personas están ocupadas y pueden ver la solicitud como incómoda.

Necesitas ir al grano y hacerlo rápidamente.

Entonces, ¿a qué punto necesitas llegar?

Esencialmente:

1. Te conozco
2. Me agradas
3. y respeto el trabajo que estás haciendo.

Eso es todo.

A las personas les gusta ser conocidas. Les gusta que les agraden. Les gusta que se reconozca el trabajo que hacen y las vidas que llevan.

La mayoría de nosotros recibimos reconocimiento en nuestros cumpleaños. Las personas de nuestro pasado pueden enviar mensajes de texto de “feliz cumpleaños”, publicaciones en redes sociales, o incluso llamarnos.

Pero ¿qué pasa con los otros 364 días del año? A las personas también les gusta ser reconocidas en esos otros días.

Bueno, aquí tienes una forma sencilla de reconocer a las personas.

Paso 1: Investiga a la persona. Búscala en Google. Lee las publicaciones más recientes en sus redes sociales. Lee su perfil de LinkedIn. Si publica fotos familiares, tómate el tiempo para mirarlas de verdad.

Paso 2: Piensa en algo que podrías decir que alegraría un poco su día.

Paso 3: Elige una plataforma de redes sociales en la que haya estado activo recientemente. Envíale un mensaje directo.

Voy a compartir una plantilla, pero nunca uses las plantillas literalmente, porque si el destinatario busca tu mensaje en Google, descubrirá que es una plantilla y todo tu buen ánimo se desperdiciará.

Si estuviera enviando un mensaje a alguien con quien no he hablado en varios meses o años de la nada, diría algo como esto:

“Hola [nombre], espero que tu [año nuevo / primavera / semana] haya comenzado divertido. Felicitaciones por [nuevo trabajo / ascenso / nuevo bebé / proyecto completado]. Es inspirador verte avanzar y lograr cosas.”

Algo corto y directo como eso. Saludo + felicitaciones + cumplido. Esa es la fórmula básica.

No solo lo digas. Síntelo.

Realmente quieres que esta persona se sienta reconocida. Realmente quieres alegrarle el día. Realmente quieres animarla a seguir avanzando hacia sus metas.

Los humanos son muy buenos detectando la insinceridad. No trates de exagerarlo. No les des ninguna razón para pensar “esta persona quiere algo de mí”.

Por eso, lo más importante de todo es: sé breve. Respeta el tiempo de las personas. Nadie quiere una larga carta a la que sentirán obligados a responder detalladamente.

Porque, repítemelo otra vez – las personas están ocupadas.

Cómo construir conexiones aún más sólidas

Porque las personas están tan ocupadas, a menudo están tentadas a ver a los desconocidos más por lo que esos desconocidos pueden hacer por ellas:

• Esta persona conduce el autobús que me lleva al trabajo.
• Esta persona prepara mi bebida exactamente como me gusta.
• Esta persona en Recursos Humanos responde a mis preguntas sobre días libres.
• Esta persona armó una lista de reproducción de acid jazz increíble para que la escuche mientras programo.
• Esta persona me envía correos electrónicos útiles cada semana con recursos de programación gratuitos.

Hasta cierto punto, eres lo que haces por las personas.

Sí, lo sé. Eso puede sonar demasiado simplista. Incluso cínico. Y eso no es 100% cierto para los amigos cercanos y la familia en tu vida.

Pero para las personas que apenas te conocen, que te encuentran mientras van por su día, es probablemente así como te ven.

Tienes que darles una razón para que les importes. Tienes que inspirarlos a aprender más sobre ti.

Antes de poder convertirte en el amigo cercano de alguien, en alguien a quien realmente le importas y piensan en ti cuando no estás cerca, debes empezar como alguien que les resulta útil.

Y eso es lo que vamos a hacer aquí. Vamos a construir relaciones aún más profundas ofreciendo ayudar a las personas.

Esto será un proceso largo. Y debes comenzarlo mucho antes de buscar trabajo. Lo último que quieres es que alguien piense “Oh, solo estás contactándome porque necesitas algo de mí”.

Al contrario, estás contactándolos porque tienes algo que ofrecerles.

Después de todo, posees uno de los conjuntos de habilidades más poderosas que una persona puede adquirir. La habilidad de controlar las máquinas a tu voluntad. Eres un programador.

O al menos, estás en el camino para convertirte en uno.

Así que ya tienes un buen pretexto para contactar a las personas.

Tal vez hayas oído el término “llamada en frío”. Esto es cuando llamas a alguien sin saber casi nada sobre ellos e intentas venderles algo. Esto no es fácil y la gran mayoría de las llamadas en frío terminan con la otra persona colgando.

Pero cuanto más información tengas sobre la otra persona, más cálida se vuelve la llamada y más probabilidades tienes de tener éxito.

Ahora, aquí no estás vendiendo nada. Y como mencioné antes, tampoco los estás llamando. Les estás enviando un mensaje directo.

Tal vez esto sea a través de Twitter, LinkedIn, Discord, Reddit, donde sea. Pero te estás comunicando con ellos con un párrafo de texto.

Como dije, la forma más sólida de empezar, el enfoque que tiene más probabilidades de obtener una respuesta, es ofrecer ayuda de manera casual.

Si yo estuviera haciendo esto, aquí hay una plantilla simple que usaría. Recuerda no usar esta plantilla textualmente. Reescríbela con tu propio estilo, cómo se lo dirías a un amigo:

“Hola [nombre], felicitaciones por el [nuevo trabajo / ascenso / nuevo bebé]. He estado aprendiendo programación y estoy construyendo mi portafolio. Inmediatamente pensé en ti como alguien que resuelve muchas cosas. ¿Hay alguna herramienta o aplicación que podría hacer tu vida más fácil? Puede que pueda programarla para ti, como práctica.”

Este es un enfoque sólido porque es personalizado y no parece automatizado. Las personas reciben tantos mensajes automatizados en estos días que rápidamente ignoran cualquier cosa que se asemeje a un mensaje automatizado.

Por eso envío todos mis mensajes manualmente y no confío en la automatización. Es mejor componer lentamente los mensajes uno por uno que intentar ahorrar tiempo con un guion o un correo masivo.

La forma más rápida de ser bloqueado es enviarle a alguien un mensaje como “Hola [VACÍO], ¿cómo te va?” donde claramente falta un nombre, evidencia de que el mensaje es una plantilla.

A veces recibo un mensaje usando mi apellido en lugar de mi nombre. “Hola Larson”. ¿Qué, ¿estoy en una escuela militar ahora?

Y mucha gente en LinkedIn ha comenzado a poner un emoji al principio de su nombre. Esto hace que sea fácil detectar mensajes automatizados, porque nadie incluiría ese emoji en un mensaje directo.

Cuando un mensaje comienza con: “Hola 🍜Sarah, ¿estás buscando un nuevo trabajo?” Entonces sabes que es un mensaje masivo.

También debes tener en cuenta que mi plantilla anterior no dice “fuimos a la escuela juntos” o algo así. A menos que hayan conocido a alguien hace solo unos días, no deberías especificar cómo se conocen.

¿Por qué? Porque el mero hecho de recordarles cómo se conocen mutuamente hará que algunas personas retrocedan y piensen: “Vaya, apenas conozco a esta persona”.

Cómo mantener la conversación en marcha

Nuevamente, tu objetivo es obtener una respuesta de ellos para poder iniciar una conversación de ida y vuelta.

Estas plataformas de mensajería tienen un ambiente informal. Mantenlo informal.

No envíes un solo mensaje de varios párrafos. Mantén tus mensajes cortos y concisos. No quieres que se sienta como una tarea responder a tu mensaje.

Una vez que logres que te respondan, comienza a tomar notas en tu Tablero de Red Personal para que puedas recordar estos datos más tarde.

Tal vez tengan alguna idea de aplicación o herramienta. Genial. Hazles preguntas al respecto. Ver si puedes construirla para ellos.

Comienza dibujando un boceto simple de la interfaz de usuario. Usa papel cuadriculado si quieres lucir extra sofisticado. Toma una foto y envíasela. “¿Algo así?”

Esto establecerá que te tomas en serio ayudarlos. Y estaría dispuesto a apostar que para la mayoría de las personas, esta sería una experiencia nueva.

“¿Me estás ayudando? ¿Estás creando esta aplicación para mí?” Será halagador, y es probable que lo recuerden. Incluso si la aplicación misma no llega a ninguna parte.

A partir de ahí, puedes seguir la conversación sin esfuerzo. Tal vez se desvanezca. No te preocupes. Déjalo estar. Puedes encontrar una razón para retomar la conversación unas semanas después.

Lo genial de estos mensajes directos en redes sociales es que tienes todo el registro del mensaje ahí. La próxima vez que les envíes un mensaje, solo tienen que desplazarse hacia arriba y ver “oh, esta es la persona que se ofreció a construir esa aplicación para mí”. Ya no hay más inclinaciones de cabeza de “¿quién eres de nuevo?” que podrías tener en conversaciones en persona.

Nuevamente, mantén todo informal y animado. Si sientes que la conversación va lenta, no hay problema. Porque tendrás docenas de otras conversaciones en marcha. Otras cosas en puertas. Serás una abejita ocupada construyendo tu red.

Cómo Conocer Gente Nueva y Ampliar tu Red Personal

Hemos hablado de cómo conectarte con personas que ya conoces. Esas conexiones aún están ahí, incluso si se han debilitado con el tiempo.

Pero ¿cómo haces nuevas conexiones?

No es una tarea fácil. Pero tengo algunos consejos que harán que este proceso sea un poco menos intimidante.

En primer lugar, conocer a personas por primera vez en persona es mucho más poderoso que conocerlas en línea.

Cuando conoces a alguien en persona, tu memoria tiene mucha más información en qué aferrarse:

• Cómo se ve la persona, su postura y cómo se mueve por el espacio
• El sonido de su voz y la forma en que hablan
• Las luces, sonidos, aromas, temperatura y la sensación general del lugar
• Y tantos otros pequeños detalles que se graban en tu memoria

Pasar 10 minutos hablando con alguien en persona puede construir una conexión más profunda que docenas de mensajes de ida y vuelta, a lo largo de semanas de correspondencia.

Por eso, recomiendo encarecidamente: sal y conoce gente en eventos locales.

Cómo Conocer Gente en Eventos Locales

¿Qué eventos? Si vives en una ciudad densamente poblada, es posible que tengas muchas opciones a tu disposición. Es posible que puedas ir a eventos tecnológicos varias noches a la semana, con un mínimo de desplazamiento.

Si vives en un pueblo pequeño, puede que debas conformarte con conocer gente en reuniones locales. Ferias del libro, reuniones para comer helado, eventos deportivos.

Si vas a la iglesia, mezquita o templo, conoce también a las personas allí.

Y sí, me doy cuenta de que esto puede sonar ridículo. “¿Esa persona parada en las gradas junto a mí en el partido de fútbol? ¿De alguna manera me ayudará a conseguir un trabajo como desarrollador?”

Tal vez. Tal vez no. Pero no descartes a las personas.

Esa persona puede dirigir un pequeño negocio.

Tal vez haya estudiado con un amigo que es vicepresidente de ingeniería en una empresa Fortune 500.

Y tal vez, solo tal vez, ellos también sean ingenieros de software. Después de todo, hay millones de nosotros, ingenieros de software, por ahí. Y no todos vivimos en Silicon Valley. 😉

Cuando conozcas a una nueva persona, no querrás sacar tu teléfono de inmediato y decir “¿Puedo agregarte a mi red profesional de LinkedIn?”

En su lugar, mantén la calma. Preséntate.

Recuerda su nombre. Los nombres son fundamentales para construir una relación. Si no se te dan bien los nombres, practica recordarlos. Puedes practicar tratando de recordar el nombre de cada personaje, por insignificante que sea, cuando ves programas de televisión o películas.

Si olvidas el nombre de alguien, no adivines. Solo di “¿Cómo se llama de nuevo?” y asegúrate de recordarlo la segunda vez.

Estrecha su mano o choca los puños. Habla con ellos sobre lo que te parezca natural. Si la conversación se acaba, no te preocupes. Déjala.

Las relaciones se construyen con el tiempo. No se trata del tiempo total que pasas con alguien, sino del número de veces que te encuentras con esa persona en un período de tiempo más largo.

Hay una buena probabilidad de que veas a esa persona nuevamente en el futuro. Tal vez en ese mismo lugar exacto unas semanas más tarde. Y ese es el momento en el que das el siguiente paso:

“Hola [nombre], ¿cómo va lo del [tema sobre el que hablaste la última vez]?”

Continúa la conversación donde la dejaron. Si parecen alguien que sería una adición útil a tu Tablero de Red Personal, pregúntales “oye, ¿qué harás el [día de la semana]? ¿Quieres acompañarme a [otro evento local próximo]?”

Siempre ten en mente los eventos de la próxima semana, para que puedas invitar a personas a unirse a ti.

Esta es una excelente manera de hacer que las personas pasen tiempo contigo en un lugar seguro y público. Y estás proporcionando algo de valor: dándoles conocimiento sobre un evento próximo.

Si parecen interesados, puedes decir “Genial. ¿Cuál es la mejor forma de comunicarme contigo y enviarte los detalles del evento?”

Boom: ahora tienes su correo electrónico, red social o número de teléfono, y a partir de ahí tu relación puede desarrollarse.

Esto puede parecer un enfoque lento. ¿Por qué ser tan cauteloso?

Nuevamente, la gente está ocupada. Las personas inteligentes se defienden de su tiempo y de su información personal.

Hay demasiados vampiros por ahí que quieren aprovecharse de las personas: intentar venderles algo, estafarlas, involucrarlas en su esquema de mercadeo multinivel o de alguna otra manera intentar persuadirlas.

La mejor manera de ayudar a las personas a superar esta defensiva refleja es ya estar en su radar desde encuentros anteriores como una persona razonable.

Cómo aprovechar tu red

Hablaremos más sobre cómo aprovechar tu red en el Capítulo 4. Por ahora, mira tu red simplemente como una inversión de tiempo y energía.

Me gusta pensar en mi red como un huerto. Estoy sembrando relaciones. Cuidándolas y asegurándome de que estén saludables.

Quién sabe cuándo esas relaciones crecerán como árboles y darán frutos. El objetivo es seguir plantando árboles y en algún momento en el futuro esos árboles te ayudarán a sustentarte.

Sigue enviando energía positiva. Sigue ofreciendo ayudar a las personas utilizando tus habilidades, e incluso tu propia red. (Rara vez es un movimiento equivocado hacer una introducción cortés entre dos personas que conoces.)

Sé una persona amable, atenta y servicial.

Nunca te impacientes con lo lento que puede ser una búsqueda de empleo.

Nunca te sientas menospreciado o excluido.

Nunca te sientas celoso del éxito de otra persona.

Lo que das, recibes. Un día cosecharás lo que siembras. Y si estás sembrando energía positiva, estás preparándote para una cosecha abundante.

Capítulo 3: Cómo construir tu reputación

“La manera de ganarse una buena reputación es esforzarse por ser lo que deseas parecer.” – Sócrates

Ahora que has empezado a construir tus habilidades y tu red, estás listo para comenzar a construir tu reputación.

Tal vez estés comenzando desde cero, como un recién llegado total a la tecnología. O tal vez ya tengas algo de credibilidad que puedas traer contigo desde tu otro trabajo.

En este capítulo, compartiré consejos prácticos sobre cómo puedes construir una reputación impecable entre tus compañeros. Esto será clave para obtener clientes como freelancer, un primer empleo y avanzar en tu carrera.

Pero primero, te contaré cómo construí mi reputación.

Hora de la historia: ¿Cómo creó un profesor en sus 30s una reputación como desarrollador?

La última vez en Hora de la historia: Quincy comenzó a construir su red de desarrolladores, empresarios y gerentes de contratación en tecnología. Estaba frecuentando espacios de hackers y eventos tecnológicos en la ciudad. Pero aún no había subido al escenario y probado su habilidad…

Ya llevaba varios meses en mi camino hacia la programación cuando finalmente reuní el valor para ir a mi primer hackathon.

Un día me encontré con un error particularmente molesto y no estaba seguro de cómo solucionarlo. Así que hice lo que mucha gente haría en esa situación: procrastiné navegando en la web. Y ahí es cuando lo vi. Startup Weekend EDU.

Startup Weekend es una competición de 54 horas que implica construir una aplicación y luego presentarla a un panel de jueces. Estos eventos recompensan tu conocimiento de programación, diseño y emprendimiento también.

Este evento en particular, celebrado en el corazón de Silicon Valley, tuvo un panel de educadores y emprendedores educativos como jueces. Con mi experiencia en educación para adultos, esto parecía ser el primer hackathon ideal para mí.

Le hablé a Steve sobre el evento. Y luego dije las palabras mágicas: “Yo conduciré”. Lo cual fue bueno, porque Steve no tenía licencia de conducir.

Con Steve a bordo, completamos nuestro equipo con un par de desarrolladores del Santa Barbara Hackerspace.

Pasé semanas preparándome para el evento investigando acerca de los jueces y las compañías para las que trabajaban. Investigé acerca de los patrocinadores. Y por supuesto, practiqué programación como un monje Shaolin.

Finalmente, después de un mes de preparación, llegó el gran fin de semana. Nos amontonamos en mi Toyota Corolla del 2003 con la capa de barniz descascarada, pusimos música energética y comenzamos nuestro viaje de 5 horas.

En el camino, discutimos qué deberíamos construir. Debería estar enfocado en la educación, por supuesto. Preferiblemente dirigido a estudiantes de secundaria, ya que esos eran los niveles de grado en los que las compañías de los jueces se enfocaban.

Pero, ¿qué debería hacer la aplicación? ¿Cómo iba a facilitar la vida de las personas?

Recordé mi tiempo en la escuela secundaria. No tenía mucho en qué basarme, ya que abandoné después de solo un año. (Logré estudiar y aprobar el GED, un título suficientemente bueno como lo llamábamos, mientras trabajaba en Taco Bell antes de finalmente ir a la universidad. Pero esa es otra historia.)

Pero había un punto doloroso que recordaba de la escuela secundaria, y que seguía resonando después de todos estos años: los trabajos de inglés.

Ahora, me encantaba escribir. Pero no me encantaba escribir en formato MLA, con sus rígidas reglas de citación. Solía temer preparar una página de Referencias Bibliográficas. Mi profesor siempre me restaba puntos por no formatear correctamente mis citas.

Después de escuchar muchas ideas regulares de los otros pasajeros en el auto, tomé la palabra. Dije: “Tengo una idea. Deberíamos programar una aplicación que cree citas por ti”.

Y alguien se rió y dijo: “Fuera de vista”.

Y Steve dijo: “Hey, ese es un buen nombre. Podríamos llamarlo Out of Cite con una ‘C'”.

Todos nos reímos y nos sentimos ingeniosos. Luego comenzamos a discutir los detalles de implementación.

Cuando llegamos al lugar, había alrededor de 100 otros desarrolladores. Era un espacio de oficina de planta abierta, con cubículos de baja altura rodeados de pizarras blancas.

Escuché susurros acerca de uno de esos desarrolladores. “¡Hey, es ese chico que ganó el evento el año pasado!”, escuché a la gente decir. Señalaron a un desarrollador con aspecto arrogante rodeado de fanáticos. “Quizás me deje unirme a su equipo”.

El evento comenzó con las presentaciones. Cualquiera podía ir al frente de la sala, tomar el micrófono y hacer una presentación de 60 segundos para la aplicación que querían construir.

Estaba tan nervioso que sentía que un alien estaba a punto de salir de mi pecho. Así que naturalmente, fui el primero en la fila. Quitarse la curita de una vez, ¿no?

Estaba sudando y gesticulando descontroladamente mientras corría a través de mi presentación. Dije algo como esto: “Las citas son un fastidio. Quiero decir, no son un fastidio. Son necesarias. Y necesitas agregarlas a tus trabajos. Pero preparar citas es un fastidio. Construyamos una aplicación que complete tu página de referencias bibliográficas por ti. ¿Quién está conmigo?”

La sala estaba en silencio. Luego la gente se dio cuenta de que había terminado de hablar y me dio una ronda de aplausos obligatoria. El presentador me quitó el micrófono de la mano y se lo dio a la siguiente persona, y volví a mi asiento saltando.

Después de las presentaciones, era hora de formar equipos. Nuestro grupo de Santa Barbara nos miramos y dijimos “Supongo que somos un equipo”.

Descubrimos la contraseña del wifi y tomamos los mejores espacios de trabajo: una oficina en esquina que tenía una puerta que realmente podías cerrar.

Comencé a garabatear bocetos de la interfaz de usuario en la pizarra. Dije: “Queremos algo que siempre esté a un clic de distancia. Directamente en la barra de menú de tu navegador”.

“Como un complemento del navegador”, dijo Steve.

“Sí. Construyamos un complemento del navegador”.

Les mostré ejemplos de los tres formatos que los ensayos podrían requerir: MLA, APA y Chicago.

“¿Podríamos generar los tres al mismo tiempo, para que solo tengan que copiar y pegarlos?” pregunté.

“Podemos hacerlo mejor que eso”, dijo Steve. “Podemos tener un botón para cada uno de ellos que coloque la cita directamente en su portapapeles”.

Trabajamos rápido, creando un simple MVP (Producto Mínimamente Viable) al final de la noche del viernes. Todo lo que hacía era tomar los metadatos del sitio web actual y estructurarlo como una cita. Pero funcionó.

Dado que era mi primer hackathon, no quería el estrés de quedarme en un albergue. Así que me di el gusto de reservar una habitación de hotel. Teníamos dos camas individuales, así que cada noche alternábamos quién tenía que dormir en el suelo.

El sábado por la mañana, nuestras ambiciones crecieron. Me acerqué al pizarrón y le dije al equipo: “Citar páginas web está bien y todo. Pero muchas de las cosas que los estudiantes citan están en libros o trabajos académicos. Necesitamos poder generar citas para esos también”.

Encontramos una API que podíamos usar para obtener información de citas basada en el ISBN (un número de serie utilizado para libros). Y creamos un script que podía buscar trabajos académicos basados en su DOI (un número de serie utilizado para trabajos académicos), y luego extraer datos de la página de resultados.

Para la noche del sábado, el código de nuestro complemento para navegador realmente estaba tomando forma. Así que me senté y empecé a preparar las diapositivas de la presentación. Dejé gran parte de la codificación final a mis compañeros mientras ensayaba mi presentación una y otra vez durante horas.

Aunque esta vez me tocaba dormir en una cama, apenas pude conciliar el sueño debido a los nervios. Aquí estaba, justo en el corazón del ecosistema tecnológico. Silicon Valley.

Como profesor, solía dar charlas frente a mis compañeros, a veces docenas de ellos. Pero esto era diferente.

En pocas horas, estaría presentando frente a una sala llena de desarrolladores ambiciosos. Y jueces. Personas con doctorados, algunos de los cuales habían fundado sus propias empresas tecnológicas. Iban a evaluar nuestro trabajo. Me aterraba arruinarlo de alguna manera.

Incapaz de dormir, abrí mi correo electrónico. El personal del Startup Weekend había enviado un correo electrónico, que incluía un PDF de un libro. Era una mezcla no oficial de los clásicos de inicio de tecnología 4 Steps to the Epiphany y The Lean Startup.

Ahora, ya había leído estos libros, porque eran lecturas obligatorias para cualquiera que quisiera construir productos de software a principios de la década de 2010. Pero también había leído docenas de otros libros sobre startups. Y muchos de sus conocimientos se mezclaron en un cúmulo de consejos.

Eran las 4 a.m. y no podía dormir. Así que comencé a leer. Una cosa en la que estos libros realmente incidían era en construir algo por lo que la gente estuviera dispuesta a pagar. La forma definitiva de validación del cliente.

Fue entonces cuando me di cuenta: ¿sabes qué realmente llevaría mi presentación a la meta? Prueba de la adecuación del producto al mercado. Prueba de que la aplicación que estábamos construyendo resolvía un problema real que las personas tenían. Tanto que estarían dispuestas a gastar dinero.

Esto me dio una idea. Debería llevar nuestra aplicación a la carretera y venderla a la gente.

Pero era domingo por la mañana. ¿Dónde iba a encontrar posibles clientes? Bueno, resulta que nuestro hotel estaba cerca del campus principal de la Universidad de Stanford.

Llevé a mi equipo al lugar del evento, me despedí y les dije: “Volveré cuando tenga dinero en efectivo frío y duro de los clientes”.

Mis compañeros se rieron. No estoy seguro si pensaron que estaba hablando en serio. Dijeron: “Solo no llegues tarde para la presentación”.

Pero hablaba en serio. Tenía un prototipo de la aplicación funcionando en mi computadora portátil. Ingresé Stanford en mi GPS y comencé mi misión.

Estudié en una universidad estatal realmente económica en Oklahoma. Así que me sentí completamente fuera de mi elemento cuando llegué a una de las principales universidades del mundo.

Stanford cuesta $50,000 al año para asistir. Y estacioné mi auto, que valía 1/10 de eso, en su estacionamiento.

El campus estaba desierto a esta hora de la semana. Pero un pueblo fantasma suntuoso, no obstante. Estatuas de bronce. Arcos icónicos por todas partes.

Me pregunté: ¿dónde están los estudiantes más destacados, más dedicados a esta hora del día? ¿Aquellos que no tienen tiempo para perder creando manualmente sus páginas de Citas Bibliográficas?

Entré a la biblioteca principal, justo pasando el escritorio de seguridad y un letrero que decía “prohibido solicitar”.

Recorrí las estanterías, encontrando a un puñado de personas estudiando. Había un chico tomando notas diligentemente mientras leía un grueso libro de texto. ¡Bingo!

Me deslicé en el asiento junto a él. “Psst. Oye. ¿Te gustan las citas?”

“¿Qué?”

“Citas. Ya sabes, como las páginas de citas de trabajo.”

“Ehm…”

“Ya sabes, la última página de tu trabajo, donde tienes que listar todos los…”

“Sé lo que es una página de citas.”

“De acuerdo. Pues mira esto.” Saqué mi chaqueta como si fuera traficante de drogas, y saqué mi netbook de $200. Él me siguió la corriente mientras hacía mi incómoda venta.

Dije: “Aquí. Tengo este plugin para el navegador. Voy a cualquier sitio web, hago clic en el botón y voilà. Creará una cita para mí.”

El chico levantó las cejas. “¿Puede hacerlo en MLA?”

Mordí mi emoción y dije: “MLA, APA e incluso Chicago. Mira.” Hice clic en el botón y aparecieron tres citas, cada una con su propio botón para copiar al portapapeles.

El chico asintió, pareciendo algo impresionado. Así que intenté cerrar la venta.

“¿Y si te dijera que estoy a punto de lanzar esta aplicación con una suscripción anual? Pero si te registras ahora, obtendrás acceso ilimitado no solo por un año, sino de por vida”.

El chico pensó por un momento.

Había oído que el silencio era el mejor amigo del vendedor. Así que me quedé sentado durante un tiempo incómodo en total silencio, mirándolo fijamente.

Finalmente él dijo: “Genial, me apunto”.

“Increíble. Eso serán veinte dólares”.

El chico se echó para atrás. “¿Qué? Eso es caro”.

Por supuesto, esta era la era de las startups subsidiadas por capital de riesgo, donde Uber y Lyft perdían dinero en cada viaje en una carrera por la cuota de mercado. Así que la reacción del chico no fue totalmente sorprendente.

Pero pensé rápidamente. “Bueno, ¿cuánto efectivo llevas contigo?”

Él buscó en su billetera y luego dijo: “cinco dólares”.

Miré el billete arrugado y encogí los hombros. “Vendido”.

Él sonrió, y le envié un correo electrónico con las instrucciones para instalarlo. Luego dije: “Una cosa más. Vamos a sacarnos una foto juntos”.

Puse mi teléfono en modo selfie. Él comenzó a sonreír, y dije: “Aquí. Sostén el billete de cinco dólares”.

Pasé otra hora tratando de convencer a la gente en la biblioteca y logré conseguir otro cliente de pago. Luego volé de regreso al lugar del evento para finalizar nuestro prototipo con el equipo.

Esa tarde, di lo que sigo pensando que fue la mejor presentación de mi vida. Mostramos en vivo la aplicación funcional, que funcionó perfectamente.

Terminamos la presentación con las fotos que había tomado, posando con estudiantes de Stanford que ahora eran nuestros clientes de pago. Cuando mostré el dinero que ganamos, la audiencia estalló en aplausos.

En general, fue una de las experiencias más emocionantes de mi vida. Quedamos en segundo lugar y ganamos crédito de API de una de las empresas que patrocinaron el evento.

En la fiesta posterior, engullí algo de pizza para tener más tiempo para relacionarme con todos. Me conecté en LinkedIn. Seguí en Twitter. Tomé selfies con la gente y usé ampliamente el hashtag del evento.

Este fue un momento decisivo en mi trayectoria como programador. Había demostrado a las personas de esa sala que podía ayudar a diseñar, programar e incluso vender una aplicación. Y lo que es más importante, me lo había demostrado a mí mismo.

Recorriendo el circuito de hackathones

A partir de ese momento, quedé enganchado a los hackathones. Ese año, participé en docenas de ellos. Me convertí en un guerrero de la carretera, recorriendo la costa de arriba abajo, asistiendo a todas las competiciones que podía.

A partir de ahí sería mucho más difícil. Ya no tenía un equipo. Estaba solo.

Llegaba, conocía a tanta gente como podía y luego subía al escenario a presentar una idea que pensaba que convencería a los jueces.

A veces la gente se unía a mi equipo. A veces yo me unía a los equipos de otras personas.

No solo quería diseñar aplicaciones, también quería programarlas. Y a menudo mis ambiciones superaban mis habilidades.

Hubo muchos hackathones en los que todavía intentaba solucionar errores hasta los últimos minutos antes de subir al escenario. A veces mis aplicaciones se colgaban durante las demostraciones en vivo.

En un hackathón en Las Vegas, arruiné el código de tal manera que solo pudimos usar una presentación de diapositivas. Me senté en la audiencia con la cabeza entre las manos, viendo impotente cómo mi compañero de equipo explicaba cómo funcionaría hipotéticamente nuestra aplicación, si yo hubiera logrado que funcionara. No nos fue bien con los jueces.

Pero seguí esforzándome. Seguí llegando a nuevas ciudades, registrándome en el albergue, y yendo al lugar, y comiendo toda la pizza gratis que podía.

Mis equipos habían quedado en segundo o tercer lugar tantas veces que apenas podía contar. Pero nunca habíamos logrado ganar un hackathon directamente.

Abriendo camino

Eso fue hasta un evento en San Diego. Nunca olvidaré la sensación de construir algo que conquistó al público y a los jueces a tal punto que nuestra victoria parecía un hecho inevitable.

Después de que nos anunciaron como los ganadores, recuerdo que salí sigilosamente por la puerta trasera hacia el estacionamiento y llamé a mis abuelos. Les dije que finalmente lo había logrado. Había ayudado a construir una aplicación y elaborar una propuesta que había ganado un hackathon.

No sé cuánto entendían mis abuelos sobre desarrollo de software o sobre hackathons. Pero dijeron que estaban orgullosos de mí.

Con ellos ya no aquí, a menudo pienso en esa conversación. Aprecio su aliento. Su fe en un nieto profesor de treintañero que podría intentarlo con todas sus fuerzas y convertirse en desarrollador.

Seguí asistiendo a hackathons después de eso. Seguí formando nuevos equipos y aprendiendo nuevas herramientas en el proceso. Nunca olvidarás la primera vez que haces que una API funcione. O cuando finalmente entiendes cómo funciona algún comando de Git. Y nunca olvidarás a las personas que se esfuerzan contigo, tratando de que la aplicación se mantenga unida durante la demostración.

El hackathon de TechCrunch Disrupt. El hackathon de DeveloperWeek. El hackathon de ProgrammableWeb. El hackathon de $1 Million Prize Salesforce. Tantos hackathons importantes y tanto aprendizaje. Este fue el crisol donde se forjaron mis habilidades de desarrollador.

No solo logré desarrollar mis habilidades y mi red en el proceso, ahora tenía una reputación como alguien que realmente podía ganar un hackathon.

Podía entregar resultados (ship).

Eso me convertía en un valor conocido.

Y esa reputación fue crucial para conseguir mis primeros clientes freelance, mi primer trabajo como desarrollador y, lo más importante, confiar en mis propios instintos como desarrollador.

Por qué tu reputación es tan importante

El papel de la reputación en la sociedad se remonta a la prehistoria humana. En la mayoría de las tribus y asentamientos, había algún sistema para mantener un registro de quién le debía qué a quién.

Antes de que existiera el dinero en efectivo, existía el crédito.

Esto podía ser un libro contable escrito o un anciano que simplemente llevaba todos los registros en su cabeza.

Más allá de la contabilidad, también había una vibración menos tangible, pero igualmente importante, que las personas llevaban consigo.

“John sabe cómo herrar un caballo.”

O “Jane es la mejor narradora de historias de la tierra.”

O “El coraje de Jay en la batalla nos salvó de los invasores hace tres inviernos.”

Te darás cuenta de que todos estos ejemplos implican que alguien sea bueno en algo. No simplemente ser una persona agradable y simpática.

Ciertamente, ayuda ser una persona tranquila y accesible. Pero esto no es The Big Lebowski, y no vamos a sobrevivir solo con nuestro encanto.

Un desarrollador puede decir fácilmente: “Oh sí, conozco JavaScript como la palma de mi mano. Puedo construir cualquier tipo de aplicación JavaScript que necesites, que se ejecute en cualquier dispositivo que puedas imaginar.”

O decir: “Entrego código dentro del presupuesto y antes de tiempo, todo el tiempo.”

Pero, ¿cómo sabes que no están exagerando sus afirmaciones?

Después de todo, un hombre astuto una vez dijo:

“Si solo puedes ser bueno en una cosa, sé bueno mintiendo. Entonces eres bueno en todo.”

(Se desconoce el origen verdadero de esta cita. Pero me gusta imaginar que fue dicho por un estafador de los años 20 con sombrero de copa y monóculo.)

Cualquiera puede mentir. Y algunas personas lo hacen.

Al principio de mi carrera, tuve la desagradable tarea de despedir a un profesor que había mentido sobre tener un máster. Pasaron los años y nadie se dio cuenta.

Cada año, mentía en su documentación anual, para obtener un aumento de sueldo más alto que los demás profesores. Y cada año, se salía con la suya.

Pero un día, una pequeña discrepancia me llamó la atención. Revisé su archivo, llamé a algunos departamentos de registro universitario y descubrí que nunca se molestó en terminar su carrera.

Cuando lo atrapé fue como un verdadero momento de Scooby Doo. “Y me habría salido con la mía, si no fuera por ustedes malditos chicos.”

Fue frustrante saber que esta persona enseñaba en la escuela durante años y ganaba más dinero que muchos otros profesores, solo porque estaba dispuesto a mentir.

El botín de las mentiras siempre está ahí, brillante. Algunas personas están dispuestas a sucumbir a esa tentación.

Los empleadores lo saben. Saben que no pueden confiar en cualquier persona que afirme conocer el desarrollo de JavaScript de pila completa. Debes ser cauteloso acerca de quién obtiene una credencial de la empresa, una dirección de correo electrónico de la empresa y las llaves para tus bases de datos de producción.

Por eso los empleadores utilizan preguntas de entrevista de comportamiento, para intentar atrapar a personas que son más propensas a ser deshonestas.

Llámame ingenuo, pero creo que la mayoría de las personas son inherentemente buenas. La mayoría de las personas están dispuestas a jugar según las reglas, siempre y cuando esas reglas sean razonablemente justas.

Pero si incluso una persona de cada diez sería una contratación desastrosa, significa que todos estamos sujetos a un escrutinio más riguroso.

El peor escenario no es simplemente alguien que miente para ganar más dinero. Es alguien que vende secretos de la empresa, destruye relaciones con los clientes o rompe las leyes en nombre de inflar sus números.

La historia está llena de empleados que causaron un daño catastrófico a sus empleadores, todo por su beneficio personal.

Por lo tanto, el proceso de contratación de desarrolladores en la mayoría de las grandes empresas es paranoico como el infierno. Tal vez así debe ser. Pero desafortunadamente, esto dificulta que todos obtengan un trabajo de desarrollador, incluso los candidatos más honestos.

Como desarrolladores, necesitamos pruebas de que nuestras habilidades son tan sólidas como decimos que son. Necesitamos pruebas de que nuestra ética de trabajo es tan firme como nuestros empleadores lo necesitan.

Aquí es donde entra en juego la reputación. Reduce la ambigüedad. Reduce el riesgo de contraparte. Hace que sea más seguro para los empleadores hacer una oferta de trabajo y firmar un contrato de empleo contigo.

Esto significa que, si tienes una reputación lo suficientemente fuerte, puedes ingresar a la empresa a través de una puerta lateral en lugar de la puerta principal por la que se alinean otros solicitantes.

Algunas empresas incluso tienen reclutadores internos que pueden acelerar tu proceso de entrevista. Una reputación sólida también puede ayudarte a tener más poder de negociación durante las negociaciones salariales.

Así que hablemos de cómo puedes construir una reputación sólida y convertirte en alguien solicitado por los gerentes.

Cómo construir tu reputación como desarrollador

Hay al menos seis formas probadas en el tiempo en las que puedes construir tu reputación como desarrollador. Estas son:

1. Hackathons
2. Contribuir a proyectos de código abierto
3. Crear contenido enfocado en desarrollo
4. Ascender en las filas trabajando en empresas con “nombre conocido”
5. Construir un portafolio de clientes independientes
6. Iniciar tu propio proyecto de código abierto, empresa o organización benéfica

Cómo encontrar hackathons y otras competiciones de desarrollo

Los hackathons representan la forma más inmediata de construir tu reputación, tu red y tus habilidades de programación al mismo tiempo.

La mayoría de los hackathons son gratuitos y están abiertos al público. Solo necesitas tener tiempo y presupuesto para viajar.

Si vives en una ciudad con muchos hackathons, como San Francisco, Nueva York, Bengaluru o Beijing, es posible que puedas ir y volver al evento y luego dormir en tu propia cama.

Aunque yo vivía en Santa Bárbara, que solo tenía hackathons una vez cada pocos meses, tenía un compañero de clase en San Francisco que me dejaba quedarme en su sofá. Esto me dio acceso a muchos más eventos.

Antes, los hackathons eran eventos muy intensos. Las personas tomaban bebidas energéticas y dormían en el suelo para terminar su proyecto a tiempo de presentarlo.

Pero los organizadores de hackathons cada vez son más conscientes de la salud y la sostenibilidad de estos eventos. Después de todo, muchos de los participantes tienen hijos o empleos de tiempo completo, y no pueden dedicarse únicamente a programar durante todo un fin de semana.

La mejor manera de encontrar eventos próximos es simplemente buscar en Google “hackathon [nombre de tu ciudad]” y explorar los distintos calendarios de eventos que aparecen en los resultados de búsqueda. Muchos de ellos serán organizados por universidades, empleadores locales o incluso organizaciones benéficas enfocadas en la educación.

Si juegas para ganar, te recomiendo que investigues de antemano.

¿Quiénes son los patrocinadores del evento? Por lo general, serán empresas del tipo Business-to-Developer, con API, herramientas de bases de datos u diversas ofertas de Software-as-a-Service.

Estos patrocinadores probablemente tendrán un stand en el evento donde podrás hablar con sus defensores de desarrolladores. Estas son personas que se les paga para enseñar a la gente cómo usar las herramientas de la empresa. A veces incluso conocerás a empleados clave o fundadores en estos stands, lo cual también puede ser una excelente oportunidad de networking.

A menudo, el hackathon ofrecerá premios específicos de cada patrocinador. “Mejor uso de la API de [patrocinador].” Puede ser más fácil centrar tu tiempo en incorporar herramientas específicas del patrocinador en tu proyecto, en lugar de intentar ganar el gran premio. Aún así, puedes mencionar estos logros en tu LinkedIn o tu currículum. Una victoria es una victoria.

A veces, el hackathon es tan importante, o el premio es tan sustancial, que tiene sentido intentar ganar la competencia directamente.

En mi tiempo asistiendo a hackathones, pude ganar premios en efectivo que equivalían a varios meses de alquiler, años de espacio de coworking gratuito e incluso una visita privada al edificio de las Naciones Unidas en la ciudad de Nueva York.

En el circuito de los hackathones, conocí a personas cuya principal fuente de ingresos eran los premios en efectivo por ganar hackathones. Un desarrollador que conocía logró ganar nueve premios de patrocinadores en el mismo hackathon. Logró integrar todas esas herramientas de patrocinadores en su proyecto y también ganó el segundo lugar en general.

No te sorprendas si algunas de las personas con las que te encuentres frecuentemente en los hackathones terminan fundando empresas respaldadas por capital de riesgo o lanzando proyectos destacados de código abierto.

El nivel de ambición que verás entre los habituales de los hackathones es mucho, mucho mayor que el de los desarrolladores promedio. Después de todo, son personas que terminan su semana de trabajo y luego se sumergen directamente en un fin de semana de trabajo. Estas personas no tienen miedo de salir de la sartén y meterse en el fuego.

Cómo contribuir al código abierto

Contribuir al código abierto es una de las formas más inmediatas en que puedes construir tu reputación. La mayoría de los empleadores revisarán tu perfil de GitHub, que mostrará de manera prominente tu historial de confirmaciones de Git.

Muchos mantenedores de proyectos de código abierto, como la Fundación Linux, Mozilla (Firefox) y, por supuesto, freeCodeCamp en sí, tienen altos estándares de calidad de código.

Puedes leer los problemas abiertos en GitHub para encontrar errores conocidos o solicitudes de funciones. Luego, puedes hacer cambios en el código y abrir una solicitud de extracción. Si los mantenedores aceptan tus cambios, esto será un gran logro.

Una de las mejores formas de conseguir trabajo en una empresa tecnológica es convertirte en un prolífico contribuyente de código abierto en sus repositorios.

La contribución al código abierto es una excelente manera de construir tu reputación porque todo lo que haces está a la vista del público. Y obtienes la prueba social de que otros desarrolladores revisan y aceptan tu trabajo.

Si estás interesado en construir tu reputación a través del código abierto, aquí tienes cómo comenzar.

Lee la guía completa de Hillary Nyakundi sobre cómo empezar con el código abierto.

Cómo crear contenido enfocado en desarrolladores

Los desarrolladores son personas. Y al igual que otras personas, quieren hacer algo con su tiempo cuando no están trabajando, durmiendo o pasando tiempo con amigos y familiares.

Para muchas personas, incluyéndome a mí, eso significa pasar tiempo en los pensamientos de otras personas. Libros. Ensayos en video. Experiencias interactivas como novelas visuales.

Puedes incluir todo esto dentro de la categoría de “contenido”. No soy muy fanático de la palabra, porque hace que estas obras se sientan desechables. Pero así es como las llaman las personas.

El desarrollo de software es un campo increíblemente amplio, con tantos temas diferentes a los que puedes abordar. Hay vlogs de estilo de vida para desarrolladores, tutoriales de preparación de entrevistas de código, transmisiones en vivo de programación en Twitch y podcasts de entrevistas a desarrolladores como el Podcast de freeCodeCamp.

Probablemente haya categorías completas de contenido para desarrolladores que aún no hemos pensado, las cuales surgirán en la próxima década.

Si estás interesado en el cine, el periodismo o la escritura creativa, el contenido de desarrollador puede ser una buena manera de construir tu reputación.

Puedes elegir un tema específico y gradualmente ser visto como el experto.

Hay desarrolladores que se especializan en tutoriales para pilas de tecnología específicas, por ejemplo.

Mi amigo Andrew Brown es un ex CTO de Toronto que ha pasado todos los principales exámenes de DevOps. Crea cursos gratuitos para prepararte para todas las certificaciones de AWS, Azure y Google Cloud, y también dirige un servicio de preparación para exámenes.

Hay más de 30 millones de desarrolladores de software en todo el mundo. Eso es mucha gente que potencialmente consumirá tu contenido y que llegará a conocerte.

Cómo ascender en los rangos trabajando en grandes empresas

Puede que hayas visto a un desarrollador presentado como un “Ex Googler” o un “Ex ingeniero de Netflix”.

Algunas empresas tecnológicas tienen procesos de contratación tan rigurosos y estándares tan altos que incluso conseguir un trabajo en la empresa es un gran logro.

Hay algunas razones prácticas por las que los empleadores miran dónde han trabajado los candidatos anteriormente. Reduce el riesgo de una mala contratación.

Puedes construir tu reputación ascendiendo en la jerarquía de prestigio. Puedes ir desde un empleador local hasta una empresa Fortune 500 y, en última instancia, llegar a una de las grandes compañías tecnológicas.

Por supuesto, trabajar en una gran corporación no es para todos. Hablaré más sobre esto en el Capítulo 4. Pero debes saber que es una opción que tienes para construir tu reputación.

Cómo construir tu reputación creando un portafolio de clientes freelance

Puedes construir tu reputación trabajando con empresas como freelancer.

Los desarrolladores freelance suelen trabajar en proyectos más pequeños de una sola persona. Por lo que esta puede ser una mejor estrategia para construir tu reputación a nivel local.

Por ejemplo, si hiciste un buen trabajo para un banco con sede local, eso puede ser suficiente para convencer a un bufete de abogados local de contratarte también.

Hay algo que decir acerca de ser un “héroe local”. Conozco a muchos desarrolladores que pueden competir eficazmente con la competencia en línea simplemente por estar presentes físicamente en las reuniones y conocer a la gente localmente.

Cómo construir un portafolio de desarrollador de tu trabajo

Una vez que hayas construido algunos proyectos, querrás mostrarlos. Y la mejor manera de hacerlo es con videos cortos.

La gente está ocupada. No tiene tiempo para descargar tu código y ejecutarlo en su propio ordenador.

Y si envías a la gente a un sitio web, es posible que no comprendan completamente lo que están viendo y por qué es tan especial.

Por eso te recomiendo que uses una herramienta de captura de pantalla para grabar demos de video de 2 minutos.

Dos minutos deberían ser suficientes para mostrar cómo funciona el proyecto. Y una vez que hayas hecho eso, puedes explicar algunos detalles de implementación y decisiones de diseño que tomaste.

Pero siempre, siempre comienza con la demostración. La gente quiere ver algo funcionar. Quieren ver algo visual.

Una vez que hayas atraído a las personas con tu demostración convincente de tu aplicación en funcionamiento, puedes explicar todos los detalles que quieras. Tu audiencia tendrá más contexto y estará más interesada.

Dos minutos también es una duración mágica, porque puedes subir ese video a un tweet y se reproducirá automáticamente en Twitter mientras la gente lo ve pasar. Los videos de reproducción automática se ven mucho, mucho más en Twitter. Eliminan la fricción de tener que hacer clic en un botón de reproducción o navegar a otro sitio web.

So a freeCodeCamp alum built their own twitter.

Like… so many of the core features and UI elements.

It looks uncanny.🦹

🧑‍💻 Code by Risal
🥁 Music by me pic.twitter.com/cFDjNxthnF

— Quincy Larson (@ossia) December 15, 2022

Puedes poner estos videos de demostración de proyectos en sitios web como YouTube, Twitter, tu perfil de GitHub y, por supuesto, tu propio sitio web de portafolio.

Para capturar este video, recomiendo usar QuickTime, que viene incorporado con MacOS. Y si estás en Windows, puedes usar Game Recorder, que viene gratis en Windows 10.

Y si deseas una herramienta más potente, OBS es gratuita y de código abierto. Es más difícil de aprender, pero infinitamente personalizable.

En cuanto a consejos de grabación: mantén el tamaño de fuente lo más grande posible y usa un micrófono externo. Cualquier micrófono que puedas encontrar, incluso de auriculares baratos, será mejor que hablar en el micrófono incorporado de tu laptop.

Invierte tanto tiempo como necesites en grabar y volver a grabar tomas hasta que lo claves.

Poder demostrar tus proyectos y presentar tu código es una habilidad valiosa que utilizarás a lo largo de tu carrera. El tiempo que dediques a practicar nunca será desperdiciado.

Cómo Empezar tu Propio Proyecto de Código Abierto, Empresa o Caridad

Ser fundador es la forma más rápida, pero también la más arriesgada, de construir una reputación como desarrollador.

Es arriesgada porque estás apostando tu tiempo, tu dinero, y posiblemente incluso tus relaciones personales, todo por un resultado desconocido.

Si contribuyes lo suficiente en código abierto, construirás una reputación como desarrollador.

Si participas en suficientes hackathons, construirás una reputación como desarrollador.

Pero podrías intentar iniciar proyectos empresariales durante décadas sin obtener tracción. Y malgastar tu tiempo, dinero y conexiones en el camino.

El emprendimiento va más allá del alcance de este libro. Pero si estás interesado, te daré este consejo rápido:

La mayoría de los emprendedores fracasan. Algunos fracasan por circunstancias fuera de su control. Pero muchos fracasan porque no entienden la naturaleza de los riesgos que asumen.

No te precipites a fundar un proyecto, una empresa o una caridad. Intenta trabajar para otras organizaciones que ya estén trabajando en tu campo de interés.

Al trabajar para alguien más, te pagan para aprender. Tienes exposición al trabajo y a los riesgos que lo rodean. Y puedes ahorrar para una futura empresa emprendedora.

Cómo No Destruir tu Reputación

“Se tarda toda una vida en construir una buena reputación, pero puedes perderla en un minuto.” – Will Rogers, Actor, Cowboy, y uno de mis héroes mientras crecía en Oklahoma City

Construir tu reputación es una maratón, no una carrera de velocidad.

Puede llevar años construir una reputación lo suficientemente sólida como para abrir las puertas adecuadas.

Pero al igual que en una maratón competitiva, un tropiezo puede costarte tiempo valioso. Un tropiezo que resulte en una lesión puede sacarte completamente de la carrera.

No Digas Cosas Estúpidas en Internet

La gente solía decir cosas estúpidas todo el tiempo. Las palabras podían quedarse en el aire durante unos minutos mientras todos se retorcían. Pero las palabras eventualmente se disipaban.

Ahora, cuando la gente dice cosas estúpidas, a menudo lo hacen en línea. Y en tinta indeleble.

Siempre debes asumir que en el momento en que escribes algo en un sitio web y presionas enter, se guardará en una base de datos. Esa base de datos se respaldará en varios centros de datos alrededor del mundo.

Puedes demostrar la existencia de datos, pero no hay forma de demostrar la ausencia de datos.

Debes asumir, para todos los efectos prácticos, que el gato está fuera de la bolsa. No se puede volver a meter el gato en la bolsa. Lo que acabas de decir: está en tu expediente permanente.

Puedes borrar el comentario. Puedes eliminar tu cuenta. Incluso puedes intentar eliminarlo de los resultados de búsqueda de Google. Pero alguien probablemente ya lo haya respaldado en la Máquina Wayback. Y cuando una de esas bases de datos inevitablemente sea hackeada dentro de años, esos datos probablemente todavía estén ahí en algún lugar, listos para que alguien los vuelva a aparecer.

Es un momento aterrador para ser un bocazas. Así que no lo seas. Piensa antes de hablar.

Mi consejo, que puede sonar cobarde: deja de discutir con gente en línea.

Algunas personas siguen la regla del patio de recreo de “si no tienes algo agradable que decir, no digas nada en absoluto”.

Prefiero la regla de “elogia en público, critica en privado”.

Reconoceré públicamente el buen trabajo que alguien está haciendo en la comunidad de desarrolladores. Si veo un proyecto que me impresiona, lo diré.

Pero generalmente me abstengo de derribar a la gente. Incluso a las personas que se lo merecen.

En una pelea, todos salen sucios.

No quieres parecer iracundo, destrozando el argumento de alguien o uniéndote a alguien que acaba de decir algo estúpido.

Por supuesto, el ingenio ácido puede ganarte puntos en internet a corto plazo. Pero también puede hacer que la gente te quiera un poco menos y te tema un poco más.

También trato de abstenerme de quejarme. Sí, probablemente podría obtener un mejor servicio al cliente si amenazo con tuitear sobre un vuelo cancelado.

Pero la gente está ocupada. La mayoría de ellos no quieren desperdiciar su tiempo escrolleando en redes sociales solo para verme quejarme de lo que, en el gran esquema de las cosas, es una pequeña molestia.

Entonces, ese es mi consejo sobre el uso de las redes sociales. Intenta mantenerlo positivo.

Si es un asunto en el que crees firmemente, no voy a impedirte que expreses tu opinión. Solo piensa antes de escribir y piensa antes de enviarlo.

No te comprometas demasiado y no cumplas lo prometido

Una de las formas más comunes en las que veo a los desarrolladores arruinar su propia reputación es comprometerse demasiado y no cumplir lo prometido. Esto no es necesariamente un error fatal. Pero es malo.

¿Recuerdas cuando hablé del hackatón de Las Vegas donde fracasé por completo en terminar el proyecto a tiempo para presentarlo, y tuvimos que usar diapositivas en lugar de una aplicación funcionando?

Sí, ese fue uno de los puntos más bajos en mi aprendizaje para codificar. Mis compañeros de equipo fueron amables, pero estoy seguro de que estaban decepcionados conmigo. Después de todo, había sido demasiado confiado. Había prometido más de lo que sería capaz de lograr en ese lapso de tiempo, y no cumplí lo prometido.

Es mucho mejor ser modesto en tus estimaciones de tus habilidades.

Recuerda la parábola de Ícaro, quien voló demasiado cerca del sol con alas de cera. Si tan solo hubiera adoptado un enfoque más mesurado. Ascendido un poco más despacio. Entonces sus alas no se habrían derretido, y no habría caído al mar dejando a un padre lleno de culpa.

Controla las adicciones antes de dañar tu reputación

Si tienes una adicción no tratada a las drogas, el alcohol o el juego, busca ayuda primero. La búsqueda de empleo en desarrollo puede ser larga y agotadora. Quieres enfrentarla con toda tu atención.

Incluso algo aparentemente inofensivo como la adicción a los videojuegos puede distraerte y absorber demasiado tiempo. Vale la pena controlarlo primero.

No soy médico y no voy a darte un discurso de “las drogas son malas”. Pero diré esto: es posible que hayas escuchado sobre las tendencias en Silicon Valley, donde los desarrolladores abusan de las drogas pensando que de alguna manera pueden mejorar su capacidad de codificación o resolución de problemas.

Hubo una tendencia de “microdosis de LSD”. Hubo una tendencia de anfetaminas farmacéuticas.

Mi reacción instintiva ante eso es: cualquier ventaja que puedan darte probablemente no sea sostenible y sea un resultado negativo a largo plazo.

No sientas presión de grupo para consumir drogas psicoactivas. No sientas presión de grupo para beber en los happy hours. (No he tomado ni siquiera una cerveza desde que nació mi hija hace 8 años, y no siento que me haya perdido de nada en absoluto.)

Si estás en recuperación de una adicción, ten en cuenta que aprender a programar y obtener un empleo como desarrollador será un proceso estresante. Ve a tu propio ritmo para no arriesgarte a una recaída.

No querrás llegar al final del proceso de transición de carrera y lograr tanto, solo para que los viejos hábitos resurjan y deshagan tu arduo trabajo.

Intenta separar tu vida profesional de tu vida personal

Es posible que hayas escuchado la expresión “no mezcles los negocios con el placer”.

Como desarrollador, te convertirás en una persona poderosa. Comandarás cierto grado de respeto de otras personas en tu ciudad.

Tal vez no tanto como un médico o un astronauta. Pero aún así, las personas te admirarán.

Vas a hablar con personas que desearían estar en tu lugar.

No presumas de tu riqueza.

No actúes como si fueras más inteligente que todos los demás.

No abuses de la dinámica de poder para obtener lo que quieres en tus relaciones.

Esto te hará antipático a las personas que te rodean. Y si alguien lo captura y lo publica en línea, podría perseguirte durante el resto de tu carrera.

No pierdas de vista todo lo que tienes. Y todo lo que tienes en juego.

Usa el truco del narrador

Terminaré este capítulo con un pequeño truco que uso para motivarme.

Primero, recuerda que eres el héroe de tu propio viaje de codificación. En el teatro de tu mente, eres la persona a la que todos están observando, aquella por la que están animando.

El Truco del Narrador consiste en narrar tus acciones en tu cabeza mientras las llevas a cabo.

Quincy atraviesa el hackerspace con su computadora portátil bajo el brazo. Coloca su taza debajo del dispensador de agua caliente y deja caer una bolsita de té fresca. Tira de la palanca. Y mientras el agua humeante llena su taza, dice en voz alta con su mejor acento británico: “Té. Earl Grey. Caliente”. Con su bebida energizante en la mano, se desliza en una cabina, coloca su computadora en la superficie y cruza miradas con otro desarrollador. Se miran fijamente por un segundo. Quincy inclina ligeramente la cabeza, reconociendo la presencia del desarrollador. El desarrollador inclina la cabeza en señal de saludo, compartiendo casi telepáticamente este sentimiento: “Te veo, amigo. Te veo presentándote. Te veo terminando las tareas”.

Esto puede sonar ridículo. Y sí, lo es. Pero lo hago todo el tiempo. Y funciona.

Narrar incluso los momentos más mundanos de tu vida en tu cabeza puede ayudarte a energizarte. Clarifica el momento que tienes ante ti y te da claridad de propósito.

Y esto funciona aún mejor cuando piensas en tu vida en términos de épocas (“los años de Taco Bell”). O puntos de inflexión (“pasar el examen de GED”).

¿Qué tiene esto que ver con construir tu reputación? Tu reputación es básicamente el resumen de quién eres. Lo que significas para las personas que te rodean.

Al tomarte más en serio, al pensar en tu vida como una película, vas trabajando gradualmente en quién eres y en quién quieres llegar a ser algún día.

Al narrar tus acciones, iluminas más su significado en tu propia mente. ¿Por qué acabo de hacer eso? ¿En qué estaba pensando? ¿Había una mejor opción?

Muchas personas sabotean sus reputaciones sin siquiera darse cuenta, simplemente porque han caído en malos hábitos.

Durante años pensé que tenía que ser “divertido” todo el tiempo. Buscaba cualquier oportunidad para agregar un poco de humor autodepreciativo. Muchas personas se daban cuenta de lo que estaba haciendo y lo encontraban divertido. Pero muchas otras no lo entendían y se llevaban la impresión de que era un idiota.

¿Por qué lo hacía? Creo que se remonta a la escuela primaria, cuando siempre trataba de ser el payaso de la clase y hacer reír a la gente.

Pero décadas después, este reflejo de llenar el silencio con risas no me estaba sirviendo bien.

“Cuando repites un error, deja de ser un error. Se convierte en una decisión.” – Paulo Coelho

Tal vez habría seguido mucho tiempo sin darme cuenta de este mal hábito. Pero con el Truco del Narrador, la torpeza de mi comportamiento quedó al descubierto.

Estoy seguro de que tengo muchas otras formas de pensar y formas de hacer las cosas que no son óptimas. Y con la ayuda del Truco del Narrador, espero identificarlas en el futuro y mejorarlas antes de que den a las personas una impresión equivocada.

Tu Reputación Se Convertirá en tu Legado.

Piensa en quién quieres ser al final de tu historia. Cómo quieres que las personas piensen en tu tiempo en la Tierra. Luego trabaja hacia atrás desde ahí.

La persona que quieres ser al final de la película. Ese héroe que quieres que las personas admiren. ¿Por qué no empezar a comportarte así desde ahora?

¿Puedes imaginar cómo sería ser un desarrollador exitoso? ¿Haber construido sistemas de software en los que la gente dependa?

Ese “tú” del futuro, ¿cómo pensaría? ¿Cómo abordaría situaciones y resolvería problemas? ¿Cómo hablaría de sus logros? ¿De sus contratiempos?

Solo pensar en tu futuro yo puede ayudarte a aclarar tu forma de pensar. Tus prioridades.

A menudo pienso en “Old Man Quincy”, con su dolor de espalda. Tiene que disculparse para correr al baño cada 30 minutos.

Pero Old Man Quincy aún hace todo lo posible para trabajar con lo que tiene. Se mueve a pesar de sus articulaciones doloridas. Reflexiona a pesar de una mente nublada.

Old Man Quincy todavía quiere terminar las tareas. Está orgulloso de lo que ha logrado, pero no pasa mucho tiempo mirando hacia atrás. Mira hacia adelante lo que hará ese día y qué metas cumplirá.

A menudo pienso en Old Man Quincy y retrocedo hasta dónde estoy hoy.

¿Qué decisiones puedo tomar hoy que me preparen para ser alguien digno de admiración mañana? ¿Tengo que esperar décadas para ganarme esa reputación? ¿O puedo “pedir prestado” algo de ese respeto del futuro?

Pensando en cómo mi yo del futuro podría pensar, ¿puedo tomar decisiones que me den una buena reputación en el presente?

Creo que puedes aprovechar tu reputación futura, tu legado, en este momento. Solo piensa en términos de tu yo del futuro y en lo que lograrás. Y usa eso como un punto de referencia para guiarte hacia adelante.

Espero que estas herramientas, el “Truco del Narrador” y visualizar a tu yo del futuro, te ayuden no solo a reflexionar sobre la naturaleza de la reputación. Espero que también te ayuden a dar pasos concretos hacia la mejora de tu reputación.

Porque construir una reputación, hacerse un nombre, es el camino más seguro hacia el éxito sostenible como desarrollador.

El éxito puede significar muchas cosas para muchas personas. Pero la mayoría de la gente, de la mayoría de las culturas, estaría de acuerdo: un gran aspecto del éxito es poder poner comida en la mesa para ti y tu familia.

Y eso es de lo que vamos a hablar a continuación.

Capítulo 4: Cómo ganar dinero programando – Clientes freelance y la búsqueda de empleo

Si has estado desarrollando tus habilidades, tu red y tu reputación, entonces conseguir un trabajo como desarrollador no es tan complicado.

Nota que dije que no es complicado, todavía es mucho trabajo. Y puede ser agotador.

Primero, déjame contarte cómo conseguí mi primer trabajo.

Tiempo de Historia: ¿Cómo consiguió un profesor en sus 30s su primer trabajo como desarrollador?

En el último episodio de Tiempo de Historia: Quincy se metió de lleno en el circuito de hackathones, incluso ganando algunos de ellos. Estaba construyendo su reputación como un desarrollador “peligroso” con JavaScript. No muy talentoso. Sólo peligroso…

Acababa de terminar un largo día de aprendizaje en la biblioteca del centro de Santa Bárbara, tomando té y construyendo proyectos.

Lo mejor de vivir en California es el clima. Bromeábamos diciendo que cuando alquilabas un costoso apartamento de una habitación en los suburbios, no estabas pagando por el interior, estabas pagando por el exterior.

Mi objetivo era pasar el menor tiempo posible en esa antigua trampa de ratas de 100 años y pasar el resto del tiempo paseando por la ciudad.

Era una hermosa tarde de miércoles. Todavía me quedaban dos días más para prepararme para el hackathon del fin de semana. Y mi cerebro estaba completamente agotado después del día de programación. Mi esposa estaba trabajando hasta tarde, así que revisé mi calendario para encontrar algo qué hacer.

El primer lunes de cada mes, mapeaba todos los eventos tecnológicos que se llevarían a cabo en el sur de California durante ese mes, así siempre tenía un evento al que asistir si tenía energía suficiente.

Ah, esta noche es la reunión de Santa Bárbara Ruby on Rails, y ya había confirmado mi asistencia.

No sabía mucho sobre Ruby on Rails, pero había completado algunos pequeños proyectos con él. Yo era más desarrollador de JavaScript y Python.

Pero pensé, qué diablos. Necesito mantener mi impulso en la construcción de mi red. Y el lugar estaba a solo unas cuadras de distancia.

Entré y eran solo unos pocos desarrolladores sentados alrededor de una mesa charlando. Rápidamente quedó claro que todos trabajaban juntos en una empresa local, manteniendo una gran base de código de Ruby on Rails. La mayoría de ellos habían estado trabajando allí durante varios años.

En este punto, había pasado el último año desarrollando mis habilidades, mi red y mi reputación. Así que pude mantenerme durante la conversación.

Pero también tenía una idea de los límites de mis habilidades. Así que me mantuve modesto. Sin exagerar. De la misma manera en que había visto a muchos otros desarrolladores exitosos maniobrar una conversación en eventos tecnológicos.

Quedó claro que uno de los desarrolladores en la mesa era el Director de Ingeniería. Reportaba directamente al CTO.

Y luego quedó claro que estaban buscando contratar desarrolladores de Ruby on Rails.

Fui sincero sobre mi experiencia y mis habilidades. “Mi formación está en educación de adultos. Enseñanza de inglés y administración de escuelas. Recién comencé a aprender a programar hace aproximadamente un año”.

Pero el hombre sorprendentemente no pareció importarle. “Bueno, si quieres venir para una entrevista, podemos ver si serías adecuado para el equipo”.

Esa noche caminé a casa sintiendo una especie de electricidad. Era mucho más temor que emoción.

No me sentía ni cerca de estar preparado. Y ni siquiera estaba buscando trabajo. Solo vivía de mis ahorros, aprendiendo a programar a tiempo completo, con seguro médico a través del trabajo de mi esposa.

Era un ahorrador compulsivo. La gente me criticaba por eso. Yo mismo cambiaba el aceite de mi coche, me cortaba el pelo y hasta cocinaba mi propio arroz en casa cuando pedíamos comida para llevar, solo para ahorrar unos cuantos dólares.

A lo largo de la década en la que trabajé como maestro, logré ahorrar casi una cuarta parte de mis ingresos después de impuestos. Y compraba videojuegos antiguos en Craigslist para luego venderlos en eBay. Puede sonar tonto, pero era una fuente de ingresos importante para mí.

¿Para qué estábamos ahorrando todo esto? No estábamos seguros. ¿Quizás para comprar una casa en California en algún momento en el futuro? Pero significaba que no tenía que esforzarme por conseguir un trabajo. Sabía que estaba en una posición privilegiada e intentaba aprovecharla al máximo aprendiendo más cada día.

En resumen, no creía estar listo para mi primer trabajo como desarrollador. Y me preocupaba que si me contrataban, sería un gran error. Se darían cuenta de lo de poca experiencia que era, me despedirían y luego tendría que explicar ese fracaso en futuras entrevistas laborales.

Por supuesto, ahora sé que estaba viendo esta oportunidad de manera equivocada. Pero permíteme terminar la historia.

Cuando programé mi entrevista de trabajo, me pidieron un currículum. No estaba seguro de qué hacer, así que incluí toda mi experiencia profesional allí. Todas las escuelas en las que había trabajado a lo largo de los años. (Omití el tiempo que trabajé en el drive-thru en Taco Bell.)

Por supuesto, ninguna de mis experiencias laborales tenía nada que ver con la programación. Pero ¿qué se suponía que debía hacer, entregarles una hoja de papel en blanco?

Bueno, tenía un portafolio en línea de proyectos que había creado. Y lo más importante, tenía una lista de todos los hackatones en los que había ganado o quedado en los primeros lugares. Así que los incluí.

Pasé las últimas horas antes de la entrevista revisando todos los tutoriales de Ruby on Rails que había utilizado durante el último año, para refrescar mi memoria. Luego me puse mi sudadera, jeans y mochila, y caminé hacia su oficina.

La gerente de la oficina era una señora amable que me llevó a la oficina de desarrollo y me presentó a su pequeño equipo de desarrolladores. Había tal vez una docena de ellos, la mayoría vestidos con jeans y sudaderas, desde principios de los 20 hasta finales de los 40. Dos de ellos eran mujeres.

Fui pasando por el enredo de escritorios y cables, estrechando la mano de cada uno de ellos y presentándome. Aquí es donde toda mi experiencia como maestro memorizando los nombres de los alumnos me resultó útil. Pude recordar todos sus nombres, para que luego a lo largo del día cuando me fuera, pudiera hablar con cada uno de ellos: “Fue un gusto conocerte [nombre]. Estaría emocionado de trabajar contigo.”

Primero me reuní con el director de ingeniería. Fuimos a una pequeña oficina y cerramos la puerta.

Un pizarrón en la pared estaba lleno de bocetos de diagramas de lenguaje unificado de modelado (UML). Un arco iris de marcadores de borrado en seco mostraba las relaciones entre varios servidores y servicios.

No dejaba de mirar ese pizarrón, temiendo que me pidiera resolver algunos problemas de programación y demostrar mis habilidades. ¿Quizás el famoso problema FizzBuzz? ¿Quizás quería que invirtiera un árbol binario?

Pero ni siquiera mencionó el pizarrón. Solo se quedó sentado mirándome intensamente todo el tiempo.

Eran una empresa de aproximadamente 50 empleados, con mucho financiamiento de capital de riesgo y miles de clientes de pago, principalmente pequeñas empresas. Se enorgullecían de ser pragmáticos. En ningún momento preguntaron sobre lo que estudié en la escuela o qué tipo de trabajo había hecho en el pasado. Lo único que realmente les importaba era…

“Mira, sé que puedes programar”, dijo. “Has estado programando todo este tiempo, ganando hackatones. Vi algunos de tus proyectos en tu portafolio. La calidad del código estaba bien para alguien que es nuevo en la programación. Así que para mí, la verdadera pregunta es: ¿puedes aprender cómo hacemos las cosas aquí? ¿Puedes trabajar con los demás desarrolladores del equipo? Y lo más importante: ¿puedes lograr que las cosas se hagan?”

Tragué saliva, me incliné hacia adelante y reuní toda la confianza que pude. “Sí”, dije. “Creo que puedo.”

Y él dijo: “Bien. Bien. Bueno. Ve a esperar en el restaurante de Pho de abajo. [El CTO] estará allí en un minuto.”

Así que hablé con el CTO mientras comíamos fideos. Mayormente escuché. Aprendí que las personas proyectan inteligencia en las personas tranquilas. Escuchar atentamente no solo te ayuda a ser más inteligente, incluso te hace parecer más inteligente.

Y la estrategia funcionó. La reunión duró aproximadamente una hora. Los fideos estaban deliciosos. Aprendí mucho sobre la historia de la empresa y sus metas a corto plazo. El CTO dijo: “Bien, vuelve arriba y habla con [el director de ingeniería].”

Y eso hice. Y me ofreció un trabajo.

Ahora, quiero enfatizar. Esto no es cómo la mayoría de las personas consiguen su primer trabajo como desarrollador.

Probablemente estés pensando: “Vaya, aquí Quincy se está metiendo de casualidad en un trabajo como desarrollador que ni siquiera estaba buscando. Si tan solo todos pudiéramos tener tanta suerte”.

Y eso es exactamente lo que sentí en ese momento. Pero en la siguiente sección, voy a explorar la relación entre los empleadores y los desarrolladores. Y cómo conseguir ese trabajo tuvo menos que ver con mis habilidades como entrevistado, y más con el año de programación, networking y creación de reputación que lo precedió.

No era un trabajo cómodo en una gran empresa de tecnología, con todas las compensaciones, beneficios y pistas de bolos de la empresa. Era un puesto de contratista que pagaba más o menos lo mismo que como maestro.

Pero era un trabajo de desarrollador. Una empresa me estaba pagando para escribir código.

Ahora era un desarrollador profesional.

Qué buscan los empleadores

Avanzamos una década. Ahora he estado en ambos lados de la mesa. Me han entrevistado gerentes de contratación como desarrollador. He entrevistado a desarrolladores como gerente de contratación.

He pasado muchas horas en llamadas con desarrolladores que están en medio de la búsqueda de trabajo. Algunos de ellos han solicitado cientos de empleos y solo han obtenido unas pocas “llamadas” para entrevistas de trabajo.

También he pasado muchas horas en llamadas con gerentes y reclutadores, tratando de comprender mejor cómo contratan y qué buscan.

Creo que gran parte de la frustración que los desarrolladores sienten acerca del proceso de contratación se debe a una falta de comprensión.

Los empleadores valoran una cosa por encima de todo: la previsibilidad.

¿Cuál de estos candidatos crees que preferiría un empleador?

X es un codificador “estrella del rock” 10 veces mejor que a menudo tiene destellos de genialidad. X también tiene ráfagas de una productividad increíble. Pero X a menudo está de mal humor con sus colegas y a menudo incumple plazos o reuniones.

Y es un codificador aceptable, y tiene una producción más lenta pero más consistente. Y se lleva bien con sus colegas y rara vez se pierde reuniones o plazos.

Z es similar a Y en su producción, y puede llevarse bien con sus colegas y cumplir plazos. Pero Z ha cambiado de trabajo 3 veces en los últimos 3 años.

Bueno, probablemente puedas adivinarlo por todo lo que he dicho hasta ahora: Y es el candidato preferido. Y eso se debe a que los empleadores valoran la previsibilidad por encima de todo.

X es un candidato trampa que algunos gerentes novatos pueden cometer el error de contratar. Si te preguntas por qué sería tan mala idea contratar a X, lee Despedimos a nuestro mejor talento. La mejor decisión que hemos tomado.

Añadí a Z a esta lista solo para hacer un punto: trata de no cambiar de trabajo con demasiada frecuencia.

Puedes aumentar tus ingresos bastante rápido saltando de un empleador a otro. Puedes empezar a solicitar nuevos empleos en el momento en que aceptes una oferta de trabajo. Pero esto ahuyentará a muchos gerentes de contratación.

Después de todo, la piedra que rueda no engendra musgo. Estarás dentro y fuera de bases de código antes de tener tiempo de entender cómo funcionan.

Ahora, considera esto: puede tomar 6 meses o más para que un gerente lleva a un nuevo desarrollador a velocidad, hasta el punto en que pueda ser un beneficio neto para el equipo.

Hasta ese momento, el nuevo empleado es básicamente una carga para los recursos de la empresa, absorbiendo tiempo y energía de sus compañeros que tienen que ayudarlo a integrarse, ayudarlo a entender una base de código y solucionar sus errores.

La mayoría de los empleadores evitan correr riesgos

Supongamos que un gerente contrata al desarrollador equivocado. Tómate un momento para pensar en lo malo que puede ser eso para el equipo.

En promedio, se tarda aproximadamente 3 meses en cubrir una posición de desarrollador en una empresa. Los empleadores primero tienen que:

• obtener la aprobación de sus jefes para contratar a un desarrollador
• crear la descripción del trabajo
• publicar el trabajo en sitios de empleo y comunicarse con reclutadores
• revisar currículums, muchos de los cuales serán de baja calidad de candidatos que están solicitando a tantos empleos como sea posible
• iniciar el proceso de entrevistas, que puede incluir volar a los candidatos a la ciudad y alojarlos en un hotel
• rondas de entrevistas con muchos miembros del equipo. Para algunos empleadores, esto es un asunto que puede durar varios días
• seleccionar al candidato final, y negociar una oferta…
• que muchos candidatos igualmente no aceptarán
• firmar contratos e incorporar al empleado
• darles acceso a sistemas internos sensibles
• presentarlos a sus compañeros de equipo, y asegurarse de que todos se lleven bien
• meses de capacitación informal, donde el empleado necesita entender un servicio o una parte de una base de código existente
• y finalmente, sumergirlos en la forma en que el equipo hace las cosas

En resumen – mucho trabajo.

Ahora imagina que después de hacer todo eso, el nuevo empleado dice “Oye, acabo de recibir una oferta mejor de esta otra compañía. ¡Adiós, amigo!”.

O imagina que el empleado es poco confiable y muchas veces llega horas después de haber comenzado la jornada laboral.

O imagina que el empleado lucha con adicciones no tratadas de drogas, alcohol o juego, problemas de ira – o resulta ser una persona pasivo-agresiva que socava al equipo.

Ahora tienes que comenzar todo este proceso nuevamente y buscar un nuevo candidato para el puesto.

Contratar es difícil.

Así que puedes ver por qué los empleadores son adversos al riesgo. Muchos de ellos descartarán a candidatos aparentemente calificados hasta que encuentren a alguien en quien se sientan un 99% seguros.

Porque los empleadores son tan adversos al riesgo, los buscadores de empleo sufren

Ahora, si crees que contratar es difícil, espera a escuchar sobre el proceso de solicitud de empleo. Es posible que ya estés demasiado familiarizado con esto. Pero aquí va…

• Tienes que preparar tu currículum. En el proceso, tomarás decisiones que constantemente te harán dudar durante toda tu búsqueda de empleo.
• Tienes que buscar ofertas de trabajo en línea, investigar a los empleadores y evaluar si es probable que sean compatibles contigo.
• La mayoría de las ofertas de trabajo te llevarán a formularios web donde tendrás que volver a escribir tu currículum una y otra vez, esperando que el formulario no se bloquee debido a errores del servidor o errores de validación de JavaScript.
• Una vez que envías estas solicitudes de empleo, tienes que esperar mientras el empleador las procesa. Algunos empleadores reciben tantas solicitudes que no pueden revisarlas todas manualmente. (Google solo recibe 9,000 solicitudes por día). Los empleadores utilizarán software para filtrar las solicitudes. Los reclutadores internos dedican en promedio 6 segundos a revisar cada currículum. A menudo, tu solicitud ni siquiera será revisada por un humano.
• Es probable que nunca recibas noticias de la empresa. Tienen poco incentivo para decirte por qué te rechazaron (no quieren que presentes una demanda por discriminación). Si tienes suerte, recibirás uno de esos correos electrónicos que dicen “Hemos elegido seguir con otros candidatos”.
• Y todo el tiempo que pasas solicitando estos trabajos, potencialmente horas por semana, es mentalmente agotador y, por supuesto, no remunerado.

¡Vaya! Así que puedes ver qué pesadilla es el proceso de contratación tanto para los empleadores como para los candidatos a empleo.

Pero si perseveras, eventualmente puedes recibir ofertas. Y cuando llueve, escampa.

Aquí hay datos de la búsqueda de empleo de un colaborador de freeCodeCamp durante 12 semanas:

Y a medida que llegaban las ofertas, el salario inicial iba aumentando. Ten en cuenta, por supuesto, que esto es para un trabajo en San Francisco, una de las ciudades más caras del mundo.

La tasa de este desarrollador para obtener entrevistas es bastante sólida. Y su habilidad para negociar también era fuerte. Puedes leer más sobre su proceso si tienes curiosidad.

Pero como he dicho antes, es mucho más fácil ingresar a una empresa a través de la puerta lateral.

Y esa es una de las razones por las que escribí este libro. No quiero que sigas haciendo fila en la puerta principal de estos empleadores.

Si Desarrollas Tus Habilidades, Tu Red de Contactos y Tu Reputación, Puedes Evitar Gran Parte del Proceso de Solicitud de Empleo.

A lo largo de este libro, te he enseñado técnicas para aumentar tus posibilidades de “tener suerte” y recibir una oferta de trabajo.

“La suerte es la preparación encontrando la oportunidad. Si no hubieras estado preparado cuando llegó la oportunidad, no habrías tenido ‘suerte'”. – Oprah Winfrey

Por eso, a lo largo de este libro, te he animado a desarrollar estas tres áreas al mismo tiempo y a comenzar a pensar en ellas desde el primer día, mucho antes de tu búsqueda de empleo.

Mi historia de ni siquiera buscar trabajo y conseguir trabajo puede parecer tonta. Pero esto sucede más a menudo de lo que piensas.

La realidad es: aprender a programar es difícil.

Pero saber cómo programar es importante.

En todas las industrias, en prácticamente todas las empresas del mundo, los gerentes están tratando de encontrar formas de llevar sus procesos al ámbito del software.

Eso significa desarrolladores.

Tal vez escuches sobre grandes despidos en tecnología de vez en cuando. Muchos de estos despidos afectan a empleados que no son desarrolladores. Pero a menudo muchos desarrolladores pierden sus trabajos.

¿Por qué las empresas despedirían a desarrolladores después de gastar tanto tiempo y dinero reclutándolos y capacitándolos? Aparte de una situación de quiebra, no conozco la respuesta a esa pregunta. No estoy seguro de que alguien la conozca.

Hay cada vez más evidencia de que los despidos destruyen el valor a largo plazo dentro de una empresa. Pero en la práctica, muchos CEO sienten presión de sus inversores para hacer despidos. Y cuando varias empresas hacen despidos alrededor del mismo tiempo, otros CEO pueden seguir su ejemplo.

Aún así, incluso con los despidos, la mayoría de los economistas esperan que el número de empleos para desarrolladores y otros empleos relacionados con el software siga creciendo. Por ejemplo, el Departamento de Estadísticas Laborales de Estados Unidos espera un aumento del 15% en desarrolladores durante la próxima década.

El mercado laboral puede estar ajustado en este momento, pero pocas personas esperan que esta recesión dure.

Espero que con habilidades sólidas, una buena red de contactos y una buena reputación, puedas conseguir un buen trabajo a pesar de un mercado laboral desafiante.

Esperemos que algún día sea más fácil para los empleadores y los empleados con habilidades encontrar a los demás, sin el largo y brutal proceso de solicitud y entrevista de trabajo.

Qué esperar del proceso de entrevista de trabajo para desarrolladores

Una vez que comiences a tener entrevistas de trabajo, tendrás un adelanto del temido proceso de entrevista de trabajo para desarrolladores y la notoria entrevista de codificación.

Un flujo típico de entrevista podría involucrar:

1. Hacer una evaluación en línea de tus habilidades de codificación o una “entrevista preliminar” por teléfono.
2. Y luego, si pasas eso, una segunda entrevista técnica por teléfono o video.
3. Y luego, si pasas eso, una entrevista “en persona” donde debes viajar a la oficina de la empresa. Estas suelen involucrar varias entrevistas con recursos humanos, gerentes de contratación y desarrolladores de rango y archivo con los que podrías trabajar.

En el camino, te enfrentarás a preguntas que pondrán a prueba tu conocimiento de resolución de problemas, algoritmos y estructuras de datos, depuración y otras habilidades.

Tus entrevistadores pueden permitirte resolver estos problemas de codificación en una computadora en un editor de código. Pero a menudo tendrás que resolverlos a mano mientras estás parado frente a una pizarra.

Lo importante a recordar es que la persona que te entrevista no solo busca una respuesta correcta de tu parte. También están tratando de entender cómo piensas.

Quieren saber: ¿entiendes los fundamentos de la programación y la ciencia de la computación? ¿O simplemente estás repitiendo un montón de soluciones que memorizaste?

Ahora bien, practicar algoritmos y estructuras de datos será de gran ayuda. Pero también debes ser capaz de pensar en voz alta y explicar tu proceso de pensamiento mientras escribes tus soluciones.

La mejor manera de practicar esto es hablar en voz alta contigo mismo mientras programas. O, si te sientes aventurero, transmitir en vivo mientras programas.

Hay muchos flujos de “programación en vivo” en Twitch donde las personas “aprenden en público” construyendo proyectos frente a una audiencia. Como bonificación, si estás dispuesto a exponerte así, también te ayudará a construir tu reputación como desarrollador.

Otra cosa a recordar durante las entrevistas en pizarra: tu entrevistador. No están sentados allí esperando a que termines. Están contigo todo el tiempo, observándote y evaluándote consciente e inconscientemente.

Intenta hacer que el proceso de entrevista sea lo más interactivo posible para tu entrevistador. Sonríe y mantén contacto visual ocasionalmente. Trata de observar su lenguaje corporal. ¿Están relajados? ¿Asienten mientras explicas tus puntos?

Tu entrevistador probablemente sabe lo que está buscando en tu código. Así que intenta sacarle algunas pistas. Haciendo observaciones o haciendo preguntas abiertas en voz alta contigo mismo, es posible que puedas hacer que tu entrevistador intervenga y se sienta involucrado en el proceso.

Quieres que tu entrevistador te caiga bien. Quieres que esté a tu favor, para que pueda pasar por alto algunas debilidades en tus habilidades de programación, o pasar por alto algunos errores que puedas cometer en tu código.

Te estás vendiendo como candidato a un trabajo. Asegúrate de que tu entrevistador sienta que está obteniendo un buen trato.

Y lo mismo se aplica para cualquier entrevista de comportamiento que debas superar. Estas entrevistas se tratan menos sobre tu capacidad de codificación y más sobre si encajas en la “cultura” de la empresa. (Desearía poder decirte qué significa esto, pero cada gerente lo definirá de manera ligeramente diferente).

En estas Entrevistas de Comportamiento, tendrás que convencer a tu entrevistador de que tienes habilidades sólidas de comunicación.

Definitivamente ayuda ser fluido en el idioma en el que estás siendo entrevistado, y conocer la jerga adecuada. Puedes aprender mucho de esto al escuchar regularmente podcasts de tecnología, como el Podcast de freeCodeCamp.

Una gran cosa que tus entrevistadores están tratando de establecer es: ¿eres una persona tranquila que se llevará bien con los demás? La mejor manera de demostrar esto es ser educado y evitar el uso de palabras groseras o desviarte demasiado del tema en cuestión.

No quieres entrar en un debate sobre algo irrelevante, como una rivalidad deportiva. También recomiendo no intentar corregir a tus entrevistadores, incluso si dicen cosas que tú crees que son ridículas o falsas.

Si tienes una mala sensación acerca de la compañía, no estás obligado a aceptar su oferta de trabajo. Los empleadores rechazan candidatos todo el tiempo. Y tú, como candidato, también tienes el derecho de rechazar a un empleador. La entrevista en sí probablemente no es el mejor momento para conflictos.

¿Debo Negociar mi Salario en mi Primer Trabajo como Desarrollador?

Intentar negociar un salario más alto generalmente no causa daño siempre y cuando lo hagas de manera educada.

He escrito extensamente sobre cómo negociar la oferta de trabajo y el salario como desarrollador.

Básicamente, negociar un salario de inicio más alto se reduce a cuánto poder de negociación tienes.

Tu empleador tiene trabajo que debe hacerse. ¿Cuánto necesita tu empleador que trabajes para ellos? ¿Qué otras opciones tienen?

Tú necesitas un ingreso para sobrevivir. ¿Qué otras opciones tienes? ¿Cuál es tu plan de respaldo?

Si tienes una oferta de trabajo de otro empleador que ofrece pagarte cierta cantidad, puedes usar eso como palanca en tu negociación salarial.

Si tu mejor plan de respaldo es volver a la escuela y obtener un título de posgrado… eso no es una palanca particularmente fuerte, pero es mejor que nada. Y podrías mencionarlo durante el proceso de negociación salarial.

Recuerda el largo proceso de contratación que describí anteriormente. Los empleadores tienen que pasar al menos por una docena de etapas antes de poder llegar a la etapa de la oferta de trabajo con los candidatos. Probablemente ya están planeando que negocien y no se sorprenderán por ello.

Ahora, si estás en una situación como la mía, en la que una compañía simplemente te ofrece un trabajo de la nada, es posible que te sientas incómodo al intentar negociar.

He de admitir – en mi historia anterior, cuando mi jefe me ofreció el trabajo, no negocié.

En retrospectiva, ¿debería haber negociado mi compensación? Probablemente.

¿Tenía palanca? Probablemente no mucho. Mi plan de respaldo era simplemente seguir compitiendo en hackathones y seguir tomando té y programando en la biblioteca pública.

Tal vez podría haber negociado y obtener algunos dólares más por hora. Pero en el momento en que me ofrecieron el trabajo, la compensación fue lo último en lo que pensé. Estaba emocionado de convertirme en un desarrollador profesional.

Por cierto, una vez que hayas trabajado como desarrollador en una compañía durante aproximadamente un año, es posible que quieras pedir un aumento de sueldo. He escrito extensamente sobre cómo pedir un aumento de sueldo como desarrollador. Pero se reduce a lo mismo: palanca.

¿Deberías Usar un Reclutador para tu Búsqueda de Trabajo como Desarrollador?

Sí. Si puedes encontrar un reclutador que te ayude a conseguir tu primer trabajo como desarrollador, creo que deberías.

He escrito extensamente sobre por qué los reclutadores son una herramienta subestimada en tu arsenal.

Muchos empleadores pagarán una tarifa de búsqueda a los reclutadores por enviarles candidatos de alta calidad.

Los incentivos de los reclutadores están bien alineados con tus propios objetivos como buscador de empleo:

1. Dado que les pagan en función de tu salario de inicio, tienen la tendencia de ayudarte a negociar el salario de inicio más alto posible.
2. Cuanto más candidatos colocan, y más rápido los colocan, más dinero ganan los reclutadores. Así que querrán ayudarte a conseguir un trabajo lo más rápido posible para poder pasar a otros buscadores de empleo.
3. Dado que solo cobran si tienes éxito como empleado (y te quedas al menos 90 días), se asegurarán de que seas competente y encajes bien con la cultura de la empresa.

Dicho esto, si un reclutador te pide dinero por cualquier cosa, eso es una señal de alerta.

Y no todos los reclutadores son iguales. Investiga antes de trabajar con un reclutador. Incluso si al final están siendo pagados por el empleador, tú estás invirtiendo tu tiempo en ayudarlos a colocarte. Y el tiempo es valioso.

Hablando de tiempo, una forma de empezar a ganar dinero como programador antes, incluso mientras te preparas para la búsqueda de empleo, es conseguir clientes freelance.

Cómo conseguir clientes freelance

Recomiendo a los nuevos desarrolladores intentar conseguir algunos clientes freelance antes de comenzar su búsqueda de empleo. Hay tres buenas razones para esto:

1. Es mucho más fácil conseguir un cliente freelance que obtener un trabajo a tiempo completo.
2. El trabajo freelance es menos arriesgado, ya que puedes hacerlo sin dejar tu trabajo actual.
3. Puedes empezar a ganar dinero programando antes y construir tu portafolio de trabajo profesional antes.

Conseguir clientes freelance puede ser mucho más fácil que conseguir un trabajo de desarrollador. ¿Por qué es esto?

Piensa en pequeños negocios locales. Tal vez sea una familia que tiene un restaurante. O una tienda. O una empresa de plomería. O un bufete de abogados.

¿Cuántos de esos negocios se beneficiarían al tener un sitio web interactivo, sistemas de gestión internos y herramientas para automatizar sus flujos de trabajo? La mayoría de ellos.

Ahora, ¿cuántas de esas compañías pueden permitirse tener un desarrollador de software a tiempo completo para construir y mantener esos sistemas? No tantas.

Ahí es donde entran los freelancers. Pueden trabajar de manera más económica y caso por caso. Un pequeño negocio puede contratar a un freelancer para un proyecto único o por un período de tiempo más corto.

Si estás creando tu red de contactos activamente, algunas de las personas que conoces pueden convertirse en tus clientes.

Por ejemplo, puedes conocer a un contador local que quiera actualizar su sitio web. Y tal vez agregar la opción de programar una consulta o aceptar pagos con tarjeta de crédito. Estas son funciones comunes que los pequeños negocios pueden solicitar, y puedes volverte bastante bueno implementándolas.

También puedes conocer a gerentes de pequeños negocios que necesitan un sistema ERP, o un sistema CRM, o un sistema de inventario, u otras herramientas.

En muchos casos, hay herramientas de código abierto que puedes implementar y configurar para ellos. Luego solo tienes que enseñarles cómo usar ese sistema. Y puedes cobrarles una tarifa mensual por tener tus servicios disponibles para solucionar problemas que puedan surgir.

Debo usar un contrato para el trabajo freelance?

Querrás encontrar una plantilla de contrato estándar, personalizarla y obtener la aprobación de un abogado.

Puede parecer incómodo hacer que una panadería local firme un contrato contigo solo para ayudar con su sitio web o presencia en redes sociales. Pero hacerlo hará que toda la transacción se sienta más profesional que un simple acuerdo de palabra.

Es poco probable que un pequeño negocio te lleve a juicio por unos pocos miles de dólares. Pero en caso de que esto suceda, te alegrará haber firmado un contrato.

¿Cuánto debería cobrar por el trabajo freelance?

Tomaría lo que ganas en tu trabajo actual, calcularía tu tarifa por hora y la duplicaría. Puede sonar como mucho dinero, pero el trabajo freelance es mucho más difícil que el trabajo regular. Tienes que aprender mucho.

Alternativamente, podrías cobrar por un proyecto. “Desplegaré y configuraré este sistema por $1,000”.

Asegúrate de especificar un periodo de tiempo en el que estás dispuesto a mantener el proyecto. No querrás que las personas te llamen 3 años después esperando que regreses y arregles un sistema que nadie ha estado manteniendo.

¿Cómo me aseguro de que los clientes freelance me paguen?

Muchos otros freelancers, incluido yo mismo, seguimos este enfoque simple: solicita la mitad de tu compensación por adelantado, antes de comenzar el trabajo. Y cuando puedas demostrar que has completado la mitad, solicita la otra mitad.

Intenta siempre obtener todo el dinero antes de finalizar el proyecto. De esa manera, el cliente no podrá utilizar el dinero como una forma de presionarte y tratar de obtener más trabajo de ti.

Si ya te pagaron por completo, el trabajo que hagas para ayudar a tu cliente después transmitirá: “Estoy yendo más allá por ti”.

Lo cual es una vibra totalmente diferente a: “¿Uh oh, incluso me pagarán por todo este trabajo que estoy haciendo?”

¿Debo usar un sitio web freelance como Upwork o Fiverr?

Si te encuentras en una zona rural del mundo y no puedes encontrar clientes localmente, podrías probar algunos de estos sitios web de trabajos freelance. Pero por lo demás, no me enfocaría en ellos. Aquí está el por qué:

Cuando intentas conseguir contratos en un sitio web freelance, estás compitiendo con todos los freelancers alrededor del mundo. Muchos de ellos vivirán en ciudades que tienen un costo de vida mucho más bajo que el tuyo. Algunos de ellos ni siquiera se preocuparán realmente por su reputación como tú lo haces, y podrían estar dispuestos a entregar un trabajo de baja calidad.

En cierta medida, estos sitios web promueven un fenómeno de “carrera hacia abajo” donde la persona que ofrece hacer el trabajo más barato generalmente consigue el trabajo.

Si en cambio te enfocas en encontrar clientes a través de tu propia red local, no tendrás que competir con estos freelancers en el extranjero.

Y lo mismo ocurre para las personas que buscan ayuda de desarrolladores freelance. Si alguna vez quieres contratar a un freelancer, te recomiendo enfáticamente trabajar con alguien con quien puedas reunirte en persona, que tenga vínculos con tu comunidad.

Alguien que haya vivido en tu ciudad por varios años y que asista a muchos de los mismos eventos sociales que tú, será mucho menos propenso a tratar de aprovecharse de ti. Si tanto tú como la otra parte se preocupan por su reputación, ambos estarán invertidos en una asociación que funciona.

Cada uno puede ser una historia de éxito en el portafolio del otro.

El trabajo freelance es como dirigir una empresa de una sola persona. Y eso significa mucho trabajo oculto.

No subestimes la cantidad de “trabajo oculto” involucrado en dirigir tu práctica de desarrollo freelance.

Por un lado, puedes querer crear tu propia entidad legal.

En los Estados Unidos, el enfoque más común es crear una Sociedad de Responsabilidad Limitada (LLC) y hacer negocios como esa compañía, incluso si eres la única persona que trabaja allí.

Esto puede simplificar tus impuestos. Y, Dios no lo quiera, si cometes un error y un cliente te demanda, tu entidad legal puede ayudarte a aislar tu responsabilidad personal, para que sea tu LLC la que entre en bancarrota, no tú personalmente.

También puedes considerar obtener un seguro de responsabilidad civil para una mayor protección contra esto.

Recuerda que cuando trabajas como freelancer, generalmente tienes que pagar impuestos al final del año, así que asegúrate de ahorrar para esto.

Para crear tu LLC, por supuesto que puedes encontrar documentos estándar en línea y presentarlos tú mismo. Pero si te tomas en serio el trabajo freelance, te recomiendo hablar con un abogado y/o contador especializado en pequeñas empresas para asegurarte de configurar todo correctamente.

¿Cuándo debería dejar el freelance y empezar a buscar trabajo?

Si puedes pagar tus facturas como freelancer, es posible que solo quieras seguir haciéndolo. Con el tiempo, incluso puedes establecer tu propia agencia de desarrollo de software y contratar a otros desarrolladores para que te ayuden.

Esto dicho esto, si anhelas la estabilidad de un trabajo como desarrollador, es posible que tengas suerte. Los clientes freelance pueden convertirse en trabajos a tiempo completo si te mantienes con ellos el tiempo suficiente. En algún momento, puede tener sentido económico para un cliente ofrecerte un trabajo a tiempo completo a una tasa horaria inferior. Obtienes la estabilidad de una semana laboral de 40 horas y ellos obtienen tus habilidades a tiempo completo.

También es posible que puedas conservar algunos clientes freelance cuando consigas un trabajo. Esto puede ser un buen complemento a tus ingresos. Pero ten en cuenta que, como aprenderemos en el próximo capítulo, tu primer trabajo como desarrollador puede ser una responsabilidad absorbente. Al menos al principio.

¿Qué tan emocionante será ese primer año de trabajo como desarrollador profesional? Bueno, hablemos de eso.

Capítulo 5: Cómo tener éxito en tu primer trabajo como desarrollador

“Un barco en puerto está seguro. Pero no es para lo que se construyen los barcos.” – Grace Hopper, Matemática, Almirante de la Marina de los Estados Unidos y Pionera de la Ciencia de la Computación

Una vez que consigas tu primer trabajo como desarrollador, es cuando realmente comienza el aprendizaje.

Aprenderás cómo trabajar de manera productiva junto a otros desarrolladores.

Aprenderás a navegar por grandes bases de código heredadas.

Aprenderás sistemas de control de versiones, herramientas de Integración y Entrega Continua (CI/CD), herramientas de gestión de proyectos y más.

Aprenderás cómo trabajar bajo la supervisión de un gerente de ingeniería. Cómo trabajar para cumplir con una fecha límite. Y cómo trabajar en medio de una gran cantidad de ambigüedad en el trabajo.

Más importante aún, aprenderás cómo gestionarte a ti mismo.

Aprenderás a superar barreras psicológicas que nos afectan a todos, como el síndrome del impostor. Aprenderás tus límites y cómo empujarlos un poco más allá.

Momento de la historia: ¿Cómo tuvo éxito un profesor de treinta años en su primer trabajo como desarrollador?

La última vez en Momento de la historia: Quincy consiguió su primer trabajo como desarrollador en una startup tecnológica local. Iba a trabajar junto a una docena de desarrolladores manteniendo una base de código grande y sofisticada. Y no tenía ni idea de lo que estaba haciendo…

Me desperté a las 4 a.m. y no pude volver a dormir. Lo intenté. Pero tenía esta sensación de ardor en el pecho. Esta ansiedad. Pánico.

Había trabajado durante una década en educación. Primero como tutor. Luego como profesor. Y luego como director de escuela.

En pocas horas, iba a empezar desde cero, trabajando como desarrollador.

¿Importaría siquiera alguna de mis experiencias anteriores – éxitos anteriores – en esta nueva carrera?

Hice lo que siempre hago cuando siento ansiedad: salí a correr. Bajé a toda velocidad por las colinas, mi linterna moviéndose en la oscuridad. Cuando llegué a la playa, corrí junto al océano mientras el sol salía por encima de las copas de los árboles.

Para cuando llegué a casa, mi esposa ya se estaba yendo a trabajar. Ella me dijo que no me preocupara. Me dijo: “Todavía te amaré aunque te despidan por no saber lo que estás haciendo”.

Cuando llegué a mi nueva oficina, no había nadie. Como profesor, estaba acostumbrado a llegar a la escuela a las 7:30 en punto. Pero rápidamente me di cuenta de que la mayoría de los desarrolladores de software no empiezan a trabajar tan temprano.

Así que me senté cruzando las piernas en la entrada, programando siguiendo tutoriales en mi netbook.

Una empleada se acercó a mí con una expresión nerviosa en su rostro. Probablemente pensó que era un okupa. Pero la tranquilicé diciéndole que, de hecho, ahora trabajaba en su empresa, y la convencí de que me dejara entrar.

Sentí una sensación irreal al cruzar la oficina de planta abierta vacía hacia el escritorio de desarrollo, solo con la luz de la señal de salida para guiarme.

Configuré mi netbook en un escritorio de pie vacío y terminé mi tutorial de programación.

Un rato después, las luces se encendieron a mi alrededor. Mi jefe había llegado. Al principio no reconoció mi presencia. Simplemente se sentó en su escritorio y empezó a teclear rápidamente en su teclado mecánico.

“Larson”, dijo finalmente. “¿Listo para tu gran primer día?”

No lo estaba. Pero quería demostrar confianza. Así que dije las palabras que se pronunciaron por primera vez en “Gran lío en la pequeña China”, una de mis películas favoritas de los años 80: “Nací listo”.

“Genial”, dijo mi jefe. “Vamos a conseguirte un equipo”.

“Oh, ya tengo uno”, dije, golpeando mi netbook de $200. “Esta belleza tiene Linux Mint y ya he personalizado mi archivo .emacs para poder…”

“Somos un lugar de Mac”, dijo mientras se dirigía a un armario de almacenamiento. Buscó un momento y emergió. “Aquí está. Es un modelo de hace 3 años, pero debería funcionar. Lo restablecimos a la configuración de fábrica”.

Empecé a decir que ya estaba familiarizado con mi configuración, y que podría trabajar mucho más rápido con ella, pero no quiso escuchar nada.

“Todos estamos usando las mismas herramientas. Hace que la colaboración sea mucho más fácil. Convención sobre configuración, ya sabes”.

Fue la primera vez que escuché la frase “convención sobre configuración”, pero se mencionaría mucho en los próximos días.

Pasé las siguientes horas configurando mi nueva computadora de trabajo mientras otros desarrolladores iban llegando gradualmente.

Casi eran las 10 a.m. cuando empezamos nuestra reunión de equipo “standup”. Todos nos paramos en un círculo junto al pizarrón. Nos turnamos para informar sobre lo que íbamos a hacer ese día.

Todos dieron actualizaciones rápidas y precisas.

Cuando llegó mi turno, empecé a presentarme. Ya estaba lo suficientemente ansioso, cuando entró Mike, ese tipo ultramaratonista que participaba en los eventos de startups de Santa Bárbara. Estaba comiendo algunas zanahorias bebé, después de haber corrido unos 30 kilómetros esa mañana.

Después de terminar, Mike habló, dándome la bienvenida y diciendo que me había visto en algunos de sus eventos. Luego dio una actualización de estado de 15 segundos sobre una característica en la que estaba trabajando.

Toda la reunión duró solo unos 10 minutos y todos regresaron a sus escritorios.

Eventualmente logré que la base de código de la empresa funcionara en mi nueva computadora portátil. Era una aplicación de Ruby on Rails que había crecido en 5 años. Ejecuté el comando rake stats y vi que tenía millones de líneas de código. Me estremecí. ¿Cómo podría comprender todo eso?

Mi vecino, un desarrollador rudo y barbudo, dijo: “Eh, la mayor parte de eso son solo paquetes. La base de código real en la que trabajarás es solo de unas 100,000 líneas. No te preocupes. Le agarrarás la onda”.

Me asusté, pero pensé para mí mismo: “Eso son menos de millones de líneas. Así que eso es bueno”.

“Mi nombre es Nick, por cierto”, dijo, presentándose. “Si necesitas ayuda, solo avísame. He estado lidiando con esta base de código durante varios años, así que debería poder ayudarte”.

En los próximos días, bombardeé a Nick con preguntas sobre cada sistema interno con el que me encontraba.

Eventualmente, Nick comenzó a poner su estado de chat en “modo de código” y a usar auriculares con cancelación de ruido. Volvió un poco la espalda hacia mí, con el lenguaje corporal de “déjame en paz para que pueda hacer mi propio trabajo también”.

Esta fue una de mis primeras lecciones sobre la dinámica de equipo. No quieres agotar tu bienvenida con demasiadas preguntas. Necesitas mejorar en aprender las cosas por ti mismo.

Pero esta era una base de código masiva, y en su mayoría estaba documentada, aparte de los comentarios en línea y una wiki de equipo bastante escasa.

Dado que era una base de código de código cerrado en la que solo los desarrolladores a mi alrededor estaban trabajando, no podía usar Stack Overflow para descubrir dónde se encontraba una lógica particular. Simplemente tenía que buscar a tientas en la oscuridad.

Comencé a alternar a qué vecino molestar con una pregunta en particular. Pero parecía que estaba rápidamente agotando cualquier entusiasmo que pudieran haber tenido hacia mí como compañero de equipo.

Me excedí. Me volví tímido incluso para hacer preguntas simples. Me impuse una regla de intentar durante 2 horas resolver un problema antes de pedir ayuda.

En algún momento, después de luchar durante varias horas, pedí ayuda. Cuando mi jefe descubrió que había estado atascado toda la mañana, preguntó: “¿Por qué no pediste ayuda antes?”

Otra lucha fue entender la propia base de código: el “monolito” y sus muchos microservicios.

La base de código tenía miles de pruebas unitarias y pruebas de integración. Cada vez que escribías una nueva contribución de código, también debías escribir pruebas. Estas pruebas ayudaban a asegurar que tu código hiciera lo que se suponía y no rompiera ninguna funcionalidad existente.

Frecuentemente “rompía la compilación” al comprometer código que pensaba que estaba suficientemente probado, solo para que mi código rompiera otra parte de la aplicación en la que no había pensado. Esto frustraba a todo el equipo, que no podía fusionar su propio código hasta que el problema raíz se hubiera solucionado.

La compilación se rompía varias veces a la semana. Y no era la única persona que cometía este tipo de errores. Pero sentía que lo era.

Había días en los que sentía que no estaba hecho para ser un desarrollador. Me decía a mí mismo: “¿A quién engaño? ¿Simplemente me despierto un día y decido que voy a ser un desarrollador?”

Todo el tiempo escuchaba ecos de todas esas cosas que mis amigos desarrolladores me habían dicho un año antes, cuando comenzaba mi viaje en la programación.

“¿Cómo vas a lidiar con personas que han estado programando desde temprana edad?”

“Tendrás que beber un océano entero de conocimiento”.

“¿Por qué no te quedas con lo que se te da bien?”

Tomaba descansos cada vez más largos para alejarme de mi computadora. La oficina tenía una cocina llena de refrigerios. Buscaba más excusas para levantarme y agarrar un bocado. Cualquier cosa para retrasar la sensación abrumadora de que no tenía idea de lo que estaba haciendo.

Los primeros meses fueron difíciles. Durante las reuniones de pie de la mañana, parecía que todos se movían rápido. Cerrando errores abiertos y lanzando características. Parecía que no tenía nada que decir. Seguía trabajando en la misma característica que el día anterior.

Todos los días, cuando me despertaba y me preparaba para trabajar, sentía temor. “Hoy es el día en que me despiden”.

Pero luego iba a trabajar y todos eran bastante amables, bastante pacientes. Pediría ayuda si realmente me quedara atascado. Haría algún progreso y tal vez arreglaría uno o dos errores.

Me estaba volviendo más rápido navegando por el código base. Me estaba volviendo más rápido leyendo rastros de pila cuando mi código fallaba. Estaba enviando características a un ritmo más rápido que antes.

Cada vez que mi jefe me llamaba a su oficina, pensaba para mí mismo: “Oh no, tenía razón. Me van a despedir hoy”. Pero él solo me asignaba algunos errores más para arreglar o características para desarrollar. Uf.

Fue lo más surrealista: yo aterrorizado pensando que me van a despedir, y él sin tener idea de que algo está mal.

Por supuesto, había escuchado el término “síndrome del impostor” antes. Pero no me di cuenta de que eso era lo que estaba experimentando. Seguramente solo estaba sufriendo el “síndrome de no saber codificar”, ¿verdad?

Un día estaba sentado al lado de Nick y él parecía bastante agotado. Me ofrecí a traerle una soda de la cocina.

Cuando regresé, abrió la lata, dio un sorbo y se recostó en su silla, contemplando su monitor lleno de código. “Este error, amigo. Tres semanas intentando arreglar este error. En este punto, lo estoy depurando en mis sueños”.

“¿Tres semanas intentando arreglar el mismo error?” pregunté. Nunca había escuchado algo así.

“Algunos errores son más difíciles de resolver que otros. Este es uno de esos realmente astutos”.

Se sintió como si alguien me hubiera dado una bofetada en la cara con un salmón. Había visto mi trabajo como trozos de trabajo. Como si tomaría medio día arreglar un error y, si tomaba más tiempo que eso, estaba haciendo algo mal.

Pero aquí estaba Nick, con su licenciatura en ciencias de la computación de la Universidad de California y sus años de experiencia trabajando en este mismo código, y había estado bloqueado durante tres semanas en un solo error.

Tal vez había sido demasiado duro conmigo mismo. Tal vez algunos de estos errores que había estado arreglando no eran necesariamente “errores de medio día”, sino “errores de dos o tres días”. Sí, era inexperto y lento. Pero aun así, tal vez me estaba poniendo estándares poco realistas.

Después de todo, cuando presupuestábamos el tiempo para características, a veces teníamos “características de 5 días” o incluso “características de 2 semanas”. No hacíamos esto para errores, pero probablemente variaban de manera similar.

Fui a casa y leí más sobre el síndrome del impostor. Y lo que leí explicó mucha de mi ansiedad.

En los próximos meses, continué desarrollando características para el código base. Seguí colaborando con mi equipo. Todavía era un trabajo duro y agotador para el cerebro. Pero estaba empezando a ser un poco más fácil.

Me uní con mis compañeros de equipo cada día al almuerzo jugando juegos de mesa. Una semana, tuvimos un torneo de ajedrez en toda la compañía.

Un par de rondas después, jugué contra el CEO.

El CEO tiene un estilo de juego de ajedrez poco ortodoxo. Usó una apertura divertida que pocos jugadores de ajedrez serios elegirían. Y pude tomar una pequeña ventaja al comienzo del juego.

Pero en los siguientes movimientos, él pudo recuperar lentamente el control del juego. Finalmente, tomó la delantera y me venció.

Cuando le pregunté cómo encontraba tiempo para mantener afiladas sus habilidades en el ajedrez mientras dirigía una compañía, dijo: “Oh, no lo hago. Solo juego una o dos veces al año”.

Luego hizo una pausa por un momento, con la mano congelada frente a él, como si estuviera a punto de dar una conferencia. Dijo: “Mi tío era un jugador de ajedrez competitivo. Y él me dio un solo consejo para seguir: cada vez que tu oponente se mueva, ralentízate e intenta entender el juego desde su perspectiva, ¿por qué hizo ese movimiento?”

Luego se inclinó y se excusó para correr a una reunión.

He pensado mucho en lo que dijo a lo largo de los años. Y me di cuenta de que este consejo no solo se aplica al ajedrez. Se puede aplicar a cualquier situación adversarial.

Si tienes que hacer una tarea repetidamente, deberías automatizarla

Otra lección que aprendí sobre el desarrollo de software: como era la persona más junior del equipo, a menudo me asignaban el “trabajo de gruñón” que nadie más quería hacer. Una de estas tareas era ser el “vigilante de construcción”.

Cuando alguien rompía la construcción, descargaba la última versión de nuestra rama principal y usaba git bisect para tratar de identificar el commit que lo rompió.

Abriría ese commit, ejecutaría las pruebas y averiguaría qué salió mal. Luego, enviaría un mensaje a la persona que rompió la compilación, diciéndole lo que necesitaban arreglar.

Me volví realmente rápido haciendo esto. En un día lleno de informes de errores confusos y solicitudes de funciones ambiguas, esperaba que la compilación se rompiera. Me daba la oportunidad de sentirme útil rápidamente.

No pasó mucho tiempo antes de que alguien del equipo dijera: “Con la frecuencia con la que se rompe la compilación, deberíamos automatizar esto”.

No dije nada, pero me sentí a la defensiva. Era una mala idea. ¿Cómo podría un script hacer tan buen trabajo como yo, un desarrollador de carne y hueso, en encontrar el commit culpable?

Tomó unos días. Pero seguro, uno de mis compañeros de equipo escribió un script. Y ya no tenía que ser el vigilante de la compilación.

Se sintió extraño ver un mensaje de que la compilación falló y luego, al momento, ver un mensaje que decía qué commit rompió la compilación y quién necesitaba arreglarlo.

Me sentí indignado. No dije nada, pero en mi mente estaba pensando: “Ese debería ser mi trabajo. Ese script se llevó mi trabajo”.

Pero por supuesto, ahora miro hacia atrás mi reacción y me río. Me imagino a mí mismo, ahora en mis cuarenta, aún dejando todo varias veces a la semana para ser el vigilante de la compilación.

Porque en la práctica, si una tarea se puede automatizar, si puedes desglosarla en pasos discretos que una computadora pueda hacer de manera confiable por ti, entonces probablemente debas automatizarla.

Hay mucho trabajo más interesante que puedes hacer con tu tiempo.

Lecciones de los ancianos del pueblo

Aprendí mucho de otras personas en el equipo. Aprendí conceptos de diseño de productos de Mike. Él me llevó a correr en la playa y me enseñó cómo correr apoyando los metatarsos antes que los talones. Esto es un poco más suave para las articulaciones.

Y aprendí sobre conceptos de ingeniería de software ágil de Nick. Él me ayudó a seleccionar algunos buenos libros de desarrollo de software de la biblioteca de la empresa. Incluso me invitó a una fiesta de inauguración de su casa y conocí a sus hijos.

Después de aproximadamente un año trabajando para la empresa, sentí que era hora de intentar dar mis propios pasos y desarrollar algunos proyectos relacionados con el aprendizaje en línea. Me senté con el CTO para darle la noticia de que me iba.

Le dije: “Estoy agradecido de que todos me contrataran, aunque claramente era el desarrollador más débil de la empresa”.

Él solo soltó una risa y dijo: “Claro, cuando empezaste, eras el peor desarrollador del equipo. Diría que todavía eres el peor desarrollador del equipo”.

Me quedé allí sonriendo incómodamente, parpadeando ante él, sin estar seguro de si simplemente estaba enojado porque me iba.

Y luego dijo: “Pero eso es inteligente. Eres inteligente. Porque siempre quieres ser el peor músico de la banda. Siempre quieres estar rodeado de personas que sean mejores que tú. Así es como creces”.

Dos semanas después, registré los cambios en mi código del día y entregué mis tareas pendientes. Restablecí mi Mac a la configuración de fábrica y se lo entregué a mi gerente.

Estreché manos con mis compañeros de equipo y salí por la puerta hacia el aire nocturno de California.

Empecé con buen pie, asegurando contratos de freelance para mantener las luces encendidas. Y busqué un apartamento en el Área de la Bahía, justo cruzando el puente desde el corazón palpitante de la tecnología en South of Market San Francisco.

Ahora era un desarrollador profesional con un año de experiencia en mi haber.

Estaba listo para soñar nuevos sueños y hacer nuevos movimientos.

Lecciones de mi primer año como desarrollador

Hice muchas cosas bien durante mi primer año como desarrollador profesional. Me daría una calificación de B-.

Pero si tuviera la oportunidad de hacerlo todo de nuevo, habría algunas cosas que haría diferente.

Aquí tienes algunos consejos. Que maximicen tu aprendizaje y minimicen tus desilusiones.

Deja tu ego en la puerta

Muchas personas que ingresan al campo del desarrollo de software comenzarán desde cero. Un título que podrías tener es “Desarrollador Junior”.

Puede sentirse un poco incómodo tener la palabra “junior” en tu título a mediana edad. Pero con algo de paciencia y mucho trabajo duro, puedes superarlo.

Uno de los problemas que enfrenté todos los días fue que tenía 10 años de experiencia profesional. No era un empleado principiante. Sí, era nuevo en el desarrollo, pero tenía experiencia en la enseñanza e incluso en la gestión de personas. (Había gestionado a 30 empleados en mi trabajo de enseñanza más reciente).

Y sin embargo, a pesar de toda mi experiencia laboral anterior, todavía era un desarrollador principiante. Todavía era un novato. Un neófito. Un novato.

Por mucho que quisiera gritar “solía ser el jefe, no necesito que me cuiden”, la verdad era que sí necesitaba que me cuidaran.

¿Y si rompía accidentalmente el funcionamiento del sistema? ¿Y si introducía una vulnerabilidad de seguridad en la aplicación? ¿Y si borraba toda la base de datos? ¿O cifraba algo importante y perdía la clave?

Este tipo de desastres suceden todo el tiempo.

La realidad es que como desarrollador nuevo, eres como un toro en una tienda de porcelanas, tratando de caminar con cuidado pero rompiendo todo a tu paso.

No te impacientes con tus compañeros de equipo. Resiste la tentación de hablar sobre tus títulos avanzados, los premios que has ganado por tu trabajo o ese momento en el que el alcalde te entregó la llave de la ciudad. (OK, tal vez esto último nunca me pasó a mí).

No solo porque te hará difícil trabajar con los demás. Sino porque te distraerá de la tarea en cuestión.

En los primeros meses de mi carrera como desarrollador, usé mis logros pasados como un tipo de chupete. “Sí, soy malo en la codificación, pero soy fenomenal enseñando gramática inglesa. ¿Mencioné que solía dirigir una escuela?”

Cuando tus dedos están en el teclado y tus ojos en el editor de código, debes dejar atrás ese yo del pasado. Puedes disfrutar de los logros de ayer esta noche, después de terminar el trabajo de hoy.

Pero por ahora, debes aceptar todas las emociones que vienen con ser un principiante nuevamente. Debes concentrarte en la tarea en cuestión y hacer el trabajo.

Probablemente Solo sea el Síndrome del Impostor Hablando

Casi todas las personas que conozco han experimentado el síndrome del impostor. Esa sensación de que no perteneces. Esa sensación de que en cualquier momento tus compañeros de equipo descubrirán lo terrible que es tu código y te expondrán como un “falso desarrollador”.

En cierta medida, este sentimiento no desaparece. Siempre está presente en tu mente, listo para aparecer cuando intentes hacer algo nuevo.

“¿Me puedes ayudar a resolver este mensaje de error?” “Um… No estoy seguro si soy la mejor persona para preguntar.”

“¿Podrías programar conmigo para implementar esta función?” “Um… Supongo que si no encuentras a alguien más calificado.”

“¿Podrías dar una charla en nuestra próxima conferencia?” “Um… ¿yo?”

Conozco a ingenieros seniors que todavía sufren de síndrome del impostor de vez en cuando, incluso después de más de una década de carrera.

Cuando te sientas inadecuado o despreparado, es posible que sea solo el síndrome del impostor.

Cierto, si me dieran un bisturí y me dijeran “ayúdame a realizar una cirugía de corazón”, me sentiría como un impostor. Hasta cierto punto, sentirse fuera de tu área de conocimiento es totalmente razonable si realmente estás fuera de tu área de conocimiento.

El problema es que si has estado practicando desarrollo de software, es posible que puedas hacer algo pero todavía sufras de ansiedad inexplicablemente.

No soy médico. Pero mi instinto me dice que, para la mayoría de las personas, el síndrome del impostor disminuirá gradualmente con el tiempo, a medida que adquieras más práctica y construyas más confianza.

Pero puede aparecer aleatoriamente. No temo admitir que a veces siento pánico de sentir el síndrome del impostor al hacer una nueva tarea o una que no he hecho en un tiempo.

La clave es simplemente aceptarlo: “Probablemente solo sea el síndrome del impostor hablando”.

Y seguir adelante.

Encuentra tu Tribu, Pero No te Dejes Cegar por el Tribalismo

Cuando consigas tu primer trabajo como desarrollador, trabajarás junto a otros desarrolladores. ¡Yupi! Has encontrado tu tribu.

Pasarás mucho tiempo con ellos y todos pueden empezar a sentirse como un grupo unido.

Pero no ignores a las personas que no son desarrolladoras que te rodean.

En mi historia anterior, hablé de Mike, el Gerente de Producto que también organizaba eventos de startups. Era “no técnico”. Su conocimiento sobre codificación era limitado en el mejor de los casos. Pero me aventuraría a decir que aprendí tanto de él como cualquier otra persona en la empresa.

Puedes trabajar con otras personas de otros departamentos: diseñadores, gestores de productos, gestores de proyectos, personal de TI, personal de control de calidad, especialistas en marketing, e incluso profesionales de finanzas y contabilidad. También puedes aprender mucho de estas personas.

Sí, debes centrarte en establecer una conexión sólida con otros desarrolladores del equipo. Pero mantén la curiosidad. Relaciónate con otras personas en la sala de almuerzo o en eventos de la empresa. Nunca se sabe quién será la próxima persona que te ayude a desarrollar tus habilidades, tu red de contactos o tu reputación.

No te acomodes y especialízate demasiado pronto

A menudo doy este consejo a quienes comienzan su camino en la programación: “aprende habilidades generales de programación (JavaScript, SQL, Linux, y así sucesivamente) y luego especialízate en el trabajo.”

La idea es que, una vez que entiendas cómo funcionan las herramientas más comunes, puedes aprender fácilmente las equivalentes menos comunes de esas herramientas.

Por ejemplo, una vez que hayas aprendido PostgreSQL, puedes aprender fácilmente MySQL. Una vez que hayas aprendido Node.js, puedes aprender fácilmente Ruby on Rails o Java Spring Boot.

Pero algunas personas se especializan demasiado pronto en el trabajo. Su jefe puede pedirles que “se encarguen” de una API o función en particular. Y si lo hacen bien, su jefe puede seguir asignándoles proyectos similares.

Tú solo te encargas de ti mismo, pero tu jefe se encarga de muchas personas. Es posible que estén demasiado ocupados para desarrollar una comprensión sutil de tus habilidades e intereses. Pueden verte como “la persona de XYZ” y simplemente darte tareas relacionadas con eso.

Pero tú sabes en qué eres bueno y en qué estás interesado. Puedes intentar ofrecerte como voluntario para proyectos fuera de tu zona de confort. Si puedes hacer que tu jefe te los asigne, podrás seguir ampliando tus habilidades y, potencialmente, trabajar con nuevos equipos.

Recuerda: tu jefe puede ser responsable de tu desempeño en el trabajo, pero tú eres responsable de tu desempeño a lo largo de tu carrera.

Asume proyectos que cumplan tus obligaciones con tu empleador y que también te posicionen bien para tus metas profesionales a largo plazo.

Epílogo: Tú puedes hacer esto

Si hay un mensaje que quiero dejarte aquí, es este: tú puedes hacer esto.

Tú puedes aprender estos conceptos.

Tú puedes aprender estas herramientas.

Tú puedes convertirte en un desarrollador.

Entonces, en el momento en que alguien te pague por ayudarles a programar algo, te graduarás como un desarrollador profesional.

Aprender a programar y obtener un primer empleo como desarrollador es un proceso desafiante. Pero no te desanimes.

Si perseveras, eventualmente tendrás éxito. Solo es cuestión de práctica.

Construye tus proyectos. Muestra tus proyectos a tus amigos. Haz proyectos para tus amigos.

Construye tu red de contactos. Ayuda a las personas que conozcas en el camino. Lo que das, te será devuelto.

No es demasiado tarde. La vida es larga.

Mirarás hacia atrás en este momento dentro de algunos años y estarás contento de haber dado este paso.

Planifica que lleva tiempo. Planifica ante la incertidumbre.

Pero sobre todo, sigue volviendo al teclado. Sigue asistiendo a eventos. Sigue compartiendo tus éxitos con tus amigos.

Como dijo una vez Lao Tzu, el Viejo Maestro:

“Un viaje de mil millas comienza con un solo paso.”

Al terminar este libro, ya has dado un paso. Incluso es posible que hayas dado muchos pasos hacia tus metas.

El impulso es todo. Así que manten ese impulso hacia adelante que ya has construido en estas últimas horas con este libro.

Comienza a programar tu próximo proyecto hoy.

Y siempre recuerda:

Tú puedes hacer esto.

---

• Career
• Education
• handbook
• Learn To Code
• Self Improvement