![Cómo aprender a programar y conseguir un trabajo de desarrollador [Libro completo]](https://www.freecodecamp.org/espanol/news/content/images/size/w2000/2024/09/Learn-to-Code-and-Get-a-Developer-Job-Book.png)
Artículo original: How to Learn to Code and Get a Developer Job [Full Book]
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 – gratis – aquí mismo en esta página de freeCodeCamp.
Además, he grabado una versión completa en audiolibro GRATIS de este libro, que publiqué como el episodio #100 del Podcast de freeCodeCamp. Puedes buscarlo en tu reproductor de podcasts favorito. Asegúrate de suscribirte. También lo he incrustado a continuación para tu conveniencia.
Hace unos años, una de las 5 grandes editoriales de libros de la ciudad de Nueva York me contactó acerca de un contrato para un libro. Me reuní con ellos, pero no tenía tiempo para escribir un libro.
Bueno, finalmente tuve tiempo. Y decidí simplemente publicar este libro gratis, aquí mismo en freeCodeCamp.
La información quiere ser gratis, ¿verdad? 🙂
Te llevará unas pocas horas leer todo esto. Pero aquí está. Mis ideas sobre 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 sobre matemáticas, programación y ciencias de la computación.
Yo era un profesor de inglés que nunca había programado antes. Y pude aprender lo suficiente de programación para conseguir mi primer trabajo de desarrollo de software en solo un año.
Todo sin gastar dinero en libros o cursos.
(Gasté dinero para viajar a ciudades cercanas y participar en eventos tecnológicos. Y como verás más adelante en el libro, esto fue dinero bien gastado).
Después de trabajar como ingeniero de software durante unos años, me sentí listo. Quería enseñar a otras personas cómo hacer esta transición de carrera también.
Construí varias herramientas educativas tecnológicas en las que nadie estaba interesado en usar. Pero luego, un fin de semana, creé freeCodeCamp.org. Una comunidad vibrante se reunió rápidamente 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.
Tal vez estés 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 las 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 para terminar de leer este libro. 😉
Prometo ser respetuoso de tu tiempo. No hay exageraciones ni relleno aquí – solo consejos directos y prácticos.
Voy a llenar cada capítulo de este libro con tanta perspicacia como pueda.
Lo que me recuerda: ¿dónde está la tabla de contenidos?
Ah. Aquí está:
Tabla de contenidos
- Prefacio: ¿Para Quién es este libro?
- Resumen ejecutivo de 500 palabras
- Capítulo 1: Cómo mejorar tus habilidades
- Capítulo 2: Cómo construir tu red de contactos
- Capítulo 3: Cómo construir tu reputación
- Capítulo 4: Cómo ser pagado por programar – clientes freelance y la búsqueda de empleo
- Capítulo 5: Cómo tener éxito en tu primer trabajo como desarrollador
- Epílogo: Tú puedes hacerlo
Prefacio: ¿Para quién es este libro?
Este libro es para cualquiera que esté considerando una carrera en el desarrollo de software.
Si estás buscando una carrera que sea flexible, bien remunerada, y que implique mucho resolver problemas creativos, el desarrollo de software puede ser para ti.
Por supuesto, cada uno de nosotros aborda su viaje de codificación con ciertos recursos: tiempo, dinero y oportunidad.
Puede que seas mayor y tengas hijos o parientes ancianos de los que te ocupas. Por lo que puedes tener menos tiempo.
O puedes ser más joven, y puede que hayas tenido menos tiempo para acumular ahorros o adquirir habilidades que aumenten tus ingresos. Por lo que puedes tener menos dinero.
Y es posible que vivas lejos de las principales ciudades tecnológicas como San Francisco, Berlín, Tokio o Bengaluru.
O puedes vivir con discapacidades, físicas o mentales. El edadismo, el racismo y el sexismo son reales. El estatus migratorio puede complicar la búsqueda de empleo. También puede hacerlo un historial delictivo.
Por lo tanto, puedes tener menos oportunidad.
Aprender a programar y conseguir un trabajo como desarrollador va a ser más difícil para algunas personas que para otras. Cada uno aborda este desafío desde su propio punto de partida, con los recursos que tenga a mano.
Pero donde sea que estés comenzando -en términos de tiempo, dinero y oportunidad- haré mi mejor esfuerzo para darte consejos prácticos.
Una nota rápida sobre terminología
Siempre que use nuevos términos, haré lo mejor que pueda para definirlos.
Pero hay unos cuantos términos que usaré todo el tiempo.
Usaré las palabras "programación" y "codificación" de manera intercambiable.
Usaré la palabra "app" como se pretendía – como abreviatura de cualquier tipo de aplicación, independientemente de si se ejecuta en un teléfono, portátil, consola de juegos o refrigerador. (Lo siento, Steve Jobs. El iPhone no tiene el monopolio de la palabra app.)
También usaré las palabras "ingeniero de software" y "desarrollador de software" de manera intercambiable.
Puedes encontrar personas en tecnología que se opongan a esto. Como si la ingeniería de software fuera un campo pomposo con un legado de varios siglos, como lo son 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.
Dejaré esta cita aquí para ti, por si te sientes incómodo llamándote ingeniero de software:
"Si los constructores construyeran edificios de la manera en que los programadores escriben programas, el primer pájaro carpintero que pasara destruiría la civilización." – Gerald Weinberg, Programador, Autor y Profesor Universitario
¿Puede cualquiera 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 motivacional – no una cuestión de aptitud.
En las sabanas de África – donde los primeros humanos vivieron durante miles de años antes de extenderse a Europa, Asia y las Américas – ¿había computadoras?
Las habilidades de programación nunca fueron algo seleccionado a lo largo de los milenios. Las computadoras como las conocemos (escritorios, portátiles, teléfonos inteligentes) surgieron en los 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 necesitará dedicar tiempo al teclado.
Una gran mayoría de personas que intentan aprender a programar se frustrarán y se rendirán.
Yo ciertamente lo hice. Me frustré y me rendí. Varias veces.
Pero como 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 conseguir un trabajo de desarrollador es difícil. Y es aún más difícil para algunas personas que para otras, debido a las circunstancias.
No voy a fingir haber enfrentado una verdadera adversidad al aprender a programar. Sí, estaba en mis 30s, y no tenía formación formal en programación o ciencias de la computación. Pero considera esto:
Crecí en clase media en los Estados Unidos – un estadounidense de cuarta generación de un hogar de habla inglesa. Fui a la universidad. Mi padre fue a la universidad. Y su padre fue a la universidad. (Sus padres antes que él eran agricultores de Suecia.)
Me beneficié de una especie de privilegio intergeneracional. Un impulso que algunas familias pueden acumular con el tiempo cuando no son destrozadas por la guerra, la hambruna o la esclavitud.
Así que ese es mi gran salvedad para ti: no soy una figura motivacional para animarte a superar la adversidad.
Si necesitas inspiración, hay un montón de personas en la comunidad de desarrolladores que han superado una verdadera adversidad. 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 surgir si todos aprenden a programar.
En cambio, solo voy a darte consejos prácticos sobre cómo adquirir estas habilidades. Y cómo puedes conseguir un buen trabajo, para que puedas mantener a tu familia.
No hay nada de malo en aprender a programar porque quieres un trabajo bueno y estable.
No hay nada de malo en aprender a programar para que puedas iniciar un negocio.
Puedes encontrar personas que digan que debes estar tan apasionado por la programación que sueñas con ella. Que sales de tu trabajo de tiempo completo, luego pasas todo el fin de semana contribuyendo a proyectos de código abierto.
Conozco gente que es tan apasionada por la programación. Pero también conozco a muchas personas que, después de terminar una semana de trabajo arduo, solo quieren pasar tiempo en la naturaleza o jugar juegos de mesa con amigos.
La gente generalmente disfruta haciendo cosas en las que son buenos. Y puedes desarrollar un nivel razonable de pasión por la programación simplemente mejorando en ella.
Entonces, en resumen: ¿para quién es este libro? Para cualquiera que quiera mejorar en la programación y conseguir un trabajo como desarrollador. Eso es todo.
No necesitas ser un autoproclamado "geek", un introvertido o un activista ideológicamente motivado. O cualquiera de esos estereotipos.
Está bien si lo eres. Pero no necesitas serlo.
Entonces, si eso eres tú – si estás seriamente comprometido en aprender a programar lo suficientemente bien como para que te paguen por hacerlo – este libro es para ti.
Y deberías 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 gratificante creativamente. Hay una progresión de carrera clara 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 desarrollador están fuera de lo que tradicionalmente llamamos "tecnología" – en agricultura, manufactura, gobierno e industrias de servicios como banca y salud.
Si te preocupa que tu trabajo se automatice antes de jubilarte, ten en cuenta lo siguiente: la codificación es el acto de automatizar cosas. Por tanto, es por definición la última profesión que se automatizará por completo.
La automatización impactará la codificació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 le das a las computadoras objetivos de nivel superior. En otras palabras: programación al estilo de Star Trek.
Aún deberías aprender matemáticas aunque ahora tengamos calculadoras. Y aún deberías aprender a programar aunque ahora tengamos herramientas de IA que pueden escribir código.
¿Te he convencido para que elijas la codificación como carrera?
Bien. Aquí te explico cómo ingresar en el 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
Estas son todas tecnologías maduras, con más de 20 años. Sea cual sea la empresa para la que trabajes, casi seguro usarás la mayoría de estas herramientas.
La mejor manera de aprender estas herramientas es construir proyectos. Intenta codificar al menos un poco cada día. Si haces el currículum de freeCodeCamp de principio a fin, aprenderás todo esto y construirás docenas de proyectos.
Algunas de las certificaciones en el currículo central de freeCodeCamp.
Construye tu red de contactos.
Conseguir un empleo depende mucho de a quién conoces.
Está bien ser introvertido, pero necesitas expandir tus límites.
Crea cuentas en GitHub, Twitter, LinkedIn y Discord.
Asiste a reuniones y conferencias tecnológicas. Viaja si es necesario. (La mayor parte de tu presupuesto para "aprender a codificar" debería ir hacia viajes y entradas a eventos, no en libros y cursos.)
Saluda a las personas que están solas. Deja que otros hagan la mayor parte de la charla, y escucha de verdad. Recuerda los nombres de las personas.
Agrega gente en LinkedIn, síguelos en Twitter, y ve a las fiestas posteriores.
Construye tu reputación.
Comparte demos de video cortos de tus proyectos.
Sigue postulando para hablar en conferencias cada vez más grandes.
Pasa el rato en hackerspaces y ayuda a personas que son aún más nuevas en la codificación que tú.
Contribuye al código abierto. El trabajo es similar al desarrollo de software profesional.
Desarrolla tus habilidades, red de contactos y reputación al mismo tiempo. No te permitas posponer las partes más aterradoras.
En lugar de postular a trabajos a través de la "puerta principal", utiliza tu red para conseguir entrevistas de trabajo a través de la "puerta lateral". Los reclutadores también pueden ayudarte.
Sigue entrevistándote hasta que empieces a recibir ofertas de trabajo. No necesitas aceptar la primera oferta que recibas. Sé paciente.
Tu primer trabajo como desarrollador será el más difícil. Trata de quedarte allí al menos 2 años, y básicamente recibirás pago por aprender.
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 codificar lo suficientemente bien como para conseguir un trabajo como desarrollador.
Es solo una cuestión de cuánto lo deseas y de cuán persistente puedes ser en la búsqueda de empleo.
Recuerda: puedes hacerlo.
Este libro está dedicado a la comunidad global de freeCodeCamp.
Gracias a todos ustedes que han apoyado nuestra caridad y nuestra misión durante los últimos 9 años.
Es a través de su voluntariado y filantropía que hemos podido ayudar a tantas personas a aprender a codificar y conseguir su primer trabajo como desarrollador.
La comunidad ha crecido mucho desde el humilde proyecto de código abierto que desplegué 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 información. Acceso a educación. Y acceso a las herramientas que están moldeando el futuro.
Estos son aún días tempranos. No tengo la ilusión de que todos sabrán cómo codificar en mi vida. Pero al igual que la Biblia de Gutenberg aceleró la alfabetización en 1455, podemos seguir acelerando la alfabetización tecnológica a través de recursos de aprendizaje gratuitos y abiertos.
Nuevamente, gracias a todos.
Y un agradecimiento especial a Abbey Rennemeyer por sus comentarios editoriales y a Estefania Cassingena Navone por diseñar la portada del libro.
Y ahora, el libro.
Capítulo 1: Cómo desarrollar tus habilidades
"Todo artista fue primero un aficionado." ― Ralph Waldo Emerson
El camino para saber cómo codificar es largo.
Para mí, fue ambiguo.
Pero no tiene que ser así para ti.
En este capítulo, voy a compartir algunas estrategias para aprender a codificar de la manera más fluida posible.
Primero, permíteme contarte cómo aprendí a codificar 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.
Historia: ¿Cómo un maestro en sus 30 se enseñó a codificar?
Yo era un maestro que dirigía una escuela de inglés. Teníamos unos 100 estudiantes adultos que habían viajado a California desde todo el mundo. Estaban aprendiendo inglés avanzado para poder ingresar a la escuela de posgrado.
A la mayoría de los maestros de nuestra escuela les encantaba enseñar. Les encantaba salir con estudiantes por la ciudad y ayudarlos a mejorar su inglés conversacional.
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 tenías que ser inteligente para eso? Apenas podía configurar un router WiFi. Y era pésimo en matemáticas.
Bueno, un día simplemente dejé todo eso de lado y pensé: "¿Sabes qué? Voy a intentarlo. ¿Qué tengo que perder?"
Empecé a buscar en Google preguntas como "cómo hacer clic automáticamente en sitios web" y "cómo importar datos de sitios web a Excel".
En ese momento no me di cuenta, pero estaba aprendiendo a automatizar flujos de trabajo.
Y comenzó el aprendizaje. Primero con macros de Excel. Luego con una herramienta llamada AutoHotKey donde puedes programar tu ratón para moverse a ciertas coordenadas de una pantalla, hacer clic, copiar texto, luego moverse a diferentes coordenadas y pegarlo.
Después de unas semanas de andar a tientas, 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 rellenada.
Era el trabajo de un aficionado. Lo que los desarrolladores podrían llamar un "hack sucio". Pero hizo el trabajo.
Usé mis nuevas habilidades de automatización para seguir agilizando la escuela.
Pronto, los maestros apenas tenían que tocar una computadora. Yo estaba haciendo el trabajo de varios maestros, solo con mis habilidades rudimentarias.
Esto tuvo un impacto visible en la escuela. Mucho de nuestro tiempo había estado atado a trabajos rutinarios en la computadora. Y ahora éramos libres.
Los maestros eran más felices. Pasaban más tiempo con los estudiantes.
Los estudiantes eran más felices. Le decían a todos sus amigos en su país de origen "tienes que ver esta escuela."
Pronto éramos una de las escuelas más exitosas en todo el sistema escolar.
Esto me envalentonó aún más. Recuerdo pensar para mí mismo: "Tal vez pueda aprender a programar."
Conocía a algunos ingenieros de software de mi noche de juegos de mesa. Ellos tenían antecedentes tradicionales, con títulos de Cal Tech, Harvey Mudd y otros famosos programas de Ciencias de la Computación.
En ese momento, era mucho menos común que personas en sus 30 aprendieran a programar.
Reuní el valor para compartir mis sueños con algunos de estos amigos.
Quería aprender a programar de manera adecuada. Quería poder escribir código para ganarme la vida como ellos lo hacían. Y tal vez incluso escribir software que pudiera impulsar escuelas.
Compartía estos sueños con mis amigos desarrolladores. "Quiero hacer lo que ustedes hacen."
Pero se encogían de hombros. Luego decían algo como:
"Quiero decir, podrías intentarlo. Pero tendrás que beber todo un océano de conocimiento."
Y: "Es un campo bastante competitivo. ¿Cómo piensas competir con gente que creció programando desde una edad temprana?"
Y: "Ya lo estás haciendo bien como maestro. ¿Por qué no te quedas con lo que eres bueno?"
Y eso me desviaba durante unas semanas. Iba en largas caminatas nocturnas en busca de mi alma. Reflexionaba sobre mi futuro bajo las estrellas. ¿Estaban en lo cierto estas personas? Es decir, ellos sabrían, ¿verdad?
Pero cada mañana volvía a mi escritorio. Mirando mis scripts correr. Viendo mis informes compilarse a velocidades sobrehumanas. Observando cómo mi computadora ejecutaba mis órdenes.
Se me ocurrió un pensamiento: tal vez estos amigos solo intentaban salvarme de un desamor. Tal vez simplemente no conocen a nadie que haya aprendido a programar en sus 30. Así que no creen que sea posible.
Es como... durante años los médicos pensaron que sería imposible para alguien correr una milla en 4 minutos. Pensaban que tu corazón podría explotar de correr tan rápido.
Pero luego alguien logró hacerlo. Y su corazón no explotó.
Una vez que Roger Bannister, un estudiante de Oxford de 25 años, rompió esa barrera psicológica, un montón de otras personas lo lograron también. Hasta la fecha, más de 1000 personas han corrido una milla en menos de 4 minutos.
Roger Bannister corriendo como un campeón. (Imagen: Britannica)
Y no es que yo estuviera haciendo algo tan audaz e inédito como correr una milla en 4 minutos. Muchos desarrolladores famosos han logrado enseñarse a sí mismos a programar a lo largo de los años.
Vaya, Ada Lovelace se enseñó a programar en la década de 1840. Y ni siquiera tenía una computadora funcionando. Solo tenía un entendimiento de cómo funcionaría en teoría la computadora de su amigo Charles Babbage.
Escribió varios de los primeros algoritmos de computadoras. Y es ampliamente considerada la primera programadora del mundo. Nadie la enseñó. Porque no había nadie para enseñarla. Cualquiera que fuera la duda en sí misma que pudo haber tenido, claramente la superó.
Ahora, yo no era Ada Lovelace. Solo era un maestro que ya tenía una computadora funcionando, una conexión decente a internet y la capacidad de buscar en miles de millones de páginas web con Google.
Me crují los nudillos y afiné mi mirada. Iba a hacerlo.
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? Tienes que reflexionar sobre tus actividades para obtener una verdadera experiencia. Si haces del aprendizaje un compromiso continuo, obtendrás experiencia. Si no lo haces, no importa cuántos años tengas en tu haber, no la obtendrás." – Steve McConnell, Ingeniero de Software
Oh mira, un tutorial de Ruby.
Oh no, está empezando a ponerse difícil. 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 una cosa graciosa. En el momento en que algo empieza a ponerse difícil, nos preguntamos: ¿estoy haciendo esto bien?
Tal vez este tutorial esté desactualizado. Tal vez su autor no sabía de lo que hablaba. ¿Acaso alguien todavía usa este lenguaje de programación?
Cuando te enfrentas a mensajes de error ambiguos horas dentro de una sesión de codificación, el césped del otro lado empieza a verse mucho más verde.
Era fácil pretender que había hecho progreso. Hora de ir a almorzar.
Vería a un amigo en el café. "¿Cómo va tu programación?" preguntaría.
"Va genial. Ya he codificado 4 horas hoy."
"Increíble. Me encantaría ver lo que estás construyendo algún día."
"Claro," diría yo, sabiendo que no había construido nada. "Pronto."
Tal vez iría a la biblioteca a revisar un nuevo libro de JavaScript.
Está ese viejo dicho de que comprar libros te da la mejor sensación del mundo. Porque también se siente como si estuvieses comprando el tiempo para leerlos.
Y aquí es precisamente donde me encontré unas semanas después de comenzar a aprender 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 "el infierno de los tutoriales".
El infierno de los tutoriales es donde saltas de un tutorial a otro, aprendiendo y luego reaprendiendo las mismas cosas básicas. Pero nunca realmente yendo más allá de los fundamentos.
Porque ir más allá de los fundamentos? Bueno, eso requiere un trabajo real.
Se necesita una aldea para criar a un programador
Aprender a programar estaba absorbiendo todo mi tiempo libre. Pero no estaba haciendo mucho progreso. Ahora podía teclear los caracteres { y * sin mirar el teclado. Pero eso era todo.
Sabía que necesitaba ayuda. Tal vez algún mentor al estilo Yoda, que pudiera enseñarme el camino. Sí – si tal persona existiera, seguramente marcaría toda la diferencia.
Descubrí un lugar cercano llamado un "hackerspace". Cuando escuché el nombre por primera vez, me sentí un poco aprensivo. ¿Acaso los hackers no hacen cosas ilegales? Yo era un profesor de inglés al que le gustaba jugar juegos de mesa. No estaba en busca de problemas.
Bueno, llamé al número que se listaba y hablé con un chico llamado Steve. Nerviosamente 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 irrumpir maliciosamente en 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 aún así puedes tener "un truco ingenioso" – un truco ingenioso para hacer que tu código funcione más eficientemente.
En resumen: no te asustes de la palabra "hack."
El campus corporativo de Facebook tiene la palabra "hack" escrita en letras gigantes en el concreto. (Imagen: Bloomberg)
Yo, por mi parte, apenas uso el término porque es muy confuso. Y creo que recientemente muchos hackerspaces han captado la ambigüedad. Muchos de ellos ahora se llaman a sí mismos "makerspaces" en su lugar.
Porque de eso se trata un hackerspace – de hacer cosas.
Steve me invitó a visitar el hackerspace una tarde de sábado. Dijo que varios desarrolladores de la zona estarían allí.
La primera vez que crucé las puertas del Hackerspace de Santa Barbara, quedé impresionado.
El lugar olía a un incendio eléctrico. Sus mesas improvisadas estaban llenas de soldadores, tiras de luces LED, placas de circuito Arduino para aficionados y montones de robots aspiradores Roomba.
El mismo Steve con quien había hablado por teléfono estaba allí y me saludó. Tenía gafas, cabello engominado y una barba de chivo. 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. Aún era un apasionado de esos temas. 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 escrito que reconocería códigos QR en un video y los reemplazaría con imágenes.
Alguien en la audiencia mostró un código QR en su laptop y lo sostuvo frente a la cámara. La aplicación de Steve entonces reemplazó el código QR con 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 comenzó a hacer cambios en tiempo real. Tabulaba sin esfuerzo entre su editor de código, su línea de comandos y el navegador en el que la aplicación estaba ejecutándose, "cargando en caliente" actualizaciones del código.
Para mí, esto era hechicería. No podía creer que Steve hubiera sacado esa aplicación en el transcurso de unas pocas horas. Y ahora estaba añadiendo nuevas características sobre la marcha, a medida que la audiencia las pedía.
Pensé: "Este tipo es un genio."
Y esa noche, después de que terminó el evento, él y yo nos quedamos y se lo dije.
Pero Steve se resistió. Dijo, "Yo no soy nada especial. No te limites. Si sigues con la programación, podrías superarme fácilmente".
Ahora bien, ni por un segundo creí las palabras que me dijo. Pero el simple hecho de que lo dijera me puso mariposas en el estómago.
Aquí estaba: un desarrollador que creía en mí. Él me veía – algún maestro cualquiera – la definición misma de un "script kiddie" – y pensaba que podía lograrlo.
Steve y yo hablamos hasta altas horas de la noche. Me mostró su computadora netbook de $200, que incluso para los estándares de 2011 estaba lamentablemente subpotenciada.
"No necesitas una computadora potente para construir software", me dijo Steve. "El hardware de hoy es increíblemente poderoso. Las computadoras son lentas solo porque el software hinchado que ejecutan las hace lentas. Consigue una laptop de tienda, formatea el disco duro, instala Linux en ella y empieza a programar".
Tomé nota del modelo de la laptop que él tenía y pedí exactamente la misma cuando llegué a casa esa noche.
Después de unos días depurando mi nueva computadora con Stack Overflow, logré instalar Ubuntu exitosamente. Empecé a aprender cómo usar el editor de código Emacs. Para el siguiente sábado, sabía algunos comandos y estaba listo para mostrarlos.
Steve asintió con aprobación. Dijo, "Genial. Pero, ¿qué estás construyendo?"
No entendía lo que quería decir. "Estoy aprendiendo a usar Emacs. Mira. Memorice..."
Pero Steve lucía pensativo. "Eso está bien y todo. Pero necesitas un proyecto. Siempre ten un proyecto. Luego aprende lo que necesites aprender en el camino para terminar ese proyecto".
Aparte de algunos scripts que había escrito para ayudar a los maestros de mi escuela, nunca había terminado nada. Pero empecé a ver lo que estaba diciendo.
Y empecé a darme cuenta. Todo este tiempo había estado atrapado en el infierno de tutoriales, dando vueltas en círculos, sin terminar nada.
Steve dijo, "Quiero que construyas un proyecto usando HTML5. Y el próximo sábado, quiero que lo presentes en el hackerspace."
Me aterraron sus palabras. Pero me levanté derecho y dije. "Suena como un plan. Estoy en ello."
Nadie puede hacerte un pesarrollador más que tú
"Estoy tratando de liberar tu mente, Neo. Pero solo puedo mostrarte la puerta. Tú eres quien tiene que atravesarla." – Morpheus en la película de 1999 The Matrix
A la mañana siguiente, me desperté extra temprano antes del trabajo y busqué en Google algo así como "tutorial de HTML5". Ya sabía mucho de esto por mi tiempo anterior en el infierno de tutoriales. Pero en lugar de avanzar rápido, simplemente fui despacio y seguí todo al pie de la letra, escribiendo cada comando.
Usualmente, una vez que terminaba un tutorial, simplemente iba a encontrar otro tutorial. Pero en cambio, empecé a jugar con el código del tutorial. Tenía una idea simple para un proyecto. Iba a hacer una página de documentación en HTML5. Y la iba a codificar puramente en HTML5.
Déjame explicar HTML5 rápidamente. Es solo una versión más nueva de HTML, que ha existido desde las primeras páginas web allá en los años 90.
Si un sitio web fuera un cuerpo, HTML sería los huesos. Todo lo demás se apoya en 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 a diferentes partes de la misma página web usando propiedades de ID. Así que pensé: ¿qué tal si pongo una tabla de contenidos a lo largo del lado izquierdo? Luego, al hacer clic en los diferentes ítems a la izquierda, se desplazará hacia abajo en la página a la derecha para mostrar esos ítems.
En media hora, había codificado un prototipo básico.
Pero era hora de presentarme al trabajo en la escuela. Todo el día, lo único que podía pensar era en mi proyecto y en cómo avanzar para terminarlo.
Corrí a casa, abrí mi laptop y pasé toda la noche codificando.
Copié la documentación oficial de HTML (con licencia creative commons) directamente en mi página, "codificándola duramente" en el HTML.
Luego pasé alrededor de una hora en el CSS, haciendo que todo se viera bien y usando posicionamiento absoluto para mantener la barra lateral en su lugar.
Me aseguré de usar la mayor cantidad posible de las nuevas etiquetas "semánticas" de HTML5.
Y boom – proyecto terminado.
Una ola de logro me invadió. Corrí a un campo de fútbol cercano e hice vueltas alrededor del campo, celebrando. Lo hice. Terminé un proyecto.
Y decidí en ese mismo momento: de aquí en adelante, todo lo que haga va a ser un proyecto. Voy a trabajar hacia algún producto terminado.
La noche siguiente me acerqué al podio, conecté mi laptop y presenté mi página en HTML5. Respondí preguntas de los desarrolladores allí sobre HTML5.
A veces me equivocaba en algo, y alguien en la audiencia decía, "eso no suena bien – déjame revisar la documentación."
La gente no tenía miedo de corregirme. Pero eran educados y apoyaban. Ni siquiera sentía que me estuvieran corrigiendo – sentía que estaban corrigiendo el registro público – para que nadie se fuera 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 maestros.
En cambio, casi sentí como si fuera parte de la audiencia, aprendiendo junto a ellos.
Después de mi charla, Steve se me acercó y dijo, "No está mal."
Sonreí durante un rato torpemente largo, sin decir nada, simplemente contenta conmigo misma.
Luego Steve entrecerró los ojos y frunció los labios. Dijo: "Empieza tu próximo proyecto esta noche."
Lecciones de mi viaje de programación
Revisaremos el viaje de programación de un joven Quincy en cada uno de los siguientes capítulos. Pero ahora quiero desglosar algunas de las lecciones aquí. Y quiero responder algunas de las preguntas que puedas tener.
¿Por qué es tan difícil aprender a programar?
Aprender cualquier nueva habilidad es difícil. Ya sea driblar un balón de fútbol, cambiar el aceite de un coche o hablar un nuevo idioma.
Aprender a programar es difícil por algunas razones particulares. Y algunas de estas son únicas de la programación.
La primera es que la mayoría de las personas no entienden exactamente qué es la programación. Bueno, te lo voy a decir.
¿Qué es la programación?
Programar es decirle a una computadora qué hacer, de una manera que la computadora pueda entender.
Eso es todo. Eso es realmente la programació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 programando, probablemente no harán lo que quieres que hagan.
Puedes estar pensando: ¿y los servidores? ¿y las bases de datos? ¿y las redes?
Al final del día, todos estos son controlados por capas de software. Código. Es todo código hasta abajo. Eventualmente llegas al hardware físico, que está moviendo electrones alrededor de las placas de circuitos.
Durante las primeras décadas de la informática, los desarrolladores escribían código que estaba "cerca del metal": a menudo operando directamente sobre 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 otros programas – que solo unas pocas líneas de código en JavaScript pueden hacer cosas realmente poderosas.
En los años 60, un "error" podía ser un insecto arrastrándose dentro de una computadora del tamaño de una habitación, y freírse en uno de los circuitos.
El primer error informático, descubierto en 1945, fue una polilla que quedó atrapada en los paneles de una computadora calculadora del tamaño de una habitación en Harvard. (Imagen: Dominio Público)
Hoy en día, estamos escribiendo código en muchas capas de abstracción por encima del hardware físico.
Eso es programar. Es infinitamente más fácil de lo que ha sido en el pasado. Y está siendo más fácil cada año.
No estoy exagerando cuando digo que en unas pocas décadas, programar será tan fácil y tan común que la mayoría de los jóvenes sabrán cómo hacerlo.
¿Por qué sigue siendo tan difícil aprender a programar después de todos estos años?
Hay tres grandes razones por las cuales aprender a programar es tan difícil, incluso hoy:
- Las herramientas siguen siendo primitivas.
- La mayoría de las personas no son buenas manejando la ambigüedad, y aprender a programar es ambiguo. La gente se pierde.
- La mayoría de las personas no son buenas manejando retroalimentación negativa constante. Y aprender a programar es un brutal mensaje de error tras otro. La gente se frustra.
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 siguen siendo primitivas
Un poseído Barclay de Star Trek: La Nueva Generación, programando en el Holodeck.
"Computadora. Iniciar nuevo programa. Crear lo siguiente. Silla de estación de trabajo. Ahora crea una consola alfanumérica estándar posicionada a la mano izquierda. Ahora una consola de visualización icónica para la mano derecha. Conecta ambas consolas al núcleo principal de la computadora de la Enterprise, utilizando la interfaz de escaneo neural." - Barclay de Star Trek: La Nueva Generación, Temporada 4 Episodio 19: "El Grado N-ésimo"
Así es como la gente podría programar en el futuro. Es un ejemplo de mi programa de televisión de ciencia ficción favorito, Star Trek: La Nueva Generación.
Cada personaje en Star Trek puede programar. Doctores, agentes de seguridad, pilotos. Incluso el pequeño Wesley Crusher (interpretado por el actor infantil Wil Wheaton) puede hacer que la computadora de la nave haga lo que él quiera.
Claro, una de las razones por las que todos pueden programar es que viven en una sociedad del siglo XXIV sin escasez, con acceso a una 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 una computadora exactamente qué hacer, y – si eres lo suficientemente preciso – la computadora lo hará.
¿Qué pasaría si programar fuera tan fácil como simplemente decir 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.
Trabajando con una computadora basada en tarjetas perforadas en los años 50 (Imagen: NASA)
Antes, programar incluso una aplicación simple requería instrucciones meticulosas.
Aquí hay 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. 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).
Voy a mostrarte dos ejemplos de este programa.
Primero, aquí está el programa en ensamblador x86:
format ELF executable 3
entry start
segment readable writeable
buf rb 1
segment readable executable
start: mov eax, 3 ; syscall "read"
mov ebx, 0 ; stdin
mov ecx, buf ; buffer for read byte
mov edx, 1 ; len (read one byte)
int 80h
cmp eax, 0 ; EOF?
jz exit
xor eax, eax ; load read char to eax
mov al, [buf]
cmp eax, "A" ; see if it is in ascii a-z or A-Z
jl print
cmp eax, "z"
jg print
cmp eax, "Z"
jle rotup
cmp eax, "a"
jge rotlow
jmp print
rotup: sub eax, "A"-13 ; do rot 13 for A-Z
cdq
mov ebx, 26
div ebx
add edx, "A"
jmp rotend
rotlow: sub eax, "a"-13 ; do rot 13 for 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 ; string length
int 80h
jmp start
Este ejemplo de Assembly x86 proviene del proyecto Rosetta Code con licencia Creative Commons.
Y aquí está el mismo programa, escrito en Python:
def rot13(text):
result = []
for char in text:
ascii_value = ord(char)
if 'A' <= char <= 'Z':
result.append(chr((ascii_value - ord('A') + 13) % 26 + ord('A')))
elif 'a' <= char <= 'z':
result.append(chr((ascii_value - ord('a') + 13) % 26 + ord('a')))
else:
result.append(char)
return ''.join(result)
if __name__ == "__main__":
input_text = input("Enter text to be encoded/decoded with ROT-13: ")
print("Encoded/Decoded text:", rot13(input_text))Esto es bastante más simple y fácil de leer, ¿verdad?
Este ejemplo de Python proviene directamente de GPT-4. Le di la instrucción de la misma forma en que el Capitán Picard daría una orden 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 cámbiala 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 generó este código Python, y luego me leyó el resultado: "Onanan."
Lo que estamos haciendo aquí se llama Programación Declarativa. Estamos declarando "computadora, deberías 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 usan hoy en día es Programación Imperativa. Les decimos a las computadoras exactamente qué hacer, paso a paso. Porque históricamente, las computadoras han sido bastante tontas. Así que hemos tenido que ayudarles a poner un pie delante del otro.
El campo del desarrollo de software aún no está maduro.
Pero al igual que las herramientas humanas primitivas avanzaron - de piedra a bronce a hierro - lo mismo está pasando con las herramientas de software. Y mucho más rápido.
Probablemente todavía estamos en el equivalente en programación de la Edad de Bronce en este momento. Pero podríamos llegar a la Edad de Hierro en nuestra vida. Las herramientas de IA generativa como GPT están volviéndose rápidamente más poderosas y confiables.
La comunidad de desarrolladores aún está dividida sobre cuán útiles serán herramientas como GPT para el desarrollo de software.
Por un lado, tienes a los influencers emprendedores de "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 para una aplicación."
Y en el otro lado del espectro, tienes a los desarrolladores de la "vieja guardia" con décadas de experiencia en programación, muchos de los cuales son escépticos de que herramientas como GPT sean realmente útiles para producir código de calidad para 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 para una aplicación, luego le piden a ChatGPT que genere el código que necesitan. Algunas personas incluso pueden tomar ese código y conectarlo 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.
Aun así, muchos desarrolladores son escépticos sobre cuán útiles se volverán estas herramientas en última instancia. Cuestionan si seremos capaces de lograr que las IAs dejen de "alucinar" información falsa.
Este es el problema fundamental de la "Interpretabilidad." Podrían pasar décadas antes de que realmente entendamos lo que está pasando dentro de una IA de caja negra como GPT-4. Y hasta que lo hagamos, deberíamos verificar todo lo que dice y asumir que habrá muchos errores y fallos de seguridad en el código que nos da.
Hay una gran diferencia entre lograr que una computadora haga algo por ti, y realmente entender cómo la computadora lo está haciendo.
Muchas personas pueden operar un coche. Pero muchas menos pueden reparar un coche, y aún menos pueden diseñar un coche nuevo desde cero.
Si quieres ser capaz de desarrollar sistemas de software poderosos que resuelvan nuevos problemas, y quieres que esos sistemas sean rápidos y seguros, todavía necesitas aprender a programar adecuadamente.
Y eso significa abrirte camino a través de mucha ambigüedad.
Aprender a programar es un proceso ambiguo
Cuando estás aprendiendo a programar, te preguntas constantemente: "¿Estoy aprovechando bien mi tiempo? ¿Estoy aprendiendo las herramientas correctas? ¿Saben siquiera de qué están hablando estos autores de libros/creadores de cursos?"
La ambigüedad empaña cada sesión de estudio. "¿Falló mi caso de prueba porque el tutorial está desactualizado y ha habido cambios importantes 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 de "el pasto es más verde en el otro lado."
Esto se ve agravado por el hecho de que algunos desarrolladores creen que es ingenioso responder preguntas con "Leer el Maldito Manual." No es muy útil. ¿Qué manual? ¿Qué sección?
Otro problema es: 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, vas a revolcarte.
Esto es aún más 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 la gente teclea en Google cada día no se han buscado nunca antes. Eso son malas noticias si usted es la persona que teclea una de ellas.
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 es posible que seas uno de los muchos desarrolladores que tuvo que inventar su propia solución para el mismo problema exacto.
Y luego, por supuesto, están los viejos hilos de foros y las páginas de StackOverflow.
Cómic por XKCD
Cómo no perderte al aprender a programar
La buena noticia es: 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 usualmente está estructurada 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 solo necesitas aceptarlo. Aprender a programar es un proceso ambiguo. Y hasta los desarrolladores experimentados lidian con la ambigüedad.
Después de todo, programar es la rara profesión en la cual puedes reutilizar infinitamente soluciones para problemas que has encontrado anteriormente.
Así que, como desarrollador, siempre estará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.
Vas a pasar una gran parte de tu carrera solo pensando intensamente. O ingresando comandos a ciegas en un prompt tratando de entender cómo funciona un sistema.
Y vas a pasar mucho tiempo en reuniones con otras personas: gerentes, clientes, compañeros desarrolladores. Aprendiendo sobre el problema que debe resolverse, para que puedas construir una solución.
Si te sientes cómodo con la ambigüedad, llegarás lejos.
Aprender a programar es un mensaje de error tras otro
Muchas personas que están aprendiendo a programar sienten que chocan contra 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, luego calificará esas tareas y te las devolverá. A lo largo de un semestre, puede que solo tengas una docena de ocasiones en las que recibas retroalimentación.
"Oh no, realmente me fue mal en 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 realmente puede arruinar tu día.
Y así es generalmente cómo pensamos sobre la retroalimentación como humanos.
Si has pasado algún tiempo programando, sabes que las computadoras son bastante rápidas. Pueden ejecutar tu código en unos pocos 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 tratando de hacer cuando encontró el error – junto con un número de línea para el fragmento de código que causó el bloqueo del programa.
Ahora esto es una retroalimentación negativa en tu cara desde una computadora. No todo el mundo puede soportarlo, ver esto una y otra vez todo el día.
Imagina si cada vez que entregabas tu trabajo final a tu profesor, él te lo devolviera con una gran "F" roja escrita en él. E imagina que hiciera esto antes de que pudieras parpadear. Una y otra vez.
Así es como puede sentirse programar a veces. Quieres agarrar la computadora y gritarle, "¿por qué no entiendes lo que estoy tratando de hacer?"
Cómo no frustrarse
La clave, nuevamente, es la práctica.
Con el tiempo, desarrollarás una tolerancia a los mensajes de error vagos y a los stack traces de longitud de pantalla.
Programar nunca será más difícil de lo que es cuando estás empezando.
No solo no sabes lo que estás haciendo, sino que no estás acostumbrado a recibir una retroalimentación tan impersonal, rápida y negativa.
Así que aquí hay algunos consejos:
Consejo #1: Sabe que no eres singularmente malo en esto.
Todos los que aprenden a programar luchan con la frustración de tratar de establecer una Conexión Vulcana con una computadora y hacer que te entienda. (Esa es otra referencia de Star Trek.)
Por supuesto, algunas personas empezaron a programar cuando eran solo niños. Pueden actuar como si siempre hubieran sido buenos programando. Pero lo más probable es que ellos también lucharon como nosotros los adultos, y con el tiempo simplemente han olvidado las horas de frustración.
Piensa en la computadora como tu amigo, no tu adversario. Solo te está pidiendo que aclares tus instrucciones.
Consejo #2: Respira.
La reacción natural de muchas personas cuando obtienen un mensaje de error es rechinar los dientes. Luego vuelven a su editor de código y comienzan a cambiar código a ciegas, con la esperanza de tener suerte y lograr pasarlo.
Esto no funciona. Y te diré por qué.
El universo es complejo. El software es complejo. Es poco probable que te tropieces en algo bueno por pura suerte.
Forest Gump haciendo lo que hace y teniendo una suerte improbable atrapando camarones.
Quizás hayas oído hablar del Teorema del Mono Infinito. Es un experimento mental en el que imaginas chimpancés escribiendo en máquinas de escribir.
Si tuviéramos una redacción llena de chimpancés haciendo esto, ¿cuánto tiempo pasaría antes de que uno de ellos tecleara la frase "ser o no ser" por azar?
Supongamos que cada chimpancé teclea un carácter aleatorio por segundo. Probablemente uno de ellos tardaría 1 quintillón de años en teclear "ser o no ser". Eso es 10 a la 18ª potencia. Un billón de billones.
Incluso suponiendo que los chimpancés se mantengan en buena salud y las máquinas de escribir se mantengan regularmente, la galaxia sería un frío, oscuro vacío para cuando uno de ellos logre escribir "ser o no ser."
¿Por qué te cuento todo esto? Porque no quieres ser uno de esos chimpancés.
En ese tiempo, casi con certeza podrías encontrar una manera de enseñar a esos chimpancés a escribir palabras en inglés. Probablemente podrían escribir todo Hamlet, no solo su línea más famosa.
Incluso si de alguna manera tienes suerte y superas el error, ¿qué habrás aprendido?
Así que en lugar de agitarte, quieres tomarte un tiempo. Entiende el código. Entiende lo que está sucediendo. Y luego soluciona el error.
Siempre tómate el 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 cosas a ciegas, con la esperanza de superar el mensaje de error, desacelera.
Toma una respiración profunda. Estira. Levántate para agarrar una bebida caliente.
Tu yo futuro estará agradecido de que hayas tomado esto como un momento de enseñanza.
Consejo #3: Usa la depuración con el patito de goma
Consigue un patito de goma y colócalo al lado de tu computadora. Cada vez que encuentres un mensaje de error, intenta explicar lo que crees que está sucediendo a tu patito de goma.
Por supuesto, esto es ridículo. ¿Cómo podría ser útil?
Excepto que lo es.
La depuración con el patito de goma es una gran herramienta para desacelerar y hablar sobre el problema en cuestión.
Por supuesto, no tienes que usar un patito de goma. Podrías explicar tu aplicación de Python a tu cactus mascota. Tu consulta SQL al gato que sigue saltando sobre tu teclado.
El simple acto de explicar tu pensamiento en voz alta parece ayudarte a procesar mejor la situación.
¿Cómo aprende a programar la mayoría de la gente?
Ahora hablemos de las rutas tradicionales hacia el primer trabajo de desarrollador.
¿Por qué deberías preocuparte por lo que hace todo el mundo? Spoiler: realmente no necesitas hacerlo.
Haz lo tuyo.
Dicho esto, puedes dudar de ti mismo y de las decisiones que has tomado sobre tu aprendizaje. Puedes anhelar el camino no tomado.
Mi objetivo con esta sección es calmar cualquier ansiedad que puedas tener.
La importancia de los grados en ciencias de la computación
Los títulos universitarios siguen siendo el estándar dorado 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 grado en Ciencias de la Computación para convertirte en desarrollador.
Pero su utilidad es innegable. Y te explicaré por qué.
Primero, te preguntarás: ¿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 sobre el campo:
"La educación en ciencias de la computación no puede hacer que nadie sea un programador experto, más de lo que estudiar pinceles y pigmento puede hacer que alguien sea un pintor experto." – Eric Raymond, Programador, Científico de la Computación y Autor
Las facultades de Ciencias de la Computación eran tradicionalmente parte del departamento de matemáticas. Las universidades en los años 60 y 70 no sabían exactamente dónde poner todo este asunto de las computadoras.
En otras universidades, la Ciencia de la Computación se consideraba una extensión de la Ingeniería Electrónica. Y 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 una especie de doble titulación con Ingeniería Electrónica.
Pero la mayoría de las universidades ahora han llegado a entender la importancia de la Ciencia de la Computación como campo de estudio.
Hasta el momento de escribir esto, Ciencias de la Computación es el título más rentable que puedes obtener. Más alto incluso que campos enfocados en el dinero, como Finanzas y Economía.
Según Glassdoor, el promedio de un titulado en Ciencias de la Computación radicado en Estados Unidos gana más dinero en su primer trabajo que cualquier otro titulado. US $70,000. Eso es mucho dinero para alguien que acaba de graduarse de la universidad.
Más que los titulados en Enfermería ($59,000), Finanzas ($55,000) y Arquitectura ($50,000).
OK – así que obtener un título en Ciencias de la Computación puede ayudarte a conseguir un trabajo de nivel inicial bien remunerado. Eso probablemente no es una noticia para nadie. Pero ¿por qué es eso?
Cómo piensan los empleadores sobre los títulos de licenciatura
Puede que hayas escuchado a algunos grandes empleadores en tecnología decir cosas como, "ya no requerimos que los candidatos a empleo tengan un título de licenciatura."
Google dijo esto. Apple dijo esto.
Y les creo. Que ya no requieren títulos de licenciatura.
Hemos tenido muchos exalumnos de freeCodeCamp conseguir trabajos en estas compañías, algunos de los cuales no tenían títulos de licenciatura.
Pero esos exalumnos de freeCodeCamp que consiguieron esos trabajos probablemente tuvieron que ser candidatos especialmente fuertes para superar el hecho de que no tenían títulos de licenciatura.
Puedes ver estas ofertas de trabajo como si tuvieran una variedad de criterios por los que juzgan a los candidatos:
- Experiencia laboral
- Educación
- Portafolio y proyectos
- ¿Tienen una recomendación de alguien que ya trabaja en la empresa? (Discutiremos cómo construir tu red en profundidad en el Capítulo 2)
- Otras consideraciones de reputación (discutiremos cómo construir tu reputación en el Capítulo 3)
Para los empleadores que no exigen una licenciatura, la educación es sólo una de varias consideraciones. Si eres más fuerte en otras áreas, pueden optar por entrevistarte, independientemente de que hayas pisado alguna vez un aula universitaria
Solo ten en cuenta que tener una licenciatura te hará más fácil obtener una entrevista, incluso en estos empleadores que "no requieren título".
¿Por qué tantos trabajos de desarrollador requieren específicamente un título en informática?
Una licenciatura es una licenciatura, a menudo digo a la gente. Porque para la mayoría de los casos, lo es.
¿Quieres entrar a las fuerzas armadas de EE.UU. como oficial, en lugar de miembro alistado? Necesitarás una licenciatura, pero cualquier especialidad servirá.
¿Quieres obtener una visa de trabajo para trabajar en el extranjero? Probablemente necesitarás una licenciatura, pero cualquier especialidad servirá.
Y para tantas ofertas de trabajo que dicen "se requiere licenciatura" – cualquier especialidad servirá.
¿Por qué es esto? ¿No importa en absoluto la materia que estudies en la universidad?
Bueno, aquí está mi teoría sobre esto: lo que aprendes en la universidad es menos importante que si terminaste la universidad.
Los empleadores están intentando seleccionar personas que puedan encontrar una manera de pasar por este rito de iniciación.
Es ciertamente verdadero que puedes estar en el fondo de tu clase, repitiendo cursos que fallaste, y estando en suspensión académica la mitad del tiempo. Pero un título es un título.
¿Sabes cómo llaman al estudiante que terminó último en su clase en la escuela de medicina? "Doctor".
Y para la mayoría de los empleadores, lo mismo es cierto.
En muchos casos, la gente de Recursos Humanos solo está marcando una casilla en su software de filtrado de solicitudes de empleo. Están filtrando a los solicitantes que no tienen un título. En esos casos, puede que nunca miren las solicitudes de empleo de personas sin títulos.
De nuevo, no todos los empleadores son así. Pero muchos lo son. Aquí en EE.UU., y quizás aún más en otros países.
Es una mierda, pero es como funciona el mercado laboral ahora mismo. Puede cambiar en las próximas décadas. Puede que no.
Por eso siempre animo a las personas que están en su adolescencia y 20s a considerar seriamente obtener una licenciatura.
No por ninguna de las cosas que las universidades se promocionan como:
- La educación en sí. (Puedes tomar cursos de algunas de las mejores universidades en línea de forma gratuita, así que esto solo no justifica el alto costo de la matrícula.)
- La "experiencia universitaria" de vivir en un dormitorio, hacer nuevos amigos y autodescubrimiento. (La mayoría de los estudiantes universitarios en EE.UU. nunca viven en el campus, por lo que realmente no obtienen esto de todos modos.)
- Cursos de educación general que te ayudan a convertirte en un "individuo bien formado". (¿Alguna vez has oído hablar del "Freshman 15"? Esto es una broma, por supuesto. Pero muchos estudiantes de primer año universitario ganan peso debido al estrés de la experiencia.)
De nuevo, 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 una licenciatura, como los que mencioné: opciones de carrera militar ampliadas y mayor facilidad para obtener visas de trabajo.
Uno de estos es: si quieres convertirte en doctor, dentista, abogado o profesor, primero necesitarás una licenciatura. Luego puedes usar eso para ingresar a la escuela de posgrado.
Bien – esto es mucha información de fondo. Así que 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 una licenciatura.
Una licenciatura hará que sea mucho más fácil obtener una entrevista en muchos empleadores. Y puede que también te ayude a ganar un salario más alto.
¿Qué hay de los títulos de asociado? ¿son valiosos?
En teoría, sí. Hay algunos campos en tecnología donde tener un asociado puede ser requerido. Y creo que siempre aumenta tus posibilidades de obtener una entrevista.
Dicho esto, no recomendaría ir a la universidad con el objetivo específico de obtener un título de asociado. Al 100% te animaría a quedarte en la escuela hasta obtener una licenciatura, que es muchísimo más útil.
Según el Departamento de Educación de EE.UU., a lo largo de tu carrera, tener una licenciatura te hará ganar 31% más que simplemente tener un título de asociado.
Y estoy seguro de que esa diferencia es mucho mayor con una licenciatura en Informática.
¿Vale la pena ir a la universidad para obtener una licenciatura más tarde en la vida, si aún no tienes una?
Digamos que tienes 30 años. Tal vez asististe a algunos cursos en la universidad. Tal vez completaste los primeros dos años y pudiste obtener un título de asociado.
¿Tiene sentido "volver a la escuela" en el sentido formal?
Sí, puede tener sentido hacerlo.
Pero no creo que nunca tenga sentido dejar tu trabajo para volver a la escuela a tiempo completo.
El estilo de vida del estudiante a tiempo completo está diseñado realmente pensando en estudiantes "tradicionales". Es decir, personas de 18 a 22 años (o un poco mayores si estuvieron en el ejército), que aún no han entrado en la fuerza laboral más allá de los trabajos de verano / de secundaria.
Las universidades tradicionales cuestan mucho dinero asistir, y se supone que los estudiantes pagarán a través de alguna combinación de becas, fondos familiares y préstamos estudiantiles.
Como adulto trabajador, tendrás menos acceso a estas fuentes de financiamiento. Y tan importante como esto, tendrás menos tiempo disponible que un recién graduado de secundaria tendría.
Pero eso no significa que tengas que 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 buenas reputaciones 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 de una universidad estatal que ofrezca grados. Muchos de estos programas están en línea. Y algunos de ellos son incluso autoguiados, para que puedas completar los cursos conforme lo permita tu horario de trabajo.
Haz tu investigación. Si una escuela parece prometedora, recomiendo encontrar a uno de sus exalumnos en LinkedIn y contactarlo. Pregúntales sobre su experiencia y si creen que valió la pena.
Recomiendo no asumir ninguna deuda para financiar tu grado. Es mucho mejor asistir a una escuela más barata. Después de todo, un título es un título. Siempre y cuando sea de una institución acreditada, debería estar bien para la mayoría de los propósitos.
Si ya tienes un título de licenciatura, ¿tiene sentido volver y obtener una segunda licenciatura en informática?
No. Los títulos de segunda licenciatura casi nunca valen el tiempo y el dinero.
Si tienes cualquier título de 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 un máster en ciencias de la computación?
Estos pueden ser útiles para el avance profesional. Pero deberías buscarlos más tarde, después de que ya estés trabajando como desarrollador.
Muchos empleadores pagarán por la educación continua de sus empleados.
Un programa al que muchos de mis amigos en tecnología han asistido es el Máster en Ciencias de la Computación de Georgia Tech.
El departamento de Ciencias de la Computación de Georgia Tech está entre los mejores de los EE.UU. Y este programa de grado no solo es completamente en línea, sino que también es bastante asequible.
Pero no recomendaría hacerlo ahora. Primero enfócate en conseguir un trabajo como desarrollador. (Cubriré eso en profundidad más adelante en este libro).
¿Seguirán importando los grados en el futuro?
Sí, creo que los grados universitarios seguirán importando por décadas, y posiblemente siglos, por venir.
Los grados universitarios han existido por más de 1,000 años.
Muchas de las principales universidades en los EE.UU. son más antiguas que el propio EE.UU. (Harvard tiene más de 400 años).
La muerte del grado universitario está muy exagerada.
Se ha vuelto popular en algunos círculos criticar a las universidades y decir que los grados ya no importan.
Pero si miras las estadísticas, esto claramente no es cierto. Tienen un impacto en los ingresos de por vida.
Y tan importante como eso, pueden abrir carreras que son más seguras, más estables y, en última instancia, más satisfactorias.
Claro, puedes ganar excelentes ingresos trabajando como marinero en alta mar, dando servicio a plataformas petrolíferas.
Pero puedes ganar ingresos igualmente excelentes trabajando como desarrollador en una oficina con control de clima, dando servicio a servidores y parcheando 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 opinión" que critican a las universidades se han beneficiado ellos mismos de una educación universitaria.
Una razón por la que creo que muchas personas piensan que los grados son "inútiles" es: es difícil separar el aprendizaje del impulso de estatus que obtienes.
¿Es la universidad solo una forma de señalización de clase, una forma para que los ricos continúen pasando ventajas a sus hijos? Después de todo, es tres veces más probable encontrar a un niño rico en Harvard que a uno 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 grado que te dará más opciones en el futuro.
O puedes ir por el modo difícil, potencialmente ahorrar tiempo y dinero, y ser más selectivo sobre a qué empleadores aplicas.
Tengo muchos amigos que han usado ambos enfoques con gran éxito.
¿Qué alternativas hay a un grado universitario?
He trabajado en la educación para adultos durante casi dos décadas, y aún no he visto un sustituto convincente para un grado universitario.
Claro, hay programas de certificación y bootcamps.
Pero estos no tienen el mismo peso ante los empleadores. Y rara vez son tan rigurosos.
Nota al margen: cuando digo "programas de certificación", me refiero a un programa donde 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. Discutiremos esto con más profundidad más adelante.
Lo que le digo a la gente es: tener un grado o no tenerlo, esa es la cuestión.
Conozco a muchas personas que son mecánicos de autos, electricistas o que hacen algún otro tipo de oficio, que no tienen licenciatura. Claramente pueden aprender un conjunto de habilidades, aplicarlas y mantener un trabajo.
Conozco a muchas personas que son contadores, asistentes legales y otros "trabajadores del conocimiento" que no tienen licenciatura. Claramente pueden aprender un conjunto de habilidades, aplicarlas y mantener un trabajo.
En muchos casos, estas personas pueden simplemente aprender a programar por su cuenta, utilizando recursos de aprendizaje gratuitos y pasando el rato con personas afines.
Algunas de estas personas siempre han tenido la meta personal de volver y terminar su licenciatura. Esa es una buena razón para hacerlo.
Pero no es para todos.
Si quieres educación formal, opta por la licenciatura. Si no quieres educación formal, no hagas ningún programa. Solo autoenseña.
Lo principal que los bootcamps y otros programas de certificación te van a ofrecer es estructura y un poco de presión de pares. Eso no es malo. Pero, ¿vale la pena pagar miles de dólares por ello?
Cómo enseñarte a programar
La mayoría de los desarrolladores son autodidactas. Incluso los desarrolladores que obtuvieron una licenciatura en ciencias de la computación a menudo todavía se describen a sí mismos como "autodidactas" en encuestas de la industria como la encuesta anual de Stack Overflow.
La mayoría de los desarrolladores en activo se consideran a sí mismos como "autodidactas" (Imagen: Encuesta de Stack Overflow 2016)
Esto se debe a que aprender a programar es un proceso de por vida. Siempre hay nuevas herramientas que aprender, nuevos códigos heredados que mapear y nuevos problemas que resolver.
Entonces, ya sea que busques educación formal o no, debes saber esto: necesitarás volverte bueno en autoenseñanza.
¿Qué significa ser un desarrollador "autodidacta"?
Sin ser pedante, cuando me refiero a autoenseñanza, me refiero al aprendizaje autodirigido: aprendizaje fuera de la educación formal.
Muy pocas personas son realmente "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 sobre la marcha.
De manera similar, Ada Lovelace se enseñó a sí misma a programar. Porque antes de ella no había programación. Ella la inventó.
Alguien podría decirte: "No eres realmente autodidacta porque aprendiste de libros o cursos en línea. Entonces tuviste maestros". Y tienen razón, pero solo en el sentido más estricto.
Si alguien tiene problemas con que te llames autodidacta, simplemente di: "Según tus estándares, nadie que no haya sido criado por lobos puede reivindicarse como autodidacta en algo."
Señálales esta sección de este libro y diles: "Quincy anticipó tu esnobismo". Y sigue con tu vida.
Porque vamos, ¿la vida es demasiado corta, verdad?
Eres autodidacta.
¿Qué es el aprendizaje autodirigido?
Como autodidacta, vas a curar tus propios recursos de aprendizaje. Vas a elegir qué aprender y de dónde. Esa es la esencia del "Aprendizaje Autodirigido."
Pero, ¿cómo sabes que estás aprendiendo las habilidades correctas y aprovechando los recursos adecuados?
Bueno, ahí es donde entra la comunidad.
Hay muchas comunidades de aprendices alrededor del mundo, todas ayudándose mutuamente a expandir sus habilidades.
La comunidad es una palabra difícil de definir. ¿Es Tech Twitter una comunidad? ¿Qué pasa con el foro de freeCodeCamp? ¿O los muchos grupos de Discord y subreddits dedicados a habilidades de codificación específicas?
Considero a todos estos como comunidades. Si hay personas que se reúnen allí regularmente y se ayudan mutuamente, lo considero una comunidad.
¿Qué pasa con los eventos presenciales? ¿La reunión mensual de desarrolladores de Ruby en Oakland? ¿La reunión comunitaria de startups de la ciudad de Nueva York? ¿El grupo de usuarios de Linux del Centro de Texas?
Estas comunidades pueden ser en línea, presenciales o una mezcla de ambas.
Hablaremos más sobre comunidades en el capítulo Construye tu Red. Pero la conclusión es: los nuevos amigos que conozcas en estas comunidades pueden ayudarte a reducir tus opciones de qué aprender y de cuáles recursos aprender.
¿Qué lenguaje de programación debería aprender primero?
La respuesta corta es: no importa realmente. Una vez que hayas aprendido bien un lenguaje de programación, es mucho más fácil aprender el siguiente.
Hay diferentes tipos de lenguajes de programación, pero hoy en día la mayoría del desarrollo se realiza utilizando "lenguajes de scripting de alto nivel" como JavaScript y Python. Estos lenguajes sacrifican la eficiencia bruta que obtienes de "lenguajes de programación de bajo nivel" como C. Lo que obtienen a cambio: el beneficio 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 las personas escribían sus programas en lenguajes como C. Ese poder compensa con creces la relativa ineficiencia de los lenguajes de scripting.
Vale la pena señalar que tanto JavaScript como Python están escritos en C, y ambos son cada vez más rápidos cada año, gracias a sus grandes comunidades de contribuyentes de código abierto.
Python es un lenguaje poderoso para la computación científica (Ciencia de Datos y Aprendizaje Automático).
Y JavaScript... bueno, JavaScript puede hacer de todo. Es el lenguaje de programación navaja suiza por excelencia. JavaScript es la cinta adhesiva que mantiene unido a la World Wide Web.
"Cualquier aplicación que pueda ser escrita en JavaScript, eventualmente será escrita en JavaScript." – Ley de Atwood (Jeff Atwood, fundador de Stack Overflow y Discourse)
Podrías programar toda tu carrera en JavaScript y no necesitarías aprender un segundo lenguaje. (Dicho esto, querrás aprender Python más adelante, y tal vez algunos otros lenguajes también).
Así que recomiendo empezar con JavaScript. No solo es mucho más fácil de usar que lenguajes como Java y C++, sino que también es más fácil de aprender. Y hay muchas más ofertas de trabajo para personas que saben JavaScript.
Una captura de pantalla del motor de búsqueda de empleo Indeed. Mi búsqueda de "javascript" para EE.UU. arrojó 68,838 ofertas de trabajo.
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 la piel. (JavaScript serían los músculos, que hacen posible que la web se mueva y sea interactiva).
Puedes aprender algo de HTML y CSS en una sola tarde. Como la mayoría de las herramientas que menciono aquí, son fáciles de aprender, pero difíciles de dominar.
También querrás aprender a usar Linux. Linux da potencia a una 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 una PC con Windows, querrás instalar WSL, que significa Subsistema de Windows para Linux. Luego podrás ejecutar comandos de Linux en tu PC. Y si te sientes aventurero, incluso puedes tener un arranque dual con los sistemas operativos de Windows y Linux en la misma computadora.
Si vas a instalar Linux en una computadora, te recomiendo empezar con Ubuntu. Es la distribución de Linux más utilizada (y documentada). Así 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. Red Hat es una empresa multimillonaria a pesar de que su software es de código abierto, porque las empresas pagan por su ayuda en la atención y soporte de servidores Linux.
También querrás aprender Git. Este Sistema de Control de Versiones es la forma en que los equipos de desarrolladores coordinan sus cambios en una base de código.
Probablemente 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. Estos son los caballos de batalla 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 grafos, bases de datos de documentos y almacenes clave-valor). Puedes aprender más sobre estas más adelante. Pero concéntrate en SQL primero.
Finalmente, querrás aprender cómo funcionan los servidores web. Querrás comenzar con Node.js y Express.js.
Cuando escuchas el término "desarrollo full stack" se refiere a unir el front end (HTML, CSS, JavaScript) con el back end (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 ir aprendiéndolas sobre la marcha.
Pero las habilidades clave en las que deberías gastar el 90% de tu tiempo de aprendizaje antes del trabajo son:
- HTML
- CSS
- JavaScript
- Linux
- Git
- SQL
- Node.js
- 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 de nivel inicial. (Por supuesto, muchas descripciones de puestos incluirán otras herramientas, pero hablaremos de estas más adelante en el libro).
Entonces, podrías estar pensando: genial. ¿Cómo aprendo esto?
¿Dónde puedo aprender a programar?
Es curioso que lo preguntes. Hay un plan de estudios completo diseñado por ingenieros de software y profesores con experiencia. Está diseñado pensando en adultos ocupados. Y es completamente gratuito y autodidacta.
Así es. Estoy hablando del plan de estudios central 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 la fecha, miles de personas han pasado por este plan de estudios central y han conseguido un trabajo como desarrollador. No necesitaron dejar su trabajo diurno, pedir préstamos, ni realmente arriesgar nada más que algunas 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 están aprendiendo a programar por su cuenta.
Si nada más, el plan de estudios central de freeCodeCamp puede ser tu "base de operaciones" para el aprendizaje, y puedes ramificarte desde ahí. Puedes aprender las habilidades principales que la mayoría de los trabajos requieren, y también incursionar en tecnologías que te interesan.
Hay décadas de libros y cursos de los que aprender. Algunos están disponibles en tu biblioteca pública, o a través de servicios de suscripción mensual. (Y puede que también puedas acceder a algunos de estos servicios de suscripción de forma gratuita a través de tu libreria).
Además, freeCodeCamp ahora tiene casi 1,000 cursos completos gratuitos sobre todo, desde preparación para la certificación de AWS hasta desarrollo de aplicaciones móviles y Kali Linux.
Nunca ha habido un momento más fácil para enseñarte a ti mismo programación.
Aprender siempre será un esfuerzo de toda la vida
Hemos hablado sobre por qué la autoeducación probablemente sea el mejor camino a seguir, y cómo hacerlo.
Hemos hablado sobre las alternativas a la autoeducación, como obtener un título de licenciatura en Ciencias de la Computación, o obtener un título de maestría.
Y hemos hablado sobre qué herramientas específicas deberías enfocarte en aprender primero.
Ahora, cambiemos de marcha y hablemos sobre cómo construir la segunda pata de tu taburete: tu red.
Capítulo 2: Cómo construir tu red
"Si quieres ir rápido, ve solo. Si quieres ir lejos, ve acompañado." – Proverbio Africano
"Hacer contactos". Puede que te estremezcas al escuchar esa palabra.
El trabajo en red puede traer a la mente incómodas ferias de empleo con trajes estirados, empujando desesperadamente tu currículum a las manos de cualquiera que lo acepte.
Networking puede evocar imágenes de fiestas regadas con alcohol – donde finges estar interesado en un deporte que ni siquiera sigues.
Networking puede evocar el deseo de decir "feliz cumpleaños" a personas que apenas conoces en LinkedIn, o de dar "me gusta" a sus actualizaciones de estado esperando que te noten.
Pero el networking no tiene que ser así.
En este capítulo, te contaré todo lo que he aprendido sobre conocer personas. Te mostraré cómo ganarte su confianza y ser la primera persona en la que piensen cuando necesitan 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 red personal robusta que te apoyará durante décadas.
Historia: ¿Cómo un profesor en sus 30s construyó una red en tecnología?
La última vez en Historia: Quincy aprendió algo de codificación leyendo libros, viendo cursos online gratuitos y pasando tiempo con desarrolladores en el Hackerspace local. Había terminado de construir su primer proyecto y dado su primera charla técnica...
OK – ahora tenía algunas habilidades básicas de codificación. Ya podía codificar mi salida del proverbial saco de papel.
¿Qué seguía? Después de todo, yo era un completo extraño en el mundo tecnológico.
Bueno, aunque era nuevo en la tecnología, no era nuevo en el trabajo. Había puesto comida en la mesa durante casi una década trabajando en escuelas y enseñando inglés.
Como profesor, me pagaban por impartir conocimientos. Y como desarrollador, me pagarían por escribir código.
Ya conocía una verdad muy importante sobre la naturaleza del trabajo: es a quién conoces.
Conocía el poder de las redes. Sabía que el camino hacia la oportunidad pasa directamente por los guardianes.
Todo lo que se interponía entre mí y un lucrativo trabajo como desarrollador era un gerente de contratación que pudiera decir: "Sí. Este Quincy parece alguien digno de unirse a nuestro equipo."
Por supuesto, siendo un extraño en el campo tecnológico, no conocía la cultura.
La cultura académica es mucho más formal.
Llevas un traje.
Usas terminología académica elegante para demostrar que eres parte del "grupo interno".
Encuentras formas de incluir en cada conversación que fuiste a la universidad X, o que fuiste asistente de docencia del Dr. Y, o que publicaste en el Diario Z.
Las trayectorias profesionales son diferentes. Las conferencias son diferentes. Las estructuras de poder son diferentes.
Y no aprecié este hecho de inmediato.
En los primeros eventos tecnológicos a los que asistí, llevé un traje.
Llevaba copias de mi currículum, meticulosamente dobladas, en el bolsillo en todo momento.
Incluso llevaba tarjetas de presentación. Había pedido láminas de aluminio anodizado y usado un cortador láser para grabar mi nombre, dirección de correo electrónico e incluso una cita del legendario educador John Dewey:
"Cualquiera que haya comenzado a pensar pone en peligro alguna parte del mundo." – John Dewey
Sigue siendo mi cita favorita hasta el día de hoy.
Pero hablemos de ser excesivamente directo.
"Hola, soy Quincy. Aquí tienes mi tarjeta de presentación roja de aluminio. Perdón de antemano – podría activar el detector de metales en tu vuelo de regreso a casa."
Estaba intentando demasiado. Y probablemente era dolorosamente evidente para todos con quienes hablaba.
Entré en Meetup.com y confirmé mi asistencia a cada evento de desarrolladores que pude encontrar. Santa Bárbara es una ciudad pequeña, pero está cerca de Los Ángeles. Así que también hacía el camino para asistir a eventos allí.
Rápidamente me di cuenta y cambié mi traje por jeans y una sudadera con capucha. Y noté que nadie más entregaba tarjetas de presentación. Así que dejé de llevarlas.
Tomé pistas de los desarrolladores que conocí en el hackerspace: Se apasionado, pero moderado. Mantén parte de tu entusiasmo en reserva.
Y leí muchos libros para entender mejor la cultura de los desarrolladores.
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, mira la serie de televisión Mr. Robot. Sus personajes son un poco extremos, pero hacen un buen trabajo capturando la mentalidad y las maneras de muchos desarrolladores.
Pronto, hablaba menos como un profesor y más como un desarrollador. No destacaba tan torpemente.
Varias veces a la semana asistí a eventos locales relacionados con la tecnología. Mi evento favorito ni siquiera era un evento de desarrolladores. Era la Noche de Startups de Santa Bárbara. Una vez 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 ángeles – personas ricas que invierten en compañías en etapas tempranas.
El tipo que dirigía el evento se llamaba Mike. Debía conocer a todos los desarrolladores y emprendedores de Santa Bárbara.
Cuando finalmente reuní el valor para presentarme a Mike, estaba asombrado. Era un ultramaratonista con un ritmo cardíaco en reposo en los bajos 40s. Cabello y barba perfectamente recortados. Para mí era el tipo más genial del planeta. Siempre impecable. Siempre respetuoso.
Mike era "no 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 descartaban a las personas no técnicas. "Es solo un tipo de negocios," decían. O: "Ella es una ejecutiva." Pero nunca escuché a nadie decir eso de Mike. Tenía el respeto de todos.
Me propuse observar cómo Mike interactuaba con los desarrolladores. Después de todo, yo no estaba tan lejos de ser "no técnico" yo mismo. Solo llevaba unos meses programando.
A menudo me dejaba arrastrar por mis viejos hábitos. Durante las conversaciones tenía la tentación de presumir de lo que había aprendido o construido.
Muchos desarrolladores son modestos acerca de sus habilidades o logros. Podrían decir: "Me meto un poco en Python." Y el inseguro de mí abriría su gran boca y diría algo como, "Oh, sí. He codificado tantos algoritmos en Python. Escribo Python mientras duermo."
Y luego iría a casa y buscaría en Google el nombre de ese desarrollador, y me daría cuenta de que era un colaborador principal de una importante biblioteca de Python. Y me patearía.
Rápidamente aprendí a no alardear de mis logros o habilidades. Hay una buena posibilidad de que la persona con la que estás hablando pueda programar mucho mejor que tú. Pero la mayoría de ellos nunca lo mencionaría.
No hay nada peor que sacar tu portátil con confianza, presumir de tu código, y luego que alguien te haga un montón de preguntas para las que no estás en absoluto preparado para responder.
Mis primeros meses asistiendo a eventos fue una experiencia humillante. Pero estos eventos me energizaron para seguir avanzando con mis habilidades.
Pronto, la gente del sur de California comenzaría a reconocerme. Decían: "Sigo encontrándote en estos eventos. ¿Cómo te llamas otra vez?"
Una noche, un desarrollador dijo, "Sigámonos en Twitter." A regañadientes había creado una cuenta de Twitter unos días antes, pensando que era un sitio web llamativo. ¿Cuánto se podría realmente transmitir 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 refinando mi presencia online. Hice mi LinkedIn menos formal y más amigable. Observar cómo otros desarrolladores de la comunidad se presentaban online me ayudó.
En unos pocos meses, conocía a personas de muchos campos distintos:
- desarrolladores con experiencia
- personas no técnicas o semi-técnicas que trabajaban en empresas de tecnología
- gerentes de contratación y reclutadores
- y lo más importante, mis compañeros que también estaban a mitad de carrera y tratando de entrar en el campo de la tecnología
¿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: digamos que un gerente de contratación contrata a un nuevo desarrollador, lo capacita, y resulta que es muy bueno en su trabajo. Ese gerente de contratación va a preguntar: ¿dónde puedo encontrar más personas como tú?
Tus compañeros son una de las partes más importantes de tu red. Muchas de mis oportunidades freelance y de entrevistas de trabajo vinieron de personas que empezaron a aprender a programar más o menos al mismo tiempo que yo.
Crecimos juntos. Éramos hermanos y hermanas en armas. Esos lazos son los más fuertes.
De todos modos, todo este networking durante los meses finalmente daría fruto una noche cuando entré en el bar de un elegante hotel del 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.
¿Realmente es a quien conoces?
Probablemente hayas escuchado la expresión que el éxito es "menos sobre lo que sabes, y más sobre a quién conoces".
En la práctica, es sobre ambos.
Sí, tus conexiones pueden ayudarte a conseguir el trabajo de tus sueños. Pero si estás fuera de tu alcance, y careces de las habilidades para tener éxito, no te irá bien en ese rol.
Pero asumamos que estás construyendo tus habilidades proactivamente. Has seguido mi consejo del Capítulo 1. ¿Cuándo es el momento adecuado para empezar a construir tu red?
El mejor momento para empezar a construir tu red es ayer.
Pero no necesitas una máquina del tiempo para hacerlo. Porque ya tienes una red. Probablemente es mucho más pequeña de lo que te gustaría que fuera, pero conoces gente.
Pueden ser amigos de tu ciudad natal, o los colegas de tus padres. Cualquier persona que conozcas de tu pasado – por más marginal que sea – puede ser de ayuda.
Entonces, el primer paso es hacer un inventario completo de las personas que conoces. No te preocupes – no te estoy pidiendo que contactes a nadie aún, o pongas en riesgo tus relaciones personales.
Piensa antes de actuar. Formula una estrategia.
Primero, hagamos un inventario de todas las personas que conoces.
Cómo construir un tablero de red personal
Quieres empezar creando una lista de personas que conoces.
Podrías hacerlo con una hoja de cálculo, o con una herramienta de Gestión de Relaciones con Clientes (CRM) como usan los vendedores. Pero probablemente sería exagerado para lo que estamos haciendo aquí.
Recomiendo usar una herramienta de tablero Kanban como Trello, que es gratuita.
Vas a crear 5 columnas: "por evaluar", "a contactar", "esperando respuesta", "recientemente en contacto", y "no contactar aún".
Luego querrás crear etiquetas, para que puedas clasificar a las personas según cómo las conoces. Aquí tienes algunas ideas de etiquetas: "Amigo de la infancia", "Amigo de la familia", "Excompañero", "Compañero de clase", "Amigos de eventos tecnológicos".
Ahora puedes empezar a crear tarjetas. Cada tarjeta puede ser solo su nombre, y si tienes tiempo, puedes añadir una foto a la tarjeta.
Aquí está el tablero de Trello que creé para darte una idea de cómo podría verse este Tablero de Red Personal. Usé personajes de mi película favorita de la infancia, el clásico de 1989 Tortugas Ninja Mutantes Adolescentes.
Mi Tablero de Red Personal con mis amigos de mi trabajo secundario luchando contra el crimen.
Puedes revisar tus cuentas de redes sociales – incluso tus antiguos anuarios escolares si los tienes – y empezar a añadir personas.
Muchas de estas personas no serán de ninguna ayuda. Pero te recomiendo que las añadas para ser exhaustivo. Nunca se sabe cuándo te acordarás: "Ah, fulanito ha conseguido un trabajo en la empresa XYZ. Debería ponerme en contacto con ellos".
Este proceso puede tomar uno o dos días. Pero debes saber que esto es una inversión. Podrás usar este tablero para el resto de tu carrera.
Podrías pensar "No necesito hacer esto – ya tengo una cuenta en LinkedIn". Eso podría funcionar bien, pero LinkedIn es un instrumento tosco. Aquí quieres maximizar la señal y minimizar el ruido. Por eso te animo a crear este tablero de red personal dedicado.
A medida que agregues personas a tu tablero, puedes etiquetarlas. Tómate un momento para investigar a cada una de estas personas. ¿Qué están haciendo estos días? ¿Tienen un trabajo? ¿Dirigen una empresa?
Puedes agregar notas a cada tarjeta, a medida que descubres nuevos datos sobre ellas. ¿Recientemente participaron en una carrera de 5K para recaudar fondos? ¿Su abuela celebró recientemente su 90 cumpleaños? Estos datos pueden parecer extraviados. Pero si la persona los comparte en las redes sociales, significa que estos datos son importantes para ellos.
Esfuérzate por interesarte en las personas. Sus vidas diarias. Sus aspiraciones. Al comprender sus motivaciones y objetivos, tendrás una visión más profunda de cómo puedes ayudarlos.
Y como dije anteriormente, la mejor manera de forjar alianzas es ayudar a las personas. Hablaremos de esto extensamente en un momento.
Para cada una de las personas que agregues a tu Tablero de Red Personal, considera si vale la pena contactarla. Luego colócala en la columna "para contactar" o "no contactar todavía".
Te podrías preguntar: ¿por qué la columna se llama "no contactar todavía"? Porque nunca sabes cuándo podría ser útil conocer a alguien. Nunca des por sentado ninguna amistad o conocido.
Una vez que hayas llenado tu tablero, etiquetado a todos y clasificado en columnas, estás listo para comenzar a contactar.
Cómo prepararse para contactar a la red
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 ciertos datos sobre ti. Quieres reducir quién eres a lo fundamental. Y la mejor manera de hacer esto es escribir una biografía personal.
Cómo escribir una biografía personal para 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."
Adelante, escribe la tuya. Trata de reducirla a 100 caracteres o menos. Trata de evitar usar palabras sofisticadas o jerga.
Puede ser difícil destilar tu identidad en unas pocas palabras. Pero este es un proceso importante.
Recuerda: la gente está ocupada. No necesitan conocer la historia de tu vida. A medida que los conozcas mejor, puedes ir poco a poco llenando los detalles de quién eres como persona. A medida que hagan preguntas, podrán conocerte mejor con el tiempo.
Y en esa nota, necesitas una buena foto de tu cara sonriente.
Cómo hacer una foto de perfil para redes sociales
Si tienes dinero, simplemente encuentra un fotógrafo local y págale para que te tome algunas fotos profesionales.
Incluso podrías tener un amigo que esté interesado en la fotografía, que pueda tomarlas gratis.
Yo mismo tomé mi foto de perfil, usando Photobooth, que viene preinstalado en MacOS. Mi amigo pasó unos 10 minutos arreglando un poco el fondo y la sombra en Photoshop. Es posible que haya hecho mis dientes un poco más blancos. Así es como se ve:
Mi foto de perfil. Uso esta misma foto en todas partes.
Asegúrate de sonreír con los ojos, para que no parezcas robótico. O mejor aún, piensa en algo realmente divertido, como hice aquí. Entonces la sonrisa será genuina.
Toma muchas fotos desde diferentes ángulos, y usa la que mejor te quede.
Te recomiendo usar una foto de perfil que se vea como te ves cualquier día. No una foto fuertemente retocada que intente maximizar tu atractivo. Quieres que la gente en los eventos te reconozca por tu foto. Y no quieres intimidar a la gente con tu belleza. Quieres ponerlos a gusto.
Hablando de poner a la gente a gusto: no uses gafas de sol, ni trates de verte demasiado cool. Quieres parecer amigable y accesible. Una buena prueba de fuego para esto es: mira tu foto. Si estuvieras perdido y vieras a esta persona en la calle, ¿te atreverías a pedirle indicaciones?
Una vez que hayas elegido tu foto de perfil, usa esa misma foto en todas partes. Úsala en todas tus cuentas de redes sociales.
Úsala en tu sitio web personal. Incluso añade la foto de perfil a tu cuenta de correo electrónico.
Te recomiendo usar esa misma foto por años. Cada vez que la cambies, corres el riesgo de que algunas personas no te reconozcan de inmediato. Incluso los cambios sutiles en la iluminación, el ángulo o el fondo pueden afectar la familiaridad de las personas.
Asegúrate de mantener una versión de alta definición de la foto. De esa forma, 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 ahí.)
Cómo contactar a personas de tu pasado
Ahora que tienes tu biografía y fotos organizadas, estás listo para comenzar a hablar con las personas.
Hace 15 años, te diría que llames a las personas por teléfono en lugar de enviarles un mensaje. Pero la cultura ha cambiado mucho con la introducción de los teléfonos inteligentes. La mayoría de las personas no responderán bien a una llamada telefónica.
Del mismo modo, no recomiendo invitar a la gente a tomar un café o a comer hasta mucho más avanzada la conversación. La gente está ocupada y puede considerar incómoda la petición.
Necesitas ir al grano, y hacerlo de manera rápida.
Entonces, ¿cuál es ese punto al que necesitas llegar?
Esencialmente:
- Te conozco.
- Me caes bien.
- y respeto el trabajo que estás haciendo.
Eso es todo.
A las personas les gusta ser conocidas. Les gusta caer bien. Les gusta que el trabajo que hacen y las vidas que viven sean notadas.
La mayoría de nosotros recibimos reconocimiento en nuestros cumpleaños. Personas de nuestro pasado podrían enviarnos 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 les gusta ser reconocidas en esos otros días también.
Bueno, aquí hay una forma sencilla de reconocer a las personas.
Paso 1: Investiga a la persona. Búscala en Google. Lee sus publicaciones más recientes en redes sociales. Lee su LinkedIn. Si publican fotos familiares, tómate el tiempo para verlas.
Paso 2: Piensa en algo que podrías decir para alegrarles un poco el día.
Paso 3: Elige una plataforma de redes sociales en la que hayan estado recientemente activos. Envíales un mensaje directo.
Voy a compartir una plantilla, pero nunca uses ninguna plantilla literalmente, porque si el destinatario coloca tu mensaje en Google, descubrirá que es una plantilla, y toda tu buena voluntad se desperdiciará.
Si yo estuviera enviando un mensaje a alguien con quien no he hablado en unos meses o años de la nada, diría algo como esto:
"Hola [nombre], espero que tu [nuevo año / primavera / semana] haya comenzado de forma divertida. Felicidades por [nuevo trabajo / ascenso / nuevo bebé / proyecto completado]. Es inspirador verte por ahí logrando cosas."
Algo corto y al grano como eso. Saludo + felicitaciones + cumplido. Esa es la fórmula básica.
No solo lo digas. Signifícalo.
Realmente quieres que esta persona se sienta reconocida. Realmente quieres alegrarles el día. Realmente quieres animarlos a seguir avanzando hacia sus objetivos.
Los humanos son muy buenos detectando la falta de sinceridad. No intentes exagerar. No les des ninguna razón para pensar "esta persona quiere algo de mí".
Por eso, lo más importante de esto es: sé breve. Respeta el tiempo de las personas. Nadie quiere una carta larga a la que se sientan obligados a responder extensamente.
Porque – dilo conmigo otra vez – las personas están ocupadas.
Cómo construir conexiones aún más profundas
Debido a que las personas están tan ocupadas, a menudo se sienten tentadas a ver a los extraños más por lo que esos extraños pueden hacer por ellos:
- Esta persona conduce el autobús que me lleva al trabajo.
- Esta persona prepara mi bebida justo como me gusta.
- Esta persona en Recursos Humanos responde mis preguntas sobre el tiempo libre.
- Esta persona armó una lista de reproducción increíble de acid jazz para que escuche mientras programo.
- Esta persona me envía correos electrónicos útiles cada semana con recursos gratuitos de programación.
En cierta medida, eres lo que haces por las personas.
Lo sé, lo sé. Esto puede sonar demasiado reduccionista. Incluso cínico. Y eso es 100% no cierto para los amigos cercanos y la familia en tu vida.
Pero para las personas que apenas te conocen - que solo te encuentran mientras realizan sus actividades diarias - es probable que así te vean.
Tienes que darles a las personas una razón para que se preocupen por ti. Tienes que inspirarlos a aprender más sobre ti.
Antes de que puedas convertirte en el amigo cercano de alguien - alguien que realmente les importe y en quien piensen cuando no estás cerca - necesitas comenzar siendo alguien que les sea útil.
Y eso es lo que vamos a hacer aquí. Vamos a construir relaciones más profundas ofreciendo ayudar a las personas.
Este será un proceso largo. Y deberías iniciarlo con bastante anticipación a tu búsqueda de empleo. Lo último que quieres es que alguien piense "Oh – estás contactando porque necesitas algo de mí."
Al contrario – estás contactando porque tienes algo que ofrecerles.
Después de todo, posees una de las habilidades más poderosas que una persona puede adquirir. La habilidad de hacer que las máquinas hagan lo que tú desees. Eres programador.
Esto es lo que se siente ser bueno programando.
O, al menos, estás en camino a convertirte en uno.
Así que ya tienes un buen pretexto para comunicarte con las personas.
Tal vez hayas escuchado el término "llamada en frío". Esto es cuando llamas a alguien sabiendo 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 parte colgando.
Pero cuanta más información sepas sobre la otra persona, más cálida será la llamada, y más probable será que tengas éxito.
Ahora, no estás vendiendo nada aquí. Y como mencioné antes, tampoco los estás llamando. Les estás enviando un mensaje directo.
Tal vez sea a través de Twitter, LinkedIn, Discord, Reddit – donde sea. Pero te estás contactando con ellos con un solo párrafo de texto.
Como dije, el movimiento inicial más fuerte – el enfoque que tiene más probabilidades de obtener una respuesta – es ofrecer ayuda de manera casual.
Si yo estuviera haciendo esto, aquí tienes una plantilla simple que usaría. Recuerda no usar esta plantilla literalmente. Reescríbela con tu propia voz, como lo dirías a un amigo:
"Hola [nombre], felicidades por el [nuevo trabajo / ascenso / nuevo bebé]. He estado aprendiendo algo de programación, y estoy construyendo mi portafolio. Inmediatamente pensé en ti como alguien que logra muchas cosas. ¿Hay alguna herramienta o aplicación que haría tu vida más fácil? Podría programarla para ti, para practicar."
Se trata de un enfoque sólido, porque es personalizado y no parece automatizado. Hoy en día, la gente recibe tantos mensajes automáticos que se apresura a ignorar cualquier cosa que se le parezca.
Por eso envío todos mis mensajes manualmente y no confío en la automatización. Es mejor componer los mensajes lentamente, uno por uno, que intentar ahorrar tiempo con un script o una combinación de correos.
La forma más rápida de ser bloqueado es enviar un mensaje a alguien con "Hola, ¿cómo va?" donde claramente falta un primer nombre; una evidencia de que el mensaje es una plantilla.
A veces recibo un mensaje usando mi apellido en lugar de mi primer 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 facilita la detección de mensajes automatizados, porque nadie incluiría ese emoji en su mensaje directo.
Cuando un mensaje comienza con: "Hola 🍜Sarah, ¿estás buscando un nuevo trabajo?" Entonces sabes que es un mensaje masivo.
También observa que mi plantilla anterior no dice "fuimos a la escuela juntos" o algo así. A menos que acabes de conocer a alguien hace unos días, no deberías especificar cómo se conocen.
¿Por qué? Porque el mero hecho de recordar a las personas cómo se conocen hará que algunas personas retrocedan y piensen: "Vaya, apenas conozco a esta persona".
Cómo mantener la conversación
De nuevo, tu objetivo es obtener una respuesta de ellos, para que puedas iniciar una conversación de ida y vuelta.
Estas plataformas de mensajería tienen una sensación casual. Mantenlo casual.
No envíes un solo mensaje de varios párrafos. Mantén tus mensajes cortos y rápidos. No quieres que sientan que es una tarea responderte.
Una vez que estén respondiendo, comienza a hacer notas en tu Tabla de Red Personal para que puedas recordar estos hechos más tarde.
Tal vez tengan alguna idea para una aplicación o herramienta. Genial. Hazles preguntas al respecto. Ve si puedes construirlo para ellos.
Comienza dibujando un boceto simple de la interfaz de usuario. Usa papel cuadriculado si quieres parecer más sofisticado. Haz una foto y envíala. "¿Algo como esto?"
Esto establecerá que estás serio sobre ayudarles. Y estaría dispuesto a apostar que para la mayoría de las personas, esto 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 en sí no prospera.
A partir de ahí, puedes seguir el flujo de la conversación. Tal vez se apague. No importa. Déjalo. Puedes encontrar una razón para retomar la conversación unas semanas después.
Lo grandioso de estos mensajes directos en redes sociales es que todo el registro del mensaje está allí. La próxima vez que les envíes un mensaje, pueden simplemente 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 "¿quién eres tú de nuevo?" inclinaciones de cabeza que podrías obtener durante conversaciones en persona.
De nuevo, mantén todo casual y alegre. Si sientes que la conversación va lenta, no hay problema. Porque vas a tener docenas de otras conversaciones en marcha. Otros hierros en el fuego. Vas a ser una abeja ocupada construyendo tu red.
Cómo conocer a nuevas personas y expandir tu red personal
Hemos hablado sobre cómo contactar a personas que ya conoces. Esas conexiones aún están ahí, incluso si se han atrofiado un poco con los años.
Pero ¿cómo hacer nuevas conexiones?
Esta no es una tarea fácil. Pero tengo algunos consejos que harán que este proceso sea un poco menos desalentador.
En primer lugar, conocer a las 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 a la que 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 habla
- Las luces, sonidos, olores, temperatura y la sensación general del lugar
- Y tantos otros pequeños detalles que se impregnan 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 a gente en eventos locales en la ciudad
¿Qué eventos? Si vives en una ciudad densamente poblada, puedes tener muchas opciones a tu disposición. Puedes ir a eventos tecnológicos varias noches a la semana, con un mínimo desplazamiento.
Si vives en una pequeña ciudad, puede que tengas que conocer gente en reuniones locales. Ferias de libros, eventos sociales con helado, eventos deportivos.
Si vas a la iglesia, la mezquita o el templo, conoce a la gente allí también.
Y sí, me doy cuenta de que esto puede sonar ridículo. "¿Esa persona que está de pie en las gradas junto a mí en el partido de fútbol? ¿De alguna manera va a ayudarme a conseguir un trabajo como desarrollador?"
Quizás. Tal vez no. Pero no descartes a las personas.
Esa persona puede administrar una pequeña empresa.
Puede que haya ido a la escuela con un amigo que es vicepresidente de Ingeniería en una empresa Fortune 500.
Y tal vez – solo tal vez – también sea un ingeniero de software. Después de todo, hay millones de nosotros, los ingenieros de software, por ahí. Y no todos vivimos en Silicon Valley. 😉
Cuando conozcas a una nueva persona, no saques inmediatamente tu teléfono y digas "¿Puedo añadirte a mi red profesional de LinkedIn?"
En lugar de eso, debes actuar con calma. Preséntate.
Recuerde su nombre. Los nombres son fundamentales para construir una relación. Si eres malo recordando nombres, practica recordarlos. Puedes practicar tratando de recordar el nombre de cada personaje - sin importar lo menor que sea - cuando veas programas de televisión o películas.
Si olvidas el nombre de alguien, no adivines. Simplemente di "¿cómo es tu nombre otra vez?" y asegúrate de recordarlo la segunda vez.
Dale la mano o choca los puños. Habla con ellos sobre lo que se sienta natural. Si la conversación se agota, no te preocupes. Déjala así.
Construyes relaciones a lo largo del tiempo. No se trata del tiempo total que pasas con alguien - se trata del número de veces que te encuentras con esa persona en un período de tiempo más largo.
Es probable que vuelvas a ver a esa persona en el futuro. Tal vez en ese mismo lugar exacto unas semanas después. Y ese es el momento de moverte:
"Hola [nombre], cómo va lo de [cosa de la que hablaron la vez anterior]?"
Retoma la conversación donde la dejaste. Si parece una persona que sería una adición útil a tu Red Personal, pregúntale "oye, ¿qué vas a hacer el próximo [día de la semana]? ¿Quieres venir conmigo a [otro evento local próximo]?"
Siempre ten en mente tu semana de eventos por venir, para que puedas invitar a la gente a unirse a ti.
Esta es una excelente manera de hacer que la gente pase tiempo contigo en un espacio seguro y público. Y estás proporcionando algo de valor: darles a conocer un evento próximo.
Si parecen interesados, puedes decir "Genial. ¿Cuál es la mejor manera para que te envíe un mensaje y te dé los detalles del evento?"
¡Boom! Ahora tienes su correo electrónico, redes sociales o número de teléfono, y tu relación puede desarrollarse a partir de ahí.
Esto puede sonar como un enfoque lento. ¿Por qué ser tan cauteloso?
De nuevo, la gente está ocupada. Las personas inteligentes son defensivas con su tiempo y con su información personal.
Hay demasiados vampiros por ahí que quieren aprovecharse de la gente - tratando de venderles algo, estafarlos, meterlos en su esquema de marketing multinivel, o de alguna otra manera proselitizarlos.
La mejor manera de ayudar a otras personas a superar esta defensiva refleja es ya estar en su radar por encuentros previos 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, ve tu red puramente como una inversión de tiempo y energía.
Me gusta pensar en mi red como un huerto. Estoy plantando relaciones. Cuidándolas y asegurándome de que estén saludables.
Quién sabe cuándo esas relaciones crecerán en árboles y darán frutos. El objetivo es seguir plantando árboles, y en algún momento del futuro, esos árboles te ayudarán a sostenerte.
Sigue enviando energía positiva. Sigue ofreciendo ayuda a la gente utilizando tus habilidades, e incluso tu propia red. (Rara vez es un mal movimiento hacer una introducción cortés entre dos personas que conoces.)
Sé una persona amable, reflexiva y servicial.
Nunca te sientas impaciente con la lentitud de una búsqueda de empleo.
Nunca te sientas despreciado o rechazado.
Nunca te sientas celoso del éxito de otra persona.
Lo que va, viene. Un día cosecharás lo que has sembrado. Y si estás sembrando energía positiva, te estás preparando para una cosecha abundante.
Capítulo 3: Cómo construir tu reputación
"El camino para ganar una buena reputación es esforzarse por ser lo que deseas parecer." – Sócrates
Ahora que has comenzado a construir tus habilidades y tu red, estás listo para comenzar a construir tu reputación.
Puedes estar empezando desde cero - un total recién llegado a la tecnología. O quizás ya tengas alguna credibilidad que puedas aportar 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. Esta será la clave para conseguir clientes freelance, un primer trabajo y avanzar en tu carrera.
Pero primero, aquí está cómo construí mi reputación.
Tiempo de Historia: ¿Cómo construyó un maestro en sus 30s una reputación como desarrollador?
La última vez en Tiempo de Historia: Quincy comenzó a construir su red de desarrolladores, emprendedores y gerentes de contratación en tecnología. Estaba frecuentando hackerspaces y eventos tecnológicos en la ciudad. Pero aún no había subido a la arena y puesto a prueba su bravura...
Ya llevaba varios meses en mi camino del código cuando finalmente reuní el valor para ir a mi primer hackathon.
Un día me encontré con un error particularmente desagradable, y no estaba seguro de cómo solucionarlo. Así que hice lo que muchas personas harían en esa situación: procrastiné navegando por la web. Y fue entonces cuando lo vi. Startup Weekend EDU.
Startup Weekend es una competencia de 54 horas que implica construir una aplicación, y luego presentarla a un panel de jueces. Estos eventos recompensan tu conocimiento de codificación, diseño y emprendimiento también.
Este evento en particular – realizado en el corazón de Silicon Valley – tenía un panel de educadores y emprendedores en educación como jueces. Con mi experiencia en educación para adultos, este parecía un hackathon ideal para mí.
Le conté 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 Hackerspace de Santa Bárbara.
Pasé semanas preparándome para el evento, investigando sobre los jueces y las empresas para las que trabajaban. Investigué a los patrocinadores. Y, por supuesto, practiqué la codificación como un monje shaolin.
Por fin, tras un mes de preparación, llegó el gran fin de semana. Nos metimos en mi Toyota Corolla 2003 con la capa transparente descascarillada, pusimos música enérgica y emprendimos el viaje de cinco horas.
De camino, hablamos de lo que debíamos construir. Se centraría en la educación, por supuesto. Preferiblemente dirigida a estudiantes de secundaria, ya que eran los niveles en los que se centraban las empresas de los jueces.
Pero, ¿qué debía hacer la aplicación? ¿Cómo iba a facilitar la vida de la gente?
Pensé en mi época en el instituto. No tenía mucho en lo que basarme, ya que había abandonado los estudios después de un solo año. (Conseguí estudiar y aprobar el GED -Good Enough Degree, como lo llamábamos nosotros- mientras trabajaba en Taco Bell, antes de ir a la universidad. Pero esa es otra historia).
Pero sí recuerdo un punto doloroso del instituto, que todavía me resuena después de todos estos años: Los trabajos de inglés.
Me encantaba escribir. Pero no me encantaba escribir en formato MLA, con sus rígidas normas de citación. Me daba pavor preparar una página de trabajo citado. Mi profesor siempre me quitaba puntos por no formatear las citas correctamente.
Después de escuchar un montón de buenas ideas de los otros pasajeros del coche, me animé. Dije: «Tengo una idea. Deberíamos programar una aplicación que cree citas por ti».
Y alguien se rió y dijo: «Fuera de la vista.»
Y Steve dijo: «Oye, ese es un buen nombre. Podríamos llamarlo Fuera de Cita con una 'C'».
Todos nos reímos y nos sentimos inteligentes. Luego empezamos a discutir los detalles de la puesta en marcha.
Cuando llegamos al lugar, había unos 100 desarrolladores más. Era una oficina diáfana, con cubículos bajos flanqueados por pizarras.
Oí murmullos sobre uno de esos desarrolladores. «Eh, es el tipo que ganó el evento el año pasado», oí decir a la gente. Señalaban en dirección a un desarrollador de aspecto arrogante rodeado de fans. «Quizá me deje formar parte de su equipo».
El evento empezó con lanzamientos. Cualquiera podía pasar al frente de la sala, coger el micrófono y presentar durante 60 segundos la aplicación que quería crear.
Estaba tan nerviosa que parecía que me iba a salir un extraterrestre del pecho. Así que, naturalmente, fui el primero de la fila. Quítate la tirita, ¿vale?
Estaba sudando y gesticulando como un loco mientras me apresuraba a decir mi discurso. Dije algo como esto: «Las citas apestan. Quiero decir, no apestan. Son necesarias. Y hay que añadirlas a los artículos. Pero preparar citas es una mierda. Construyamos una aplicación que llene tu página de Trabajo Citado por ti. ¿Quién está conmigo?»
La sala se quedó en silencio. Entonces la gente se dio cuenta de que había terminado de hablar y me dieron un aplauso obligatorio. El maestro de ceremonias me quitó el micrófono de las manos y se lo dio a la siguiente persona.
Después de los lanzamientos, llegó el momento de formar los equipos. Nuestro contingente de Santa Bárbara se miró y dijo: «Supongo que somos un equipo».
Averiguamos la contraseña del wifi y cogimos el mejor de los espacios de trabajo: un despacho en una esquina con una puerta que se podía cerrar.
Empecé a garabatear maquetas de interfaz de usuario en la pizarra. Dije: «Queremos algo que esté siempre a un clic de distancia. En la barra de menú del navegador».
«Como un plugin del navegador», dijo Steve.
«Sí. Construyamos un plugin para el navegador».
Les mostré ejemplos de los tres formatos que pueden requerir los ensayos: MLA, APA y Chicago.
«¿Podríamos generar los tres a la vez, para que puedan copiarlos y pegarlos?». les pregunté.
«Podemos hacerlo mejor», responde Steve. «Podemos tener un botón para cada una de ellas que ponga la cita directamente en su portapapeles».
Trabajamos rápido, creando un sencillo MVP (Producto Mínimo Viable) al final de la noche del viernes. Todo lo que hacía era tomar los metadatos del sitio web actual y estructurarlos como una cita. Pero funcionaba.
Como era mi primer hackathon, no quería el estrés de alojarme en un albergue. Así que había derrochado para conseguir una habitación de hotel. Teníamos dos camas individuales, así que cada noche rotábamos cuál de los dos tenía que dormir en el suelo.
El sábado por la mañana, nuestras ambiciones crecieron. Me acerqué a la pizarra y le dije al equipo: «Citar páginas web está muy bien. Pero muchas de las cosas que citan los estudiantes están en libros o artículos académicos. Tenemos que ser capaces de generar citas para esos también».
Encontramos una API que nos permitía obtener información sobre citas a partir del ISBN (número de serie de los libros). Y elaboramos un script que podía buscar artículos académicos a partir de su DOI (un número de serie utilizado para los artículos académicos) y, a continuación, extraer datos de la página de resultados.
El sábado por la noche, el código de nuestro complemento para navegadores ya estaba listo. 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 de equipo mientras ensayaba mi presentación una y otra vez durante horas.
Aunque 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 delante de mis compañeros, a veces decenas de ellos. Pero esto era diferente.
En unas horas, me presentaría ante una sala llena de desarrolladores ambiciosos. Y jueces. Personas con doctorados, algunas de las cuales habían fundado sus propias empresas tecnológicas. Iban a evaluar nuestro trabajo. Me aterrorizaba que de alguna manera lo echara a perder.
Incapaz de dormir, abrí mi correo electrónico. El personal de Startup Weekend había enviado un correo, que incluía un PDF de un libro. Era una combinación no oficial de los clásicos de las startups tecnológicas 4 Steps to the Epiphany y The Lean Startup.
Ya había leído estos libros, porque eran lectura obligatoria 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 una amalgama de consejos.
Eran las 4 a.m., y no podía dormir. Así que simplemente empecé a leer. Una cosa en la que estos libros realmente insistían era en construir algo por lo que la gente pagaría. La forma definitiva de validación del cliente.
Entonces me di cuenta: ¿sabes qué realmente llevaría mi presentación al siguiente nivel? Prueba de encaje producto-mercado. Prueba de que la aplicación que estábamos construyendo resolvía un problema real que la gente tenía. Tanto así que abrirían sus billeteras.
Esto me dio una idea. Debería llevar nuestra aplicación a la carretera y vendérsela a la gente.
Pero era domingo por la mañana. ¿Dónde iba a encontrar clientes potenciales? Bueno, nuestro hotel estaba ubicado cerca del campus principal de la Universidad de Stanford.
Conduje a mi equipo al lugar del evento, les saludé y dije: "Volveré cuando tenga dinero en efectivo de los clientes."
Mis compañeros se rieron. No estoy seguro de si pensaban que estaba siendo serio. Dijeron, "Solo no llegues tarde para la presentación."
Pero yo estaba siendo serio. Tenía un prototipo de la aplicación corriendo en mi computadora portátil. Escribí Stanford en mi GPS y me embarqué en mi misión.
Ahora, estudié en una universidad estatal muy económica en Oklahoma. Así que me sentí realmente fuera de lugar cuando llegué a una de las universidades más destacadas del mundo.
Stanford cuesta $50,000 por año para asistir. Y yo llegué a su estacionamiento conduciendo un coche que valía 1/10 de eso.
El campus era una ciudad fantasma a esta hora de la semana. Pero una ciudad fantasma palaciega, de todos modos. Estatuas de bronce. Arcos icónicos por todas partes.
Me pregunté: ¿dónde están los estudiantes más aplicados y hardcore a esta hora del día? Aquellos que no tienen tiempo para perder haciendo manualmente sus páginas de trabajos citados?
Entré en la biblioteca principal, pasé junto al escritorio de seguridad y un cartel que decía "prohibido solicitar."
Caminé entre los estantes, encontrando un pequeño puñado de personas estudiando. Este chico estaba tomando notas diligentemente mientras leía un grueso libro de texto. Bingo.
Me senté a su lado. "Psst. Oye. ¿Te gustan las citas?"
"¿Qué?"
"Citas. Ya sabes, como páginas de trabajos citados."
"Um..."
"Sabes, la última página de tu trabajo, donde tienes que listar todas las..."
"Ya sé lo que es una página de trabajos citados."
"OK. Bueno, mira esto." Me abrí la chaqueta como un traficante de drogas, y saqué mi netbook de $200. Me dio la oportunidad de entregar mi torpe discurso de ventas.
Dije: "Aquí. Tengo este complemento de 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 hacer MLA?"
Contuve 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 de copiar al portapapeles.
El chico asintió, pareciendo algo impresionado. Así que intenté cerrar la venta.
"¿Qué tal si te digo que estoy a punto de lanzar esta aplicación con una suscripción anual. Pero si te registras ahora, obtendrás acceso ilimitado, no 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é allí durante un tiempo incómodamente largo en total silencio, mirándolo fijamente.
Finalmente dijo: "Genial, me apunto."
"Estupendo. Serán veinte dólares."
El chico retrocedió. "¿Qué? Eso es caro."
Esta era, por supuesto, la era de las startups subsidiadas por capital de riesgo, donde Uber y Lyft estaban perdiendo 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ápido. "Bueno, ¿cuánto dinero en efectivo tienes contigo?"
Rebuscó en su billetera y luego dijo, "cinco dólares."
Miré el billete arrugado y me encogí de hombros. "Vendido."
Él sonrió, y le envié un correo electrónico con instrucciones sobre cómo instalarlo. Luego dije: "Una cosa más. Tomémonos una foto juntos."
Puse mi teléfono en modo selfie. Él comenzó a sonreír, y yo dije, "Aquí. Sostén el billete de cinco dólares."
Pasé otra hora presentando la aplicación a personas en la biblioteca, y logré conseguir otro cliente que pagara. Luego corrí de vuelta al lugar del evento para finalizar nuestro prototipo con el equipo.
Esa tarde, di lo que todavía creo que es la mejor presentación de mi vida. Hicimos una demostración en vivo de la aplicación funcionando – 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 levanté 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 algún crédito de API de una de las empresas que patrocinaban el evento.
En la fiesta, almacené pizza, así tendría más tiempo para hacer contactos con todos los que pude. Me conecté en LinkedIn. Seguí en Twitter. Nos tomamos selfies juntos y usé mucho el hashtag del evento.
Fue un momento decisivo en mi viaje por la programación. Había demostrado a los presentes 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.
Montando en el circuito de hackatones
Desde ese momento, me enganché a los hackatones. Ese año, participé en docenas de ellos. Me convertí en un guerrero de la carretera, recorriendo la costa, asistiendo a cada competencia que podía.
A partir de entonces, sería mucho más difícil. Ya no tenía un equipo. Estaba solo.
Llegaba, conocía a tanta gente como podía, luego subía y presentaba una idea que pensaba que podría ganar a los jueces.
A veces la gente se unía a mi equipo. A veces me unía a los equipos de otras personas.
No solo quería diseñar aplicaciones, también quería codificarlas. Y a menudo, mis aspiraciones superaban mis habilidades.
Hubo muchos hackatones en los que todavía estaría tratando de corregir errores hasta los últimos minutos antes de subir al escenario. A veces mis aplicaciones se bloqueaban durante las demostraciones en vivo.
En un hackatón en Las Vegas, logré estropear la base de código tan gravemente que solo tuvimos que usar una presentación de diapositivas. Me senté en el público con la cabeza entre las manos, viendo impotente cómo mi compañero de equipo demostraba cómo nuestra aplicación funcionaría hipotéticamente, si hubiera podido hacerla funcionar. No nos fue bien con los jueces.
Pero seguí esforzándome. Seguí llegando a nuevas ciudades, registrándome en el hostal, asistiendo al evento 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 llevar la cuenta. Pero nunca habíamos logrado ganar un hackatón.
Rompiendo barreras
Eso fue hasta un evento en San Diego. Nunca olvidaré la sensación de construir algo que ganó tanto al público como a los jueces al grado de que nuestra victoria se sintió como una conclusión inevitable.
Después de que nos anunciaran como ganadores, recuerdo salir a hurtadillas por la puerta trasera hacia un estacionamiento y llamar a mis abuelos. Les dije que finalmente lo había logrado. Había ayudado a construir una aplicación y elaborar una presentación que había ganado un hackatón.
No sé cuánto entendían mis abuelos sobre desarrollo de software o sobre hackatones. Pero dijeron que estaban orgullosos de mí.
Ahora que ya no están, a menudo pienso en esa conversación. Valoro su aliento. Su fe en que un nieto maestro de 30 años podría intentarlo con todas sus fuerzas y convertirse en desarrollador.
Seguí yendo a hackatones después de eso. Seguí formando nuevos equipos y aprendiendo nuevas herramientas en el camino. Nunca olvidas la primera vez que consigues que una API funcione. O cuando finalmente comprendes cómo funciona algún comando de Git. Y nunca olvidas a las personas que se esfuerzan junto a ti, tratando de mantener la aplicación cohesiva durante la demo.
El hackatón de TechCrunch Disrupt. El hackatón de DeveloperWeek. El hackatón de ProgrammableWeb. El hackatón de Salesforce con premio de $1 millón. Tantos grandes hackatones y tanto aprendizaje. Esta fue la prueba de fuego donde se forjaron mis habilidades como desarrollador.
No solo logré mejorar mis habilidades y mi red de contactos en el camino, sino que ahora tenía la reputación de ser alguien que realmente podía ganar un hackatón.
Podía lanzar.
Esto me convirtió en una entidad conocida.
Y esa reputación fue crucial para conseguir mis primeros clientes freelance, mi primer trabajo de 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 mucho, mucho tiempo atrás en la prehistoria humana. En la mayoría de las tribus y asentamientos, había algún sistema para llevar registro de quién debía qué a quién.
Antes de que existiera el dinero, existía el crédito.
Esto pudo haber sido un libro de contabilidad escrito. O podría haber sido un anciano que simplemente mantenía todos estos registros en su cabeza.
Más allá de la contabilidad, también había una vibra menos tangible, pero igualmente importante que la gente llevaba consigo.
"John ciertamente sabe cómo herrar un caballo."
O "Jane es la mejor narradora del lugar."
O "El valor de Jay en la batalla nos salvó contra los invasores hace tres inviernos."
Notarás que estos ejemplos involucran a alguien que es bueno en algo. No solo ser una persona agradable y simpática.
Ciertamente ayuda ser una persona tranquila y con los pies en la tierra. Pero esto no es El Gran Lebowski, y no vamos a sobrevivir solo con nuestro encanto.
El Gran Lebowski (izquierda). No tenía trabajo, no tenía habilidades, no tenía energía. Pero tenía mucha tranquilidad.
Es fácil para un desarrollador decir: "Oh sí. Conozco JavaScript como la palma de mi mano. Puedo construir cualquier tipo de aplicación en JavaScript que necesites, funcionando 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 en mentir.
Entonces eres bueno en todo."
(Se desconoce la verdadera procedencia de esta cita. Pero me gusta imaginar que lo dijo 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 maestro que había mentido sobre haber obtenido una maestría. Pasaron los años y nadie lo descubrió.
Cada año, mentía en su papeleo anual, para poder obtener un aumento de sueldo mayor que el de los otros maestros. Y cada año, se salía con la suya.
Pero un día, una pequeña discrepancia me alertó. Revisé su expediente, llamé a algunos departamentos de registro universitario y descubrí que nunca se había molestado en terminar su título.
Cuando le pillé fue un auténtico momento Scooby Doo. "Y me habría salido con la mía, si no fuera por ustedes, malditos niños".
Fue terrible saber que esta persona estaba enseñando en la escuela durante años y recibiendo más dinero que muchos otros profesores, simplemente porque estaba dispuesto a mentir.
Los beneficios de mentir siempre están ahí, brillando. Algunas personas están dispuestas a sucumbir a esa tentación.
Los empleadores lo saben. Saben que no puedes confiar en cualquier persona que afirma conocer el desarrollo full-stack de JavaScript. Tienes que ser cauteloso sobre quién obtiene una insignia de la empresa, una dirección de correo electrónico de la empresa y las llaves de tus bases de datos de producción.
Por eso los empleadores usan preguntas de entrevistas conductuales – para tratar de atrapar a personas que son más capaces de ser deshonestas.
Llámame ingenuo, pero creo que la mayoría de las personas son inherentemente buenas. Que la mayoría de las personas están dispuestas a seguir las reglas mientras 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 mayor escrutinio.
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 clientes, o quebranta leyes con el propósito de inflar sus números.
La historia está plagada de empleados que desataron daños catastróficos a sus empleadores, todo para su propio beneficio personal.
Así, el proceso de contratación de desarrolladores en la mayoría de las grandes empresas es paranoico a más no poder. Tal vez debería serlo. Pero desafortunadamente, esto hace que sea más difícil para todos conseguir un trabajo de desarrollador – incluso para los candidatos más honestos.
Como desarrolladores, necesitamos pruebas de que nuestras habilidades son tan fuertes como decimos que son. Necesitamos pruebas de que nuestra ética de trabajo es tan firme como nuestros empleadores necesitan que sea.
Ahí es donde entra 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 llegar a la empresa por una puerta lateral, en lugar de por la puerta principal por la que se alinean otros solicitantes.
Incluso algunas empresas tienen reclutadores internos que pueden agilizar tu proceso de entrevista. Una reputación fuerte también puede ayudarte a tener más poder de negociación durante las negociaciones salariales.
Entonces, hablemos de cómo puedes construir una reputación sólida y ser buscado por los gerentes.
Cómo construir tu reputación como desarrollador
Hay al menos seis maneras comprobadas de construir tu reputación como desarrollador. Estas son:
- Hackathons
- Contribuir a código abierto
- Crear contenido enfocado en desarrolladores
- Ascender en las filas trabajando en empresas con un "nombre conocido"
- Construir un portafolio de clientes freelance
- Comenzar tu propio proyecto de código abierto, empresa o caridad
Cómo encontrar hackathons y otras competencias para desarrolladores
Los hackathons representan la manera más inmediata de construir tu reputación, tu red de contactos y tus habilidades de codificación al mismo tiempo.
La mayoría de los hackathons son gratuitos y abiertos al público. Solo necesitas tener el tiempo y el presupuesto para viajar.
Si vives en una ciudad con muchos hackathons – como San Francisco, Nueva York, Bengaluru o Beijing – puedes desplazarte al evento y luego volver a casa y 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 antiguo compañero de clase en San Francisco que me dejaba dormir en su sofá. Esto me dio acceso a muchos más eventos.
Los hackathons solían ser eventos muy intensos. La gente tomaba bebidas energéticas y dormía en el suelo, todo para terminar su proyecto a tiempo para la presentación.
Pero los organizadores de hackathons gradualmente se están volviendo más conscientes de la salud y la sostenibilidad de estos eventos. Después de todo, muchos participantes tienen hijos o trabajos de tiempo completo exigentes, y no pueden simplemente codificar todo un fin de semana.
La mejor manera de encontrar eventos próximos es simplemente googlear "hackathon [nombre de tu ciudad]" y explorar los diversos calendarios de eventos que aparecen en los resultados de búsqueda. Muchos de estos serán organizados por universidades, empleadores locales o incluso organizaciones benéficas enfocadas en la educación.
Si estás compitiendo para ganar, te recomiendo investigar con anticipación.
¿Quiénes son los patrocinadores del evento? Usualmente serán empresas del tipo Business-to-Developer, con API, herramientas de bases de datos o varias ofertas de Software-as-a-Service.
Estos patrocinadores probablemente tendrán un estand en el evento donde podrás hablar con sus defensores de desarrolladores. Estas son personas que se les paga por 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 estands, lo cual también puede ser una gran oportunidad de networking.
A menudo, el hackathon ofrecerá premios específicos de los patrocinadores. "Mejor uso de [API del patrocinador]". Puede ser más fácil enfocar tu tiempo en incorporar herramientas específicas del patrocinador en tu proyecto, en lugar de intentar ganar el gran premio. Aun así puedes poner estos logros en tu LinkedIn o tu currículum. Una victoria es una victoria.
A veces, el hackathon es tan de alto perfil – o el premio es tan sustancial – que simplemente tiene sentido tratar de ganar la competencia en general.
Durante mi tiempo asistiendo a hackathons, pude ganar el equivalente a varios meses de alquiler en premios en efectivo, varios años de espacio de co-working gratuito e incluso un tour privado del edificio de las Naciones Unidas en Nueva York.
No te sorprendas si algunas de las personas con las que te encuentras frecuentemente en hackatones 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 hackatones es muchísimo mayor que el del desarrollador promedio. Después de todo, estas son personas que terminan una semana laboral para lanzarse directamente a un fin de semana de trabajo. Estas personas no temen saltar de la sartén al fuego.
Cómo contribuir al código abierto
Contribuir al código abierto es una de las formas más inmediatas en las que puedes construir tu reputación. La mayoría de los empleadores van a mirar tu perfil de GitHub, que mostrará prominentemente tu historial de commits en Git.
El perfil de GitHub de Mrugesh Mohapatra, quien hace un montón de desarrollo de plataforma y DevOps para freeCodeCamp.org. Nota qué tan verde está su barra de actividad. 2,208 contribuciones en el último año.
Muchos mantenedores de proyectos de código abierto, como la Fundación Linux, Mozilla (Firefox), y por supuesto nosotros mismos en freeCodeCamp, tienen altos estándares de calidad de código.
Puedes leer problemas abiertos en GitHub para encontrar errores conocidos o solicitudes de características. Luego puedes hacer los cambios en el código y abrir una solicitud de incorporación de cambios (pull request). Si los mantenedores integran tu solicitud de incorporación de cambios, esto será un gran mérito en tu carrera.
Una de las mejores maneras de conseguir un empleo en una empresa de tecnología es convertirse en un prolífico contribuidor de código abierto a sus repositorios.
Contribuir 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 revisen y acepten tu trabajo.
Si estás interesado en construir tu reputación a través del código abierto, aquí te mostramos cómo empezar.
Lee la guía completa de Hillary Nyakundi para empezar con código abierto.
Cómo crear contenido enfocado en desarrolladores
Los desarrolladores son personas. Y al igual que otras personas, quieren algo que hacer con su tiempo cuando no están trabajando, durmiendo, o pasando el rato con amigos y familia.
Para muchas personas, incluyéndome a mí, eso significa pasar tiempo en los pensamientos de otras personas. Libros. Video ensayos. Experiencias interactivas como novelas visuales.
Puedes referirte de manera general a esto como "contenido". No soy un gran fan de la palabra, porque hace que estas obras se sientan desechables. Pero así es como la gente lo llama.
El desarrollo de software es un campo increíblemente amplio, con tantos temas diferentes que podrías abordar. Hay vlogs sobre el estilo de vida de los desarrolladores, tutoriales de preparación para entrevistas de codificación, transmisiones en vivo de codificación en Twitch, y podcasts de entrevistas a desarrolladores como el Podcast de freeCodeCamp.
Probablemente hay categorías completas de contenido para desarrolladores que ni siquiera hemos imaginado todavía, y que surgirán en la próxima década.
Si estás interesado en el cine, el periodismo, o la escritura creativa, el contenido para desarrolladores puede ser una buena manera de construir tu reputación.
Puedes elegir un tema específico y, gradualmente, llegar a 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 exámenes principales 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 de exámenes.
Hay más de 30 millones de desarrolladores de software en todo el mundo. Es mucha gente que potencialmente consumirá tu contenido, y que llegará a conocerte.
Cómo ascender en la jerarquía trabajando en grandes empresas
Es posible que hayas visto a un desarrollador presentado como un "Ex-Googler" o un "Ex-ingeniero de Netflix."
Algunas empresas de tecnología tienen procesos de contratación tan rigurosos, y estándares tan altos, que incluso conseguir un trabajo en la compañía es un gran logro.
Hay algunas razones prácticas por las que los empleadores observan dónde han trabajado anteriormente los candidatos. Reduce el riesgo de una contratación fallida.
Puedes construir tu reputación escalando en la jerarquía de prestigio. Puedes ascender desde un empleador local a una empresa Fortune 500, y finalmente a uno de los gigantes tecnológicos.
Por supuesto, trabajar en una corporación gigante no es para todos. Hablaré más sobre esto en el Capítulo 4. Pero ten en cuenta que es una opción que tienes para construir tu reputación.
Cómo construir tu reputación construyendo un portafolio de clientes freelance
Puedes construir tu reputación trabajando con empresas como freelancer.
Los desarrolladores freelance generalmente trabajan en proyectos más pequeños de una sola persona. Así que esta puede ser una mejor estrategia para construir tu reputación localmente.
Por ejemplo, si hiciste un buen trabajo para un banco local, eso podría ser suficiente para convencer a un bufete de abogados local para contratarte también.
Hay algo que decir sobre ser un "héroe local". Conozco a muchos desarrolladores que pueden competir eficazmente con la competencia en línea solo estando físicamente presentes en las reuniones y conociendo a personas 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.
Gente está ocupada. No tienen tiempo de 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 recomiendo usar una herramienta de captura de pantalla para grabar demostraciones en 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 de los detalles de la implementación y las decisiones de diseño que tomaste.
Pero siempre, siempre comienza con la demostración. La gente quiere ver algo funcionando. Quieren ver algo visual.
Una vez que hayas atraído a la gente con tu demostración convincente de tu aplicación en funcionamiento, podrás explicar todos los detalles que quieras. Tu audiencia ahora tendrá más contexto y estará más interesada.
Dos minutos es también una duración mágica, porque puedes subir ese video a un tuit, y se reproducirá automáticamente en Twitter a medida que las personas lo desplacen. Los videos que se reproducen automáticamente tienen muchas, muchas más probabilidades de ser vistos 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.
— Quincy Larson (@ossia) December 15, 2022
Like... so many of the core features and UI elements.
It looks uncanny.🦹
🧑💻 Code by Risal
🥁 Music by me pic.twitter.com/cFDjNxthnF
Puedes poner estos videos de demostración de proyectos en sitios web como YouTube, Twitter, tu perfil de GitHub y, por supuesto, en 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 quieres una herramienta más poderosa, OBS es gratuito 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 tu fuente lo más grande posible y usa un micrófono externo. Cualquier micrófono que puedas encontrar, incluso de unos auriculares baratos, será mejor que hablar en el micrófono incorporado de tu portátil.
Invierte todo el tiempo que necesites en grabar y volver a grabar tomas hasta que lo consigas.
Poder mostrar tus proyectos y presentar tu código es una habilidad valiosa que usarás a lo largo de tu carrera. El tiempo dedicado a practicar presentaciones nunca es tiempo perdido.
Cómo iniciar tu propio proyecto de código abierto, compañía o caridad
Ser un fundador es la forma más rápida, pero también la más arriesgada, de construir una reputación como desarrollador.
Es la más arriesgada porque estás apostando tu tiempo, tu dinero y posiblemente incluso tus relaciones personales, todo por un resultado desconocido.
Si contribuyes al código abierto durante suficiente tiempo, construirás una reputación como desarrollador.
Si participas en el circuito de hackatones el tiempo suficiente, construirás una reputación como desarrollador.
Pero podrías intentar iniciar proyectos empresariales durante décadas sin lograr tracción. Y desperdiciar tu tiempo, dinero y conexiones en el camino.
El emprendimiento está más allá del alcance de este libro. Pero si te interesa, te daré este rápido consejo:
La mayoría de los emprendedores fracasan. Algunos fracasan debido a circunstancias fuera de su control. Pero muchos fracasan por no entender la naturaleza de los riesgos que están asumiendo.
No te apresures a fundar un proyecto, empresa o caridad. Intenta trabajar para otras organizaciones que ya están haciendo trabajos en tu campo de interés.
Al trabajar para otra persona, te pagan por aprender. Tienes exposición al trabajo y a los riesgos que lo rodean. Y puedes construir ahorros para una eventual aventura empresarial.
Cómo no destruir tu reputación
"Se necesita una vida para construir una buena reputación, pero puedes perderla en un minuto." – Will Rogers, Actor, Vaquero y uno de mis héroes mientras crecía en Oklahoma City
Construir tu reputación es una maratón, no un sprint.
Puede tomar años construir una reputación lo suficientemente fuerte como para abrir las puertas correctas.
Pero al igual que en una maratón competitiva, un tropiezo puede costarte un tiempo valioso. Un tropiezo que resulte en una lesión puede dejarte fuera de la carrera por completo.
No digas cosas tontas en internet
La gente solía decir cosas tontas todo el tiempo. Las palabras podían colgar en el aire por unos minutos mientras todos se estremecían. Pero las palabras finalmente se disipaban.
Ahora, cuando la gente dice cosas tontas, a menudo lo hacen en línea. Y en tinta indeleble.
Siempre asume que en el momento en que escribes algo en un sitio web y presionas enter, será guardado en una base de datos. Esa base de datos será respaldada en varios centros de datos alrededor del mundo.
Puedes probar la existencia de los datos, pero no hay forma de probar la ausencia de datos.
Debes asumir, para todos los efectos, que el gato está fuera de la bolsa. No hay forma de volver a meter al gato en la bolsa. Lo que acabas de decir: eso está en tu expediente permanente.
Puedes eliminar el comentario. Puedes eliminar tu cuenta. Incluso puedes intentar borrarlo de los resultados de búsqueda de Google. Pero probablemente alguien ya lo ha respaldado en la Wayback Machine. Y cuando inevitablemente una de esas bases de datos sea hackeada años después, esos datos probablemente aún estarán ahí en alguna parte, listos para que alguien los saque a la superficie.
Es un momento aterrador para ser una bocaza. Así que no lo seas. Piensa antes de hablar.
Mi consejo, que puede sonar cobarde: sal del hábito de discutir con la gente en línea.
Algunas personas siguen la regla del patio de recreo de "si no tienes algo bueno que decir, no digas nada en absoluto."
Yo prefiero el "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 en general me abstengo de criticar a la gente. Incluso a la gente que se lo merece.
En una pelea, todos se ven sucios.
No quieres parecer iracundo, destrozando el argumento de alguien o amontonándote sobre alguien que acaba de decir algo tonto.
Claro, el ingenio cáustico puede hacerte ganar 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 amenazara con tuitear sobre un vuelo cancelado.
Pero la gente está ocupada. La mayoría no quiere usar su poco tiempo, desplazándose por las redes sociales, solo para verme quejándome de lo que en el gran esquema de las cosas es una leve inconveniencia.
Así que ese es mi consejo sobre el uso de las redes sociales. Trata de mantenerlo positivo.
Si es un asunto sobre el que tienes fuertes convicciones, no te detendré de expresar tu opinión. Solo piensa antes de escribir y piensa antes de enviar.
No prometas de más y cumplas de menos
Una de las formas más comunes en que veo a los desarrolladores torpedear sus propias reputaciones es prometiendo de más y cumpliendo de menos. Esto no es necesariamente un error fatal. Pero es malo.
Recuerda cuando hablé del hackathon de Las Vegas donde fracasé completamente en terminar el proyecto a tiempo para la presentación, y tuvimos que usar diapositivas en lugar de una aplicación funcional.
Sí, ese fue uno de los puntos más bajos en mi viaje de aprender a programar. Mis compañeros de equipo fueron educados, pero estoy seguro de que estaban decepcionados de mí. Después de todo, había sido demasiado confiado. Había prometido de más lo que podría lograr en ese período de tiempo, y había cumplido de menos.
Es mucho mejor ser modesto en tus estimaciones de tus habilidades.
Recuerda la parábola de Ícaro, quien con alas de cera voló demasiado cerca del sol. Si solo hubiera tomado 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.
Paisaje con la caída de Ícaro por Pieter Bruegel el Viejo, circa 1560. Ícaro pudo haber sido un contendiente. Pudo haber sido alguien. Pero, en cambio, solo son sus piernas desapareciendo en el mar. Y los agricultores y pastores no se molestan en levantar la vista de su trabajo para captar su insignificancia.
Controla tus adicciones antes de que dañen tu reputación
Si tienes una adicción no tratada a las drogas, al alcohol o al juego, busca ayuda primero. La búsqueda de empleo para desarrolladores puede ser larga y agotadora. Quieres enfrentarte a ella con toda tu atención.
Incluso algo tan aparentemente inofensivo como la adicción a los videojuegos puede distraerte y absorber demasiado de tu tiempo. Vale la pena ponerla bajo control primero.
No soy médico. Y no te voy a dar un discurso de "las drogas son malas". Pero diré: puedes escuchar sobre modas en Silicon Valley, donde los desarrolladores abusan de drogas pensando que de alguna manera pueden mejorar sus habilidades de programación o resolución de problemas.
Hubo un tiempo en que había una tendencia de "micro-dosificación de LSD". Hubo una tendencia de uso de anfetaminas farmacéuticas.
Mi reacción instintiva a eso es: cualquier ventaja que puedan darte probablemente sea insostenible y un neto negativo a largo plazo.
No sientas presión de grupo para tomar drogas psicoactivas. No sientas presión de grupo para beber en las horas felices. (No he bebido ni 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 conseguir un trabajo como desarrollador será un proceso estresante. Márchate con calma, para no arriesgar una recaída.
No quieres llegar al final del proceso de transición de carrera, y lograr tanto, solo para que los viejos hábitos resurjan y arruinen tu arduo trabajo.
Trata de separar tu vida profesional de tu vida personal
Puede que hayas escuchado la expresión, "No mezcles negocios con placer."
Como desarrollador, vas a convertirte en una persona poderosa. Vas a comandar 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í. La gente se va a fijar en ti.
Vas a hablar con personas que desearían estar en tus zapatos.
No ostentes 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 las relaciones.
Esto te hará desagradable para las personas a tu alrededor. Y si de alguna manera se captura y publica en línea, puede perseguirte por el resto de tu carrera.
Nunca pierdas de vista cuánto tienes. Y cuánto tienes que perder.
Usa el truco del narrador
Cerraré este capítulo con un pequeño truco que uso para animarme.
Primero, recuerda que eres el héroe en tu propio viaje de programación. En el teatro de tu mente, eres la persona que todos están mirando, el que están apoyando.
El truco del narrador es narrar tus acciones en tu cabeza mientras las haces.
Quincy atraviesa el espacio de hackers, con su laptop bajo el brazo. Coloca su taza debajo del dispensador de agua caliente y deja caer una bolsita de té fresca. Acciona la palanca. Y mientras el agua humeante llena su taza, dice en alto con su mejor acento británico: "Té. Earl Grey. Caliente."
Con su bebida energizante en mano, se desliza en un cubículo, coloca su laptop en la superficie y captura la mirada de un compañero desarrollador. Cruzaron miradas por un segundo. Quincy inclina la cabeza muy levemente, reconociendo la presencia del desarrollador. El desarrollador inclina la cabeza de vuelta, compartiendo casi telepáticamente este sentimiento: "Te veo amigo. Te veo presentándote. Te veo haciendo las cosas."
Esto puede sonar ridículo. Pues sí, es ridículo. 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. Cristaliza 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 eras ("los años de Taco Bell"). O puntos de inflexión ("aprobar el examen GED").
¿Qué tiene esto que ver con construir tu reputación? Tu reputación es esencialmente el resumen de quién eres. Lo que significas para las personas a tu alrededor.
Al tomarte más en serio, al pensar en tu vida como una película, estás trabajando gradualmente en quién eres. Y en quién quieres convertirte algún día.
Al narrar tus acciones, arrojas una luz más brillante sobre ellas en tu propia mente. ¿Por qué hice eso? ¿En qué estaba pensando? ¿Había un mejor movimiento ahí?
Muchas personas sabotean su reputación sin siquiera darse cuenta, simplemente porque se han instalado en malos hábitos.
Durante años pensé que tenía que ser "gracioso" todo el tiempo. Encontraba cualquier oportunidad para inyectar algo de humor autocrítico. Mucha gente se dio cuenta de lo que estaba haciendo y lo encontró divertido. Pero muchos no entendieron, y solo se quedaron con la impresión de que era un imbécil.
¿Por qué hice eso? 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, ya no es un error. Es una decisión." – Paulo Coelho
Podría haber continuado mucho más 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 de hacer las cosas que son subóptimas. Y con la ayuda del Truco del Narrador, espero identificarlas en el futuro y refinarlas, 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 la gente piense 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 la gente admire. ¿Por qué no empezar a comportarte así ahora?
¿Puedes imaginar cómo sería ser un desarrollador exitoso? ¿Haber construido sistemas de software de los que las personas dependen?
Ese tú futuro, ¿cómo pensaría? ¿Cómo abordaría las situaciones y resolvería problemas? ¿Cómo hablaría de sus logros? ¿De sus reveses?
Simplemente pensar en tu yo futuro puede ayudarte a clarificar tu pensamiento. Tus prioridades.
A menudo pienso en el "Viejo Quincy", con su dolor de espalda. Tiene que disculparse para ir al baño cada 30 minutos.
Pero el viejo Quincy aún hace su mejor esfuerzo con lo que tiene. Se mueve a pesar de las articulaciones doloridas. Reflexiona a pesar de una mente nublada.
El viejo Quincy aún quiere hacer cosas. Está orgulloso de lo que ha logrado, pero no pasa mucho tiempo mirando hacia atrás. Mira hacia adelante hacia lo que va a hacer ese día y qué objetivos va a lograr.
A menudo pienso en el viejo Quincy y trabajo hacia atrás hasta donde estoy hoy.
¿Qué decisiones puedo tomar hoy que me prepararán para ser alguien digno de admiración mañana? ¿Tengo que esperar décadas para ganarme esa reputación? ¿O puedo tomar prestado algo de ese respeto del futuro?
Al pensar como podría pensar mi yo futuro, ¿puedo hacer movimientos que me ganen una reputación positiva en el presente?
Creo que puedes aprovechar tu futura reputación, tu legado, ahora mismo. Solo piensa en términos de tu yo futuro y 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 la visualización de tu yo futuro, te ayuden no solo a pensar en la naturaleza de la reputación. Espero que también te ayuden a tomar pasos concretos hacia la mejora de tu reputación.
Porque construir una reputación, hacerte 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 las personas, de la mayoría de las culturas, estarían de acuerdo: un gran aspecto del éxito es poner comida en la mesa para ti y tu familia.
Y de eso es de lo que vamos a hablar a continuación.
Capítulo 4: Cómo obtener pago por programar – clientes freelance y la búsqueda de trabajo
Si has estado construyendo tus habilidades, tu red de contactos y tu reputación, entonces conseguir un trabajo como desarrollador no es tan complicado.
Ten en cuenta que dije que no es complicado, sigue siendo mucho trabajo. Y puede ser agotador.
Primero, déjame contarte cómo conseguí mi primer trabajo.
Hora de la historia: ¿Cómo consiguió un maestro en sus 30 su primer trabajo como desarrollador?
La última vez en Hora de la Historia: Quincy se lanzó a la circuit de hackathons con fuerza, ganando incluso algunos de los eventos. Estaba construyendo su reputación como desarrollador que era "peligroso" con JavaScript. No súper hábil. Solo 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 que cuando alquilabas un apartamento de una habitación a un precio exorbitante en los suburbios, no pagabas por el interior, sino por el exterior.
Mi objetivo era pasar el menor tiempo posible en aquella estrecha ratonera centenaria y pasar el resto paseando por la ciudad.
Era una hermosa tarde de miércoles. Todavía tenía dos días más para prepararme para el hackathon de ese fin de semana. Y mi cerebro estaba completamente frito después de un día de programación. Mi esposa estaba trabajando hasta tarde, así que revisé mi calendario para encontrar algo que hacer.
El primer lunes de cada mes, organizaba todos los eventos tecnológicos de ese mes en el sur de California, así siempre tenía un evento al que podría asistir si tenía la energía.
Ah, esta noche es la reunión de Ruby on Rails en Santa Bárbara, y ya había confirmado mi asistencia.
No sabía mucho sobre Ruby on Rails, pero había completado algunos proyectos pequeños con él. Era mucho más un desarrollador de JavaScript y Python.
Pero pensé, qué diablos. Necesito mantener mi impulso para construir mi red de contactos. Y el lugar estaba a solo unas pocas cuadras de distancia.
Entré y solo había unos pocos desarrolladores sentados alrededor de una mesa charlando. Pronto quedó claro que todos trabajaban juntos en una startup local, manteniendo una gran base de código de Ruby on Rails. La mayoría de ellos llevaban trabajando allí varios años.
En ese momento, había pasado el último año construyendo mis habilidades, mi red de contactos y mi reputación. Así que pude defenderme durante la conversación.
Pero también conocía los límites de mis habilidades. Así que me mantuve modesto. Comedido. De la manera en la que había visto a tantos otros desarrolladores exitosos manejar 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 la educación de adultos. Enseñando inglés y dirigiendo escuelas. Empecé a aprender a programar hace aproximadamente un año."
Pero el hombre sorprendió con su calma. "Bueno, si quieres venir a una entrevista, podemos ver si serías una buena incorporación para el equipo."
Esa noche caminé a casa sintiendo electricidad. Era mucho más miedo que emoción.
No me sentía ni de lejos listo. Y ni siquiera estaba buscando un 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. Cambiaba mi propio aceite, me cortaba el pelo yo mismo e incluso cocinaba mi propio arroz en casa cuando pedíamos comida para llevar, solo para ahorrar unos cuantos dólares.
Durante la década que trabajé como maestro, logré ahorrar casi una cuarta parte de mis ganancias después de impuestos. Y compraba videojuegos viejos en Craigslist y luego los vendía en eBay. Eso puede sonar tonto, pero era una fuente sustancial de ingresos para mí.
¿Para qué estábamos ahorrando todo esto? No lo sabíamos. ¿Quizás para comprar una casa en California en algún momento en el futuro? Pero significaba que no tenía que apresurarme para conseguir un trabajo. Sabía que estaba en una posición privilegiada y trataba de aprovechar 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 inexperto que era, me despedirían y luego tendría que explicar ese fracaso en futuras entrevistas de trabajo.
Por supuesto, ahora sé que estaba viendo esta oportunidad de la manera incorrecta. Pero déjame terminar la historia.
Cuando programé mi entrevista de trabajo, me pidieron un currículo. No estaba seguro de qué hacer, así que dejé toda mi experiencia profesional allí. Todas las escuelas para las que había trabajado en los últimos años. (Omití mi tiempo dirigiendo el autoservicio 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, darles una hoja de papel en blanco?
Bueno, tenía un portafolio en línea de proyectos que había construido. Y lo más importante, tenía una lista de todos los hackathons en los que había ganado o había sido finalista. Así que incluí eso.
Pasé las últimas horas antes de la entrevista revisando todos los tutoriales de Ruby on Rails que había usado durante el año pasado, para refrescar mi memoria. Y luego me puse mi sudadera con capucha, jeans y mochila, y caminé hacia su oficina.
La gerente de la oficina era una mujer agradable que me llevó al área de desarrollo y me presentó a su pequeño equipo de desarrolladores. Eran tal vez una docena, la mayoría vestidos con jeans y sudaderas con capucha, edades desde los veintitantos hasta los cuarenta y tantos. Dos de ellos eran mujeres.
Fui turnándome para navegar entre el laberinto de escritorios y cables, estreché la mano de cada uno de ellos y me presenté. Aquí es donde toda mi experiencia como maestro de aula memorizando nombres de estudiantes resultó útil. Pude recordar todos sus nombres, así que más tarde en el día cuando me fui, pude seguir con cada uno de ellos: "Encantado de conocerte, [nombre]. Estaría emocionado de trabajar contigo."
Primero me reuní con el director de ingeniería. Entramos en una pequeña oficina y cerramos la puerta.
Una pizarra blanca en la pared estaba cubierta de bocetos de diagramas de Lenguaje Unificado de Modelado (UML). Un arco iris de marcadores para pizarras delineaba las relaciones entre varios servidores y servicios.
Seguí mirando esa pizarra, temiendo que me enviaría allí para resolver algunos problemas de programación y demostrar mis habilidades. ¿Quizás el famoso problema de fizzbuzz? ¿Quizás querría que invirtiera un árbol binario?
Pero ni siquiera mencionó la pizarra. 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 que pagaban, principalmente pequeñas empresas. Se enorgullecían de ser pragmáticos. En ningún momento me preguntaron qué estudié en la escuela, o qué tipo de trabajo hice en el pasado. Lo único que realmente les importaba era...
"Mira. Sé que puedes programar", dijo él. "Has estado programando todo este tiempo, ganando hackatones. Revisé algunos de tus proyectos en el 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 otros desarrolladores en el equipo? Y lo más crítico: ¿puedes hacer las cosas?"
Tragué saliva, me incliné hacia adelante y reuní toda la confianza que pude. "Sí", dije. "Creo que puedo."
Y él dijo: "Bien. Bien. OK. Ve a esperar en el restaurante Pho abajo. [El CTO] debería estar allí en un minuto."
Así que hablé con el CTO mientras comíamos fideos. Principalmente escuché. Había aprendido que la gente proyecta inteligencia en personas calladas. Escuchar atentamente no solo te ayuda a ser más inteligente, sino que incluso te hace parecer más inteligente.
Y el enfoque funcionó. La reunión duró aproximadamente una hora. Los fideos estaban sabrosos. Aprendí mucho sobre la historia de la empresa y los objetivos a corto plazo. El CTO dijo: "OK, sube y habla con [el director de ingeniería]."
Y lo hice. Y él me ofreció un trabajo.
Ahora, quiero enfatizar. Esta no es la forma en que la mayoría de las personas obtienen su primer trabajo como desarrollador.
Probablemente estés pensando, "Vaya, aquí Quincy se ha abierto camino fortuitamente en un trabajo de desarrollador para el que ni siquiera estaba buscando. Ojalá todos pudiéramos tener tanta suerte."
Y ciertamente eso es lo que sentí en ese momento. Pero en la siguiente sección, voy a explorar la relación entre empleadores y desarrolladores. Y cómo conseguir ese trabajo se debió menos a mis habilidades como entrevistado, y más al año de programación, networking y construcción de reputación que lo precedió.
Este no era un trabajo cómodo en una gran compañía tecnológica, con toda la compensación, beneficios y boleras de la empresa. Era un puesto de contratista que pagaba más o menos lo mismo que yo ganaba como profesor.
Pero era un trabajo de desarrollador. Una empresa me estaba pagando para escribir código.
Ahora era un desarrollador profesional.
Lo que Quieren los Empleadores
Avanzamos una década. Ahora he estado en ambos lados de la mesa. He sido entrevistado por 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 empleo. Algunos de ellos han aplicado a cientos de trabajos y solo han recibido unas pocas "respuestas" para entrevistas de trabajo.
También he pasado muchas horas en llamadas con gerentes y reclutadores, tratando de entender mejor cómo contratan y qué buscan.
Creo que gran parte de la frustración que los desarrolladores sienten sobre el proceso de contratación se reduce a un malentendido.
Los empleadores valoran una cosa por encima de todo: la previsibilidad.
¿Cuál de estos candidatos crees que un empleador preferiría?
X es un "rockstar" programador 10x que a menudo tiene destellos de genialidad. X también tiene rachas de increíble productividad. Pero X a menudo está malhumorado con los colegas y a menudo se pierde plazos o reuniones.
Y es un programador decente, y tiene una producción más lenta pero más consistente. Y se lleva bien con los colegas y rara vez pierde reuniones o plazos.
Z es similar a Y en términos de producción, y es capaz de llevarse bien con los colegas y cumplir plazos. Pero Z ha cambiado de trabajo 3 veces en los últimos 3 años.
OK, probablemente puedas adivinar de todo lo que he dicho hasta ahora: Y es el candidato preferido. Y eso es porque los empleadores valoran la previsibilidad por encima de todo.
X es un candidato trampa que algunos gerentes primerizos pueden cometer el error de contratar. Si tienes curiosidad por saber por qué contratar a X sería una mala idea, lee Despedimos a nuestro mejor talento. La mejor decisión que tomamos.
Solo agregué Z a esta lista para hacer un punto: trata de no cambiar de trabajo con demasiada frecuencia.
Puedes aumentar tus ingresos bastante rápido escalando de un empleador a otro. Puedes comenzar a aplicar para nuevos trabajos en el momento en que aceptas una carta de oferta. Pero esto repelerá a muchos gerentes de contratación.
Después de todo, una piedra rodante no acumula musgo. Estarás entrando y saliendo de bases de código antes de que tengas tiempo de entender cómo funcionan.
Considera esto: puede tomar 6 meses o más para que un gerente ponga al día a un nuevo desarrollador, hasta el punto en que puedan ser una ganancia neta para el equipo.
Hasta ese momento, el nuevo empleado es esencialmente un drenaje de los recursos de la empresa, absorbiendo tiempo y energía de sus compañeros que tienen que integrarlos, ayudarlos a orientarse en una base de código y arreglar sus errores.
La mayoría de los empleadores son adversos al riesgo
Digamos que un gerente contrata al desarrollador equivocado. Tómate un momento para pensar en lo malo que puede ser para el equipo.
En promedio, toma alrededor de 3 meses cubrir un puesto de desarrollador en una empresa. Los empleadores primero tienen que:
- Conseguir que sus jefes aprueben el presupuesto para contratar a un desarrollador
- Crear la descripción del trabajo
- Publicar el trabajo en sitios de empleo y comunicarse con reclutadores
- Escoger currículums – muchos de los cuales serán de candidatos que están aplicando a ciegas a tantos trabajos como sea posible
- Comenzar el proceso de entrevistas, que puede implicar transportar a los candidatos a la ciudad y alojarlos en un hotel
- Rondas de entrevistas que involucran a muchos miembros del equipo. Para algunos empleadores, esto es un asunto de varios días
- Seleccionar un candidato final y negociar una oferta...
- la cual muchos candidatos no aceptarán de todos modos
- Firmar contratos e integrar al empleado
- Darles acceso a sistemas internos sensibles
- Presentarles a sus compañeros de equipo y asegurarse de que todos se lleven bien
- Y luego meses de entrenamiento informal, cuando el empleado necesita entender un servicio o una parte de una base de código heredada
- Y finalmente, empaparlos en la forma de hacer las cosas del equipo
En resumen: mucho trabajo.
Ahora imagina que después de hacer todo eso, el nuevo empleado dice: "Oye, acabo de recibir una oferta más alta de otra compañía. Hasta luego, adiós."
O imagina que el empleado es poco confiable y a menudo llega horas después de que ha comenzado la jornada laboral.
O imagina que el empleado tiene problemas con adicciones no tratadas a las drogas, alcohol o juegos de azar, problemas de ira, o simplemente resulta ser una persona pasivo-agresiva que socava al equipo.
Ahora tienes que comenzar todo este proceso de nuevo 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 pasarán por alto a candidatos aparentemente calificados hasta que encuentren a alguien de quien se sientan un 99% seguros.
Porque los empleadores son tan adversos al riesgo, los solicitantes de empleo sufren
Ahora, si piensas que contratar es difícil, espera hasta que escuches sobre el proceso de solicitud de empleo. Puede que ya estés demasiado familiarizado con él. Pero allá vamos...
- Tienes que preparar tu currículum o CV. En el camino, tomarás decisiones que constantemente dudarás a lo largo de tu búsqueda de empleo.
- Tienes que buscar ofertas de empleo en línea, investigar a los empleadores y evaluar si es probable que sean una buena opción para ti.
- 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íes estas solicitudes de empleo, tendrás que esperar mientras el empleador las procesa. Algunos empleadores reciben tantas solicitudes que no pueden revisarlas todas manualmente. (Solo Google recibe 9,000 solicitudes por día). Los empleadores utilizarán software para filtrar las solicitudes. Los reclutadores internos dedican un promedio de 6 segundos a mirar cada currículum. A menudo, tu solicitud ni siquiera será revisada por un humano.
- Lo más probable es que nunca escuches nada 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 de "Hemos decidido 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.
Wow. Así que puedes ver lo pesadilla que es el proceso de contratación para los empleadores, y especialmente para los candidatos.
Pero si te mantienes firme, eventualmente puedes conseguir ofertas. Y cuando llueve, llueve a cántaros.
Aquí hay datos de la búsqueda de empleo de un colaborador de freeCodeCamp durante un período de 12 semanas:
De 291 solicitudes, obtuvo finalmente 8 ofertas.
Y a medida que llegaban las ofertas, el salario inicial aumentaba cada vez más. Toma en cuenta, por supuesto, que esto es para un trabajo en San Francisco, una de las ciudades más caras del mundo.
Para la semana 12, sus ofertas de salario inicial eran casi el doble de lo que eran en la semana 2.
La tasa de este desarrollador para conseguir entrevistas es bastante fuerte. Y su capacidad de negociación 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 entrar a una empresa por la puerta lateral.
Y esa es una de las razones por las que escribí este libro. No quiero que sigas haciendo fila para la puerta principal en 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 estado enseñando técnicas para aumentar tu probabilidad de "tener suerte" con una oferta de trabajo.
"La suerte es el encuentro de la preparación con 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 las 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 un empleo 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 a la capa de software.
Eso significa desarrolladores.
De vez en cuando, puedes escuchar sobre grandes despidos en tecnología. Muchos de estos despidos afectan a empleados que no son desarrolladores. Pero a menudo, muchos desarrolladores también pierden sus empleos.
¿Por qué las empresas despedirían a desarrolladores, después de gastar tanto tiempo y dinero en reclutarlos y capacitarlos? Aparte de una situación de quiebra, no sé la respuesta a esa pregunta. No estoy seguro de que nadie la sepa.
Hay cada vez más pruebas de que los despidos destruyen el valor a largo plazo dentro de una empresa. Pero, en la práctica, muchos directores ejecutivos sienten presión por parte de sus inversores para hacer despidos. Y cuando varias empresas hacen despidos aproximadamente al mismo tiempo, otros directores ejecutivos pueden seguir su ejemplo.
Aún así, incluso con los despidos, la mayoría de los economistas esperan que el número de trabajos para desarrolladores y otros trabajos relacionados con software continúe creciendo. Por ejemplo, el Departamento de Estadísticas Laborales de EE.UU. espera un aumento del 15% en desarrolladores durante la próxima década.
Puede que el mercado de trabajo esté tenso en estos momentos, pero poca gente espera que esta recesión dure.
Mi esperanza es que con habilidades sólidas, una red fuerte y una buena reputación, puedas conseguir un buen trabajo a pesar de un mercado laboral desafiante.
Con suerte, algún día será más fácil para los empleadores y los empleados calificados encontrarse mutuamente, sin el largo y brutal proceso de solicitud y entrevistas de trabajo.
Qué esperar del proceso de entrevista para desarrolladores
Una vez que empieces a conseguir entrevistas de trabajo, experimentarás el temido proceso de entrevista para desarrolladores y la notoria entrevista de codificación.
Un flujo de entrevista típico podría involucrar:
- Realizar una evaluación de codificación en línea de tus habilidades o una "Pantalla Telefónica".
- Y luego, si pasas eso, una segunda entrevista técnica por teléfono o videollamada.
- Y luego, si pasas eso, una entrevista "en el sitio" donde viajas a la oficina de una empresa. Estas generalmente incluyen varias entrevistas con RRHH, gerentes de contratación y desarrolladores con los que podrías trabajar.
A lo largo del camino, te enfrentarás a preguntas que evalúan tu conocimiento en resolución de problemas, algoritmos y estructuras de datos, depuración y otras habilidades.
Tus entrevistadores podrían 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 de pie en una pizarra.
Lo fundamental que debes recordar es que la persona que te entrevista no solo busca una respuesta correcta. También intentan entender cómo piensas.
Quieren saber: ¿entiendes los fundamentos de la programación y la informática? ¿O simplemente estás repitiendo un montón de soluciones que memorizaste?
Practicar algoritmos y estructuras de datos te llevará lejos. Pero también necesitas 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 codificas. O, si te sientes aventurero, haz streaming en vivo de tu codificación.
Hay muchos streams de "codificación en vivo" en Twitch donde las personas "aprenden en público" construyendo proyectos frente a una audiencia. Como un bono, si estás dispuesto a exponerte así, también te ayudará a construir tu reputación como desarrollador.
Otra cosa que recordar durante las entrevistas en pizarra: tu entrevistador. No solo está sentado allí esperando a que termines. Está contigo todo el tiempo, observándote y evaluándote tanto consciente como inconscientemente.
Intenta hacer que el proceso de entrevista sea lo más interactivo posible para tu entrevistador. Sonríe y haz contacto visual ocasional. Intenta juzgar su lenguaje corporal. ¿Están relajados? ¿Asienten con la cabeza mientras explicas puntos?
Tu entrevistador probablemente sabe qué busca en tu código. Así que intenta sacarles algunas pistas. Haciendo observaciones o haciendo preguntas abiertas en voz alta para ti mismo, podrías lograr que tu entrevistador intervenga y se sienta involucrado en el proceso.
Quieres que tu entrevistador guste de ti. Quieres que te apoyen, para que pudieran pasar por alto algunas de las deficiencias en tus habilidades de programación o algunos de los errores que puedas cometer en tu código.
Estás vendiéndote como un candidato para el trabajo. Asegúrate de que tu entrevistador sienta que está obteniendo un buen trato.
Y lo mismo se aplica a cualquier Entrevista de Comportamiento que tengas que superar. Estas entrevistas tienen menos que ver con tu habilidad de codificación y más con tu "encaje cultural". (Desearía poder decirte qué significa esto, pero cada gerente lo definirá de una manera ligeramente diferente).
En estas Entrevistas de Comportamiento, tendrás que convencer a tu entrevistador de que tienes fuertes habilidades de comunicación.
Definitivamente ayuda ser fluido en el idioma en el que estás entrevistándote y conocer la jerga adecuada. Puedes aprender mucho de esto escuchando regularmente podcasts de tecnología, como el Podcast de freeCodeCamp.
Una gran cosa que tus entrevistadores están tratando de establecer: ¿eres una persona tranquila que se lleva bien con los demás? La mejor manera de mostrar esto es ser cortés y abstenerse de usar profanidades o desviarse demasiado del tema en cuestión.
No quieres entrar en un debate sobre algo no relacionado, como una rivalidad deportiva. También recomiendo no intentar corregir a tus entrevistadores, incluso si dicen cosas que crees que son tontas o falsas.
Si sientes malas vibraciones por parte de la empresa, no tienes que aceptar su oferta de trabajo. Los empleadores rechazan a los candidatos todo el tiempo. Y tú, como candidato, también tienes el derecho de rechazar a un empleador. La entrevista en sí probablemente no sea el mejor momento para un conflicto.
¿Debería negociar mi salario en mi primer trabajo como desarrollador?
Intentar negociar tu salario hacia arriba generalmente no hace daño siempre y cuando lo hagas con cortesía.
He escrito extensamente sobre cómo negociar el salario de tu oferta de trabajo como desarrollador.
Esencialmente, negociar un salario inicial más alto se reduce a cuánto apalancamiento tienes.
Tu empleador tiene trabajo que necesita ser hecho. ¿Cuánto necesita tu empleador que trabajes para ellos? ¿Qué otras opciones tienen?
Y tú necesitas ingresos para sobrevivir. ¿Qué otras opciones tienes? ¿Cuál es tu plan de respaldo?
Si tienes una oferta de trabajo de otro empleador que te ofrece pagarte una cierta cantidad, puedes usar eso como apalancamiento en tu negociación salarial.
Si tu mejor plan de respaldo es volver a estudiar y obtener un título de posgrado... no es una baza especialmente fuerte, pero es mejor que nada. Y podrías mencionarlo durante el proceso de negociación salarial.
Piensa en el largo proceso de contratación que describí anteriormente. Los empleadores deben pasar por al menos una docena de pasos antes de poder llegar a la etapa de oferta de trabajo con los candidatos. Probablemente ya están planeando que negocies, y no se sorprenderán por ello.
Ahora bien, si te encuentras en una situación como la mía donde una empresa te ofrece un trabajo de la nada, puede que te sientas incómodo al intentar negociar.
Smithers de Los Simpson
Voy a admitir – en la historia que conté antes, cuando mi gerente me ofreció el trabajo, no negocié.
En retrospectiva, ¿debería haber negociado mi compensación? Probablemente.
¿Tenía apalancamiento? Probablemente no mucho. Mi plan de respaldo era seguir compitiendo en hackatones y seguir tomando té y codificando en la biblioteca pública.
Tal vez podría haber negociado y obtenido unos cuantos dólares más por hora. Pero en el momento en que me ofrecieron el trabajo, la compensación era lo último en mi mente. Estaba simplemente eufórico de que iba a ser un desarrollador profesional.
Por cierto, una vez que has trabajado como desarrollador en una empresa durante un año o más, es posible que desees pedir un aumento. He escrito extensamente sobre cómo pedir un aumento como desarrollador. Pero todo se reduce a lo mismo: apalancamiento.
¿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 hacerlo.
He escrito extensamente sobre por qué los reclutadores son una herramienta subestimada en tu caja de herramientas.
Muchos empleadores pagarán a los reclutadores una tarifa de búsqueda por enviarles candidatos de alta calidad.
Los incentivos de los reclutadores están bien alineados con tus propios objetivos como buscador de empleo:
- Dado que se les paga basado en tu salario inicial, están inclinados a ayudarte a negociar un salario inicial lo más alto posible.
- Cuantos más candidatos ubiquen, y cuanto más rápido los ubiquen, 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.
- Dado que solo se les paga si tienes éxito como empleado (y te quedas al menos 90 días), intentarán asegurarse de que eres competente y de que encajas bien con la cultura de la empresa.
Dicho esto, si un reclutador te pide que le pagues dinero por cualquier cosa, eso es una señal de alerta.
Y no todos los reclutadores son iguales. Haz tu investigación antes de trabajar con un reclutador. Incluso si al final les paga el empleador, aún estás invirtiendo tu tiempo en ayudarles a ubicarte. Y el tiempo es valioso.
Hablando de tiempo, una manera en la que puedes empezar a cobrar por programar más pronto – incluso mientras te preparas para la búsqueda de empleo – es conseguir algunos clientes como freelance.
Cómo conseguir clientes freelance
Animo a los nuevos desarrolladores a intentar conseguir algunos clientes freelance antes de comenzar su búsqueda de empleo. Hay tres buenas razones para esto:
- Es mucho más fácil conseguir un cliente freelance que un trabajo a tiempo completo.
- El trabajo freelance es menos arriesgado ya que puedes hacerlo sin renunciar a tu trabajo diario.
- Puedes empezar a cobrar por programar más pronto y comenzar a construir tu portafolio de trabajo profesional más pronto.
Conseguir clientes freelance puede ser mucho más fácil que conseguir un trabajo como desarrollador. ¿Por qué es esto?
Piensa en los pequeños negocios locales. Puede ser solo una familia que maneja un restaurante. O una tienda. O una empresa de fontanería. O un bufete de abogados.
¿Cuántos de esos negocios podrían beneficiarse de tener un sitio web interactivo, sistemas de gestión de back office y herramientas para automatizar sus flujos de trabajo comunes? La mayoría de ellos.
Ahora, ¿cuántas de esas empresas 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 hacer el trabajo de una manera más económica, en una base de caso por caso. Un pequeño negocio puede contratar a un freelancer para un solo proyecto, o por un período de tiempo más corto.
Si estás construyendo activamente tu red, 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 capacidad para programar una consulta, o aceptar un pago con tarjeta de crédito para una factura. Estas son características comunes que los pequeños negocios pueden solicitar, y puedes volverte bastante bueno en implementarlas.
También puedes conocer a gerentes de pequeños negocios que necesiten un sistema ERP, o un sistema CRM, o un sistema de inventario, o una de las innumerables otras herramientas.
En muchos casos, hay una herramienta de código abierto que puedes implementar y configurar para ellos. Luego puedes simplemente enseñarles a usar ese sistema. Y puedes cobrarles una tarifa mensual de servicio para estar "de guardia" y listo para solucionar problemas que puedan surgir.
¿Debería usar un contrato para el trabajo freelance?
Querrás encontrar una plantilla de contrato estándar, personalizarla y hacer que un abogado la apruebe.
Puede sentirse incómodo hacer que la panadería local firme un contrato contigo solo para ayudar a actualizar su sitio web o su presencia en redes sociales. Pero al hacerlo, hará que toda la transacción se sienta más profesional que un mero acuerdo verbal.
Es poco probable que un pequeño negocio te lleve a los tribunales por unos pocos miles de dólares. Pero en caso de que esto suceda, estarás feliz de haber firmado un contrato.
¿Cuánto debo cobrar por un trabajo autónomo?
Tomaría lo que gana en su trabajo diario, calcularía su tarifa por hora y la duplicaría. Esto puede sonar como mucho dinero, pero el trabajo independiente es mucho más difícil que el trabajo regular. Tienes que aprender mucho.
Alternativamente, podrías simplemente cobrar por proyecto. "Desplegaré y configuraré este sistema para ti por $1,000".
Solo asegúrate de especificar un plazo en el que estés dispuesto a mantener el proyecto. No querrás que la gente te llame 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 –incluyéndome a mí– usan este enfoque simple: pedir la mitad de tu compensación por adelantado, antes de comenzar el trabajo. Y cuando puedas demostrar que estás a medio camino, pide la otra mitad.
Siempre intenta obtener todo el dinero antes de terminar realmente el proyecto. De esa manera, el cliente no podrá colgarte el dinero sobre la cabeza y tratar de obtener trabajo extra de ti.
Si ya te han pagado en su totalidad, el trabajo que realices para ayudar a tu cliente después transmitirá: "Estoy yendo más allá por ti."
Lo cual es una vibra totalmente diferente de: "Uh oh – ¿vas a pagarme siquiera por todo este trabajo que estoy haciendo?"
¿Debería usar un sitio web freelance como Upwork o Fiverr?
Si estás en una zona rural del mundo y no puedes encontrar clientes locales, podrías probar algunos de estos sitios web freelance. Pero de lo contrario, no me enfocaría en ellos. Aquí está por qué:
Cuando intentas conseguir contratos en un sitio web freelance, estás compitiendo con todos los freelancers del mundo. Muchos de ellos vivirán en ciudades que tienen un costo de vida mucho menor que el tuyo. Algunos de ellos ni siquiera se preocuparán realmente por sus reputaciones como tú, y pueden estar dispuestos a entregar trabajo de baja calidad.
En cierta medida, estos sitios web promueven un fenómeno de "carrera hacia el fondo" 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 del extranjero.
Y lo mismo vale para las personas que buscan ayuda de desarrolladores freelance. Si alguna vez quieres contratar a un freelancer, recomiendo encarecidamente trabajar con alguien con quien puedas reunirte en persona, que tenga lazos con tu comunidad.
Alguien que haya vivido en tu ciudad durante varios años y asista a muchas de las mismas reuniones sociales que tú: será mucho menos probable que trate de aprovecharse de ti. Si tanto tú como tu contraparte se preocupan por su reputación, ambos estarán comprometidos en una asociación que funcione.
Cada uno puede ser una historia de éxito en el portafolio del otro.
El trabajo freelance es como dirigir una empresa unipersonal. 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, puede que desees crear tu propia entidad legal.
En EE. UU., el enfoque más común es crear una Compañía de Responsabilidad Limitada (LLC) y realizar negocios como esa empresa, incluso si eres la única persona trabajando allí.
Esto puede simplificar tus impuestos. Y si, Dios no lo quiera, cometes un error y un cliente te demanda, tu entidad legal puede ayudarte a aislarte de la responsabilidad personal, de modo que sea tu LLC la que entre en bancarrota, no tú personalmente.
También puedes considerar obtener un seguro de responsabilidad para protegerte aún más contra esto.
Recuerda que cuando trabajas freelance, usualmente tienes que pagar impuestos al final del año, así que asegúrate de ahorrar para esto.
Para crear tu LLC, por supuesto, 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 especializado en pequeñas empresas y/o un contador para asegurarte de configurar todo correctamente.
¿Cuándo debería dejar de trabajar freelance y comenzar a buscar un trabajo?
Si puedes pagar tus cuentas trabajando freelance, es posible que solo quieras seguir haciéndolo. Con el tiempo, incluso podrías crear tu propia agencia de desarrollo de software y contratar a otros desarrolladores para que te ayuden.
Dicho esto, si anhelas la estabilidad de un trabajo como desarrollador, podrías tener 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 tarifa por hora más baja. Obtendrás la estabilidad de una semana laboral de 40 horas y ellos obtendrán tus habilidades a tiempo completo.
También puedes retener a 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 completamente absorbente. Al menos al principio.
¿Qué tan agitado va a 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 el puerto está seguro. Pero ese no es el propósito de los barcos." – Grace Hopper, matemática, Contraalmirante de la Marina de EE. UU., y pionera en ciencias de la computación
Una vez que consigas tu primer trabajo como desarrollador, es cuando el verdadero aprendizaje comienza.
Aprenderás cómo trabajar productivamente junto a otros desarrolladores.
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 a trabajar bajo las órdenes de un gerente de ingeniería. Cómo entregar antes de la fecha límite. Y cómo manejar una gran cantidad de ambigüedades en el trabajo.
Lo más importante, aprenderás a gestionarte a ti mismo.
Aprenderás a superar barreras psicológicas que nos afectan a todos, como el síndrome del impostor. Conocerás tus límites y cómo empujarlos ligeramente más allá.
Hora de la Historia: ¿Cómo tuvo éxito un profesor de unos 30 años en su primer trabajo como desarrollador?
La última vez en Hora de la Historia: Quincy consiguió su primer trabajo como desarrollador en una startup tecnológica local. Iba a trabajar como uno de una docena de desarrolladores manteniendo una base de código grande y sofisticada. Y no tenía idea de lo que estaba haciendo...
Me desperté a las 4 a.m. y no pude volver a dormir. Lo intenté. Pero tenía una sensación ardiente en el pecho. Esta ansiedad. Pánico.
Había trabajado durante una década en educación. Primero como tutor. Luego como profesor. Y más tarde como director de una escuela.
En unas pocas horas, estaría comenzando de nuevo desde lo más bajo, trabajando como desarrollador.
¿Importarían en esta nueva carrera algunas de mis experiencias pasadas, incluso mis éxitos?
Hice lo que siempre hago cuando siento ansiedad: salí a correr. Descendí corriendo las colinas, con mi linterna moviéndose en la oscuridad. Cuando llegué a la playa, corrí junto al océano mientras el sol se asomaba por la cima de los árboles.
Para cuando llegué a casa, mi esposa ya estaba saliendo para trabajar. Me dijo que no me preocupara. Dijo: "Te seguiré queriendo incluso si te despiden por no saber lo que estás haciendo."
Cuando llegué a mi nueva oficina, no había nadie allí. 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é con las piernas cruzadas en el pasillo de entrada, codificando siguiendo tutoriales en mi netbook.
Una empleada se me acercó con una expresión nerviosa. Probablemente pensó que era un okupa. Pero la tranquilicé diciéndole que ahora trabajaba en su empresa, y la convencí de que me dejara pasar.
Se sintió surrealista caminar por la oficina, de diseño abierto y vacía, hacia el área de desarrolladores, guiado solo por la luz del letrero de salida.
Instalé mi netbook en un escritorio de pie vacío y terminé mi tutorial de codificación.
Un poco después, las luces se encendieron a mi alrededor. Mi jefe había llegado. Al principio no reconoció mi presencia. Solo se sentó en su escritorio y comenzó a teclear con furia en su teclado mecánico.
"Larson", finalmente dijo. "¿Listo para tu gran primer día?"
No lo estaba. Pero quería transmitir confianza. Así que dije las palabras que se pronuncian por primera vez en Big Trouble in Little China, una de mis películas favoritas de los 80: "Nací listo."
Probablemente has oído "Nací listo" un millón de veces. Pero se pronunció por primera vez en 1986 por Jack Burton a su amigo Wang Chi, cuando se preparaban para enfrentar a un mago de mil años en su almacén de muerte. No puedo creer que mis padres me dejaran ver esto en aquel entonces, pero me alegro de que lo hicieran.
"Genial", dijo mi jefe. "Vamos a conseguirte una máquina."
"Oh, ya tengo una", dije, tocando mi netbook de $200. "Este bebé está ejecutando Linux Mint, y ya he personalizado mi archivo .emacs para poder..."
"Somos una empresa que usa Mac", dijo caminando hacia un armario de almacenamiento. Revolvió por un momento y salió. "Aquí. Es un modelo de 3 años, pero debería servir. Lo dejamos en su configuración de fábrica."
Comencé a decir que ya estaba familiarizado con mi configuración y que podía trabajar mucho más rápido con ella, pero él no quiso saber nada de eso.
"Todos usamos las mismas herramientas. Hace que colaborar sea mucho más fácil. Convención sobre configuración, ya sabes."
Esa fue la primera vez que escuché la frase "convención sobre configuración", pero aparecería mucho durante los próximos días.
Pasé las siguientes horas configurando mi nueva computadora de trabajo mientras otros desarrolladores iban llegando gradualmente.
Eran casi las 10 a.m. cuando comenzamos nuestra "reunión de pie" del equipo. Todos nos poníamos de pie en círculo junto a la pizarra. Nos turnábamos para informar sobre lo que estábamos trabajando ese día.
Todos daban actualizaciones rápidas y precisas.
Cuando fue mi turno, empecé a presentarme. Ya estaba bastante ansioso, cuando entró nada menos que Mike, ese tipo ultramaratonista que dirigía los eventos de startups en Santa Bárbara. Estaba masticando algunas zanahorias baby, habiendo corrido ya unos 30 kilómetros esa mañana.
Después de que terminé, 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 alguna característica en la que estaba trabajando.
Toda la reunión solo duró unos 10 minutos, y todos se dispersaron de vuelta a sus escritorios.
Finalmente logré que la base de código de la empresa funcionara en mi nuevo portátil. Era una aplicación de Ruby on Rails que había crecido durante 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 alguna vez?
Mi vecino, un desarrollador barbudo y gruñón, dijo: "Eh, la mayor parte de eso son solo paquetes. La base de código real en la que trabajarás tiene solo unas 100,000 líneas. No te preocupes. Le cogerás el tranquillo."
"Me llamo Nick, por cierto", dijo, presentándose. "Si necesitas alguna ayuda, solo házmelo saber. He estado dando tumbos en esta base de código durante bastantes años, así que debería poder ayudarte."
Durante los próximos días, llené a Nick de preguntas sobre cada sistema interno que encontraba.
Eventualmente, Nick comenzó a poner su estado de chat en "modo código" y a ponerse sus auriculares con cancelación de ruido. Giraba un poco su espalda hacia mí, con el lenguaje corporal de: "déjame en paz para que pueda hacer algo de 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 cosas por ti mismo.
Pero esta era una base de código enorme, y estaba en gran parte sin documentación, aparte de comentarios en línea y un wiki de equipo bastante escaso.
Dado que era una base de código de fuente cerrada en la que solo los desarrolladores a mi alrededor estaban trabajando, no podía usar Stack Overflow para averiguar dónde se encontraba alguna lógica en particular. Solo tenía que tantear en la oscuridad.
Comencé a rotar a cuál vecino molestaría con una pregunta en particular. Pero sentía que rápidamente agotaba cualquier entusiasmo que pudieran haber tenido por mí como compañero de equipo.
Me sobrecorregí. Me volví tímido para hacer incluso preguntas simples. Me hice una regla de intentar durante 2 horas desatascarme antes de pedir ayuda.
En algún momento, después de luchar durante varias horas, pedí ayuda. Cuando mi gerente descubrió que había estado atascado toda la mañana, me preguntó: "¿Por qué no pediste ayuda antes?"
Otra lucha fue entender la base de código en sí: el "monolito" y sus muchos microservicios.
La base de código tenía miles de pruebas unitarias y de integración. Siempre que escribías una nueva contribución de código, también se suponía que debías escribir pruebas. Estas pruebas ayudaban a asegurar que tu código hiciera lo que se suponía que debía hacer y que no rompiera ninguna funcionalidad existente.
Frecuentemente "rompía la compilación" al enviar código que pensaba que estaba suficientemente probado, solo para que mi código rompiera alguna 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 de raíz se hubiera solucionado.
La compilación se rompía varias veces a la semana. Y no era el único 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 desarrollador. Me decía a mí mismo: "¿A quién engaño? ¿Solo me despierto un día y decido que voy a ser desarrollador?"
Seguía escuchando ecos de todas esas cosas que mis amigos desarrolladores me habían dicho un año antes, cuando estaba empezando mi viaje de codificación.
"¿Cómo vas a competir con personas que empezaron a codificar desde una edad temprana?"
"Vas a tener que beberte un océano entero de conocimiento."
"¿Por qué no te quedas con lo que eres bueno?"
Tomaba descansos cada vez más largos para alejarme de mi computadora. La oficina tenía una cocina llena de bocadillos. Encontraba más excusas para levantarme a por un bocadillo. Cualquier cosa para retrasar la aplastante sensación de que no tenía idea de lo que estaba haciendo.
Los primeros meses fueron duros. Durante las reuniones matutinas de pie, sentía que todos se estaban moviendo rápido. Cerrando errores abiertos y lanzando funcionalidades. Sentía que no tenía nada que decir. Aún estaba trabajando en la misma funcionalidad del día anterior.
Cada día cuando me despertaba y me preparaba para ir a trabajar, sentía temor. "Este va a ser el día en que me despidan."
Pero luego iba al trabajo y todos eran bastante amables, bastante pacientes. Pedía ayuda si estaba realmente atascado. Hacía algo de progreso, y tal vez arreglaba uno o dos errores.
Estaba mejorando en navegar por la base de código. Estaba mejorando en leer rastros de pila cuando mi código fallaba. Estaba lanzando funcionalidades a un ritmo más rápido que antes.
Siempre que mi jefe me llamaba a su oficina, pensaba para mí mismo: "Oh no, tenía razón. Hoy me van a despedir." Pero solo me asignaba más errores para arreglar o funcionalidades para desarrollar. Menos mal.
Era lo más surrealista: yo, aterrorizado, pensando que me iban a despedir, y él sin tener idea de que algo estaba mal.
Por supuesto, había escuchado el término "síndrome del impostor" antes. Pero no me daba cuenta de que eso era lo que estaba experimentando. Seguramente solo estaba sufriendo de "síndrome del 'soy malo programando'", ¿verdad?
Un día estaba sentado junto a Nick, y él parecía bastante frenético. Me ofrecí a traerle un refresco de la cocina.
Cuando volví, abrió la lata, tomó un sorbo, y se recostó en su silla, mirando su monitor lleno de código. "Este error, hombre. Tres semanas tratando de arreglar este maldito error. A estas alturas lo estoy depurando en mis sueños."
"¿Tres semanas tratando de arreglar el mismo error?" pregunté. Nunca había escuchado algo así.
"Algunos errores son más difíciles de romper que otros. Este es uno de esos realmente astutos."
Se sintió como si alguien me hubiera abofeteado con un salmón. Había visto mi trabajo como trozos de tareas. Como si debería tardar medio día en arreglar un error, y si tardaba más que eso, estaba haciendo algo mal.
Pero aquí estaba Nick, con su título en informática de la Universidad de California y sus años de experiencia trabajando en esta misma base de código, y llevaba tres semanas atascado en un solo error.
Quizá había sido demasiado duro conmigo mismo. Quizá algunos de esos fallos que había estado arreglando no eran necesariamente "fallos de medio día", sino "fallos de dos o tres días". Sí, era inexperto y lento. Pero aun así, quizá me exigía a mí mismo unos niveles de exigencia poco realistas.
Después de todo, cuando presupuestamos tiempo para las características, a veces tendríamos "características de 5 días" o incluso "características de 2 semanas". No hacíamos esto para los 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ó gran parte de mi ansiedad.
Durante los meses siguientes, seguí desarrollando características para la base de código. Seguí colaborando con mi equipo. Seguía siendo un trabajo duro, que rompía la cabeza. Pero comenzaba a ser un poco más fácil.
Me uní a mis compañeros cada día en el almuerzo con juegos de mesa. Una semana, tuvimos un torneo de ajedrez en toda la empresa.
Un par de rondas después, jugué contra el CEO.
El CEO tiene un estilo de juego de ajedrez poco ortodoxo. Usó una apertura tonta que pocos jugadores serios de ajedrez optarían por usar. Y pude tomar una ventaja temprana en el juego.
Pero en las siguientes jugadas, pudo recuperar lentamente el control del juego. Eventualmente, tomó la ventaja y me ganó.
Cuando le pregunté cómo encontraba tiempo para mantener sus habilidades de ajedrez mientras dirigía una empresa, dijo: "Oh, no lo hago. Solo juego una o dos veces al año."
Luego hizo una pausa por un momento, su mano congelada frente a él, como si se preparara para lanzar una conferencia. Dijo: "Mi tío era un jugador de ajedrez competitivo. Y solo me dio un consejo a seguir: cada vez que tu oponente se mueva, detente y trata de 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 he dado cuenta de que este consejo no solo se aplica al ajedrez. Puedes aplicarlo a cualquier situación adversarial.
Si sigues teniendo que hacer una tarea, deberías automatizarla
Otra lección que aprendí sobre el desarrollo de software: ya que era la persona más junior del equipo, a menudo me asignaban el "trabajo tedioso" que nadie más quería hacer. Una de estas tareas era ser la "niñera de compilación".
Cada vez que alguien rompía la compilación, bajaba la última versión de nuestra rama principal y usaba git bisect para intentar identificar el commit que la rompió.
Abría ese commit, ejecutaba las pruebas y averiguaba qué había salido mal. Luego enviaba un mensaje a la persona que rompió la compilación, diciéndole lo que necesitaba arreglar.
Me volví muy rápido en hacer esto. En un día lleno de informes de errores confusos y solicitudes de características ambiguas, esperaba con ansias que se rompiera la compilación. Me daba la oportunidad de sentirme útil muy rápido.
No pasó mucho tiempo antes de que alguien en el equipo dijera: "Con la frecuencia con la que se rompe la compilación, deberíamos simplemente automatizar esto."
No dije nada, pero me sentí a la defensiva. Esta era una mala idea. ¿Cómo podría un script hacer tan buen trabajo en encontrar el commit culpable como yo, un desarrollador de carne y hueso, podría?
Tomó unos pocos días. Pero ciertamente, uno de mis compañeros de equipo elaboró un script. Y ya no tenía que ser la niñera de compilación.
Se sintió extraño ver un mensaje de que la compilación fallaba, y luego un momento después ver un mensaje diciendo qué commit rompió la compilación y quién necesitaba ir a arreglarlo.
Me sentí indignado. No dije nada, pero en mi mente estaba pensando: "Eso se supone que es mi trabajo. Ese script tomó mi trabajo."
Pero por supuesto, ahora miro hacia atrás a mi reacción y me río. Me imagino a mí mismo, ahora en mis 40, todavía dejando todo varias veces a la semana para poder ser la niñera de compilación.
Porque en la práctica, si una tarea se puede automatizar, si puedes descomponerla en pasos discretos que una computadora pueda realizar de manera confiable por ti, entonces probablemente deberías automatizarla.
Hay un montón de trabajo más interesante que puedes hacer con tu tiempo.
Este gráfico de XKCD puede ayudarte a decidir si vale la pena la inversión de tiempo para automatizar una tarea.
Lecciones de los ancianos del pueblo
Aprendí mucho de otras personas del equipo. Aprendí conceptos de diseño de productos de Mike. Me llevó a correr en la playa y me enseñó cómo correr sobre la parte delantera del pie, donde la parte delantera del pie toca el suelo antes que los talones. Esto es un poco más fácil para las articulaciones.
Y aprendí sobre conceptos de ingeniería de software ágil de Nick. Me ayudó a elegir algunos buenos libros de desarrollo de software de la biblioteca de la empresa. Y hasta me invitó a una fiesta de inauguración de casa, y conocí a sus hijos.
Después de aproximadamente un año de trabajar para la empresa, sentí que era hora de intentar independizarme y construir algunos proyectos relacionados con el aprendizaje en línea. Me senté con el CTO para darle la noticia de que me iba.
Dije: "Estoy agradecido de que me hayan contratado, aunque claramente era el desarrollador más débil de la empresa."
Él simplemente soltó una carcajada y dijo: "Claro, cuando empezaste, eras el peor desarrollador del equipo. Diría que aún eres el peor desarrollador del equipo."
Me quedé allí sonriendo torpemente, parpadeando, sin estar seguro de si estaba simplemente 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é mis cambios de código por el día y entregué mis tickets abiertos. Reinicié mi Mac a la configuración de fábrica y se la entregué a mi manager.
Estreché la mano de mis compañeros de equipo y salí por la puerta al aire del atardecer californiano.
Me puse manos a la obra, buscando contratos de freelance para mantener la luz encendida. Y busqué un apartamento en la zona de la bahía, justo al otro lado del puente del corazón de la tecnología, en South of Market, San Francisco.
Ahora era un desarrollador profesional con un año de experiencia ya a mis espaldas.
Estaba listo para soñar nuevos sueños y hacer nuevos movimientos.
Me dirigí a la tierra de las startups.
Lecciones de mi primer año como desarrollador
Hice muchas cosas bien durante mi primer año como desarrollador profesional. Me doy un B-.
Pero si tuviera la oportunidad de hacerlo todo de nuevo, hay algunas cosas que haría de manera diferente.
Aquí hay algunos consejos. Que estos maximicen tu aprendizaje y minimicen tu sufrimiento.
Deja tu ego en la puerta
Muchas personas que ingresan al campo del desarrollo de software comenzarán desde el nivel más bajo. Un título que podrías tener es "Desarrollador Junior."
Puede ser un poco incómodo tener mediana edad y tener la palabra "junior" en tu título. Pero con algo de paciencia y trabajo duro, puedes superarlo.
Un problema que enfrentaba todos los días era que tenía 10 años de experiencia profesional. No era un empleado de nivel inicial. Sí, era nuevo en el desarrollo, pero tenía bastante experiencia enseñando e incluso gestionando personas. (Había gestionado a 30 empleados en mi trabajo de enseñanza más reciente.)
Y aún así – a pesar de toda mi experiencia laboral pasada – seguía siendo un desarrollador de nivel inicial. Seguía siendo un novato. Un neófito. Un principiante.
Por mucho que quisiera gritar "Solía ser el jefe – no necesito que me cuides" – la verdad es que sí necesitaba cuidadores.
¿Qué pasaría si accidentalmente rompía la producción? ¿Qué pasaría si introducía una vulnerabilidad de seguridad en la aplicación? ¿Qué pasaría si borraba toda la base de datos? ¿O cifraba algo importante y perdía la clave?
Este tipo de desastres ocurren todo el tiempo.
La realidad es que como nuevo desarrollador, eres como un toro en una cristalería, tratando de caminar cuidadosamente, 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 ha ganado tu trabajo o esa vez que el alcalde te dio la llave de la ciudad. (OK, tal vez eso último nunca me pasó.)
No solo porque hará difícil trabajar contigo. Porque te distraerá de la tarea actual.
Durante los primeros meses de mi carrera como desarrollador, usé mis logros pasados como una especie de chupete. "Sí, soy pésimo 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 están en el editor de código, tienes que dejar ir ese yo del pasado. Puedes deleitarte con los logros de ayer esta noche, después de que el trabajo de hoy esté hecho.
Pero por ahora, necesitas aceptar todas las emociones que vienen con ser un principiante de nuevo. Necesitas enfocarte en la tarea actual y hacer el trabajo.
Probablemente solo sea el síndrome del impostor hablando
Casi todos los 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 van a ver lo terrible que es tu código y te expondrán como alguien que no es un "verdadero desarrollador."
En cierto modo, la sensación no desaparece. Siempre está ahí en el fondo de tu mente, lista para asomar la cabeza cuando intentas hacer algo nuevo.
"¿Podrías ayudarme a superar este mensaje de error?" "Em... no estoy seguro de ser la mejor persona para preguntar."
"¿Podrías programar en pareja conmigo para implementar esta función?" "Em... supongo que si no encuentras a alguien más calificado."
"¿Podrías dar una charla en nuestra próxima conferencia?" "Em... ¿yo?"
He conocido a ingenieros senior que aún sufren del síndrome del impostor ocasional, más de una década en su carrera.
Cuando te sientes inadecuado o despreparado, puede ser simplemente el síndrome del impostor.
Claro – si me pasas un bisturí y dices, "ayúdame a realizar una cirugía cardíaca", me sentiría como un impostor. En cierto modo, sentirse superado es totalmente razonable si realmente estás fuera de tu profundidad.
El problema es que si has estado practicando el desarrollo de software, es posible que puedas hacer algo pero aún así sufras inexplicablemente de ansiedad.
No soy doctor. 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 obtengas más práctica y construyas más confianza.
Pero puede aparecer aleatoriamente. No tengo miedo de admitir que a veces siento punzadas de síndrome del impostor cuando hago 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 caigas en el tribalismo
Cuando consigas tu primer trabajo como desarrollador, trabajarás junto a otros desarrolladores. ¡Yupi – encontraste tu tribu!
Pasarás mucho tiempo con ellos, y todos pueden comenzar a sentirse como una unidad muy unida.
Pero no ignores a las personas que no son desarrolladores a tu alrededor.
En mi historia anterior, hablé sobre Mike, el Gerente de Producto que también organizaba eventos de startups. Él era "no técnico". Su conocimiento de la codificación era limitado en el mejor de los casos. Pero me atrevería a decir que aprendí tanto de él como de cualquier otra persona en la empresa.
Puedes trabajar con otras personas de otros departamentos – diseñadores, gerentes de producto, gerentes de proyecto, gente de TI, gente de control de calidad, mercadólogos, incluso personas de finanzas y contabilidad. Puedes aprender mucho de estas personas, también.
No te pongas demasiado cómodo y te especialices demasiado pronto
A menudo doy este consejo a quienes están comenzando su viaje en la programación: "aprende habilidades de programación generales (JavaScript, SQL, Linux, etc.) y luego especialízate en el trabajo".
La idea es que, una vez que entiendas cómo funcionan las herramientas más comunes, puedes luego aprender los equivalentes menos comunes de esas herramientas.
Por ejemplo, una vez que hayas aprendido PostgreSQL, podrás aprender fácilmente MySQL. Una vez que hayas aprendido Node.js, podrás 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 hagan cargo" de cierta API o característica. Y si hacen un buen trabajo con eso, su jefe puede seguir dándoles proyectos similares.
Tú solo te manejas a ti mismo, pero tu jefe maneja a muchas personas. Puede que estén demasiado ocupados para desarrollar una comprensión matizada de tus habilidades e intereses. Pueden comenzar a verte como "la persona XYZ" y simplemente asignarte tareas relacionadas con eso.
Pero tú sabes en qué eres bueno y qué te interesa. Puedes intentar ofrecerte como voluntario para proyectos fuera de tu zona de confort. Si puedes conseguir que tu jefe te asigne estos proyectos, podrás continuar expandiendo tus habilidades y, potencialmente, trabajar con nuevos equipos.
Recuerda: tu jefe puede ser responsable de tu desempeño en tu trabajo, pero tú eres responsable de tu desempeño a lo largo de tu carrera.
Acepta proyectos que cumplan tanto con tu obligación hacia tu empleador, como también te posicionen bien para tus objetivos profesionales a largo plazo.
Epílogo: Tú puedes hacerlo
Si hay un mensaje con el que quiero dejarte aquí, es este: tú puedes hacerlo.
Tú puedes aprender estos conceptos.
Tú puedes aprender estas herramientas.
Tú puedes convertirte en un desarrollador.
Luego, en el momento en que alguien te dé dinero para que les ayudes a codificar algo, te graduarás como un desarrollador profesional.
Aprender a programar y conseguir un primer trabajo como desarrollador es un proceso desalentador. Pero no te desanimes.
Si te mantienes firme, eventualmente tendrás éxito. Es solo cuestión de práctica.
Construye tus proyectos. Muéstraselos a tus amigos. Construye proyectos para tus amigos.
Construye tu red. Ayuda a las personas que conozcas en el camino. Lo que va, vuelve. Recibirás lo que te corresponde.
No es demasiado tarde. La vida es larga.
Mirarás hacia atrás en este momento en los próximos años y estarás contento de haber tomado una decisión.
Planifica que te llevará mucho tiempo. Planifica para la incertidumbre.
Pero por encima de todo, sigue regresando al teclado. Sigue asistiendo a eventos. Sigue compartiendo tus logros con tus amigos.
Como dijo Lao Tsu, el Viejo Maestro, una vez:
"Un viaje de mil millas comienza con un solo paso."
Al terminar este libro, ya has dado un paso. Vaya, puede que ya hayas dado muchos pasos hacia tus objetivos.
El impulso lo es todo. Así que mantén ese impulso hacia adelante que ya has construido durante estas últimas horas con este libro.
Comienza a codificar tu próximo proyecto hoy.
Y siempre recuerda:
Tú puedes hacerlo.