Programadores. El hilo de los hinformáticos profesionales como PABLOPL.

Yo esto del Low-code o No-code lo veo poco comparable con DevOps y DevSecOps. Los primeros son un concepto introducido por quienes te quieren vender entornos en los que «programar sin código». Supongo que tendrán su lugar, pero con lo poco que conozco a mí no me convence ni le veo utilidad práctica.

Con lo de DevOps me llevo ganando la vida unos años y es verdad que, como con los microservicios, es necesario que haya una transformación importante o te comes una mierda de proporciones épicas. Sin un enfoque a nivel estructural de cómo se trabaja entre equipos, todo el mundo sufre.

Te leo y me inspira una compasión tremenda, cuando ciertos directivos se empeñan en subirse a barcos modernos sin plan alguno para adaptar el funcionamiento de la nave de la que ya se hacen cargo es un viaje muy doloroso. A veces todo se evitaría con la sencilla pregunta de «¿para qué queremos esta puta mierda?», seguida de «¿y cómo coño vamos a adaptarnos a ella?».
Si es que no hay una solución mágica. Viendo hace poco un vídeo de microservicios escuchaba a una pava decir que muy chuli lo de tener modulitos independientes pero que aumentabas notablemente la superficie de ataque...

Yo como administración pública no busco innovación porque sí, busco soluciones robustas y mantenibles en nuestro contexto.

Por cierto, en los pliegos ahora mismo todos buscando como locos 100tifikos de datos y todos los perfiles posibles en seguridad. Filón tremendo hay ahí
 
Si algo me daba por culo los años de programador/analista o como se llame ahora es la formación continua que debes exigirte. En mi caso, cambiando las cosas constantemente me producía desazón siempre. Una vez me encontraba cómodo a cambiar otra vez. Y las horas de estudio en tu casa (excepto los cursos que te pagaba la empresa). Y en casa tenía a la parienta preguntando que si me iba a poner delante del ordenador otra vez, que la niña no sé qué... Nunca entendió de qué iba aquello.

Ya me borré de aquello hace muchos años.
Siempre me gustó lo de estar a la última, intentar profetizar sobre cuál será la próxima moda que lo pete y empaparme de ello. Me he puesto a leer este hilo desde el principio y tuve una combinación de buen ojo y suerte. El problema es que ahora también espero tener tiempo para la familia y que en la última etapa de mi trabajo actual he perdido un poco las ganas porque mi faena diaria se ha vuelto un coñazo, no sé si remontaré al ritmo de antes o es una etapa que ha terminado para mí.


Si es que no hay una solución mágica. Viendo hace poco un vídeo de microservicios escuchaba a una pava decir que muy chuli lo de tener modulitos independientes pero que aumentabas notablemente la superficie de ataque...
Eso de la superficie de ataque es muy relativo. Si tu infraestructura está en la nube pública y las APIs de esos microservicios son accesibles desde internet, pues sí, tienes más superficie, pero eso no es necesariamente mucho peor que tener un monolito mantenido con palillos. Las cosas bien hechas, bien hechas están en ambos modelos y no por ser de uno o de otro son necesariamente mejores desde el punto de vista de la seguridad.

He formado parte de varias auditorías de seguridad y si la infraestructura está bien planteada siguiendo prácticas que están clarísimas en toda documentación, los microservicios están tras una capa muy robusta. Obviamente tiene sentido auditarlos también, pero puedes limitarte a las partes más críticas o potencialmente accesibles, abaratando en varios órdenes de magnitud respecto a un monolito.

Eso no quita que haya problemas con los microservicios. Por ejemplo: es fácil duplicar esfuerzo en distintos equipos y a la vez es jodido mantener uniformidad en las herramientas para posibilitar movilidad de personal, el reclutamiento de nuevo talento y a la vez mantener algo de flexibilidad para que cada equipo use lo que mejor le venga. La interacción entre equipos se puede volver excesivamente burocrática con reuniones para acordar funcionalidades de la API. Creo que este tipo de arquitectura requiere que lo de ÁGIL sea algo que se tome en serio y no una excusa para colgar pósters motivacionales.

Yo como administración pública no busco innovación porque sí, busco soluciones robustas y mantenibles en nuestro contexto.

Por cierto, en los pliegos ahora mismo todos buscando como locos 100tifikos de datos y todos los perfiles posibles en seguridad. Filón tremendo hay ahí
La seguridad tiene futuro profesional, pero muchísimo. El problema es que no mola tanto como parece. Te crees que es hackear el mainframe y al final se trata de mandar circulares para que la gente no pinche en enlaces de rusas que buscan marido en tu zona y mantener una lista de software permitido en equipos empresariales, es como trabajar en una guardería llena de adultos que se cagan encima de las maneras más creativas posibles.

