Consejos para desarrolladores de software nuevos que ya leyeron todos los demás ensayos de consejos
(buttondown.email)- Al inicio de la carrera, incluso los consejos de desarrolladores famosos no deberían seguirse al pie de la letra; primero hay que evaluar si aplican a tu situación, y muchas afirmaciones en el campo del software no tienen demasiada evidencia concluyente
- Si una idea te gusta, puedes probarla por tu cuenta, pero pasar por ensayo y error sin estorbar a tus colegas forma parte del proceso de aprendizaje
Debugging: The 9 Rulesse recomienda como un libro introductorio fácil sobre una habilidad de depuración que los libros para principiantes suelen dejar de lado- La “forma correcta” o las “mejores prácticas” muchas veces surgen de casos concretos de fracaso y trayectorias históricas, así que conviene distinguir entre la técnica en sí y la forma en que se difunde
- Exponerte desde temprano a funciones ocultas de las herramientas, al trabajo de otros departamentos y a distintos tipos de programación facilita encontrar el trabajo de software que mejor encaja contigo
Actitud ante los consejos
- Los consejos para desarrolladores que circulan mucho a veces se difunden no porque quien los escribió sea un programador excepcional, sino porque escribe bien
- No hace falta rechazar automáticamente todos los consejos, pero sí conviene evaluar con cuidado cómo se aplican a tu propia situación
- Las afirmaciones sobre “verdades objetivas” del software deben tomarse con cautela; no hay mucho estudiado científicamente y, en general, los resultados de investigación no son muy concluyentes
- No hace falta preocuparse demasiado por aprender “lo incorrecto”
- Si te gusta la idea de alguien, puedes probarla tú mismo
- Mientras no obstaculices activamente a tus colegas, incluso si más adelante miras atrás y piensas que deberías haberlo hecho de otra manera, probablemente terminará siendo aprendizaje
- Debugging: The 9 Rules es un libro recomendado para desarrolladores principiantes
- Es fácil de leer y trata una habilidad importante, la depuración, que otros libros para “programadores principiantes” casi no cubren
- También puedes pedirlo prestado en una biblioteca o solicitar que tu empresa lo compre
Los límites de la “forma correcta” y las mejores prácticas
- En algún momento podrías descubrir la “Right Way” de programar y convencerte de que, si todos la siguieran, el campo mejoraría
- Se mencionan como ejemplos desarrollo guiado por pruebas, programación funcional, Lisp y métodos formales
- Es difícil evitar entusiasmarse con una de esas formas, y puede ser una experiencia agradable, pero lo importante es no convertir tu identidad en la de “Right Way Guy”
- Con el tiempo aprenderás que, sea cual sea el enfoque, programar puede ser frustrante y desordenado, y que se puede construir software excelente sin usar ese enfoque
- Cuando conoces varias “Right Way”, puedes combinarlas según el problema
- La primera “Right Way” que encuentres probablemente venga de alguien completamente entusiasmado con ese enfoque
- Más adelante, no conviene culpar demasiado a esa persona; es mejor no confundir la técnica real con la forma en que la promociona
- Muchas ideas necesitan ajustarse un poco para usarse junto con otras, en lugar de aplicarse en su forma pura
- Como dice Julia Evans, “detrás de toda mejor práctica hay una historia de terror”
- Si hay una mejor práctica que no entiendes, puedes buscar el caso de fracaso que la originó
- Si ese caso de fracaso no tiene relación con tu situación, está bien elegir otro enfoque
- Muchas mejores prácticas y convenciones son dependientes de la trayectoria
- Puede ser una práctica que sigues porque la seguía tu mentor, y que tu mentor seguía porque la seguía su mentor anterior
- Una forma creada para resolver problemas del pasado puede ser menos relevante hoy
- Las convenciones que suenan como explicaciones plausibles inventadas después de los hechos pueden ser exactamente eso, y si investigas puedes reconstruir cómo se formaron
Cómo ampliar el criterio práctico
- Salir a caminar se propone como un hábito útil para ordenar las ideas
- La mayoría de las herramientas que usas tienen una profundidad oculta
- No necesitas dominar a nivel experto lenguajes de programación, Git, JIRA ni herramientas similares
- Pero sí se recomienda invertir unos 5 a 10 minutos en averiguar qué más pueden hacer
- Hablar con personas de otros departamentos dentro de la empresa amplía tu comprensión del trabajo
- Puedes conversar con soporte, áreas del dominio de negocio, ventas, etc.
- Si tienes tiempo y es fácil pedirlo, también se sugiere acompañarlos para ver cómo trabajan
- Al inicio de tu carrera, si es posible, conviene experimentar con varios tipos de programación
- No necesariamente tienes que cambiar de trabajo; la mayoría de las empresas hacen varios tipos de programación al mismo tiempo
- En una empresa de desarrollo web, podrías probar frontend, backend, operaciones, trabajo con bases de datos, etc.
- Esto ayuda a aprender, pero más importante aún, aumenta la probabilidad de encontrar el trabajo de software que realmente te gusta
- Se incluye el caso personal de que el primer empleo fue en frontend y resultó difícil, pero luego el cambio a backend hizo que la persona fuera más feliz
- El campo del software cambia constantemente, así que tiene sentido el consejo de no dejarse arrastrar por las modas de frameworks y concentrarse en habilidades fundamentales
- Por internet, el open source, las conferencias y otros canales, la información del campo del software se difunde muy rápido
- Como las barreras para compartir ideas son bajas, incluso un proyecto personal usado por una sola persona puede parecer algo que mucha gente conoce
- Muchas de las tecnologías de las que oyes hablar pueden tener una base de usuarios pequeña y no estar ampliamente adoptadas
- Si te interesan mucho, está bien ser early adopter; si no, también está bien esperar unos años y ver si realmente perduran
- Nadie puede predecir el futuro, y el presente también es el resultado de cosas que eran difíciles de prever
- Hace falta hacer lo mejor que puedas, vivir de acuerdo con tus valores y disfrutar el proceso
1 comentarios
Opiniones de Hacker News
En un proyecto reciente de hobby trabajé con un desarrollador junior y otro no tan junior, y ambos estaban obsesionados con “la forma correcta”.
Para un bot de Discord + código en Rust de unas 300 líneas que solo íbamos a ejecutar nosotros, exigían documentación completa, VMs separadas para QA y “producción”, despliegue con systemd, un sistema de plantillas para unas pocas cadenas de texto, e incluso una capa ORM para cuatro consultas SQL.
Era un proyecto que usarían, como mucho, unas 10 personas, y eso era apenas la mitad de los requisitos de la versión “0.3”; además, estaban planeando diseños todavía más excesivos, así que me bajé del proyecto.
Al comienzo de mi etapa programando yo también fui así durante varios años, pero aprendí que en ciencias de la computación hay cosas mucho más profundas que las mejores prácticas o el estilo de código, y que al final lo importante es código que funcione.
Es decir, dedicar una cantidad desproporcionada de atención a detalles insignificantes en vez de al problema central; está la analogía del comité que aprueba una planta nuclear y, en lugar de hablar de la planta, discute solo el color del cobertizo para bicicletas de al lado.
En este caso, concentrarse en separar VMs de QA/producción, despliegue con systemd, plantillas para unas pocas cadenas y un ORM para unas pocas consultas SQL en un proyecto para 10 usuarios parece un ejemplo típico de la ley de la trivialidad.
Estas partes son especialmente fáciles de entender y debatir para desarrolladores junior, por eso tienden a meterse más ahí, mientras que las funcionalidades centrales difíciles suelen quedar descuidadas.
Eso sí, documentar bien las partes significativas del proyecto no me parece obsesionarse con nimiedades.
Cosas como escribir una unidad de systemd o usar un ORM no llevan tanto tiempo como uno pensaría, pero después ayudan bastante cuando alguien revisa el proyecto o cuando otra persona quiere contribuir.
Es más fácil hacerlo mientras el contexto todavía está fresco en la cabeza, y una vez que el proyecto crece, esas tareas misceláneas casi nunca se atienden.
Al ser un proyecto de hobby, quizá justamente querían hacerlo bien para aprender herramientas y sentir satisfacción.
Al principio hay una escena en la que necesitan comprar un router de 50 dólares; cuando uno de los personajes sugiere intentar reparar el router existente, los otros responden “ya lo intentamos” casi antes de que termine la frase.
Eso muestra que se conocen tan bien y pasan tanto tiempo juntos que casi se leen la mente.
Pero cuando alguien dice “yes” a comprar el router nuevo, otro responde que hace falta un “aye”.
Es decir, la regla sobre la palabra que debe usarse al votar decisiones del negocio secundario es muy estricta; no importa si son tan cercanos que se terminan las frases, si es un router de 50 dólares o si los ingresos del negocio son insignificantes.
La regla exige aye.
Algunas de las personas obsesionadas con “la forma correcta” parecen haber tenido éxito copiando el conocimiento almacenado en la inteligencia colectiva social, pero sin entender muy bien qué ocurre realmente en su propia cabeza.
Tiene la ventaja de heredar metodologías probadas sin tener que descubrirlas con esfuerzo por cuenta propia, pero la desventaja de no entender literalmente en qué situaciones ese método llevará al fracaso.
En el comentario del director se dice que esta escena se incluyó intencionalmente para mostrar que algunos personajes se toman las reglas demasiado en serio, y otros no lo suficiente.
La razón para recomendar a otros estas prácticas de culto cargo parece similar: si más personas las siguen, cuando esa práctica fracase de forma desastrosa será más probable que quien fracase no seas tú.
Hoy veo estos casos demasiado seguido, y a estas personas las llamo juniors inteligentes. No importa si tienen 1 año o 20 años de experiencia.
El junior inteligente conoce la mayoría de los patrones de diseño y también leyó The Mythical Man-Month, pero quiere probar tecnologías, lenguajes y frameworks nuevos, así que sale corriendo con un martillo nuevo y brillante buscando cosas que parezcan clavos.
Entonces toma decisiones raras porque no entiende la potencia que puede dar una base de datos vieja y bien optimizada.
Con 20 años de experiencia, he visto muchas veces cómo terminan esos proyectos 5 o 10 años después, cuando más de la mitad del equipo original ya se fue, y conservo las partes que realmente aportan valor mientras recorto la mitad inútil.
No estamos manejando un jardín de infantes para desarrolladores que buscan divertirse a cualquier costo; trabajamos para negocios que pagan y esperan resultados estables y relativamente rápidos.
Probar cosas nuevas por estar en la vanguardia tecnológica o para evitar el aburrimiento, a largo plazo, rompió más cosas de las que arregló.
Hay que incorporar tecnologías que todo el equipo pueda entender y dominar, no traer algo que solo conoce una superestrella aburrida.
Si quieres llenar tu currículum con muchas tecnologías, hazlo en una empresa de ese tipo; esas empresas también tienen lo suyo.
Pero, de todos modos, muchas veces estas personas no se quedan mucho tiempo, así que el valor agregado total también es dudoso. Para algunos será aburrido, pero yo a esto lo llamo una forma experta de trabajar.
Si el objetivo de un proyecto personal es lograr que las empresas miren tu GitHub, eso también puede verse más convincente.
La documentación es muy importante. Tengo proyectos bastante simples de menos de 300 líneas, incluidos bots y web scrapers, que ahora no puedo ejecutar porque no los documenté.
La Raspberry Pi donde corrían murió, y no tengo claro cómo arreglar el framebuffer virtual headless ni cómo depurar errores desconocidos para los que las búsquedas no arrojan resultados útiles.
Si los hubiera containerizado, o al menos hubiera documentado el procedimiento de configuración, no tendría estos problemas.
Es un buen texto y me gustaría que lo leyera más gente
Tras 15 años trabajando en software, especialmente en gestión de datos, aprendí exactamente esto
También me ayudó mucho el Kesamutti Sutta, que conocí por mi trasfondo en el budismo Theravada
Dice que no sigas algo tal cual solo porque lo has oído repetidas veces, porque es tradición, porque es un rumor, porque está en las escrituras, porque es una conjetura, un axioma o una lógica que suena plausible, porque tienes un sesgo hacia una idea que has considerado durante mucho tiempo, porque alguien parece competente, o porque lo dijo tu maestro
El consejo de aceptarlo cuando uno mismo sabe que “esto es bueno, no es censurable, los sabios lo elogian y, si se practica, conduce al beneficio y la felicidad” me ha sido muy útil en la vida, incluso después de volverme ateo desde la secundaria
Hay quienes sostienen que alguien distorsionó la traducción para que pareciera tener un sentido más racionalista
Si es cierto, es una pena. Quería creer que Buddha era una persona tan “iluminada”
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
Me identifico con la parte de no preocuparse demasiado por haber sido “engañado” o por haber “aprendido algo incorrecto”
¿Aprendí TDD cuando estaba de moda? Sí. ¿Uso TDD ahora? No. ¿Aun así TDD me enseñó a escribir mejor código? Sí
Lo mismo pasa con lenguajes que ya no uso profesionalmente. Todo enseña algo
No se puede encontrar un buen punto medio sin pasarse un poco hacia ambos lados
Si ya tienes código y quieres ampliarlo, tiene sentido escribir algunas pruebas alrededor de cómo se usa
Si todavía no hay código, pero tienes una estructura en la cabeza y puedes separar qué partes construir primero y luego probar, también tiene sentido
No es TDD en sentido puro; se parece más a desarrollo asistido por pruebas, pero aprovecha el espíritu de TDD
Aprender cosas malas también es una parte importante de entender qué enfoques son mejores o peores
No quiero decir que TDD en sí sea malo, pero puede volverse malo si uno se obsesiona demasiado con él
Al final, conecta con la idea común de que “los errores son el camino del aprendizaje”
Estas pautas y principios suelen ser buenos de conocer, pero el problema aparece cuando la gente los adopta como una religión
En nuestra industria, los ideólogos son un verdadero dolor de cabeza
Es breve, adecuada y pega de inmediato
Es un buen texto y un buen consejo
Al final, cuando se termina la luna de miel, aprendes que, uses el “modo correcto” que uses, programar es frustrante y desordenado, y que también puedes crear software excelente sin seguir ese modo
Con el tiempo aprendes docenas de otros “modos correctos” y los mezclas según el problema
Pero en los últimos años parece que muchos desarrolladores quedaron atrapados en la obsesión por el modo correcto y no logran ampliar sus conocimientos ni su perspectiva
Si es cierto, es triste, y no sé bien cuál es la causa
Puede que, por la menor capacidad de atención de estos tiempos, sea difícil ampliar conocimientos de forma eficiente, y que la posición actual se haya vuelto demasiado cómoda
O puede que las recompensas por aprender solo ciertos frameworks sean demasiado grandes, y que falten incentivos para aprender conocimientos básicos sobre cómo funcionan por dentro
Por eso no tienen tiempo de aprender lecciones del trabajo actual, y para cuando esas lecciones les llegan, es muy probable que ya se hayan ido
Al mismo tiempo, tampoco pueden darse el lujo de no concentrarse en la nueva tecnología de moda
Esta dinámica bloquea mucho el crecimiento
Mi consejo de 1 centavo es este: el estado es el enemigo. Hay que reducir el estado en todos los lugares posibles
No solo el estado dentro del código, sino también la cantidad de cosas que tienes que mantener en la memoria de corto plazo para trabajar, e incluso los detalles específicos de cada proyecto que debes recordar
El estado es el enemigo. Si puedes derivarlo desde primeros principios, siempre deberías intentar hacerlo
Algunas de estas cosas van más allá de consejos solo para programadores
El primer punto es algo que todos deberían meditar. Muchos autores y ensayistas son leídos no porque sean expertos en el tema, sino porque escriben bien
También hay que salir a caminar
Conviene probar distintos tipos de trabajo y aprender también otros roles dentro de la empresa
Especialmente en empresas grandes, lo que uno hace puede ser algo que luego tenga que corregirse o rodearse en otra parte, y quizá si uno lo cambia, todo se vuelva más fácil para todos
El primer punto también explica por qué hay que desconfiar de lo que se aprende en servicios de video compartido como YouTube
Si alguien habla con confianza y presenta una idea de forma profesional, la gente la toma en serio aunque tenga fallas
En un mundo donde se descubrió que algunos “ensayistas” básicamente se limitaban a leer artículos de Wikipedia y publicaciones de Reddit, hace falta una actitud que intente separar la apariencia convincente de la expresión de la exactitud
También quisiera ampliar más el punto 10. Hablar con las personas involucradas permite ver mejor qué problema busca resolver el software o el trabajo de desarrollo, y también encontrar puntos de dolor que uno no había visto
Salvo contadas excepciones, el software no se escribe por sí mismo, sino para resolver problemas
Pueden haber leído en algún lugar de internet o del proceso de entrenamiento una respuesta “correcta” y repetirla de forma convincente sin considerar si realmente es verdadera
Me gustó tanto el libro de debugging recomendado en el texto que compré varias copias para regalarlas
Se lo di a amigos, pasantes, científicos de datos e incluso a ejecutivos, y todos los que lo leyeron me lo agradecieron
Contiene algunas técnicas simples muy buenas para resolver problemas en sistemas técnicos grandes, así que es útil para casi cualquiera
Es fácil de leer e interesante, y tiene muchas “historias de guerra” que agregan color y contexto a consejos que de otro modo podrían resultar secos
https://debuggingrules.com/
La frase “la gente me escucha no porque sea buen programador, sino porque soy buen escritor” no solo significa que hay que tener cuidado al leer el contenido de buenos escritores; también aplica a la forma en que encaramos nuestro trabajo.
Si escribes bien, por lo general también mejoras tu capacidad para tratar con otras personas.
Para un desarrollador de software, escribir y comunicarse son tareas centrales.
Si eres principiante, recomiendo escribir sobre las dificultades que enfrentaste, tus experimentos y tus procesos de pensamiento.
Si puedes, también deberías escribir ensayos. Será una habilidad realmente útil más adelante en tu carrera.
Hay una frase que es difícil explicarle bien a un principiante: “tu trabajo no es escribir código”.
Usamos el código como herramienta para resolver problemas.
El código es un medio para alcanzar un objetivo, no el objetivo en sí.
Si programas por el código mismo, terminarás obteniendo malos resultados.
Debes enfocarte en resolver problemas y, si no tienes claro qué problema resuelve tu código, debes dejar de programar y averiguarlo primero.
Según la empresa, puede ser correo electrónico.
Responder preguntas, colaborar e influir en el rumbo del equipo y de la organización puede sentirse como el trabajo, pero la comunicación, igual que el código, es una herramienta para crear algo útil; no es útil por sí misma.
Creo que la mayoría del código, incluso el código escrito como “código por el código”, sí resuelve algún problema.
Muchos programadores también lo saben, al menos de forma inconsciente, y por eso escriben ese tipo de código.
El verdadero problema es que otras personas, por ejemplo la gente de negocios de traje, quieren que ese código resuelva otro problema.
Pero ese código tiene que ser el código correcto.
De forma más general, lo explicaría como “resolver problemas de negocio aplicando sistemas de software”.
Si se lo dices así a un junior, se enfocará en las necesidades del negocio y podrá evaluar críticamente lo que dicen los MBA, gerentes o PM para hacer lo correcto.
Pero el simple hecho de tener software que venderle a un VC tiene valor.
Por eso, a veces realmente te pagan por escribir código.