Quelques vidéos sur le dev vues récement.
Can You See The Red Flags Of A Toxic Tech Company?
Je retiens surtout les questions (du candidat) à poser dans un entretien d’embauche, des questions assez fortes qui risquent de surprendre l’employeur. Je pense m’en servir, ça fera gagner du temps.
How Senior Programmers ACTUALLY Write Code
Du même auteur, certains points paraissent des évidences. D’autres moins, notament
never expose refactoring
On part ici du principe qu’un refactoring est nécessaire.
Non seulement, comme le dit l’auteur, il y a un risque a être micro-managé. Mais en plus, on perd de l’energie et de du temps au lieu de faire.
Je n’évoque même pas la situation avec le manager court-termiste qui va refuser alors que vous pensiez que c’était le moment.
Assume unexpected change
on connait tous des developpeurs qui sous-estiment toujours les temps de dev.
J’aime bien partir de l’idée qu’on ne sera jamais dans le vrai, ça serait assez incroyable en fait. On a donc 2 façons de se tromper, en surestimant et en sous-estimant. Il faut essayer de s’assurer qu’on va se tromper du coté qui nous arrange le plus, celui de la sur-estimation.
Ajouter de temps pour l’imprévu, c’est indispensable (cf méthode LIMITER). Si on se retrouve avec du temps disponible en plus, il ne sera jamais perdu (où alors vous êtes malhonnête), on commencera la tache suivante en avance, on fera vraiment face à un imprévu, on dépilera un élément de notre todoliste.
On touche à quelque chose de fondamentale dans l’estimation du temps.