Pues justo en este ámbito es donde más cojeo yo y lo que más me da por saco y despierta en mi los demonios.

Podríamos ASOCIARNOS.
Así empecé, vi que había necesidad porque todos mis compañeros odiaban esa parte del trabajo y automatizarlo no sólo era productivo y me interesaba, además te ganabas el cariño de la gente, que es algo de lo que estaba falto.
 
@Faraón Hijodeputh IV me ha salido recomendada esta página en linkedin y me he acordado de ti:

a.png


Desplegar en producción los viernes :omg:
 
Curiosamente, el lunes parece ser el día que más incidentes graves se producen. Si tienes miedo de desplegar un viernes es porque tienes miedo de desplegar siempre, pero el resto de la semana no tienes planes.
Si tengo miedo de desplegar un viernes es porque sé que algo va a salir mal y el servicio va a estar fallando el fin de semana. En mi equipo hay siempre slots post despliegues reservados para resolver incidencias, porque suelen haberlas ya que los tests de integración suelen ser escasos.
 
Si tengo miedo de desplegar un viernes es porque sé que algo va a salir mal y el servicio va a estar fallando el fin de semana. En mi equipo hay siempre slots post despliegues reservados para resolver incidencias, porque suelen haberlas ya que los tests de integración suelen ser escasos.
Espero que no seas tú el responsable de ese equipo porque lo que describes es síntoma de estar gestionando muy mal el tiempo. Reservar tiempo después de cada despliegue para arreglar problemas, es para cortarse las venas, joder.
 
Espero que no seas tú el responsable de ese equipo porque lo que describes es síntoma de estar gestionando muy mal el tiempo. Reservar tiempo después de cada despliegue para arreglar problemas, es para cortarse las venas, joder.
No, no soy el responsable. :lol: Pero es muy divertido en las plannings ver al Product Owner creando una historia de usuario para que los desarrolladores puedan imputar el tiempo que van a dedicar a arreglar fallos de producción y empezar el sprint con ella.
 
No, no soy el responsable. :lol: Pero es muy divertido en las plannings ver al Product Owner creando una historia de usuario para que los desarrolladores puedan imputar el tiempo que van a dedicar a arreglar fallos de producción y empezar el sprint con ella.
Vaya vergüenza le debería de dar a un PO tener que hacer eso.

A mí en los últimos años me ayudó mucho el modelo de "squad health check" de Spotify. Haces una reunión de hora u hora y media donde repasas los aspectos fundamentales de lo bien que va un equipo y luego se publican los resultados para que todo el mundo en la empresa o al menos departamento los vea. Idealmente se repite cada 3 meses y se ve el progreso. Cuando va bien da gusto reafirmarse en ello y a los gestores les encanta sacar pecho. Cuando va mal, da una idea muy clara de dónde hay que poner esfuerzo.

Aquí se explica y hay PDF por si queréis hacerlo con tarjetas.
 
Si tengo miedo de desplegar un viernes es porque sé que algo va a salir mal y el servicio va a estar fallando el fin de semana. En mi equipo hay siempre slots post despliegues reservados para resolver incidencias, porque suelen haberlas ya que los tests de integración suelen ser escasos.
Si sabes que va a salir mal no despliegues.
Un despliegue un viernes por la tarde es de lo más normal. Y como haya que hacer una migración masiva de datos, directamente el sábado por la mañana. Y si está todo bien probado y QA dice que OK José Luis, tendrás incidencias el lunes pero deberían ser menores, y la mayoría de usuarios torpes y su desconocimiento, no por malfuncionamiento de la aplicación.
 
Si sabes que va a salir mal no despliegues.
Por lo poco que ha contado, huele a que @Tomioka hace lo que la cultura de la empresa dictamina. Si la cadena de mando dice que «esto es p'ayer», pues se despliega y luego ya veremos. El gilipollas que se llena la boca con el nombre de su puesto de JEFE de algo puede decir que las cosas salen a tiempo. Quiero pensar que si el PO está creando códigos para fichar el tiempo empleado en arreglar lo que pasa por tener prisas es en un intento desesperado de reflejar el verdadero coste de no invertir un poco de esfuerzo en tests. Es una historia muy vieja ya y parece mentira que a estas alturas aún haya quien no entienda que es MUCHÍSIMO más caro tener a ingenieros haciendo pruebas manuales o poniendo parches que pasarse el tiempo que haga falta desarrollando tests unitarios y de integración.
 

Me acuerdo de una entrevista que tuve ahí, de una seleccionadora freelance que me contactó toda motivada para que fuera. Supongo que querría llevarse su parte o algo. No salió bien, perdida de tiempo para todos.
 
