Café con Tech

Leadership and Technical Writing with Karl L. Hughes

August 23, 2021 Matias Hernández / Karl L. Hughes Season 3 Episode 6
Café con Tech
Leadership and Technical Writing with Karl L. Hughes
Show Notes Transcript

For today's episode, I had the opportunity to talk with Karl L. Hughes, currently the CTO of Draft.dev.
Karl tells us about his interesting background and experience that led them to create and run Draft.dev.
During the episode, you'll find insight into why writing is a good skill for any developer and ideas and experience around managing teams, learning how to learn, and more.

Find more from Karl by following him on Twitter,  checking his site at https://www.karllhughes.com/, and subscribing to his newsletter, the Portable CTO

Music Credits
Opening and Outro Music
by DanoSongs https://danosongs.com/
Background Music Music:
Cool Rock by Kevin MacLeod Link: https://incompetech.filmmusic.io/song/3925-iron-bacon License: https://filmmusic.io/standard-license



Auth0
Auth0 es una plataforma de autenticación y autorización lista para usar en tu app!

Cloundinary MDE
Energizing a diverse community of developers to share knowledge using media technology in web apps.

Escuela Frontend
Conviértete en un Frontend Dev Profesional Contenido de alta calidad para mejorar tu carrera!

Support the show (https://www.buymeacoffee.com/matiasfha)

Español

 [00:00:00] Matias: Bienvenido de nuevo a un nuevo episodio de Café con Tech conmigo es el propio CTO portátil Karl Hughes se unió a nosotros como invitado para hablar de tipo de historia de la carrera y la escritura técnica. Así que bienvenido. Karl, gracias por estar aquí. 

[00:00:15] Karl: Sí, gracias por recibirme Matías. Es un, es un. placer, Me alegro de conocerte finalmente fuera de Twitter. Creo que hemos, hemos interactuado allí varias veces, lo cual es divertido, pero siempre es agradable llevar eso a un bien cara a cara en 

[00:00:26] Matías: Sí. Bienvenidos a mi casa, a mi podcast. Gracias por estar aquí. Vamos a empezar esto pidiéndote un poco de biografía, como una presentación de ti mismo y por qué dije lo de CTO portátil.

[00:00:41] Karl: Claro. Así que sí, mi experiencia es que he sido un ingeniero de software y más recientemente gerente de ingeniería y CTO en algunas pequeñas empresas tecnológicas financiadas en el área de Chicago. Así que he estado haciendo eso. He estado haciendo eso durante unos ocho o nueve años, creo que hasta el año pasado. Y luego dejé mi último trabajo para iniciar una empresa llamada draft.dev.

Y podemos entrar en el borrador y todo eso sobre la marcha. Pero sí, mi formación es en ingeniería de software. Fui un ingeniero práctico durante unos años. Me cayó una especie de líder de un equipo de ingeniería y me gustó mucho el lado de liderazgo. Y por eso dirijo un boletín de noticias, como el que mencionaste llamado el CTO portátil y sí, eso ha sido una especie de acompañamiento a mi blog durante años.

Y es una salida, otra salida para escribir, ya sabes, estás en la escritura y así. Ya sabes que es bueno tener estas diferentes salidas. Y así, sí, tengo la escritura de trabajo, pero también tengo mi tipo de, para la escritura de la diversión en el lado y me gusta tener una mezcla de ambos

[00:01:41] Matias: Es divertido. Es una especie de nicho y tengo que empezar a escribir más y más y más. Así que a veces el blog en sí es como muy pequeño para, seguir escribiendo o para moverse por otras áreas. Así que, sí. Y lo que la gente puede encontrar en el CTO portátil diferente de su blog. 

[00:02:00] Karl: tenía es, es una mezcla. Yo, lo que hago es cada semana, básicamente curar los enlaces y las ideas que encuentro en torno a la Internet relacionados con la ingeniería de software, gestión de startups, y el tipo de cualquier cosa en la intersección de esas tres cosas. Esos son una especie de mis tres. No sé, los puntos fuertes de los pilares o las cosas que he tratado de conseguir bastante bueno en el año.

Y luego siempre incluyo una especie de resumen original o una introducción a algunos de los temas que, que he vinculado más enlaces en el boletín. Así que por lo general es de unas 500 palabras. Esto es lo que estoy pensando esta semana y luego un montón de enlaces y, ya sabes, es divertido porque recibo, recibo respuestas a esos de vez en cuando de la gente que tiene tal vez algo que añadir o hablar de allí.

Y, ya sabes, el correo electrónico es, está volviendo como un medio porque es, es mucho más personal en algunos aspectos que las redes sociales. Y, y sólo se siente como usted consigue el control total sobre su, su alimentación de correo electrónico, donde los medios de comunicación social alimenta mucho más difícil de conseguir ese mismo nivel de control.

[00:02:57] Matías: Oh respuestas que son tan buenas. En las redes sociales, tienes tantas respuestas que no son realmente respuestas. Es una especie de compromiso es raro. Yo también he estado escribiendo una newsletter. Y para ser honesto, las respuestas son difíciles. Nunca recibí una, pero creo que es más fácil que la gente responda allí porque primero no tienes que preocuparte por el spam ni por los comentarios raros, sino que la gente que lee tu boletín es porque lo quiere.

No se trata de una persona al azar en tu feed. 

[00:03:32] Karl: Correcto. Sí. Muchos de ellos son amigos personales o gente que he conocido en la vida real en mi red, ya sabes, y creo que eso es una especie de, eso es divertido porque es casi una forma extra para ellos para mantenerse al día con lo que estoy haciendo, lo que tal vez no trabajamos juntos más, pero nosotros, por lo que no se ven de la misma manera.

Sabes, Facebook ya no es tan genial. No sé, en mis círculos. Así que creo que el boletín de noticias es el reemplazo de ese tipo de red social de baja tecnología en cierto modo.

[00:03:56] Matias: es fan porque mencionaste a Facebook. El otro día, estaba hablando con mi esposa y Facebook caer en el usuario de edad avanzada de alguna manera. Y luego tenemos este otro tic-tac y otras áreas que no es para mí, por lo menos, porque yo en una especie de medio y lo que está en el medio, Twitter

por lo que Twitter es una especie de cosa que estaba leyendo su feed en twitter. Y encontré un enlace a la entrevista. ¿Tenías un "no CS degree.com"? Eso es un sitio que hablar y hablar y hacer las cosas para las personas que no tienen grado CS para subir de nivel sus carreras. Y en realidad, hay una buena historia allí que es realmente larga.

Y en realidad voy a dejar el enlace en las notas del programa porque es realmente en todo su, su experiencia. Una cosa que me llamó la atención es cómo se aprende a codificar. La mayoría de las personas que no tienen un título en ciencias de la computación aprenden a codificar por necesidad o porque les gusta, pero actualmente, la mayoría de ellos lo hacen a través de campamentos de iniciación o a través de videos de YouTube o cursos de YouTube o Udemy o lo que sea, pero tú te fuiste por otro agujero de conejo así que puedes, puedes, puedes conducirnos? 

[00:05:16] Karl: Sí. Así que la historia de fondo es que fui a la universidad. Estudié ingeniería mecánica, porque sabía que me gustaba el hecho de averiguar cómo funcionan las cosas y ayudar a construirlas. Así que sabía que quería hacer algo en la construcción de las cosas y la ingeniería era un buen, un buen camino para eso. Hice algunas prácticas en ingeniería mecánica y fue muy aburrido y lento.

Un montón de grandes empresas, ya sabes, es difícil. No hay muchas startups en el espacio de la ingeniería mecánica, porque es una, una industria antigua. Mientras que la ciencia de la computación y la ingeniería es una gran cantidad de nuevas empresas jóvenes, pero yo ya estaba como un par de años en la universidad y yo soy como, no voy a empezar un grado más, ya sabes, yo no, no tengo la paciencia para eso.

Así que decidí que sólo, ya sabes, en el lado, obviamente, estudiante de ingeniería mecánica. Hay un pequeño, tenemos un poco de código. Probablemente aprendimos un poco de C y un poco de MATLAB y cosas, pero no lo había hecho en serio hasta el último par de años de la universidad. Y mi motivación era que quería aprender a construir un blog del campus.

Y así conseguí ir con 20 o 30 amigos. Monté un sitio de WordPress. Empecé a querer añadir todas estas características personalizadas y cosas, y me di cuenta de que tendría que aprender más y más código. Y es como si fuera divertido. Aprendí pensando, sería genial si pudiera construir X y luego me di cuenta de cómo hackearlo.

Y quiero decir que el código era terrible. Era desordenado. No estaba haciendo las cosas de la manera correcta. Como, ya sabes, me tomó años para darse cuenta de que. Es así que para mí, el estímulo fue empezar y ver algo en la pantalla. Y así como lo hice por mí mismo en mi propio, ya sabes, blog del campus, entonces empecé a tomar otros clientes, en su mayoría pequeñas empresas locales que querían sitios de WordPress o algo realmente simple.

Podrían actualizarse. Y yo sólo les decía, ya sabes, "Oye, te construiré un sitio web para mí, unos pocos miles de dólares o algo así". Y yo no tenía idea de cuánto tiempo estos proyectos tomaría. Yo sólo. Me pagarán un poco y voy a trabajar durante un mes y sólo averiguar cómo hacerlo, ya sabes, o dos meses o lo que sea.

Y no necesitaba mucho para vivir de todos modos. Así que fue como, Poner este plazo en mí mismo, como tengo que aprender a construir X y ahora sé, ya sabes, tengo que construirlo. Esta gente me está pagando, así que vamos a resolverlo. Y entonces trabajaba hasta tarde y resolvía las cosas. Así que no recomiendo, no recomiendo este enfoque para todos.

Pero sabes, no había como mencionas. No había Bootcamps como los de ahora, al menos no en Tennessee, de donde soy. No había lo mismo, como cursos en línea que eran baratos. Tenías que ir a la universidad o simplemente ir a hackear en stack overflow y foros y tratar de averiguar, es decir, había libros, pero siempre estaban irremediablemente fuera de fecha.

Sí. Incluso en ese momento. Así que sí, era un mundo diferente el aprendizaje del desarrollo web, pero creo que ya sabes, lo que me enseñó es como aprender y creo, o cómo aprendo mejor es, no hay una sola manera de aprender las cosas. Y creo que eso es algo que me llevé de esa experiencia, mirando hacia atrás, especialmente.

Aprendí muy bien cuando tengo un proyecto de aprendizaje basado en proyectos. Y creo que eso es parte de la razón por la que no disfruté especialmente de la escuela porque gran parte de la escuela es una especie de rigorgutación, como la memorización y luego empujando las cosas de nuevo a través de, ya sabes, los cálculos, que, ya sabes, siempre, me sentí, yo sólo, me sentí como las computadoras pueden hacer esto ahora.

Como si hubiéramos terminado, debería haber terminado con esto. Quiero, quiero como, buscar cosas y hackear allí y resolverlo de todos modos. Así que esa era mi mentalidad. Y eso es como lo que me llevé de esa experiencia. De todos modos, tengo que salir de la universidad. Conseguí un trabajo. En parte un desarrollador, en parte un gestor de blogs. Era una especie de papel híbrido extraño, pero se ajustaba a lo que había estado haciendo.

Así que 

[00:08:36] Matias: ¿Maestro de la web? ¿Años? Años. ¿Años atrás? Bueno, básicamente estabas saltando. A una piscina vacía cada vez. Eso siempre es difícil. Así que un grito por eso, porque aprender a codificar sin ningún tipo de fondo real en el código es difícil y fue realmente difícil. Pero después de eso, fuiste capaz de mantenerte a flote, cierto. Así que, por ti mismo, tu apalancamiento, tu conocimiento y encuentras este camino que mencionaste que es que aprendiste sobre tu proceso de aprendizaje. Y creo que eso fue hace unos días. Tal vez semanas no puedo recordar. Exactamente. Pero escribiste sobre eso en el boletín, creo que sí.

Estoy, estoy siguiendo a cada invitado que tengo en el programa.

Soy un acosador. 

[00:09:21] Karl: Eso es impresionante.

[00:09:23] Matias: y, y tu escribiste sobre eso y como que me resuena mucho porque aunque es como un tema común, aprender a aprender, todo el mundo dijo, Oye, debes aprender como aprendes es como obvio, pero en algún momento es realmente difícil encontrar cual es tu camino porque hay tanta información, tantos consejos, como estábamos hablando antes, grabando, eso es realmente difícil.

Hablando de consejos, ¿cuál será tu opinión sobre cómo puedes encontrar tu camino? ¿Para otras personas? Así, por ejemplo, soy un, soy un completo principiante y creo que tengo que comprar un curso en. X sitio porque tienen, me ofrecen un camino, una carrera. ¿Qué, qué dirías que significa estás seguro? 

[00:10:09] Karl: Sí. Sí. Yo, esa es una gran pregunta. Es tan situacional, el, ya sabes, dependiendo de cómo aquí es, donde yo, por qué digo que aprender cómo se aprende es tan importante. Si descubres que sólo aprendes, bueno, cuando te ponen en un entorno de grupo y necesitas que otras personas se sienten a tu lado en el ordenador y hagan cosas similares o con las que competir de alguna manera para aprender cosas, entonces deberías encontrar un entorno de aprendizaje que fomente ese tipo de competencia, y que te empuje en un entorno de grupo.

No hay nada malo en eso. Eso es como un que un montón de gente encaja eso. Y creo que muchas personas que lo hacen muy bien en el campamento de entrenamiento, tienden a ser ese tipo de personas que necesitan un grupo, necesitan sentarse con un grupo de personas, tener alguna estructura, y luego cuando lo hacen, ellos, pueden Excel.

Y eso está bien. Si, por el contrario, eres una persona más independiente, como si siempre hubieras escrito o, perdón, hubieras leído libros por tu cuenta y hubieras adquirido tus propias habilidades cuando quisieras. Es ciertamente posible aprender los fundamentos de la programación de computadoras y tal vez incluso los fundamentos de la ciencia de la computación sin un curso académico o un oficial, ya sabes, como un bootcamp o nada.

Así que no hay un camino correcto o incorrecto. Así que no suelo dar a la gente el conjunto. Este es el camino, esto es lo que debes hacer. Pero lo que trato de hacer es ayudar a preguntar, para que la gente, para averiguar como, por qué están diciendo que quieren convertirse en un desarrollador o por qué quieren aprender un programa. Al igual que si su objetivo es sólo para construir algo fresco en el Internet, como usted, usted sólo quiere iniciar una empresa.

Tal vez usted puede encontrar algunos como las herramientas más pequeñas sin código para aprender de modo que usted puede construir una empresa más rápido porque el, el camino para aprender a código es, es bastante difícil. Quiero decir, no lo es. De la noche a la mañana. Así que realmente necesitas algo que te dé el resultado que buscas al final.

Mientras que si por otro lado, tal vez usted está buscando más como un trabajo estable y una buena carrera. Bueno, seguro que la programación informática es eso, pero más vale que te guste la programación porque es un, ya sabes, es mucho tiempo detrás de la pantalla, mucho tiempo sentado y si nunca has trabajado en ese tipo de ambiente, puede ser bastante duro al principio.

Así que creo que se aprende haciendo cosas y, para mí, lo que funcionó fue hacer prácticas. Así que mencioné mi pivote lejos de la ingeniería mecánica. Empecé a hacer prácticas en cuanto pude. Así que después de mi primer semestre de mi primer año, solicité todas las prácticas que pude, tuve un montón de entrevistas y conseguí una oferta, dos ofertas tal vez.

Y, y yo, ya sabes, conseguí unas prácticas muy pronto. Y lo que hizo fue mostrarme lo que era el trabajo real del día a día de un ingeniero mecánico, que no tenía ni idea. Quiero decir, tú, tú, tú aprendes en la escuela y es totalmente diferente del mundo real. Así que creo que salir allí tan pronto como sea posible para aprender, lo que realmente es ser un programador de computadoras o desarrollador y pensar en como el diferente tamaño de las empresas.

Y las diferentes formas en que eso puede afectar a tu carrera. Cómo va a ser tu día a día, cómo vas a ser compensado. Hay muchas variables que tienes que probar y ver lo que funciona para ti antes de tener un buen control sobre ello.

[00:13:02] Matías: Así que busca la exposición tan pronto como puedas. Y entonces podrás aprender si esto es para ti, realmente ser un desarrollador es muy, muy divertido, pero a veces puede ser muy estresante. Así que, sí. 

[00:13:17] Karl: Sí.

[00:13:17] Matías: Entonces, y eso de que trabaja en mi máquina es, no es, ya no. Lo siguiente es que comenzaste, como mencionaste aprendes a aprender, luego vas a las prácticas y luego fuiste capaz de encontrar tu propio camino como desarrollador.

Y ese camino te lleva a ser líder técnico y CTO, y como CTO tenías que ayudar de alguna manera a los juniors. Y entrevistar a los juniors y, tipo de llevarlos y todo eso. Así que primero, ¿cómo fue la experiencia de convertirse en un CTO fue realmente diferente o simplemente ser un buen desarrollador con buenos pensamientos acerca de lo que estás haciendo?

Porque en un equipo siempre hay algún desarrollador que es increíble y todos siguen sus consejos. Y también está el CTO que por, por el rol. La gente sigue sus consejos. Así que es una especie de intercambio. Entonces, ¿cómo fue para ti? 

[00:14:16] Karl: Sí. Definitivamente, nunca diría que soy el mejor desarrollador del mundo. El que otros desarrolladores buscan para todos los consejos, ya sabes, hay situaciones en las que sé lo que estoy hablando, pero en realidad, creo que lo que me di cuenta desde el principio y en mi carrera, un desarrollador de software era que tendía a ser atraído por los roles de liderazgo.

Y creo que esto es lo que ocurre con muchas personas que acaban desempeñando funciones de liderazgo directivo. Tienden a ser atraídos por ellos. No es tanto que, llegan y en su primer año, sólo están apuntando para ello. Es más como. Una oportunidad, una pequeña oportunidad se presenta y dices que sí a ella.

Y eso te da una mayor oportunidad más adelante. Y la gente te ve como la persona que puede pedir esas funciones, o puedes empezar a conocer a otras personas que son como tú, que buscan esas funciones de liderazgo y eso te hace entrar en esa esfera. Así que parece que ocurre de forma orgánica.

Pero ya sabes, tuve, tuve la oportunidad de liderar una startup a la que me había unido al salir de la universidad y que se convirtió en algo divertido. Se llamaba gerente de ingeniería. Yo estaba manejando. Yo y como uno o dos desarrolladores off shore, ya sabes, básicamente era la gestión de mí mismo y luego la comprobación de su código 

[00:15:21] Matias: Sucede. Tan a menudo en el 

[00:15:22] Karl: sí, sí.

En las pequeñas startups, esto es como, ¿qué? Esto es, lo que es tan interesante. Al igual que las pequeñas empresas, que necesitan un, una especie de desarrollador gerente híbrido, y que realmente no puede permitirse un gerente real. Así que muchas veces lo que hacen es contratar a alguien como yo que piensa que podría querer ser un gerente algún día y, y sabe que desarrollar y luego los pone en este papel.

Así que me pusieron en eso. Y a medida que la empresa crecía, era interesante. Mis responsabilidades crecieron con ella. Y así, por el momento en que me fui, yo estaba manejando, ya sabes, todo un equipo de ingenieros y estaba como sentado en las reuniones de liderazgo con los fundadores y las reuniones de inversión y esas cosas. Y así que realmente tengo como esto, ya sabes, Es una especie de sólo por el crecimiento de la empresa, un poco en el lugar correcto en el momento adecuado para seguir la derecha.

Subirse a la ola. Y como, esta es una de las grandes ventajas de trabajar con startups. Si consigues una que crezca rápido, puedes crecer con ella mucho más rápido de lo que lo harías en una carrera típica de una gran empresa. Ya sabes, viene con sus costos que definitivamente no, no tienden a ser pagados tan bien en efectivo.

Muchas veces te dan capital, que puede o no puede ser liquidado. Por lo general, nunca. Y usted sabe, usted puede también tener como tipo de plazos poco realistas de los fundadores, desafiando a la gente a trabajar. Eso es cierto en las grandes empresas también, pero sí, es diferente. Es diferente.

No hay nada bueno o malo de nuevo. Pero me gustó mucho trabajar con las pequeñas empresas y tengo realmente tipo de lugar correcto, el momento adecuado. Me uní a una empresa justo cuando, como, no eran tanque de tiburones, que planteó un montón de dinero. Y así, ya sabes, el equipo de ingeniería creció y yo crecí con él en la cabeza del ingeniero.

[00:16:53] Matias: Sí, hay esta experiencia de convertirse en uno de los primeros ingenieros para poner en marcha y luego, ya sabes, tanto sobre el producto en sí y el código que .

Te conviertes en un líder porque eres el único que sabe que es tu propio bebé. Y como un CTO, cómo tratar con los juniors porque hay una especie de tema en este momento.

Me parece que muchas empresas están contratando seniors por todas partes. Por cierto, no hay una definición real de lo que es un senior, pero sí, los seniors de todos modos, y los juniors que son muchos se quedan atrás de las opciones. Así que las oportunidades se quedan atrás para los juniors, pero en realidad es muy, muy saludable para, para las empresas tener juniors y entrenadores y esas cosas.

¿Cómo va a afrontar el proceso de entrevistas de contratación de jóvenes?

[00:17:46] Karl: Sí. Definitivamente yo también tengo pensamientos sobre las entrevistas, pero lo diré. Sí. Así que para las contrataciones junior, como tú típicamente, será, cada situación como esta, creo que es situacional . Depende. Así que en otras palabras, como no hay como una fórmula para la contratación de X tipo de ingenieros en ciertos tipos de empresas.

Depende totalmente. En mi caso, yo, las dos veces que estuve en una empresa de tecnología educativa y en ambos de esos dos últimos papeles, contratamos a gente junior a menudo porque. De dos cosas. Uno, no teníamos los recursos para contratar siempre a gente senior. No hay como, no habría tenido sentido. Pero entonces el trabajo que teníamos no era siempre tan interesante para la gente senior.

Así que esta es otra cosa que pienso. Muchas startups creen que su trabajo es mucho más interesante de lo que realmente es. Muchas startups siguen construyendo aplicaciones CRUD. Como crud es crear, leer, actualizar, eliminar, o es sólo datos básicos de entrada y salida, ¿sabes? Y claro. Hay como un montón de capas.

Hay una capa de front-end, capa de back-end. En los middlewares hay microservicios, lo que sea, 

[00:18:48] Matías: Hay tantos sobre la ingeniería

[00:18:50] Karl: Sí. Así que sí, definitivamente hay un problema con un poco de ingeniería sobre-ingeniería que ocurre en las empresas de nueva creación y en tal vez todas las empresas, pero especialmente las pequeñas empresas. Pero la otra cosa es que, al igual que los ingenieros senior necesitan y cualquiera que haya estado haciendo esto durante 5, 10, 20 años, necesitan problemas bastante desafiantes para mantenerse estimulados.

Mientras que con la gente junior, quiero decir, recuerdo dar a la gente junior como, Hey, actualizar este foro. Ya sabes, gung ho que son como, oh, tengo que actualizar mi primera forma en un sitio web. Ya sabes, es como emocionante para ellos y es como, el trabajo. No quería hacerlo, pero están felices de hacerlo. Así que hay esto, hay una especie de, usted tiene que mirar a su, el trabajo que tiene y el trabajo que está haciendo regularmente y decir, podría una persona junior aprendido a hacer este tipo de.

Con relativa rapidez. Y si es así, debemos contratar a gente joven porque van a aprender esta parte, y luego van a ir a aprender la siguiente cosa y la siguiente cosa. Así que soy bastante, tal vez no agresivo es la palabra correcta, pero soy bastante alcista en la contratación de personas junior cuando tienes ese tipo de trabajo donde no, no necesariamente se necesita la persona más alta para resolverlo.

[00:19:51] Matías: Alguna opinión sobre el proceso de entrevistas que solíais tener o cómo creéis que son las entrevistas actualmente. 

[00:20:00] Karl: Sí, así que yo, lo que creo que mucha gente hace mal en las entrevistas es no hacerlas en absoluto. Como el trabajo que realmente se va a hacer. Así que mi, esto es como mis experiencias personales de carrera. Cuando muestro a un empleador, lo que puedo hacer y que podría hacer el trabajo que contratan. Y eso es genial. Esa es la situación ideal, pero muchas empresas que hacen entrevistas, te hacen pasar por una especie de aros arbitrarios.

Como, por ejemplo, mostrar que has tenido un historial similar al de los fundadores o la gente que está contratando. Y simplemente no tiene sentido para mí. Así que las cosas como un problema de pizarra, como nunca en mi carrera de ingeniería, 10 años de escribir código. Tuve que sentarme frente a mis compañeros y sin que me ayudaran a resolver un problema en una pizarra, ya sabes, como que hay un elemento de colaboración a como sentarse en frente de una pizarra y todos hablamos de un problema juntos.

Claro. Pero como nada de una situación de estilo de entrevista. Así que, básicamente, estás pidiendo a un ingeniero en una entrevista que haga algo completamente diferente de lo que haría en la vida real. No tienen su IDE frente a ellos. Ellos no tienen Google en frente de ellos. Como, así que creo que es. Ya sabes, hay un problema de toma, pero en el otro extremo del espectro, como los proyectos para llevar a casa tienen su propio tipo de problemas también.

Están pidiendo mucho trabajo gratis a alguien. Así que creo que está bien. Un poco mejor si estás pagando a la gente o, ya sabes, algo de tiempo para hacer ese tipo de trabajo. Lo que hice, sin embargo, fue una especie de reunión en el medio aquí. Lo haría. Invitar a los, como, tipo de última fase de la ingeniería o de nuestras entrevistas de ingeniería era una especie de traer a los ingenieros para hacer un proyecto de programación en pareja juntos.

Así que nos sentamos durante un par de horas, ya sabes, mano a mano la solución de un problema en una biblioteca de código abierto. Y lo que hizo fue mostrar como se trabaja en un entorno de colaboración, que de nuevo es más realista. Eso es como más lo que hicimos en el día a día. Estábamos todos sentados en la misma habitación en el momento y que acaba de rebotar preguntas alrededor.

Queremos saber cómo trabajaron los demás, pero también los metimos en algo interesante y divertido que no sintieron la presión. Usted sabe, usted está siendo observado como un halcón o usted tiene tantas horas para hacer esto su propio. No sé. Así que ese fue nuestro enfoque o el enfoque de estos últimos años.

Estoy seguro de que hay, hay formas de seguir mejorando eso o hay formas de seguir mejorando las cosas. Pero me gusta cualquier cosa que nos acerque al ingeniero que hace el trabajo real, en lugar de hacer una comprobación arbitraria de habilidades.

[00:22:24] Matias: si,

es que realmente me encanta eso de trabajar juntos. E incluso más que el tipo de entrevista para llevar a casa o el tipo de entrevista para el psicólogo o la pizarra en como con gráficos y algoritmos de ordenación. Y puedo recordar cómo funciona una ordenación de burbujas. Sé que dice que sólo escribo ordenar hecho.

Sí. Y eso nos lleva a 2020 una pandemia golpeó el mundo. Así que la empresa en la que trabajas se quedó sin clientes como muchos de nosotros. Y buscas otro camino y ese otro camino se convierte en draft.dev. Bien. Entonces, ¿qué es draft.dev y por qué saltaste de desarrollador actual a otra cosa que está bastante relacionada?

Y hablaremos de eso, pero es completamente diferente. 

[00:23:19] Karl: Sí. Sí. Así que lo que hacemos en draft.dev ahora es que escribimos entradas de blog técnicas y tutoriales para las empresas que venden herramientas a los desarrolladores la mayor parte del tiempo. Así que si eres una empresa de alojamiento y quieres escribir contenido útil para los desarrolladores de software, tienes que tener ese contenido escrito por desarrolladores.

No puedes tener una persona de marketing o lo que sea, ir a escribir tus tutoriales y cómo usar tu hosting. Sí, claro. Eso no funciona. Así que venimos con el gran equipo de desarrolladores de software que tienen experiencia en todo el mundo y en todo tipo de tecnología diferente para ayudar a esas empresas a escribir este tipo de entradas de blog.

Y luego pagamos a los escritores y la empresa nos paga a nosotros. También tenemos editores. Tenemos ilustradores, de hecho ha crecido mucho este año. Pero, pero no para adelantarme. Así que, cuando empecé, honestamente, no era como si no tuviera mis grandes aspiraciones. Fue un poco como, yo, mi trabajo se redujo a medio tiempo porque la pandemia fue, nos estaba golpeando duro.

Tuvimos que despedir a un montón de gente. Y el medio tiempo me mantendría en un trabajo sin quitarle mucho a la compañía en ese momento. Ellos, simplemente no podían permitirse mantener a todo el mundo a tiempo completo. Así que yo y un par de otras personas eran medio tiempo. Y fue un poco agradable porque yo era como, bueno, tengo un montón, tengo tiempo libre extra.

Mi mujer, afortunadamente, tenía un trabajo que, ya sabes, nos evitaba cualquier dificultad financiera por ello. También ahorramos dinero. Así que estábamos en una posición muy afortunada en comparación con un montón de gente. Pero creo que, ya sabes, tengo 20 horas a la semana o más que puedo hacer algo por mi cuenta. Así que empecé a escribir en el lado.

Siempre he escrito mi propio blog personal y, de vez en cuando, una empresa me pedía que escribiera un artículo para ellos y yo lo hacía. Pero decidí empezar a preguntar y ver si podía conseguir que la gente me pagara por hacerlo. Encontré una gran lista de sitios en Internet que pagan a ingenieros de software por escribir.

Y luego ayudé a empezar a trabajar con el tipo que lo mantenía para ampliar la lista y ya sabes, me aceptaron en cinco o 10 lugares probablemente bastante rápido y empecé a escribir artículos. Yo estaba escribiendo, probablemente estaba escribiendo como cinco a 10 artículos al mes durante un mes o dos. Y entonces. Ya sabes, dentro, dentro de un mes o dos, estaba claro.

Había mucha más demanda de este tipo de escritura de la que yo podía suministrar por mi cuenta. Y entonces, empecé a pensar que esto podría ser una empresa. Y así le dije a mi empleador, que iba a salirse, ya sabes, y ellos, fue como, entendieron el momento basado en todo lo que estaba pasando. Así que me tomé un tiempo, como tres o cuatro meses para ir, ya sabes, poco a poco la reducción sólo para ayudarles a hacer la transición más fácil.

Y, por lo que fue realmente una transición agradable, suave en. Ya sabes, pasar de ser un desarrollador a tiempo completo y líder de desarrolladores a dirigir este pequeño equipo de mí y otros dos o tres escritores al principio escribiendo un montón de contenido y, ya sabes, ha crecido muy rápidamente este año, pero los primeros meses son difíciles.

Quiero decir, mentalmente hay un gran cambio entre ser un empleado y ser un F ya sabes, dueño de un negocio. Ya sabes, si alguna vez has hecho freelance, a tiempo completo. Da un poco de miedo, pero entonces es, incluso para mí, lo que era aún más aterrador, era dejar que otras personas tuvieran las riendas en cierto modo, como dar asignaciones a otros escritores y ser como, bueno, espero que no lo arruinen porque si lo hacen todo, la cosa va a parecer mal para mí.

¿Sabes? Así que hay un, hay como un elemento de eso. Recuerdo que me despertaba a las tres de la mañana y me decía: "Dios, espero que terminen el artículo a tiempo". Espero que lo terminen. Ya sabes, al principio, teniendo esta ansiedad, no sé. Sí. Es, es, es, era una cosa aterradora.

al principio.

[00:26:29] Matías: Sí.

Y en realidad es un tipo de tarea completamente diferente, porque supongo que realmente te sentías más cómodo compartiendo la responsabilidad sobre un trozo de código, incluso si se trata de actualizar el código en producción que de la escritura técnica. Eso es, entre comillas, nuevo. Para muchos de nosotros el vínculo que mencionaste es el, quién paga a los escritores técnicos.

Eso com esa lista. 

[00:26:53] Karl: Esa es una de ellas. Sabes, en realidad tenemos un repositorio de GitHub llamado programas comunitarios de jinetes. Pero ambos son buenos. Puedo enviarte el enlace aquí. 

Sin embargo, hay, ya sabes, hay un, no quiero decir que hay una tonelada de recursos para las personas que son, probablemente no hay suficientes recursos para los desarrolladores que quieren entrar en la escritura, pero al mismo tiempo, se está convirtiendo en una carrera más visible o como una carrera viable, tal vez.

Así que si es este tipo de escritura, o tal vez usted está haciendo como más tipo de documentación de la escritura no hay puestos de trabajo. Suele ser, no quiero, no voy a endulzarlo. La tarifa por hora no suele ser tan alta como la del desarrollo de software normal, pero si quieres un cambio de ritmo, lo que realmente me gustaba era que podía escribir código como si pudiera escribir un proyecto de demostración y nunca tenía que hacerlo.

La producción está lista. Ya sabes, como que era una especie de diversión porque es como, aquí está el, aquí es como un, tal vez un ejemplo. Al igual que yo estaba escribiendo artículos sobre Kubernetes y la ejecución de Kubernetes en la producción es sólo un gran dolor. Hay tantas cosas involucradas en él. Y es como, termina, que tipo de ir en este agujero de conejo pensando, oh, bueno, aquí está.

Está funcionando a su manera. Tenemos un escritorio reforzado. Tenemos que lidiar con este tipo de puertos. Tenemos que lidiar con este tipo de registro. Al igual que termina como en cascada en este enorme lío. Y te das cuenta de que estás haciendo un montón de trabajo operativo sólo para mantenerlo en marcha. Mientras que, si usted está haciendo un tutorial sobre cómo obtener su primera aplicación Kubernetes corriendo en cualquier idioma, supongo que es bastante fácil.

Es como, te lleva una tarde, te lo aprendes y luego lo escribes y ya está, ¿sabes?

[00:28:23] Matias: ¿Supongo qué? Quiero añadir algo a eso. Sí.

Aunque es bastante fácil crear demos. A veces la demo puede ser realmente engorrosa sólo porque estás tratando de enseñar algo tan complejo o profundo que terminas pensando más en cómo hacer la demo de esto. Porque una cosa es hacer una demo y una aplicación que se ponga en marcha con algo hecho.

Otra cosa es tratar de hacer una demostración. Qué pasa si no haces lo que debes hacer. Y, y eso es realmente difícil, pero la escritura técnica es realmente impresionante para el aprendizaje para compartir el contenido. Y es una especie de momento relámpago. Como un momento bombilla. Cuando descubres que te pueden pagar. Al escribir la gente, la gente ha estado escribiendo en Internet durante tantos años, como los blogs y tantos, un contenido libre que de alguna manera.

Así que usted aprende que usted puede comprar un libro de Mac. De hecho, yo compro, acabo de comprar mi libro Mac recientemente, lo recibí recientemente de la escritura técnica. Y 

[00:29:26] Karl: Eso es impresionante. 

[00:29:27] Matias: tienen, estoy emocionado por eso. Así que, Sí.

es 

[00:29:30] Karl: Sí, no, lo es. Y aunque, ya sabes, lo hice durante años de forma paralela sin cobrar o cobrando muy poco porque simplemente, no tenía tanto tiempo para dedicarme a ello en serio. Bien. Y estaba haciendo buen dinero como ingeniero, así que realmente no me importaba. Pero incluso si lo haces gratis o en tu propio blog o lo que sea, te abre nuevas oportunidades en las que no habría pensado.

Así que voy a tipo de un par de ejemplos de esto. Escribí mucho sobre las APIs de las bolsas de trabajo hace unos años, y literalmente todavía recibo gente por lo menos un par de personas al mes que se acercan a mí diciendo, Oye, ¿todavía trabajas en la API de la bolsa de trabajo es que tengo un proyecto que me encantaría contratar a un desarrollador para.

Quiero decir, como si hubiera hecho un negocio de consultoría de eso, sería un negocio viable. Y es sólo fuera de como unos pocos mensajes de blog. Lo que hace cinco, seis años ahora. Así que estas cosas se quedan en Internet más tiempo de lo que crees, y se acumulan, especialmente si eliges un área de enfoque y tratas de clavar todos los diferentes temas en esa pequeña área de enfoque, la gente empezará a conocerte por esa cosa.

Y ya sabes, puede que te lleve años, pero años no es tanto tiempo en el gran esquema de tu carrera. Creo que esa es otra cosa. La gente al principio se pierde el valor de la consistencia en el tiempo. Mi blog personal es un buen ejemplo. Estábamos hablando de CTO portátil en ese boletín. Sólo tenerlo durante 10 años, una actualización, tal vez tener un post al mes durante los primeros nueve de esos años.

Sólo recoge un montón de enlaces y recoge el tráfico. Y sabes, ahora estoy recibiendo, no sé, 20.000 páginas vistas al mes o tal vez más algunos meses. Y no es que, ya sabes, no me gane la vida con esto, pero es sólo un pequeño blog personal. No es nada super serio. Así que sólo se construye con el tiempo y tienes que seguir con él al menos algo de consistencia, si quieres conseguir mucho.

[00:31:08] Matias: Y si tenemos en cuenta que actualmente estamos viviendo bajo una explosión de creación de contenidos y la gente se está preocupando mucho por ese proceso, tipo de creación de su blog y compuesto que es incluso en un período más corto de tiempo, puede tipo de creció una marca personal. Eso es básicamente lo que haces. Usted gana mi marca personal muy rápidamente en comparación con los años antes de 2020, tipo de 2020 oportunidad más loca. sí.

De la escritura técnica o la creación de contenido para construir esta carrera en el lado, como la gente puede conseguir, se llega a conocer por su escritura. Sí. En el sitio draft.Dev, mencionaste que la marca personal es una herramienta que te permite crear una marca personal, la escritura puede ser una buena herramienta.

Y si te pagan por eso, es increíble. Entonces, ¿cuál es el proceso para convertirse en un escritor? Tienes que tener mucha experiencia para ser escritor. 

[00:32:14] Karl: Sí, nosotros, en este punto tenemos muchos, tenemos muchos solicitantes, así que hemos estado, ya sabes, hemos tenido nuestras aplicaciones abiertas desde hace meses y hago un montón de salir en la comunidad sólo para asegurarse de que la gente sabe sobre él. He tenido un par, dirijo un par de boletines además de CTO portátil. Dirijo uno llamado CFP land, que es para ponentes de conferencias.

Y también recibo muchas solicitudes para escribir en borrador a través de eso. Así que en realidad recibimos, creo que más de cien solicitudes al mes, y probablemente sólo tomamos de uno a cinco de ellos al mes, dependiendo de cuántos clientes nuevos recibimos y cómo, cuáles son los temas que están cubriendo.

Así que es un, es bastante selectivo en este punto. Buscamos sobre todo gente que. Un poco de experiencia en la escritura por ahí. Usted sabe, yo no desalentar a la gente. Que sólo han escrito dos o tres puestos de, de la aplicación, pero sólo sé que, ya sabes, estás, estás tipo de frente es un poco de un desafío aquí.

Pero hay toneladas de otros lugares a los que puedes ir, ¿verdad? Así que como, ya sabes, somos uno de como esta lista, esta lista vamos. Tiene como 40 o 50, al menos lugares que pagan a la gente. Y ya sabes, algunos de ellos son más abiertos que nosotros. Así que podría con draft.Dev porque estamos trabajando con los clientes que quieren temas específicos cubiertos, enviamos una especie de lista de aquí están todos los temas que necesitamos cubiertos esta semana.

Mientras que en otros lugares, Bill, te dejan lanzar cualquier historia que quieras. Y eso puede ser una forma de empezar a tener más muestras, de tener más práctica. Muchos de ellos también tendrán un editor profesional con el que te emparejarán. Así que obtendrás un montón de información. Nosotros también lo hacemos. Pero como, ya sabes, de nuevo, como si no, si no estás listo para entrar en nuestro programa.

Pero sí, si quieres aplicar, hacemos draft.dev/wright. Y ya sabes, sobre todo si, sí, ahora mismo, creo que estamos buscando gente senior de móviles y siempre gente de Kubernetes, un montón de cosas de Kubernetes pasando 

[00:33:56] Matías: Sí.

Vi una gran lista de Kubernetes

[00:33:59] Karl: Sí.

[00:34:00] Matias: contenido. Parece que no, no hay mucha escritura técnica por ese lado, o al menos el desarrollo web o el desarrollo móvil está como superando la, la ola de información. Una cosa que es realmente sorprendente cuando empiezas a escribir para otra persona es el proceso de edición.

Y también es agradable recibir ese tipo de comentarios. Pero si no tienes ese tipo de feedback, por favor, utiliza herramientas como Grammarly o la herramienta de lenguaje. Nada de eso es un patrocinador del programa. Así que no importa, pero ¿eso te ayuda mucho 

[00:34:34] Karl: De acuerdo. Y, y diría que también animaría a la gente, incluso si no eres un hablante nativo de inglés o tal vez eres un poco consciente de tu capacidad de inglés. En realidad, para muchos programas esa no es la mayor barrera. Porque un par de cosas, una es, como dijiste, que te emparejarán con un editor.

Y así está bien. Como que puedes conseguir algunas de esas cosas que podemos ayudarte a arreglar. La otra cosa. Que tengas habilidades técnicas únicas es probablemente lo más valioso en la ecuación de la escritura frente a las habilidades técnicas. Al menos para nosotros. Y creo que es probablemente cierto para muchos de los programas de escritura de la comunidad es sólo tener un fondo interesante o alguna experiencia técnica diferente que es tal vez único.

Eso también te llevará muy lejos. Así que, ya sabes, no, no pienses que sólo porque tu inglés no es el más fuerte, no vas a ser capaz de escribir nunca. Eso definitivamente no es cierto.

[00:35:21] Matías: Una pregunta que dejé un poco atrás. ¿Por qué empezaste a escribir? Estás por tu historia, por qué empezaste a escribir y eso vino solo a construir el borrador, pero en algún momento no estabas escribiendo y luego fuiste todo mi increíble escritor. No lo sé. 

[00:35:38] Karl: No sé sobre la escritura increíble. Yo, yo se hace más fácil. Cuanto más lo haces y te vuelves más rápido, más lo haces. Así que tienes que empujar más hacia fuera. Cuanto más lo haces, mejor te vuelves en algo, ya sabes, es como escribir código. Si escribiera 10.000 líneas de código cada día, eventualmente me volvería muy bueno en el código.

Si escribiera 10.000 palabras de, ya sabes, profesionales todos los días, se me daría bastante bien. Así que he estado escribiendo por mi cuenta desde la escuela secundaria y la universidad por diversión. De hecho fui y fui en la universidad. Me alojé con un montón de estudiantes de inglés, así que éramos un montón de nerds para diferentes cosas. Yo era un nerd para la ingeniería.

Eran nerds del inglés y nos quedábamos despiertos hasta tarde en la noche y jugábamos a esto. Juego de escribir historias, en el que te das listas de palabras y luego tienes que volver a escribir una historia alrededor de esta lista de palabras que la gente te daría. Y esto es lo más friki que hay, ¿verdad? Esto es como, 

[00:36:22] Matías: Había whisky o bourbon o algo así 

[00:36:25] Karl: hay un poco, sí, hay un poco de alcohol involucrado, pero como, todavía era como una cosa tan nerd para hacer en un viernes por la noche.

Pero eso fue así, de todos modos, supongo que siempre lo he disfrutado. Siempre asumí, ya sabes, siendo el tipo de ingeniería práctica, siempre asumí que sería imposible para mí ganarme la vida como escritor. Yo sólo. Creo que ni siquiera me di cuenta de que era un camino viable hasta que empecé a hacerlo. Y entonces yo diría, ya sabes, y, y tal vez nunca voy a ser como un, un, ya sabes, un escritor de ficción o alguien deja como publicado como un autor famoso o algo así.

Pero incluso, incluso si no vas allí, hay un montón de maneras de ganarse la vida escribiendo a tiempo completo. Y creo que eso fue lo que realmente me mostró al entrar, en este campo y luego iniciar la pequeña empresa.

[00:37:06] Matías: Entonces sé que ya dijimos que no eres una persona de consejos, pero cualquier consejo para alguien que quiera empezar a escribir, y tal vez tenga miedo de eso. Aunque. Tener esa sensación de la página en blanco que, ya sabes, ese bloqueo de que voy a escribir algo que la guía final sobre, no sé, el óxido, y entonces te enfrentas a esta pantalla blanca y vacía y no escribes nada durante meses. 

[00:37:34] Karl: Sí, así que es, es intimidante. Y como has dicho, muchas veces existe este concepto llamado la brecha, del que Ira Glass habla en un vídeo. Intentaré enviarte ese enlace también. Y la idea es que hay esta enorme brecha entre. Lo que sabes que es bueno y lo que realmente puedes crear si empiezas a convertirte en un creador.

En otras palabras, si leo una novela muy buena, puedo ser muy bueno analizando novelas y dándome cuenta de lo que es una buena novela. Pero para escribir una buena novela, hay una enorme brecha entre ser capaz de entender y ver una novela como buena y escribirla realmente. Así que esa brecha paraliza a mucha gente.

Así que lo que tienes que hacer, o lo que yo hago, es reducir esa brecha simplemente diciendo: quiero escribir un párrafo realmente bueno. Párrafo o una idea realmente buena o tal vez sólo un buen esbozo y empezar por ahí y poco a poco construir a partir de ahí. La otra cosa que le digo a los nuevos escritores es que sólo porque lo escribiste.

Ya sabes, la guía definitiva de JavaScript una vez no significa que no puedas volver y escribir la nueva guía definitiva y gigante de JavaScript. Como yo, de hecho, creo que los mejores escritores tienden a escribir sobre los mismos temas una y otra vez. Y sólo verás las versiones realmente buenas que salen al mundo, pero probablemente hicieron 10 versiones diferentes.

Detrás de las escenas que tú, no viste. Así que sigue escribiendo y sigue haciéndolo. Empieza por lo pequeño, con pequeñas victorias alcanzables, aunque solo sea escribir cien palabras en tu diario o un tuit cada día, y empezarás a coger ideas y a mejorar en ello.

[00:39:00] Matias: Sí, creo que la última pregunta sobre la escritura es por qué los desarrolladores que disfrutan de escribir código podrían querer escribir contenido como tutoriales tipo. 

[00:39:15] Karl: Sí. Me gusta escribir tutoriales, para ser honesto, ya que son, son una especie de consumo de tiempo en cuanto a la escritura, quiero decir, como, hay, hay, hay una gran cantidad de diferentes tipos de escritura técnica o incluso las entradas del blog que escribimos para los clientes. Pueden ser posts de alto nivel que requieran un poco de investigación o pueden ser, ya sabes, prácticos.

Esta aplicación de demostración y todo eso. Y eso puede tomar mucho tiempo, pero lo que hace, hace un par de cosas para mí personalmente. Una es que me hace. W Yo diría que como el aprendizaje y la lucha con algo que no he hecho antes, que siempre es divertido. Hay como una recompensa en la ingeniería de software. Es como, que has descubierto cómo resolver un problema con sólo el código, ya sabes, como que es muy divertido para mí.

Todavía lo disfruto. Ahora que no escribo código todos los días. Así que conseguir esos golpes como las recompensas de aprender una nueva cosa es genial. La otra cosa que me motiva es que ese artículo va a salir al mundo. Y durante años, la gente será capaz de buscar y encontrar en mi nombre está unido a ella.

¿Y es realmente importante para nosotros en el borrador? Como todo nuestro trabajo se acredita al autor. Se supone que es para construir como usted sabe, su carrera hacia arriba también. Así que es como una cosa mutuamente beneficiosa. Claro. Estás escribiendo este artículo para un cliente, pero también vas a mostrar tus conocimientos.

Y cuando otro empleador en el futuro quiera ver cómo demuestras que has construido una aplicación react, dices, oh, no sólo he construido una aplicación react. He escrito este tutorial para ello. Y aquí está publicado. Así que como en mi currículum, hace unos años que no lo actualizo, pero siempre lo he hecho. Enlaces a las cosas que escribí sobre cada línea en el currículum.

Así que de esa manera no sólo estaba diciendo, yo sabía esto y esto, escribí una entrada de blog sobre ello, y luego me vinculé a ella. Así que podría ir a probar que yo sabía que allí mismo y no tendría que, no tendría que meterse con el entrevistador. Así que pensé, no sé.

[00:40:58] Matias: Sí, yo también eso te ayuda cuando, estás escribiendo un, detrás de escribir código detrás de NDAs. Así que no puedes mostrar tu trabajo, pero puedes decir que realmente sabes porque escribiste esto

[00:41:10] Karl: eso es un, sí, eso es un punto excelente. Es como cuando eres la mayoría de las empresas, quiero decir, usted no va a ser capaz de compartir su código fuente que realmente hizo. Y algunas empresas ni siquiera te permiten hacer trabajos de código abierto. Pero tal vez usted puede escribir entradas en el blog, ya sabes, en el lado de forma gratuita o lo que sea, o pagados para ayudar a mostrar como, Hey, realmente saben algunas de estas cosas.

[00:41:28] Matias: Así que Karl, esto ha sido divertido realmente perspicaz. Y, pero estamos casi al final de este episodio. Así que cualquier cosa que quieras compartir con la audiencia 

[00:41:39] Karl: Quiero decir, me gusta mucho ayudar a otros ingenieros a encontrar caminos no convencionales. Y creo que por eso me gusta venir. Puedes conseguirlo con gente como tú que ha tenido caminos poco convencionales también. Es divertido hablar de estas cosas conmigo. Así que si alguna vez tienes preguntas o cosas que quieras consultar, estoy en Twitter.

Es @karllhughes. Ese es mi medio preferido para la divulgación en frío, pero también puedes enviarme un correo electrónico. Sí, yo, yo, en este punto, realmente no buscando nada específico, supongo, si desea aplicar para escribir para draft.dev puede ir a draft.dev/wright. Si estás en eso o siéntete libre de contactarme directamente también, pero sí, es un, es un placer estar en y llegar a nerd en algunas cosas.

[00:42:21] Matías: Y luego la última pregunta que hago a cada invitado es sobre una recomendación. Algo que te guste, algo que te guste y algo que quieras hacer, algo que simplemente, quieras compartir con el mundo, lo que sea, lo que sea, esto. 

[00:42:35] Karl: así que tres cosas o quieres 

[00:42:36] Matias: uno dos, lo que sea.

pero quiero decir, algo que realmente te gusta, y quieres compartir con sus, compartir tu amor. 

[00:42:45] Karl: Sí. Así que, lo que me viene a la mente inmediatamente, esto es totalmente al azar, pero yo, ya sabes, empecé un negocio el año pasado. Sí. Nunca había creado una empresa en la universidad. Trabajé por cuenta propia un poco, pero como, esto es, esto se siente diferente. Y uno de los libros que me hizo empezar se llama "Big Magic" de Elizabeth Gilbert.

Si alguna vez piensas en crear una empresa o hacer algo creativo, como convertirse en un escritor a tiempo completo, ella en realidad, eso es lo que su libro es básicamente su viaje para convertirse en un escritor. Para ser honesto, ni siquiera me gusta particularmente su escritura, como sus libros, pero este fue realmente interesante porque.

Te muestra la lucha por la que pasan otros escritores, que muchas veces no ves el resultado final, ves a la persona como yo, que ha tenido cierto grado de éxito o ves a Elizabeth Gilbert. que es una autora de best-sellers publicados en el New York Times o lo que quieras decir, una persona increíblemente exitosa, pero que pasó 10 o 15 años detrás de la escena sin hacer nada de lo que nadie hubiera oído hablar, ya sabes, luchando todos los días.

Pero ella vino a trabajar y lo hizo todos los días. Y ella habla mucho de eso. Y creo que eso es lo que pasa. La mayoría de las personas exitosas. No hay, no es un movimiento lineal de como, ya sabes, soy nuevo en algo a, soy un extremadamente exitoso es es como son? Tengo esencialmente exponencial.

Se empieza muy mal durante mucho tiempo antes de empezar a remontar rápidamente. Así que el éxito es exponencial. Así que piénsalo de esa manera y sigue trabajando, sigue probando cosas, sigue, sigue aprendiendo.

[00:44:12] Matias: Me gusta que sea exponencial. Sí. Eso tiene todo el sentido. Así que. Gracias Karl por estar aquí. He disfrutado de esta conversación, así que sí. Gracias. 

[00:44:22] Karl: Sí, gracias por recibirme. 

[00:44:24] Matías: Y nos escuchamos en el próximo episodio la semana que viene. Gracias por estar aquí.


English

[00:00:00] Matias: Welcome back to a new episode of Café con Tech with me is the portable CTO itself Karl Hughes joined us as a guest to talk about kind of career story and technical writing. So welcome. Karl, thank you for being here. 

[00:00:15] Karl: Yeah, thanks for having me Matias. It's a, it's a. pleasure, Glad to finally meet you outside of Twitter. I think we've, we've interacted there a number of times, which is fun, but it's always nice to bring that to a well face-to-face in 

[00:00:26] Matias: Yeah. Welcome to my home, my podcast. Thank you for being here. Let's start this off by asking you a little bit of bio, like an introduction of yourself and why I said the portable CTO.

[00:00:41] Karl: Sure. So yeah, my background is I've been a software engineer and then more recently engineering manager and CTO at some small funded tech startups in the Chicago area. So I've been doing that. I had been doing that for about eight or nine years, I think until last year. And then I left my last job to start a company called draft.dev.

And we we can get into draft and all that as we go. But yeah, my background's in software engineering. I was a hands-on engineer for a few years. It sort of fell into leading an engineering team and I really liked the leadership side. And so I run a newsletter though, like that you mentioned called the portable CTO and yeah, that's just been kind of like an accompaniment to my blog for years.

And so it's just an outlet, another outlet for writing you know, you're, you're into writing and so. You, you kinda know this it's, it's it's nice to have these different outlets. And so, yeah, I've got work writing, but I also have my kind of, for fun writing on the side and I like to have a mix of both

[00:01:41] Matias: It's fun. It's kind of a niche and I need to start to write more and more and more. So sometimes the blog itself is kind of too small to, keep writing or to move around other areas. So, yeah. And what people can find in the portable CTO different than your blog. 

[00:02:00] Karl: he had it's, it's a mix. I, what I do is every week, I basically curate links and ideas that I find around the internet related to software engineering, startups management, and kind of anything at the intersection of those three things. Those are sort of my three. I don't know, pillar strengths or things that I've tried to get pretty good at over the year.

And then I always include like kind of a short original like a summary or introduction to some of the topics that, that I have linked further links to in the newsletter. So it's usually about 500 words. Here's what I'm thinking about this week and then a bunch of links and, you know, it's fun because I get, I get replies to those every so often from people who have maybe something to add or talk about there.

And, you know, email is, it's kind of coming back as a medium because it's, it's a lot more personal in some ways than social media. And, and it just feels like you get full control over your, your email feed, where social media feeds a lot harder to get that same level of control.

[00:02:57] Matias: Oh replies that are so good. In social media, you have so many replies that aren't actually replys. It's kind of an engagement is weird. I've been writing a newsletter too. And to be honest, replies are hard. Never got one, but I think it's easier for people to reply there because first you don't have to care about the spam nor weird comments it kind of the people that are reading your newsletter is because they want it.

It's not just a random person in your feed. 

[00:03:32] Karl: Right. Yeah. A lot of them are personal friends or people that I've met in real life in my network, you know, and I think that's kind of, that's fun because it's almost a extra way for them to keep up with what I'm doing, what maybe we don't work together anymore, but we, so we don't see each other in the same way.

You know, Facebook isn't really as cool anymore. I dunno, in my circles. So I find maybe the newsletter is the replacement for that kind of low tech social network in a way.

[00:03:56] Matias: it's fan because you mentioned Facebook. The other day, I was speaking with my wife and Facebook fall into the elderly user somehow. And then do we have this other tick-tock and other areas that is not for me, at least, because I in kind of the middle and what is in the middle, Twitter

so Twitter is kind of the one thing I was reading your feed on twitter. And I found a link to interview. Do you had a no CS degree.com? That is a site that speak and talk and do things for people that have no CS degree to level up their careers. And you actually, there's a pretty good story there that is really long.

And actually I will leave the link in the show notes because it's really throughout all about your, your experience. One thing that caught my eyes is how you learn to code. And this is kind of most people that have no CS degree learn to code because necessity or because they like it, but currently, most of them through bootcamps or through YouTube videos or YouTube courses or Udemy or what not right?, but you went for another rabbit hole so can, can you, can you drive us? 

[00:05:16] Karl: Yeah. So the kind of backstory there is, I went into college. Studying mechanical engineering, because I knew I liked the whole just figuring out how things work and helping build things. So I knew I wanted to do something in building things and engineering was a good, a good path for that. I got into some internships with mechanical engineering and it was just really boring and slow.

A lot of big companies, you know, it's hard. There are not lot of Startups in the mechanical engineering space, because it's such a, an old industry. Whereas computer science and engineering is a lot of young startups, but I was already like a couple years into college and I'm like, I'm not going to start a degree over, you know, I just not, I don't have the patience for that.

So I decided I would just, you know, on the side, obviously, Mechanical engineering student. There's a tiny, we get a tiny bit of code. We probably learned a little bit of C and a little bit of MATLAB and things, but I hadn't done it seriously until the last couple of years of college. And my motivator was I wanted to learn to build a campus blog.

And so I got to go to 20 or 30 friends. I set up a WordPress site. I started wanting to add all these custom features and things, and I realized I'd need to learn more and more code. And it kind of just it's it's funny. I learned by just thinking to myself, it would be cool if I could build X and then I figured out how to hack it together.

And I mean, the code was terrible. It was messy. It wasn't doing things the right way. Like, you know, it took me years to figure out that. It's so for me, the encouragement was getting started and seeing something up there on the screen. And so as I did that for myself in my own little, you know, campus blog I then started to take on other clients, mostly small local businesses that wanted WordPress sites or something really simple.

They could update. And I would just kind of tell them, you know, Hey, I'll build you a website for me, a few thousand dollars or something. And I had no idea how long these projects would take. I just. I'll get paid a little bit and I'll work for a month and just figure out how to do it, you know, or two months or whatever.

And I didn't need a lot to live anyway. So it was like, Put this deadline on myself, like I've got to learn to build X and now I know, you know, I've got to build it. These people are paying me, so let's just figure it out. And then I would work late nights and figure things out. So I don't recommend, I don't recommend this approach for everybody.

But you know, there weren't like you were mentioning. There weren't Bootcamps like there are today, at least not in Tennessee, where I'm from. There weren't the same, like online courses that were cheap. You kind of had to go to college or just go hack around on stack overflow and forums and try to figure out, I mean, th there were books, but they were always hopelessly out of date even.

Yeah. Even back then. So yeah, it was just a different world learning web development, but I think you know, what it taught me is like how to learn and I think, or how I learn best it's, there's not one way to learn things. And I think that's something that I took away from that experience, looking back, especially.

I learned really well when I get a project project based learning. And I think that's part of why I didn't especially enjoy a lot of school because a lot of school is kind of rigorgutation, like memorization and then pushing stuff back through and you know, calculations, which, you know, I always, I felt, I just, I just felt like the computers can do this now.

Like we're done, I should be done with this. I want to, I want to just like, look things up and hack there and figure it out anyway. So that was my mentality. And that's like what I took away from that experience. Anyway, I got getting out of college. I got a job. Partly a developer, partly a blog manager. It was kind of weird hybrid role, but it fit for what I had been doing.

So 

[00:08:36] Matias: Web Master? Years? Years. Years ago? Well, you were basically jumping. To an empty pool every time. That's always hard. So a shouts for that, because learning to code without any actual background on code is hard and it was really hard. But after that, you kind of was able to keep up afloat, right. So, by yourself, your leverage, your knowledge and you find this path that you mentioned that is you learnt about your learning process. And I think that was a few days ago. Maybe weeks I can't recall. Exactly. But you wrote about that in the newsletter, I think Yeah.

I'm, I'm following every guest I have in the show.

I'm a stalker. 

[00:09:21] Karl: That's awesome.

[00:09:23] Matias: and, and you wrote about that and it kind of resonates a lot with me because even though it's kind of a common topic, learn to learn, everyone said, Hey, you should learn how you learn it's kind of obvious, but at some time it's really hard to find out what is your path because there's so many information, so many advices, as we were speaking before, recording, that is really hard.

So talking about advice, what will be your take on how you can find out your way? For other people? So for example, I'm a, I'm a complete beginner and I think I need to buy a course on. X site because they have, they offer me a path, a career path. What do, what would you say mean are you sure? 

[00:10:09] Karl: Yeah. Yeah. I, that's a big question. It's so situational, the, you know, depending on how here's, where I, why I say that learning how you learn is so important. If you found that you only learn, well, when put in a group setting and you need other people to sit next to you at the computer and be doing things that are similar or to compete with in a way in order to learn things, then you should find a learning environment that fosters that kind of competition, and that pushes you in a group setting.

There's nothing wrong with that. That's like an that's a lot of people fit that. And I think a lot of people that do really well in boot camp, Tend to be those kinds of people who they need a group, they need to sit down with a bunch of people, have some structure, and then when they do that, they, they may Excel.

And so that's fine. If on the other hand you are more of an independent person, like you've, if you've always written or sorry, read books on your own and kind of picked up your own skills whenever you felt like you wanted. It's certainly possible to learn the basics of computer programming and maybe even the basics of computer science without an academic course or an official, you know, like a bootcamp or anything.

So there's not a right or wrong path. So I don't usually give people the whole. This is the path this is what you should do. But what I do try to do is to help ask, to get people, to figure out like, why they're they are saying they want to become a developer or why they want to learn a program. Like if your goal is just to build something cool on the internet, like you, you just want to start a company.

Maybe you can find some like smaller no-code tools to learn so that you can just build a company faster because the, the path to learning to code is, is it's pretty hard. I mean, it's not. Overnight thing. So you really need something that's going to get you like the result that you're looking for in the end.

Whereas if on the other hand, maybe you're looking for more like a stable job and a good career path. Well, sure is that computer programming is that, but you better like programming because it's a, you know, it's a lot of behind the screen time, a lot of sitting and if you've never worked that kind of environment, It can be pretty rough at first.

So I think you just learn like by doing things and for me, what worked was having internships. So I kind of mentioned my pivot away from mechanical engineering. I, I started getting internships the moment I could. So after my first, my first semester of my freshman year, I applied for all the internships I could, I got a bunch of interviews and I got one offer, two offers maybe.

And, and I, I, you know, got an internship very early. And what it did was it showed me like what the actual day-to-day job of a mechanical engineer was, which I had no idea. I mean, you, you, you learn in school and it's just totally different from the real world. So I think getting out there as quickly as you can to learn, what does it really like to be a computer programmer or developer and think about like the different size of companies.

And the different ways that that can affect your career. What it's going to look like on your day to day, how you're going to be compensated. There's a lot of variables there that you sort of need to just test out and see what works for you before you really have a good handle on it.

[00:13:02] Matias: So look for exposure as soon as you can. And then you will be able to kind of learn if this is for you actually being a developer is really, really fun, but at sometimes can be really stressful. So, yeah. 

[00:13:17] Karl: Yeah.

[00:13:17] Matias: So, and that thing about works on my machine is, is not, not anymore. Next thing is you started, as you mentioned you learn how to learn, then you go to internships and then you was able to kind of find your own path as a developer.

And that path brings you to be come technical leader and CTO, and as a CTO you had to somehow help juniors. And interview juniors and, kind of bringing them over and all of that. So first, how was the experience of becoming a CTO was actually really different or just being a good developer with good thoughts about what you're doing?

Because in a team there is always some developer that is amazing and everyone follows their advice. And there is also the CTO that for, because of the role. People follow their advice. So it's kind of a trade-off. So what, how was it for you? 

[00:14:16] Karl: Yeah. So I I'm definitely, I would never claim to be the best developer out there. The one that other developers look to for all the advice, you know, th there's situations where I know what I'm talking about, but really, I think what I realized early on and in my career, A software developer was that I tended to get drawn into leadership roles.

And I think this is just true of a lot of people who end up going into management leadership roles. They tend to get drawn into them. It's not so much that they, they come in and in their first year, they're just gunning for it. It's more just like. An opportunity, a small opportunity comes up and you say yes to it.

And then that gives you a bigger opportunity later. And people sort of see you as the person who may ask for those roles, or you may start to just meet other people who are like you, that look for those leadership roles and that kind of gets you into that sphere. So it just seemed to happen organically.

But you know, I had, I got an opportunity to lead a startup that I had joined out of college and become like it was funny. It was called engineering manager. I was managing. Self and like one or two off shore developers, you know, basically it was managing myself and then checking their code 

[00:15:21] Matias: Happens. So often in the 

[00:15:22] Karl: yeah, yeah.

In small startups, this is like, what? This is, what's so interesting. Like small companies, they need a, a sort of hybrid manager developer, and they can't really afford a real manager. So a lot of times what they do is they hire somebody like me who thinks they might want to be a manager someday and, and knows that develop and then puts them in this role.

So I kind of got put into that. And as the company grew, it was interesting. My responsibilities grew with it. And so by the time I left, I was managing, you know, a whole team of engineers and was like sitting in on leadership meetings with the founders and investment meetings and stuff. And so I really got like this, you know, It kind of just by growing with the company, kinda got in the right place at the right time to follow right.

Ride the wave up. And like, this is one of the big advantages to working with startups. If you do get one that kind of grows fast is that you can grow along with it a lot faster than you would in a typical, like big company career setting. You know, it comes with its costs that you definitely don't, you don't tend to get paid as well in cash.

A lot of times they'll give you equity, which may or may never be able to be liquidated. Usually never. And you know, you may also have like kind of unrealistic deadlines from founders, challenging people to work with. That's true of big companies too, but yeah, there's just different. It's different.

There's no right and wrong again. But I really liked working with small companies and I got really kind of right place, right time. Joined a company just as they, like, they weren't shark tank, they raised a bunch of money. And so you know, the engineering team grew and I kind of grew with it into the head of engineer.

[00:16:53] Matias: Yeah, there is this experience of become one of the first engineers to start up and then, you know, so much about the product itself and the code that .

You just become a leader because you are the one who knows kind of it's it's your own baby. And as a CTO, how you deal with juniors because there is a kind of a topic right. now.

I feel that so many companies are hiring seniors all over the place. By the way there is no an actual definition of what a senior is, but yeah, seniors anyway, and the juniors that are a lot fall behind of the options. So opportunities falling behind for juniors, but actually it's really, really healthy for, for companies to have juniors and trainers and stuff.

So how will you deal with junior hiring interview process?

[00:17:46] Karl: Yeah. I definitely have thoughts about interviews too, but I'll say that. Yeah. So for junior hires, like you typically, it will, every situation like this, I think is situational . Dependent. So in other words, like there's not like a formula for hiring X kind of engineers at certain kinds of companies.

It just totally depends. In my case, I, both times I was in a education technology companies and in both of those last two roles, we hired junior people often because. Of two things. One, we didn't have the resources to always hire senior people. There's just like, it wouldn't have made sense. But then to the work we had was not always that interesting to senior people.

So this is another thing I think. A lot of startups think that their work is much more interesting than it really is. A lot of startups are still just building CRUD apps. Like crud is create, read, update, delete, or it's just basic in and out data, you know? And sure. There's like a bunch of layers.

There's a front end layer, backend layer. Middlewares there's microservices, whatever, 

[00:18:48] Matias: There's so many over engineering

[00:18:50] Karl: right. So yeah, there's definitely a problem with some engineering over-engineering happening in startups and in maybe all companies, but especially small companies. But then the other thing is just like senior engineers need and just anybody who's been doing this for 5, 10, 20 years, they need a pretty challenging problems to stay stimulated.

Whereas with junior people, I mean, I remember giving junior people like, Hey, update this forum. You know, gung ho they're like, oh, I get to update my first form in a website. You know, it's like exciting to them and it's like, work. I didn't want to do, but they are happy to do it. So there's this, there's kind of like, you have to look at your, the work you have and the work you're doing regularly and say, could a junior person learned to do this kind of.

Relatively quickly. And if so, we should hire junior people because they're going to learn this part of it, and then they're going to go learn the next thing and the next thing. So I I'm pretty, maybe not aggressive is the right word, but I'm pretty bullish on hiring junior people when you've got that kind of work where it doesn't, you don't necessarily need the most senior person to figure it out.

[00:19:51] Matias: Any thoughts about the interview process that you used to have or how you feel the interviews are currently are. 

[00:20:00] Karl: Yeah, so I, what I think a lot of people do wrong in interviews is not make them at all. Like the job that is actually going to be done. So my, this is just like my personal career experiences. When I show an employer, what I can do and that I could do the job they hire. And that's great. That's like the ideal situation, but a lot of companies that do interviews, they, they kind of like, they put you through these arbitrary sort of hoops to jump through that.

Like, just show that you've had a background that was similar to the founders or the people who are hiring. And it just doesn't make sense to me. So like things like a whiteboard problem, like never in my engineering career, 10 years of writing code. Had to sit in front of my peers and without them helping me solve a problem on a whiteboard, you know, like there's a collaborative element to like sitting in front of a whiteboard and we all talk about a problem together.

Sure. But like nothing interview style situation. So you're, you're basically asking an engineer in an interview to do something completely be different from what they would do in real life. They don't have their IDE in front of them. They don't have Google in front of them. Like, so I think that's. You know, there's a take problem, but on the other end of the spectrum, like take-home projects have kind of their own problems too.

They they're asking for a lot of free work from somebody. So I do think it's fine. A little better if you're you're paying people or, you know, some time to do that sort of work. What I did though, it was kind of maybe meeting in the middle here. I would. Invite the like, sort of like last phase of engineering or of our engineering interviews was kind of bringing the engineers in to do a pair programming project together.

So we would sit down for a couple hours, you know, Hand to hand solving a problem in a open source library. And so what that did was show like how they work in a collaborative environment, which again is more realistic. That's like more what we did on a day-to-day basis. We were all sitting in the same room at the time and we would just bounce questions around.

We want to know how each other worked, but also just got them into something kind of interesting and fun that they didn't feel quite the pressure. You know, you're being watched like a Hawk or you have so many hours to do this your own. I don't know. So that was our approach or the approach these last few years.

I'm sure there's, there's ways to continue improving that or there's ways to keep making things better. But I like anything that gets, gets us closer to the engineer doing the actual job, rather than doing arbitrary skill check.

[00:22:24] Matias: yeah,

it's I really love that thing about working together. And even more than the take away the home type of interview or the psychologist type of interview or the whiteboard in like with graphs and sorting algorithms. And I can remember how a bubble sort works. I know it says I just write sort done.

Yeah. And that's brings us to 2020 a pandemic hit the world. So the company where you're working was actually out of clients as many of us. And you look for another way and that other way becomes draft.dev. Right. So what is draft.dev and why did you jump between actual developer to other other thing that's quite related?

And we will talk about that, but it's completely different. 

[00:23:19] Karl: Yeah. Yeah. So like what we do at draft.dev now is we write technical blog posts and tutorials for companies that sell tools to developers most of the time. So if you're a hosting company and you want to write helpful content for software developers, you have to have that content written by developers.

You can't have a marketing person or whatever, go write your tutorials and how to use your hosting. Right. That doesn't work. So we come in with the big team of software developers who have expertise all over the world and in all sorts of different technology to help those companies write these kinds of blog posts.

And then we pay the writers and the company pays us. We also have editors. We have illustrators, it's actually grown a lot this year. But, but not to get ahead of myself. So what I, when I started it, honestly, it was not like I didn't have my like grand aspirations. It was kinda like, I, my job went down to half-time because the pandemic was, was hitting us hard.

We had to let go of a bunch of people. And half-time would keep me in a job without taking too much from the company at the time. They, they just couldn't afford to keep everybody full-time. So me and a couple other people were halftime. And it was kind of nice because I was like, well, I got a lot, I got extra free time.

My wife fortunately had a job that, you know, kept us from having any financial hardship because of it. Saved up money too. So like we were in a very fortunate position compared to a lot of people. But I think you're, you know, I've got 20 hours a week or more that I can do something on my own. So I started just writing on the side.

Like I'd always written my own personal blog and every now and then a company would reach out and ask if I would write a blog post for them and I'd do it. But I decided to start asking and seeing if I could get people to pay me to do it. I found a big list of places on the internet that will pay software engineers to write.

And then I helped started working with the guy who maintained it to like expand the list and you know, got accepted to five or 10 places probably pretty quickly and started writing articles. I was writing, I was probably writing like five to 10 articles a month for a month or two. And then. You know, within, within a month or two, it was clear.

There was way more demand for this kind of writing than I could supply on my own. And so I, then I started really think this could be a company. And so I told my employer, I was going to phase out, you know, and they, it was kind of like, they understood the timing based on everything that was going on. So I took actually, it took quite a while, like three or four months to go, you know, slowly wind down just to help them make the transition easier.

And, and so it was really a nice, smooth transition into. You know, going from being a full-time developer and developer leader to then like running this tiny team of me and two or three other writers at first writing a bunch of content and, you know, it's grown really quickly this year, but the first few months are tough.

I mean, mentally there's a big switch between being an employee and being a F you know, owner of a business. You know, if you've ever done freelancing, full-time. Kind of scary, but then it's, even to me, what was even scary, it was letting other people have the reigns in a way, like giving assignments to other writers and being like, okay, I hope they don't screw this up because if they do the whole, thing's going to look bad for me.

You know? So there's a, there's like an element of that. I would just, I remember like waking up at three in the morning and just being like, oh God, I hope they finished that article on time. I hope they finish it. You know, at first, just having this anxiety I don't know. Yeah. It's it's it's it was a scary thing.

at first.

[00:26:29] Matias: Yeah.

And it's actually a completely different type of task because I guess that you were really more comfortable by sharing responsibility about a piece of code, even if it's updating code in production than technical writing. That is quote and quote new. For so many of us the link you mentioned is the, who pays technical writers.

That com that list. 

[00:26:53] Karl: That's one of them. You know, we actually have a GitHub repository called community rider programs. But they're both good. I can send you the link here. 

Yet it's it's there's the, you know, there's a, I don't want to say there's a ton of resources for people who are, there's probably not enough resources for developers who want to get into writing, but at the same time, it's becoming a more visible career path or like a viable career path, maybe.

And so whether it's this kind of writing, or maybe you're doing like more documentation kind of writing there's there's jobs. It tends to, I don't want to, I'm not going to like sugarcoat it. The hourly rate is usually not quite as high as regular software development, but if you want a change of pace, what would I really liked about it was that I could write code just like I could write a demo project and never had to make it.

Production ready. You know, like that was kind of fun because it's like, here's the, here's like a, maybe an example. Like I was writing articles about Kubernetes and running Kubernetes in production is just a huge pain. There's just so much involved in it. And it's like, it ends up, you kind of go down this rabbit hole thinking, oh, well, here it is.

It's running in their own way. We've got a hardened desk. We have to deal with these kinds of ports. We have to deal with this kind of logging. Like it just ends up like cascading into this huge mess. And you realize you're just doing a lot of operational work just to keep it going. Whereas, if you're just doing a tutorial on how to get your first Kubernetes app running in whatever language, I guess it's pretty easy.

It's like, you takes you an afternoon, you learn it and then you write it up and then you're done, you know?

[00:28:23] Matias: I guess what? I want to add something to that. Yeah.

Even though it's quite easy to create demos. Sometimes the demo can be really cumbersome just because you're trying to teach something so complex or deep that you end up thinking more about how to demo this. Because one thing is to demo and application that get up and running with something done.

Other things is trying to demo. What happens if you don't do what you should do. And, and that's actually really hard, but technical writing is really awesome for learning for sharing content. And it's kind of an lightning moment. Like a bulb moment. When you find out that you can get paid. By writing people, people have been writing in internet for so many years, like blogs and so many, a free content than somehow.

So you learn that you can buy a Mac book. I actually, I buy, I just bought my Mac book recently, recently received it from technical writing. And 

[00:29:26] Karl: That's awesome. 

[00:29:27] Matias: have, I'm excited about that. So, Yeah.

it's 

[00:29:30] Karl: Yeah, no, it is. And even if, you know, so I did it for years on the side without getting paid or getting paid very little because I was just, I didn't have that much time to go into it seriously. Right. And I was making fine money as an engineer, so I didn't really care. But even if you just do it for free or on your own blog or whatever, it opens up new opportunities that I would not have thought about.

So I'll kind of like a couple examples of this. I wrote a lot about job board API APIs a few years ago, and I literally still get people at least a couple of people a month who reach out to me saying, Hey, do you still work in job board API is I've got a project that I'd love to hire a developer for.

I mean, like if I had made a consulting business off of that, it would be a viable business. And it's just off of like a few blog posts. What five, six years ago now. So these things kind of like they hang around in the internet longer than you think, and they kind of compound, especially if you pick a kind of focus area and like try to really like nail all the different topics in that little focus area, people will start to know you for that thing.

And you know, it might take years, but years is not that long in the grand scheme of your career. I think that's another thing. People early on kind of misses the, the value of just consistency over time. So my personal blog is a good example. We were talking about portable CTO in that newsletter. Just having it around for 10 years, an update, maybe having one post a month for the first nine of those years.

It just picks up a lot of like links and it picks up traffic. And you know, now I'm getting, I don't know, 20,000 page views a month or maybe more some months. And so it's not like, you know, not making a living off it, but it's just a small, personal blog. It's not like anything super serious. So it just builds over time and you have to just stick with it at least somewhat consistently, if you want to get a lot out.

[00:31:08] Matias: And if we consider that currently we're living under an explosion of content creation and people is caring a lot about that process, kind of creating your blog and compound that is even in a shorter period of time, you can kind of grew a personal brand. That is basically what you do. You earn my personal brand really quickly compared with the years before 2020, kind of 2020 craziest opportunity. yeah.

Of technical writing or creating content to build this career at the side, like people can get, you get to know you because of your writing. Yeah. In the draft.Dev site, you actually mentioned that personal branding stuff like so like saying if you want to create to grow your personal branding, writing can be a good tool.

And if you get paid for that, that's amazing. So what are kind of the process for draft two to become a, a writer you need to have many writing experience to, to be a writer. 

[00:32:14] Karl: yeah, we, at this point we have a lot, we get a lot of applicants, so we've been, you know, we've had our applications open for months now and I do a lot of getting out into the community just to make sure people know about it. I've had a couple, I run a couple of newsletters besides portable CTO. I run one called CFP land, which is for conference speakers.

And so I get a lot of applicants for draft to write for draft through that as well. So we actually get, I think over a hundred applicants a month right now, and we probably only take one to five of them a month, depending on how many new clients we get and kind of how, what the topics they're covering are.

So it's a, it's pretty selective at this point. We do look for mostly people who. A fair bit of writing experience out there. You know, I wouldn't discourage people. Who've only written two or three posts from, from applying, but just know that, you know, you're, you're kind of facing it's a bit of a challenge here.

But there are tons of other places that you can go, right? So like, you know, we're just one of like this list, this list we'll. It has got like 40 or 50, at least places that pay people. And you know, some of them are more open than us. So I could with draft.Dev because we're working with clients who want specific topics covered, we send out kind of a list of here's all the topics we need covered this week.

Whereas other places, bill, let you pitch any story you want. And so that can be a way to kind of like start to start to get more samples out there, get more practice. A lot of them too will they'll have a professional editor that they'll pair you with. So you'll get a lot of feeds. We we do too. But like, you know, again, like if you don't, if you're not ready quite to get into our program.

But yeah, if you want to apply, we do draft.dev/wright. And you know, especially if, yeah, right now, I think we're looking for senior mobile people and always Kubernetes people, lots of Kubernetes stuff going 

[00:33:56] Matias: Yeah.

I saw a big list of Kubernetes

[00:33:59] Karl: Yeah.

[00:34:00] Matias: content. It looks like not, there is not much technical writing at that side, or at least the web development or mobile development is kind of overtaking the, the information wave. One thing that is really amazing when you start writing for someone else is the editing process.

And it's kind of nice too, to receive that kind of feedback. But if you don't have feedback like that, please use tools like Grammarly or language tool. None of that is a sponsor of the show. So nevermind, but did that helps you a lot 

[00:34:34] Karl: agreed. And, and I would say that I would also encourage people, even if you're not a native English speaker or you maybe are a little self-conscious about your English ability. That's actually for a lot of programs, not the biggest barrier. Because a couple of things, one is like you said, they'll pair you with an editor.

And so it's fine. Like you can get some of that stuff we can help you fix. The other thing. You're having unique technical skills is probably the more valuable in the equation of writing versus technical skills. At least for us. And I think it's probably true for a lot of the community writing programs is just having an interesting background or some different technical experience that is maybe unique.

That's going to get you a long way as well. So, you know, don't, don't think that just because your English is not the strongest, you're not going to ever be able to write. That's definitely not true.

[00:35:21] Matias: One question that I left kind of behind. Why did you start writing? You are by your story, why you starting writing and that came alone to build draft, but at some point you were not writing and then you were all my amazing writer. I don't know. 

[00:35:38] Karl: I don't know about amazing writing. I, I it gets easier. The more you do it and you get faster, the more you do it. So you just get to push more out. Like the more you push out, the better you get at something, you know, it's just like writing code. If I wrote 10,000 lines of code every day, eventually I'd get pretty good at code.

If I wrote 10,000 words of, you know, pros every day, I'd get pretty good at that. So I've been writing on my own since high school and college for fun. I actually went and went in college. I roomed with a bunch of English majors, so we were a bunch of nerds for different things. I was a nerd for engineering.

They were nerds for English and we would stay up late at night and play this. Story writing game, where you give each other lists of words, and then you have to re write a story around this list of words that people would give you. And this is the nerdiest thing ever, right? This is like, 

[00:36:22] Matias: There were whiskey or bourbon or something like that 

[00:36:25] Karl: there's a little, yeah, there's some alcohol involved, but like, it was still such a like such a nerdy thing to do on a Friday night.

But that was so, anyway, I guess I've always enjoyed it. I always assumed, you know, being the practical engineering type, I've always assumed it would be impossible for me to make a living as a writer. I just. I don't even think I realized this was a viable path until I started doing it. And so I would say, you know, and, and maybe I'm never going to be like a, a, you know, a fiction writer or some somebody leaves like published as a famous author or anything like that.

But even, even if you don't go there, there's plenty of ways to make a living writing full time. And I think that was what it really showed me by getting into, into this field and then starting the little company.

[00:37:06] Matias: So I know that we already said that you're not an advice type of person, but any advice to someone that wants to start writing, and maybe he's afraid of that. Although. Have this feeling of the blank page that, you know, this blocking that I will write something that the final guide about, I don't know, rust, and then you'll face this white empty screen and you write nothing for months. 

[00:37:34] Karl: Yeah, so it's, it's intimidating. And like you said, a lot of times there's this concept called the gap, which Ira Glass talks about in a video. I'll try to send you that link too. And the idea is there's this huge gap between. What you know is good and what you can actually create if you start to become a creator.

And so in other words, if I read a really good novel, I might get really good at analyzing novels and realizing what's a good novel, right. But for me to write a good novel, there's this huge gap between being able to understand and see a novel as good and actually write it. So that gap paralyzes a lot of people.

So the thing you have to do, or the thing I do is I make that gap smaller by just saying, I want to write one really good. Paragraph or one really good idea or maybe just a good outline and get started there and just slowly build up from there. So the other thing too is like that I tell new writers is just because you wrote it.

You know, the ultimate guide to JavaScript once doesn't mean you can't come back and write the new ultimate, giant guide to JavaScript. Like I, in fact, I think the best writers tend to write about the same topics over and over again. And you'll only see the really good versions of them that get out into the world, but they probably did 10 different versions.

Behind the scenes that you, you didn't see. So just keep writing and keep doing it. Start small with little achievable wins, even if it's just writing a hundred words in your diary every day or a tweet every day, and you will start to pick up ideas and get better at it.

[00:39:00] Matias: Yeah, I think that last question about writing is why developers that enjoy write code could want to write content like tutorials kind of. 

[00:39:15] Karl: Yeah. I like writing tutorials, to be honest, like they're, they're kind of time-consuming as far as writing goes, I mean, like, there's, there's, there's a lot of different kinds of technical writing or even the blog posts we write for clients. Like they might be kind of high level overview posts that just takes some research or they might be, you know, hands-on right.

This demo app and all that. And that can take a lot of time, but what it does, it does a couple of things for me personally. One is it gets me. W I would say like learning and struggling with something I haven't done before, which is always fun. There's this like reward in software engineering. It's like, you figured out how to solve a problem with just code, you know, like that is really fun to me.

I still enjoy that. Now that I don't write code every day. So that getting those like hits the rewards from learning a new thing is great. The other thing that's motivating is like that article is going to go out there into the world. And for years, people will be able to search and find it in my name is attached to it.

And so is it really important for us at draft? Like all of our work is credited to the author. It's it's meant to build them up as you know, their career up as well. So it's like a mutually beneficial thing. Sure. You're writing this article for a client, but it's also going to be showcasing your knowledge.

And when another employer down the road wants to see you prove that you've built a react app, you say, oh, I've not only built a react app. I've written this tutorial for it. And here it is published. So like on my resume, it's been a few years since I update it, but I always have. Links to things I wrote about each line in the resume.

So that way I wasn't just saying, I knew this and this, I wrote a blog post about it, and then I linked to it. So you could just go prove that I knew that right there and wouldn't have to, wouldn't have to mess with the interviewer. So I thought, I dunno.

[00:40:58] Matias: Yeah, I also that's helps you when you, you are writing a, behind in writing code behind NDAs. So you cannot show your work, but you can say that you really know because wrote this

[00:41:10] Karl: that's a, yeah, that's an excellent point. It's like when you're most companies, I mean, you're not going to be able to share your source code that you actually did. And some companies may not even let you do open source work. But maybe you can write blog posts, you know, on the side for free or whatever, or paid To help you just showcase like, Hey, actually do know some of this stuff.

[00:41:28] Matias: So Karl, this has been fun really insightful. And, but we are almost at the end of this episode. So anything you want to share with the audience 

[00:41:39] Karl: I mean, I. I really like helping other engineers find unconventional paths. And I think that that's why I like coming on. You can get it to people like yourself who kind of have had unconventional paths as well. It's fun to talk about this stuff to me. So if you ever have questions or things you want to run by, I'm on Twitter.

It's @karllhughes. That's my preferred medium for cold outreach, but you can also email me too. Yeah, I, I, at this point, not really looking for anything specific, I guess, if you want to apply to write for draft.dev you can go to draft.dev/wright. If you're into that or feel free to reach out directly to me too, but yeah, it's a, it's a pleasure to be on and get to nerd out on some stuff.

[00:42:21] Matias: And then last question I do to every guest is about a recommendation. Something you love, something you like and something that you want to do, something that just, you want to share with the world, whatever, whatever it is, this. 

[00:42:35] Karl: so three things or you want 

[00:42:36] Matias: one two, Whatever.

but I mean, something that you really like, and you want to share with their, share your love. 

[00:42:45] Karl: Yeah. So I, the, the thing that comes to mind immediately, this is totally random, but I, you know, started a business last year. Yeah. I had never like really started a company before in college. I freelanced a little, but like, this is, this feels different. And one of the books that sort of got me got me going at first is called big magic by Elizabeth Gilbert.

If you ever think about starting a company or doing a like creative thing, like becoming a writer full time, she actually, that's what her book is about as basically her journey to becoming a writer. I don't even particularly like her writing to be honest, like her books, but this one was really interesting because.

It shows you the struggle that other writers go through, that you don't get to see a lot of times you see the end result, you see the person like me, who's had some degree of success or you see Elizabeth Gilbert. Who's like a best-selling New York times published author or whatever you want to say, like amazing successful person, but she spent 10 or 15 years behind the scenes doing nothing that anyone would have heard of, you know, just like struggling every day.

But she came to work and did it every day. And she talks about that a lot. And I think that's kind of the thing about. Most successful people. There's, it's not a linear movement from like, you know, I'm new at something to, I'm a extremely successful it's it's what are they like? I get exponential essentially.

You start off very bad for a long time before you finally start to pick up really quickly. So success is exponential. So think about it that way and just like, keep chugging, keep trying things, keep, keep learning.

[00:44:12] Matias: I like it exponential. Yep. That makes complete sense. So. Thank you Karl for being here. I enjoyed this conversation, so yeah. Thank you. 

[00:44:22] Karl: Yeah, thanks for having me. 

[00:44:24] Matias: And we hear us in the next episode next week. Thank you for being here.