Cosas en las que cambié de opinión
- La simplicidad no aparece por sí sola; es algo que requiere esfuerzo continuo
- Me di cuenta de que no hay razón para sentirse orgulloso de gestionar o entender la complejidad
- En equipos con niveles de experiencia mezclados, los lenguajes tipados son indispensables
- Java es un gran lenguaje precisamente porque es aburrido
- El REPL no es útil como herramienta de diseño, pero sí lo es para fines exploratorios
- La programación real debería hacerse casi por completo antes de escribir el código
- El desarrollo frontend se ha convertido en una especie de pesadilla kafkiana y ya no es divertido
- El concepto de elegancia no sirve como métrica real
- Una buena gestión es algo extremadamente valioso (a lo largo de muchos años de carrera casi no he visto una gestión realmente buena)
- DynamoDB es una buena base de datos si encaja exactamente con una carga de trabajo específica
- La programación orientada a objetos es un enfoque excelente en los dominios donde encaja bien. Idolatrar solo lo funcional es una tontería
Opiniones que adquirí
- El núcleo de la ingeniería es la comunicación
- No se debe llevar demasiado lejos el concepto de Monad en Java
- El Query Planner es una bestia despiadada
- Cuando algo se siente 'fácil', en realidad suele ser una señal de que no lo has entendido bien
- A los desarrolladores junior hay que darles margen para explorar y equivocarse
- Hay que desarrollar activamente las soft skills. El retorno de esa inversión se nota de inmediato
- En el desarrollo de aplicaciones general, casi no existe algo como una 'abstracción verdaderamente general'. Es mejor escribir solo el código que hace falta
- En cambio, desarrollar librerías consiste en diseñar abstracciones. Vale la pena dedicar tiempo a encontrar la estructura correcta (forma algebraica)
- Los ORM tienen muchos problemas en todos los lenguajes y en todas las implementaciones. Es mejor escribir SQL directamente
- El problema de la programación funcional muchas veces son sus devotos
- Si pasa suficiente tiempo, terminarás arrepintiéndote mucho de haber construido un sistema sobre Serverless Functions
- Los tipos son afirmaciones que hacemos al mirar el mundo
- Los locks distribuidos siguen siendo un problema tremendamente difícil
- La capacidad de modelado y análisis formal es una habilidad imprescindible
- La característica más importante de una suite de pruebas de integración es el aislamiento
- DynamoDB también puede ser la peor elección para el desarrollo de aplicaciones general
- A la mayoría de la gente no le importa demasiado la 'artesanía' del código. Valora a quienes sí les importa, pero colabora con el resto desde donde están
- Creo que los lenguajes con tipado gradual y dependiente son el futuro
- Estoy convencido de que nunca sobran los comentarios en el código de pruebas
Opiniones que no cambiaron
- Sigo pensando que quienes se obsesionan con problemas menores como el estilo de código o las reglas de linting son un grupo raro. Hay que concentrarse en cosas más importantes
- Mantengo la postura de que la cobertura de código no tiene relación con la calidad del código (y en muchos casos incluso tiende a ser inversamente proporcional)
- El monolito me sigue pareciendo una opción perfectamente válida
- Reconozco que es difícil superar décadas de investigación y mejoras acumuladas en los RDBMS
- Para aplicar microservicios es indispensable tener una razón válida (me decepciona que cada vez se dé más por sentado hoy en día)
- La mayoría de los proyectos (incluso dentro de AWS) en realidad no necesitan 'escalar', y muchas veces diseñar asumiendo escalabilidad desde el inicio termina siendo perjudicial
- Sigo pensando que si desapareciera el 93% de los project managers, o quizá el 95.2%, no habría mucho impacto o incluso aumentaría la eficiencia (el porcentaje subió respecto a hace 4 años)
- Planeo ver cómo habrán cambiado estas ideas cuando llegue a los 15 años de carrera
20 comentarios
La mayoría son ideas con las que me identifico.
La mayoría de los proyectos nunca llegan al momento en que realmente necesitan escalar, o desaparecen antes de que eso se vuelva necesario...
¿Qué son los lenguajes graduales con tipos dependientes..?
Escuché por ahí en un pódcast que es un sistema de tipos donde los valores influyen en los tipos. Viendo que el autor de este artículo menciona lenguajes funcionales, seguramente se refiere a eso. Como es algo que se investiga y se desarrolla del lado de los lenguajes funcionales....
Por ejemplo, con el tipo
List... si todos los valores están ordenados, entonces pasa a serSortedList....Si existe una propiedad así, entonces la verificación de tipos podría demostrar muchas más cosas en tiempo de compilación.
Si una función recibe un
SortedListy devuelve unSortedList... pero si el código tiene un bug y rompe el estado de ordenamiento, entonces al compilar saldría un error de tipo.Claro.... el costo de esa verificación de tipos seguramente sería bastante alto...
La verdad no tengo idea de hasta qué punto ha llegado eso en términos prácticos.
Ajá, gracias. Suena curiosamente fascinante...
Se refiere a un lenguaje que permite moverse con flexibilidad entre tipado estático y dinámico, y aplicarlo según corresponda.
Java es tan aburrido que, de hecho, es un gran lenguaje
¿Qué significa eso?
¿No será que significa que, sin importar quién lo haga, todo queda más o menos parecido y por eso es más fácil de mantener?
Supongo que quiso decir que transmite una sensación de estabilidad en sí misma, porque no hay nada que requiera una atención especial ni nada que sorprenda a los desarrolladores.
Como gran parte de lo relacionado con el estilo de código o el linting se puede resolver con herramientas, al contrario, cuando me topo con gente que no le presta atención, no me dan ganas de trabajar con ellos.
Estoy de acuerdo. Yo agrego una verificación de estilo en el CI para que, si no se cumple el estilo, ni siquiera se pueda hacer merge.
> Sigo pensando que la gente que se obsesiona con problemas menores como el estilo de código o las reglas de linting sigue siendo un grupo extraño. Hay que enfocarse en cosas más importantes.
https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
Pero también se dice que no conviene simplemente dejarlo pasar, porque al final son factores que dificultan la concentración de las personas, así que es mejor resolverlos y seguir adelante.
> A la mayoría de la gente no le importa mucho la “artesanía” del código. Hay que valorar a quienes sí le prestan atención, pero con el resto hay que colaborar desde donde están.
Totalmente de acuerdo..
Soy alguien que se arrepiente de haber construido un sistema sobre serverless.
Los cold starts siguen siendo lentos,
en algún momento el tráfico se disparó y terminó siendo casi igual que on-demand,
y por más que se intentó de todo, el despliegue es demasiado lento.
La cobertura de código no está relacionada con la calidad del código cuando:
Creo que serían una de esas dos cosas.
Pienso que el código de prueba recién adquiere sentido cuando tiene una cobertura alta y, con diversos escenarios que provocan errores, prueba la misma parte varias veces con entradas distintas.
Me resulta más convincente interpretarlo en el segundo sentido. No es que un número alto de cobertura de código se traduzca directamente en calidad del código, sino que lo importante es llenarla con casos de prueba significativos.
> Java es un gran lenguaje precisamente porque es aburrido
Qué chistoso jajaja
Estoy de acuerdo.
Temas de desarrollo de software sobre los que cambié de opinión después de estar 6 años en la industria
Opinión de Hacker News