Por lo poco que ha contado, huele a que @Tomioka hace lo que la cultura de la empresa dictamina. Si la cadena de mando dice que «esto es p'ayer», pues se despliega y luego ya veremos. El gilipollas que se llena la boca con el nombre de su puesto de JEFE de algo puede decir que las cosas salen a tiempo. Quiero pensar que si el PO está creando códigos para fichar el tiempo empleado en arreglar lo que pasa por tener prisas es en un intento desesperado de reflejar el verdadero coste de no invertir un poco de esfuerzo en tests. Es una historia muy vieja ya y parece mentira que a estas alturas aún haya quien no entienda que es MUCHÍSIMO más caro tener a ingenieros haciendo pruebas manuales o poniendo parches que pasarse el tiempo que haga falta desarrollando tests unitarios y de integración.
Al final es verdad que en la empresa privada los de arriba tienen sus objetivos estratégicos/económicos (cámbiese por políticos en la pública) pero cuando te dicen "esto no está pa salir", pues deberían creerlo.
Bien es cierto que algunos proyectos se enquistan y se atascan más de lo esperado y se llega al punto de cabreo, también es cierto que muchos de esos atascos son por nuevos requisitos que surgen sobre la marcha.
Aunque, y como ya he dicho, de un proyecto de 12 meses, en teoría son 8-9 meses desarrollo que se van a 11, y luego vienen las prisas para los sufridos equipos de despliegue/operaciones.

La calidad de una organización es directamente proporcional al caso que se le hace a QA
 
No sé quién dijo que:

"Todos los equipos de desarrollo tienen un entorno de test. Los más afortunados tienen además uno de producción".

He usado ese arma muchas veces, viene muy bien recordar que si no tienes un entorno dedicado exclusivamente a los tests, entonces no tu entorno de tests es ese al que llaman producción. Cada vez que algún PO o jefe de algo salta con lo de "mientras conseguimos que nos aprueben el presupuesto/proyecto para el entorno de tests tenemos que vivir sin él" hay que señalar, que quede muy claro que es un hecho, que la decisión es usar "producción" como laboratorio. Cuanto más importante sea la reunión y sus asistentes, mejor, descubres que una cara puede cambiar de color varias veces por segundo.
 
No sé quién dijo que:

"Todos los equipos de desarrollo tienen un entorno de test. Los más afortunados tienen además uno de producción".

He usado ese arma muchas veces, viene muy bien recordar que si no tienes un entorno dedicado exclusivamente a los tests, entonces no tu entorno de tests es ese al que llaman producción. Cada vez que algún PO o jefe de algo salta con lo de "mientras conseguimos que nos aprueben el presupuesto/proyecto para el entorno de tests tenemos que vivir sin él" hay que señalar, que quede muy claro que es un hecho, que la decisión es usar "producción" como laboratorio. Cuanto más importante sea la reunión y sus asistentes, mejor, descubres que una cara puede cambiar de color varias veces por segundo.
Me he acordado de otra frase que escuché
- tenemos un entorno de PRE que es una copia exacta de PRO
- cuándo se replicó por última vez?
- hace 8 meses
 
Yo me lo estoy tomando con una calma que asusta.

Y lo peor es que ellos mismos me inducen a tomármelo con todavía más calma.

Me recuerda a ese cómic de Astérix en que llega un nuevo reemplazo de legionarios al mando de un centurión flipado y el centurión antiguo le dice "tú no sabes cómo se hacen las cosas por aquí, verdad?"
 
Yo me lo estoy tomando con una calma que asusta.

Y lo peor es que ellos mismos me inducen a tomármelo con todavía más calma.

Me recuerda a ese cómic de Astérix en que llega un nuevo reemplazo de legionarios al mando de un centurión flipado y el centurión antiguo le dice "tú no sabes cómo se hacen las cosas por aquí, verdad?"
En mi experiencia, las prisas son un muy mal síntoma, señal de que desde hace tiempo se va en una dinámica de prometer más de lo que se puede entregar y donde los gestores no tienen las agallas de reconocerlo y enmendarlo, sino que patean hacia delante. Qué bueno es que te digan que tranquilo, que trabajo va a haber siempre y que es mejor ir despacito y con buena letra. Vaya bala has esquivado no yendo a una consultora, sería diametralmente opuesto.
 
Cosas que pasan en KPMG.

1ckxYf0.jpg


Añado audio con más detalles:

Para ver este contenido, necesitaremos su consentimiento para configurar cookies de terceros.
Para obtener información más detallada, consulte nuestra página de cookies.
 
Última edición:
Atrás
Arriba Pie