Temas de desarrollo de software en los que cambié de opinión después de 6 años en la industria
(chriskiehl.com)Cosas sobre las que cambié de opinión: cosas contra las que antes peleaba, pero en las que ahora creo
- En equipos formados por personas con distintos niveles de experiencia, los lenguajes con tipado son mejores
- Las reuniones standup son útiles para observar a la gente nueva
- Las retrospectivas de sprint tienen partes útiles y partes malas (cuando el agile/scrum master hace perder el tiempo a todos)
- La arquitectura de software es más importante que cualquier otra cosa. Una mala implementación de una buena abstracción no daña la base de código. Las malas abstracciones o las capas faltantes hacen que todo salga mal
- Java no es un lenguaje tan malo
- El código ingenioso por lo general no es buen código. La claridad está por encima de todo
- Es posible escribir código malo en cualquier paradigma
- Las "best practices" dependen del contexto y no aplican a todo. Si las sigues a ciegas, eres un tonto
- Diseñar un sistema escalable cuando no se necesita te vuelve un mal ingeniero
- El análisis estático es útil
- DRY no es la meta final, sino una forma de evitar un problema específico
- En general, RDBMS > NoSQL
- La programación funcional no es una cura para todo, sino otra herramienta
Opiniones que adopté en el camino:
- YAGNI > SOLID > DRY : en ese orden
→ You Aren't Gonna Need It : uno de los principios de XP
→ SOLID : los 5 principios del diseño orientado a objetos
Responsabilidad única
Abierto-cerrado
Sustitución de Liskov
Segregación de interfaces
Inversión de dependencias
→ DRY : Don't Repeat Yourself - Lápiz y papel son las mejores herramientas de programación que menos se usan
- Cambiar pureza por practicidad suele ser una buena decisión
- Agregar más tecnologías no es una buena decisión
- Hablar directamente con el cliente te permite aprender más sobre el problema, con más precisión y en menos tiempo
- La palabra "Scalable" tiene un poder místico y sorprendente sobre la mente de los ingenieros de software. Basta con susurrarla para empujarlos a un frenesí corrupto. Usar esa palabra sirve para justificar actos despiadados
- Aunque nos llamen "ingenieros", la mayoría de las decisiones son culto cargo, sin análisis, datos ni números que las respalden
→ culto cargo: costumbre de esperar creyendo que alguien técnicamente avanzado (otra sociedad o los antepasados) traerá una carga especial en barco o avión - El 90%, quizá el 93%, de los project managers podrían desaparecer mañana mismo porque no aportan beneficios en efectividad ni eficiencia
- Después de hacer 100 entrevistas, llegué a la conclusión de que la forma de entrevistar está completamente rota. Yo tampoco sé cómo arreglarla
Opiniones antiguas que no cambiaron:
- La gente que insiste en estilo de código, reglas de linting y otras minucias son unos raritos demente
- La cobertura de código no tiene absolutamente nada que ver con la calidad del código
- Los monolitos son bastante buenos en la mayoría de las situaciones
- Los puristas de TDD son lo peor. Sus pequeñas y frágiles mentes no pueden procesar que existen otros flujos de trabajo
- Cuando llegue a los 10 años, voy a revisar qué más cambió o se dio vuelta
9 comentarios
Cada frase genera mucha identificación. Parece que uno va pasando del idealismo de creer que todo puede ser perfecto al pragmatismo.
Después de pasar 6 años en la industria, temas de desarrollo de software sobre los que cambié de opinión
Cuando entiendes la importancia del TDD, desde ese momento eres programador ...
Sigue apareciendo la opinión de que las entrevistas están rotas. Yo mismo no tendría confianza si me dijeran que haga una prueba de código (...)
También encontré un texto así. Dicen que es contenido que aparece en el libro HARD CODE.
https://johngrib.github.io/wiki/better-interview/
¿Se dio cuenta de estas cosas después de 6 años? Jajaja, impresionante.
¡Así que después de 6 años alcanzaste la iluminación y te convertiste en Buda!
En Hacker News, otros desarrolladores e ingenieros con más de 20 años de experiencia están entrando a dejar comentarios adicionales.
https://news.ycombinator.com/item?id=25887373
Desde el primer comentario vienen con todo jaja. Si revisas punto por punto, seguro también hay casos excepcionales, pero parece peligroso volverse dogmático con cualquier cosa.
Como hay bastantes bugs que se resolverían solo con verificación de tipos, parece que seguirá siendo un tema recurrente. Además, las formas de manejar los tipos de manera segura también siguen mejorando.
(Pero TypeScript sí se me hizo algo difícil T_T)