J'utilises l'outil adapté au besoin.
Parfois tout simple et léger, parfois énorme et lourd.
Les résultats dépendent des besoins: produire vite et/ou par cher avec une base bien documentée et solide, ou bien prendre du temps de répondre à des besoins plus spécifiques avec un résultat sur mesure.

Les outils industriels restent disponibles si besoin (après tout les menuisiers aussi utilisent des machines pour se faciliter la tâche), mais le travail est plus minutieux avec une attention plus poussée sur les demandes exactes du client. La priorité est alors moins le prix ou la rapidité mais le résultat sur mesure qui va durer et pourra être maintenu.

Il ne s’agit pas de faire du prêt-à-porter ou de simplifier le processus de production, mais bien de satisfaire le client avec un résultat de qualité. Parfois en passant plus de temps sur un détail qui peut paraître insignifiant (comme refaire intégralement une interface d’admin très peu utilisée ou ajouter des Easter Eggs bien cachés), mais qui rendra le produit final unique.

👍

• éviter de réinventer la roue
• prendre du temps pour sélectionner les bons outils
• choisir les bonnes personnes

Entrer dans le monde professionel en IT depuis une école, c'est comme le grand splash.

Cette situation est normal. Et c'est d'autant plus compliqué de dire non à quelque chose lorsqu'on est junior (ref: C'est la faute du développeur).

The numbers on the Planning Poker cards tell how many browser tabs you'll need to open to complete a given user story.

Kind of true 🤣

Full stack term was invented by some smart manager who was tired of thinking who will do what.

Solution: Everyone does everything.

Now the managers continue to have a good time while you keep wondering why am I stupid to not know everything

Le développeur doit savoir dire non, lorsque cela n'est pas faisable.

Et je suis aussi dans ce cas à ne pas savoir dire non, car je me dis que c'est une occasion de m'améliorer, d'être meilleur, etc...

À éviter:

• On a toujours fait comme ça
• Tu veux des infos sur [application], vas voir [untel] !
• On fera ça après/C’est temporaire
• Chez moi ça marche
• C’est une erreur normale
• Tu peux m’aider ? Il y en a pour deux minutes !

Elle soulève souvent un problème derrière !

Le syndrome de l'imposteur illustré. Ou comment le syndrome de l'imposteur est un serpent qui se mord la queue.

TL;DR

Tu n’es pas limité. Tu n’es pas limité par un langage, par un domaine d’expertise ou par une entreprise. Ne laisse personne te faire croire le contraire.
Tu es un résolveur de problème. Ton outil c’est le code. Ta méthode c’est une suite logique d’opérations et d’instructions. Tu sais, les algorithmes dont je te parlais au début. Si tu maitrises cette logique, tu maitrises tout.
Le reste c’est un mur de syntaxe et de règles spécifiques que tu apprends sur le tas.

Passer à l'action, simplement commencer.

C'est cela qui me permet de partir courir, car une fois que je suis dedeans, tout est bon.

C'est amusant d'effectuer l'exact opposé: comment souffrire un maximum avec ce métier 🤣

C'est vrai que la liste est énorme ! 😱
(via Le Warrior du dimanche)

• Le salaire
• L’équilibre des forces et charge de travail
• Absence de vision
• Inertie
• Absence de courage managérial
• Sécurité psychologie
• Equilibre vie pro/ perso
• Ligne rouge morale franchie
• Culture d’entreprise transformée
• Absence de qualité
• Absence de progression

You are a poet and a mathematician. Programming is your poetry.
You are a hacker. You make hardware dance to your tune.
You are a maker. You build things for people to use.
― josephg.com

A collection of free single-purpose online tools for web developers...

Adding junior engineers makes the senior engineers on his team better, because the constant "Why" questions force them to articulate and confront their own assumptions.