revisar pull requests, eso es una cosa que hacemos mucho en mi empresa
pero, y de hecho esto es una de las primeras cosas que os quería comentar
bueno, si habéis leído mi libro de Git, pues ya lo sabréis porque
hablo de esto y si no lo sabéis, pues espero que lo sepáis ya
en el libro de Git hablo de diferentes estrategias de trabajar con ramas
en Git, y yo estoy intentando en mi empresa y de hecho lo conseguiremos, este año lo conseguiremos
ya os lo digo yo, que lo conseguiremos, y os invito a que llevéis esta
conversación también a vuestros equipos, sobre todo si son lo suficientemente maduros
pues, de hablar de esto, hablar de esto
ShipShowAsk, ¿qué es esto? esto básicamente es una estrategia moderna
de ramas en Git, y lo que te viene a decir, de hecho
no quiero hablar mucho de esto porque hablo de esto en mi libro y a lo mejor ya
lo habéis visto, ¿vale? pero básicamente es que tienes tres posibilidades a la hora de trabajar
con tu código, uno, sería Ship, que es para pequeños cambios, yo que sé
una traducción, pequeñas cosas de no tener que hacer
una pull request que te la revise todo el mundo
y tal, sino que simplemente la envías
y a ContraMaster, y aquí
la gente se me pone muy nerviosa
ContraMaster, ¿pero qué dices? Contra la rama principal
¿What? ¿What? Bueno
luego tenemos Show, que esto sería para
hacer una PR y que haga los checks
automáticos al menos
esto sería Ship, no de Chip
no, Ship, Ship, con ese
Ship, ¿vale? luego tendríamos
Show, ¿vale? de mostrar
que esto lo que haces es abrir la PR
pero no esperar a los deditos
a que la gente te la pruebe
y finalmente tendríamos Ask, que esto sí que sería como
hacer una PR y pedir deditos
y aprobación, o más que aprobación
que haya una discusión o que la gente te ayude
y cosas así, que también es bastante interesante
¿Vale?
Pushear a Master y luego cruzar los dedos
No, cruzar los dedos no
tener Continuous Integration y evitar que vaya producción
si ha roto algo, ¿vale?
Cruzar los dedos no funciona
no hacemos eso, ¿vale?
¿Y quién decide cuando es el Ask o Show?
Qué buena pregunta
Estábamos hablando de esto, de esta estrategia
¿Y quién decide?
Pues a ver, es muy sencillo
si te leyera mi libro de Git
A ver, ¿quién decide si es Ship, si es Show
o si es Ask, ¿vale?
Y si acabas de entrar, esto de lo que estamos hablando
es una estrategia de cómo hacer PRs
en los proyectos con Git, ¿vale?
Entonces está el de Ship, que es directamente
mergear a Master
el de Show, que es abrir una PR
respiro, no esperar los deditos
y luego mergear
cuando tienes los checks
de Continuous Integration
y tienes Ask
que es abrir una PR
y preguntar y tal
¿Quién es el que decide?
Pues yo te voy a decir quién decide
y es muy sencillo
el que decide es eres tú
porque no es un niño
hay un tema
que yo sinceramente
yo alucino
porque es que
en el mundo de la programación
como que falta gente
que digas
ostras, esta persona
parece que sí que se ha peleado
con la vida real
pero a veces me asusta un poco
la infantilización
de la gente
¿sabes?
como si fuésemos niños pequeños
en los que
por ejemplo
no podamos tener una responsabilidad
como
como decidir
como profesionales
si algo puede ser
mergeado a Master
y de hecho
ya no es un tema solo de gente de Twitter
sino de las propias empresas
que hay gente en las empresas
como líderes técnicos
que dicen
no, no
yo tengo que revisar todo el código
yo soy la persona
que tengo que revisar todo el código
esa persona es súper nociva
y súper tóxica
y seguramente no se da cuenta
porque a lo mejor
se la han enseñado así
o se cree que es la forma correcta
pero no funciona así el mundo
y no debería funcionar así
porque en realidad
cuando trabajamos con personas
trabajamos con personas adultas
que se supone que saben lo que hacen
entonces
la gente
tiene que ser responsable
de las cosas que hace
sino para que le pagan también
o sea que también
es un poquito lógico
entonces una persona
tiene que ser
consciente
de su nivel
yo si fuese junior
por supuesto
no me iba a poner
a mergear cosas a máster
pero me tengo que hacer responsable
si decido hacerlo
por supuesto que digo
vale
esto sí
y rompo algo
pues me voy a tener que responsabilizar
las cosas son así
pero esto de tener niñeras
o niñeros
mirándote el código
a ver si lo tienes bien
constantemente
si tú
como persona responsable
consideras que tu código
necesita
un par de ojos más
o tres pares de ojos más
está bien pedir ayuda
pero es que estas cosas
de no me fío de nadie
no sé
es que la gente
no sé dónde trabaja
en bunkers
luego pasa lo que pasa
también
que vemos que
a la gente
le cuesta llegar
a seniority
¿por qué la gente
le cuesta llegar
a seniority?
y esto es una cosa
que yo estoy viendo
cada vez más
antiguamente
a lo mejor
la gente
con tres años
cuatro años
llegaba bastante a senior
y hay veces
que nos estamos encontrando
gente que lleva ocho años
y no llega a senior
¿por qué?
pues porque han estado
constantemente
como supervisados
de una forma
enfermiza
casi
de las cosas que pueden
o no pueden hacer
que es del palo
no es que a mí
me miraban todo el código
y me decía
lo que en sí
está punto y coma
así
de cambiarle nombre
a todas las variables
a ver que no estamos
en una guardería
por favor
¿sabes?
o sea
tenemos que responsabilizarnos
y dejar de infantilizarnos
un poco
y especialmente
a los líderes técnicos
si estás aquí
escuchándome
y tienes un puesto
de responsabilidad
tu responsabilidad
no es mirarlo todo
y controlarlo
tu responsabilidad
es que así la gente crezca
joder
es que me cabrea mucho esto
me cabrea mucho
la gente esta
controladora
enfermiza
que
Dios mío
así que
ese es el tema
el que decides
deberías ser tú
¿vale?
y tú
y tomando
las mejores decisiones posibles
que para eso te pagan
¿es normal que no haya entendido
ship, show, ask?
pues
no es normal
es muy fácil
ship
es llevar directamente
el código master
show
es básicamente
crear la PR
pero sin esperar
que alguien te dé los deditos
poder mergearla
una vez que el
Continuous Integration
está en verde
y ask es crear una PR
y esperar que la gente la vea
y te dé feedback sobre ello
o discutir sobre ello
¿vale?
por culpa de la gente
que empieza a los 14 años
es que piden 10 años de experiencia
a los de 20 años
hostia
es verdad también
es verdad
pero hombre
14 años tío
es muy bestial
joder
eso está yendo de las manos ya
yo les recomiendo
a que empiece a intentar programar
cosas que le diviertan
a mí me parece muy buena idea esa
me parece muy buena idea
que envidia a los que empiezan
desde tan jóvenes
no tengáis envidia
a los que empiezan tan jóvenes
hay cosas buenas y malas
de empezar tan joven
hay cosas buenas y malas
no siempre es tan positivo
que no se apresuren a ser adultos
eso es lo que le diría yo
hay gente que se empieza muy joven
y se puede quemar demasiado rápido
yo a los 14 años
estaba jugando a fútbol en el parque
y estoy tranquilo
hola Midu
¿cómo estás?
estoy muy bien
gracias por preguntar
soy muy malo en algoritmos
¿qué me recomiendas para mejorar mi nivel?
hacer algoritmos
esto es como
soy muy malo haciendo ejercicio
¿qué me recomiendas?
pues haz más ejercicio
en este caso pues
colaborado
colaborado
vete a adventjs.def
que ahí tenemos 25 ejercicios