#29 Lo más importante es que un ingeniero resuelve problemas.
Paso 1) hacer una solución
Paso 2) comprobar que la solución funciona
En consecuencia has resuelto el problema. Todo lo demás es opcional.
Como he explicado en el ejemplo de #15 en mi prueba he resuelto muchísimos problemas mientras resolvía el ejercicio.
Otra manera de evaluar la capacidad puede ser enumerar los problemas que se resuelven.
- Resuelvo el problema de guardar un objeto en base de datos
- Resuelvo el problema de devolver un objeto de base de datos
- Resuelvo el problema de guardar objetos grandes de manera eficiente
- Resuelvo el problema de devolver objetos grandes de manera eficiente
- Resuelvo el problema de detectar errores y que mi sistema se adapte de manera inteligente
- Resuelvo el problema de poder reparar estos errores cuando sucedan
- Resuelvo el problema de desplegar múltiples instancias en paralelo de manera segura
- Resuelvo el problema de desplegar múltiples base de datos y adaptarme de manera segura
- Resuelvo el problema de reducir costes $$$
- Resuelvo el problema de trabajar en equipo, compartir el código y colaborar de manera eficiente
- Resuelvo el problema de desplegar mi servicio de manera segura, gradual y hacer rollbacks
Si realizas esta evaluación de manera objetiva y por ejemplo miras el caso de Codely que vimos en #2.
- Han añadido un servicio por stream en eventos para tratar de solucionar el problema pero:
- han creado el problema de mantener un RabbitMQ
- han creado el problema de que los miembros necesitan conocer AMQ, MQTT, STOMP
- han creado el problema de decidir entre RabbitMQ y Kafka y razonar el porque uno es mejor
- han creado el problema de mantener el RabbitMQ y en el futuro tener que re-empelzarlo
- han creado el problema de mantener un sistema de colas y eventos
- han creado el problema de testear todo lo anterior
- han creado el problema de que la eficiencia se ha reducido
- tanto a nivel de código como a nivel de equipo como a nivel operacional
- han creado el problema de incrementar los costes de funcionamiento y operacionales del servicio
- han creado dificultades de mantenimiento de código debido a la sobre-ingeniería
- han acoplado fuertemente su solución ha frameworks como Spring y sub-componentes y sus detalles internos
- han creado el problema de mantener un RabbitMQ
Un ingeniero resuelve problemas, si creas más problemas de los que revuelves. Eres un mal programador. No eres ni ingeniero.
Si haces caso de malos consejos, de gente que no son ingenieros terminarás como la pobre gente de PcComponentes... Menuda porquería tienen montada. Y el problema es que esta gente de PcComponentes se ha dejado mal asesorar y guiar por gurús vende-humos.
De hecho este ejemplo del propio Codely es un gran ejemplo de una porqueria de prueba, donde le piden algo muy sencillo, y hace una sobre-enginieria brutal:
Y al final del video le dice el ricitos, a ver flipado, que esto se resuelve con dos lineas de bash y fuera. Por que te complicas tanto? jajaj
Este es un ejemplo muy famoso Command-line Tools can be 235x Faster than your Hadoop Cluster
. La mayoria de programadores haciendo big-data, spark, similares... No tienen ni idea, pero ni idea, de lo que estan realmente haciendo y de lo que realmente se debería hacer.
En resumen, resuelve problemas, no crees más problemas de lo que estas tratando de resolver. Si haces esto, ya estarás en el top de mejores programadores del mundo.
