Feda /dev/ - No Javascript allowed

no tenéis un tag de política en offtopic donde meter todas esas mierdas?

.

#24191 Con el andador?

#24195Kaledros:

todos aprendemos a hostias.

Porque queréis.

Yo en este hilo minimo he puesto 6 fuentes que usan en faangs y startups punteras en como escribir documentacion tecnica y design docs.

Lo mismo que la guia de estilo al programar, no se aprender a hostias, se aprende leyendo docus estandards y siguiendolas hasta entender porque ese es el estandard. Pero bueno, por aqui hay gente que critica mi codigo porque comento todas las funciones lo que hacen... "el codigo deberia entenderse por si mismo" HAHAHAHAH

Luego como dice una vez aprenders las buenas practicas, con experiencia aprendes cuando hay que romperlas.

me ha gustado tambien el de buen codigo lo entiende un jr, mejor si lo entiende un estudiante de primer a;o. 100% yo es lo que busco, pragmatismo + explicito + usar el sistema de tipado lo suficiente para hacer malos dise;os imposibles.

#24197 Es un problema cultural no de enginieria. Si.

Yo si tengo que hacer una docu sigo el estandard de google o el que sea.

En la uni te ense;an a documentar pero te ense;an mal, te ense;an cosas de los 90 o del 00, UML, diagramas randoms.. no te ense;an bien como se hace despues en la industria.

Yo por ejemplo me encuentro con muchas docs, de cientos de paginas, que podrian ser tranquilamente una issue de proposal en gitlab/jira donde la gente comenta....

Pero bueno, esto es problema de la gente vieja.

Una cosa que me he encontrado mucho ultimamente son que muchos meetings, podrian ser videos. No es necesario tener reuniones mensuales de 4h para mostrar avances. Que cada uno se grabe sus videos, los equipos los ven por su cuenta y los comentan internamente y luego los equipos afectados entre ellos que se gestionen de manera autonoma para resolver dudas donde les toque.

Otro detalle que acabo de ver de problema cultural sobre organizacion. Muchos proyectos se organizan por paquetes de trabajo y tienen sus entregables. Entonces los repositorios / archivos compartidos tienen estas estructuras. Esto esta mal. se deberia seguir una jerarquida de ficheros igual que en el codigo. input, servicio, output. documentacion relacionada con el input del servicio, el servicio y el output (que genera).

#24199 Es lo que se llama trabajo async. La gente se ha pasado a teletrabajo pero no esta haciendo async. Y obviamente, incluso para esto, existen guias de gente que lleva mas tiempo trabajando.

https://about.gitlab.com/company/culture/all-remote/asynchronous/

#24203
Most problems are not technical but human. Including communication problems, misconceptions, and assumptions.

Diseñamos un parking con lector de matrículas, pago por uso, un montón de condiciones variables para tener descuentos dependiendo de si habían hecho X o Y cosa los usuarios, etc, todo muy bien documentado y testeado. El día de la instalación física, nos suelta el cliente que como hemos resuelto el hecho de que como el terminal de pago se encuentra dentro del edificio y el edificio hay horas que está cerrado, como van a sacar el vehículo... Que como lo hemos resuelto!! Pedazo de subnormal, primera noticia que vas a meter el terminal de pago en un edificio cerrado con llave...

#24204 Sobre esta regla, yo lo comento mucho.

Es lo que me gusta llamar cultura vs engineria. El otro dia lo comente con @Ranthas.

Como bien dice hay muchos problemas que se resuelven de manera cultural, por ejemplo forzar la guia de estilo de tu codigo o la guia de estilo de tu documentacion, si debes organizar reuniones/meetings y calentar silla o grabar videos/documentar. Lo que veniamos comentando basicamente es un subset de esto.

Sobre el tema de comunicacion es muy facil y va de la mano de como documentar bien y como escribir bien codigo.

Por ejemplo:

• mal: decir en meeting, obviamente debos realizar este dise;o.
• bien: decir en un meeting, debemos realizar este dise;o porque es mas facil de implementar, nos llevara menos horas y ya tenemos la infra montada. dejarlo documentado en la design doc

El saber cuando enviar un chat vs enviar un email tambien deberia ser algo cultura. Deberias tener una docu de cuando hacer las cosas para que todo el mundo lo hiciera. Pero desu, es obvio... no lo es. estoy hasta los huevos de gente que me abre por bobadas en teams.