Attention, ce livre regroupe un lot d’expériences d’un développeur desktop et web. Il y a des risques que ce contenu puisse vous intéresser si vous êtes curieux ou à la recherche d’expériences gratuites ! A défaut, il y a des passages drôles :)
"Sérieusement, de quoi ça parle et pourquoi ?"
Comme toujours, dans un métier, il faut bien commencer, comprendre son environnement, faire des erreurs, trouver des méthodologies, bref, découvrir le métier.
"Mais il y a internet, à quoi bon ?"
Déjà, si vous tombez sur ce livre, c’est grâce à internet, vous avez donc raison. Internet est une mine d’or et on reviendra dessus (sans avoir la prétention d’être un guide de bonne utilisation d’internet) mais il y a également tout… et son contraire.
C’est également vrai pour une formation ou des études, cela vous prépare (plus ou moins bien) mais force est de constater qu’on est souvent "catapulté" dans le monde du travail et que, quelle que soit la formation, cette dernière est souvent insuffisante (et c’est normal) pour appréhender un poste de travail.
"Donc en gros, avec ce livre, on va avoir une mine d’or déjà prête et adaptable à tout pour devenir une méga star de l’informatique et devenir millionnaire ?"
Si seulement… :) Bien sûr que non, ce ne serait tout bonnement pas possible avec un seul livre et une seule personne. Je constate juste qu’après près de vingt ans d’expérience dans ce magnifique métier, certaines personnes sont curieuses de connaître les expériences des autres et de les partager pour s’améliorer ou éviter les erreurs déjà commises.
Il faut considérer cette tentative de livre comme un agrégat de discussions compulsées au fur et à mesure lors de pauses café. C’est plus sympa et le message passe mieux. C’est d’ailleurs une semi-vérité car je rapporte ici des sujets dont je discute assez régulièrement avec mes collègues.
Clairement pour des profils techniques et en particulier pour des développeurs d’applications mais également pour les opérateurs qui déploient ces mêmes applications. Il n’y a pas de prérequis technique car je tenterai à chaque fois de rester agnostique d’une technologie ou d’un langage.
C’est d’ailleurs une des motivations de ce livre, un condensé clair pour aborder certaines situations standards dans le monde du développement informatique.
Si on trouve pléthore de sujets techniques traités très précisément via des articles, livres ou toute autre ressource, j’ai rarement trouvé des resources de retours d’expériences de projets ou humaines.
Je ne vais pas forcément vous refaire tout mon CV mais j’ai commencé en 2002 grâce à un DUT d’informatique. J’ai donc commencé surtout par le langage Pascal pour tomber totalement amoureux de Java. Si le fonctionnel (via Pascal) m’a permis d’appréhender l’algorithmie, la programmation objet (via Java) a été une vraie révélation pour moi. Le fait de pouvoir hériter, décrire et ne raisonner qu’en interfaces plutôt qu’en implémentations, et tant d’autres choses dont nous parelerons plus loin, m’ont paru d’une part évidents et d’autre part captivants.
Bien sûr, j’ai appris d’autres langages "sur le tas" comme le C et javascript autour de 2005. Pour PHP, c’est depuis le début de ma formation, mais il n’y a que moins de dix ans professionnellement. NodeJS et Angular autour de 2015 et 2016 parce que c’est difficile de de passer à côté d’un écosystème autant foisonnant qu’intéressant.
Pour faire court, ma passion pour les langages informatiques et l’architecture logicielle m’ont toujours poussé à explorer et expérimenter.
Au délà du partage d’expérience, il y a un point important sur lequel je me permets d’insister : le manque de ressources francophones. Souvent, et je suis le premier à tomber dans ce travers, on utilise l’anglais pour toute documentation, écriture de code, etc… En donnant quelques formations chez des clients, j’ai souvent eu cette remarque quand je fournissais une bibliographie anglophone : "Vous n’auriez pas le livre en français ?". En voulant toucher un maximum de personnes à travers le monde, on utilise trop souvent l’anglais en informatique mais il ne faut pas laisser la francophonie en reste qui est importante et qui mérite bien des contributions.
Et puis, il faut bien l’avouer, cela m’est bien plus facile de mon côté que de rédiger ma prose dans ma langue maternelle même si l’exercice de style en anglais demeure intéressant.
Le découpage est thématique et chacune d’elle essaiera de répondre aux questions via des anecdotes ou réflexions. Une conclusion synthétisera les grands points à retenir.
La lecture pourra donc être totalement piochée au grès des besoins ou alors lue plus conventionnellement de manière séquentielle.
Le ton de chaque paragraphe sera donné selon qu’il s’agira :
-
d’une technique ou méthode
-
d’un trait d’humour
-
d’une expérience personnelle
Il n’y aura pas ou peu de code source.
- Introduction
- Construction du livre
- Montée en compétence et expérience
- L’open source, la contribution
- Méthodologies existantes
- Les langages, frameworks et applications
- Se mettre en danger
- Utiliser la bonne solution/méthodologie
- Utiliser des outils
- Intégrer une équipe (ou pas)
- Savoir débugger
- Prendre du plaisir
- Les tests
- Développer ses outils
- Paramètre humain
- Optimiser et s’optimiser
- Avoir du temps, un luxe
- Organiser son temps
- L’histoire de l’informatique, culture
- Avoir d’autres activités…
- En quête de reconnaissance
- Sujets divers
Qu’est-ce que je suis bon !
Je le dis maintenant depuis plusieurs années, qu’est ce qu’on se sent bon quand on n’y connait rien ! Si en plus on a le loisir de travailler dans une petite équipe et qu’on est le seul curieux mais on est vraiment le meilleur !
On est le seul geek de la (petite boîte), on utilise les seules technos (donc les meilleures) qu’on connaisse, etc… Mais qu’est ce que je suis bon !
Voilà le premier écueil du début : se rendre compte rapidement de l’inexpérience qu’on a (c’est normal, on débute).
Je ne dis pas qu’il faut se flageller quotidiennement en avouant sa médiocrité mais il faut en être conscient.
Il ne faut pas pour autant se sentir nul et ne pas avoir confiance en soi. C’est toute la difficulté du débutant surtout que chaque être humain est unique. Les niveaux et les talents ne sont pas les mêmes.
EXPÉRIENCE : J’ai connu en vrac :
-
des débutants qui comprennent très vite et exécutent très vite
-
des débutants qui ne comprennent rien et ne disent rien
-
des débutants très sûrs d’eux mais qui finalement ne font que des bêtises ou n’écoutent personne
-
des débutants lents
-
des débutants non investis
-
…
La liste est très longue et les combinaisons infinies.
La capacité d’identifier la catégorie de débutant (comme d’employé d’ailleurs) à laquelle on appartient est une capacité à part entière mais il faut déjà commencer par se poser la question : Quel type de débutant je suis ou j’ai été ?.
C’est d’ailleurs une question fondamentale qu’il faudra vous adresser régulièrement : Quel employé suis-je ?.
Je ne veux pas trop rentrer dans de la psychologie d’entreprise mais identifiez vos capacités, mieux vous connaître permettra de faire de meilleurs choix ou d’avoir un meilleur comportement. Normalement, les appréciations scolaires peuvent être un indice.
Elève qui a des capacités mais qui ne les exploite pas signifie Au boulot !.
Elève en difficulté mais qui fait des efforts montre que vous êtes travailleur.
Cette question, vous pouvez la poser à votre entourage, idéalement pas à vos collègues de bureau, afin d’avoir un regard extérieur sur votre personnalité.
Attention toutefois, si vous êtes le chouchou de la famille, vu comme le petit génie et que vous vous considérez à tort comme un cador du code lors de vos premières années, la désillusion, si désillusion il y a, risque d’être assez terrible.
HUMOUR : "Bon en gros, tu ne nous apprends rien, tu nous dis, connais-toi toi-même et encore, c’est difficile car l’entourage ou nous-même pouvons avoir une vision biaisée de nos capacités !".
La seule chose que je dis, c’est de découvrir assez rapidement ses capacités pour pouvoir ensuite se positionner et éviter de se sur-évaluer, si c’est le cas.
SYNTHÈSE : On commence, il faut donc essayer de se connaître soi-même dans le monde du travail et sur un poste particulier. Ne pas se sur-évaluer ni-même se sous-évaluer. Après tout, on débute !
Quel que soit votre profil ou catégorie d’employé (cf paragraphe précédent), ne pas savoir reconnaître vos erreurs sera un frein important dans le long apprentissage qu’est la pratique d’un métier. Je dis bien un frein, n’y voyons pas une impasse, sauf pour les plus têtus.
Au début, c’est d’autant plus dur qu’on a du mal à distinguer ce qui est "bien" ou pas dans notre activité quotidienne.
Mais voici plusieurs exemples pour illustrer ce sentiment de refus de reconnaître ses erreurs.
Lorsqu’on réalise une première livraison ou un recettage, même interne, d’une application, on peut se rendre compte qu’une fonctionnalité que vous avez développée ne marche pas. Je vous vois déjà sourire, c’est expérience n’est jamais arrivée ! C’est difficile de ne pas reconnaître ses erreurs mais on peut souvent être tentée de minimiser ou de trouver d’autres excuses : * "Ca devait être testé par telle autre équipe" = mauvaise foi ou fainéantise * "Sur ma machine, ça marche", très usuelle = tests pas assez poussés ou environnement différent
La vraie réponse applicable est souvent : "Oui, j’ai fait de la merde". Certes très familière mais assez réaliste.
Il faut donc faire un véritable "post mortem" de la situation, il n’y a pas de honte à avoir, surtout quand on débute. Cela peut être déstabilisant et être un coup dur pour l’amour propre mais autant le dire tout de suite, quand tout va bien, on n’apprend pas grand chose.
Il va sans dire que dans le monde professionnel, comme dans tout groupe ou toute société, une hypocrisie sociale est de rigueur. Selon la relation avec l’équipe ou encore le client, il peut être difficile d’être aussi franc.
HUMOUR, il y a d’ailleurs une sur-utilisation de la "bévue" du débutant dans nos entreprises. Je dirais que "bizarrement", ce ne sont pas nos ingénieurs expérimentés qui ont fait une "bourde" mais le petit stagiaire inexpérimenté… Il est en effet difficile d’avouer qu’une équipe d’experts puissent être à l’origine d’une situation délicate.
Il faut donc au moins s’avouer intérieurement son erreur mais surtout trouver la "parade" pour éviter que cette même erreur ne se reproduise trop souvent. L’erreur fait partie de l’apprentissage. Si une personne vous semble infaillible, soit elle cache bien ses erreurs, soit elle a su mettre à profit l’expérience des erreurs qu’elle a commises. Mais elle en commettra d’autres.
Car oui, l’expérience n’est pas une check list immuable à apprendre par coeur, elle évolue avec le temps et l’expérience.
Dans le monde du développeur, les erreurs peuvent être nombreuses mais il y a des "classiques". Un excès de confiance, une erreur d’inattention ou de fainéantise en sont souvent à l’origine.
Et la réponse la plus souvent à apporter est un jeu de tests efficaces, point que nous aborderons dans les tests (TODO).
SYNTHÈSE : * reconnaître ses erreurs * mettre en place un processus pour éviter de la reproduire
-
l’expérience peut nous jouer des tours
-
ce qui marche chez l’un mais pas chez l’autre
-
évolution du développeur et place du développeur
-
utiliser des technos mises en place
-
être critique, voir les avantages, inconvénients
-
choisir, mettre en place des solutions
-
un meilleur code
-
vision produit vs client
-
sans faire un état de l’art
-
les classiques DRY, etc… mais qui n’aident pas tant que ça, exemple, la factorisation pouvant induire de la difficulté
-
patterns et anti-patterns
-
mais sinon, y a des vraies méthodes ? Cf éducation nationale et "lis ta leçon"
-
commencer par le cas général et "complexifier" le code
-
les connaître c’est bien, se les approprier, c’est mieux
-
on choisit celui qu’on maîtrise mais pas forcément le plus adapté (exemple sycloe)
-
se faire plaisir oui, mais doit rester utile, utilisable et maintenable
-
bases oui, apprentissage continu, oh que oui !
-
sortir de sa zone de confort comme vim et ses plugins
-
curiosité
-
apprendre ou affiner des techniques
-
s’intéresser aux autres projets ou technos
-
Savoir aborder un sujet, une problématique
-
renvoi au langage
-
architecture
-
répétitif?
-
connaître son OS
-
son éditeur ou ses éditeurs et plugins
-
snippets, macros
-
git/vim/linux/tmux a changé ma vie !
-
espace de travail
-
mais un jour il faudra
-
lire un log
-
comprendre le problème
-
technique de l’entonnoir
-
ne pas avoir peur de regarder un code qu’on n’a pas développé
-
mais ne pas oublier les spécifications et contraintes
-
c’est encore plus fun
-
on comprend mieux la difficulté de créer un bon outil
-
en parler
-
rassurer
-
impliquer
-
une réunion ou une personne peut ruiner les efforts de tout un projet
-
trouver ceux qui ont la réponse, "ceux du bout du couloir"
-
éviter les itérations livraison, retours au développement
-
éviter les erreurs bêtes, typos, inattention, utilité des tests (encore…)
-
facteurs de motivation
-
workflow de travail selon son poste, activités
Développer pour un client vs développer un framework/produit
-
Pomodoro
-
Dédier une journée à un sujet (cf Elon Musk)
-
aimer se perdre ou optimiser ?
-
pour développer ses factultés
-
parallèle avec la pratique d’un instrument
-
d’autres langues
-
le sport
-
-
instrospection
-
article de Vlad, java champion
-
travail
-
media, contribution
-
talent d’écriture, transmission
-
blog, différence entre tips/liens et articles (blougi/boulga si centres d’intérêts différents)
-
investissement en temps, rédaction d’un livre technique
-
sujets divers ou spécifiques
-
Faut-il être geek ?
-
expert vs anti expert
-
les études vs l’expérience