La question de l'agilité, c'est d'abord un choix de méthode. Il n'est pas guidé par la tendance du moment, mais par la nature des projets.

Comme le disait mon professeur, il s'agit avant tout d'un état d'esprit.

La démarche agile sert avancer sur des projets :

• dont on ne connaît pas le produit fini
• à condition d'avoir bien identifié la boucle de rétroaction.

Une méthode agile, ça n'est pas forcément le bon choix pour un projet. Parce qu'elle impose d'échouer souvent, de faire pleins d'erreurs que l'on va chercher à corriger petit à petit pour obtenir le design définitif.

when a project is being actively developed, tagged releases are the only safe option to ship to users.

Normal.

1. Ask for help if you get stuck for more than an hour... I don't think it applies to every cases though
2. Docs? What are they? Write some along your coding session for yourself: yes!
3. Product thinking: User-oriented thinking
4. Hunt for a mentor
5. Work of art
6. Being less stupid: instead of being smart, try to make one less stupid decision every day.
7. Multiple approcahes: always try to come up with multiple solutions after going though a ticket, then pick the solution that suits well in the delivery time
8. Keep the team in the loop: always over-communicate
9. Product Job Mentality: think first, don’t start working unless the requirements are 100% understood; Never work on a feature for more than 2 weeks without validating it with users.
10. Do code reviews

1. Documentation:

   When you’re checking the documentation for those details you are in-fact testing the documentation as well. If you get there and all the details or information you need are already written up then great! But if there’s details missing or out of date information then it’s your opportunity to fix the documentation for the next person.

2. Reading articles and making time for courses

3. Trying new tools and flexing your conceptions

4. Front-end team meetings and knowledge sharing

Les attentes:

• éviter le changement d'environnement tous les ans ou deux ans...
• l'UI des logiciels proposées

Pour les élèves:

• tous sur la même plateforme
• éviter de se connecter
• responsive ! On est en 2022, les élèves utilisent ces outils sur ordiphones. (WTF ce n'est pas le cas ?!)
• que tous les documents / pdf etc utilisés lors d'un cours soient dispo depuis un seul lien de partage

Pour le Warrior du Dimanche

• tous les documents en un seul lien
• mise en ligne rapide et simple des documents [→ un lien déjà partageable avant que la ressource soit téléversé ?]
• que les données restent acccessible aux fils des années (WTF ce n'est pas le cas ?!)
• ....

Sa solution semble être un très bon départ
"Par contre, c'est moche" → je peux peut être aide ! :D

Instead, we can mix 3 or 4 designs together to create something unique. For example, maybe I’ll take the color scheme from one site, the general layout and spacing from another, and the typography styles from the third!

When I’ve mentioned this strategy to actual designers, they laugh and say that it’s what they all do. I think this is their version of the “joke” that programmers spend half their time googling things.

Note : en discutant de cet article, une personne m’a expliqué qu’elle a noté deux style de développement : des personnes développent “en pile”, en interompant ce qu’elles font pour traiter les nouvelles idées d’abord pour revenir ensuite là où elles en étaient, et d’autres “en file” ou elles terminent d’abord leur idée en cours avant d’entamer la suivante.

Je développe aussi "en file".

Let’s look at a recent paper by Xia, Bao, Lo, Xing, Hassan, & Li entitled Measuring Program Comprehension: A Large-Scale Field Study with Professionals and published in IEEE Transactions on Software Engineering, 44, 951-976, 2018. This paper is quite interesting in that it describes in great details how the figures are obtained. And it says that Comprehension took on average ~58%.

So much ?!

Junior and senior dev Point of view of a bug, and a bigger bug

En une phrase, c’est souvent un développeur passionné qui cherche à écrire le meilleur code possible avec la meilleure architecture pour répondre au besoin.

Il code par passion.

Et comme toute passion, il n’attend pas que quelqu’un vienne lui apprendre quelque chose.

Le software craftsman est en perpétuelle recherche d’amélioration.

Agile est une méthodologie avec des process de management, là où le software craftsmanship met l'accent sur le code.

Comment ?

1. S'enfoncer dans les bonnes pratiques

Les bonnes pratiques, ce sont le fruit des erreurs des développeurs qui nous ont précédés.

2. Partager ses connaissances

La partage de connaissance, c'est du gagnant-gagnant

Recommandations de livre:

• Clean Code : A Handbook of Agile Software Craftsmanship
• Dive Into DESIGN PATTERNS de Alexander Svets
• The Software Craftsman : Professionalism, Pragmatism, Pride de Sandro Mancuso
• Refactoring de Martin Fowler avec la contribution de Kent Beck

I probably spend more CPU cycles optimizing the program than the program optimization will save in CPU cycles. 🤔

A methodology to build software-as-a-service apps

So I think the right path is something like this:

• Try to generalise from your experiences, but don’t hold your opinions too strongly.
• Listen to other people’s conclusions, but try to learn as much as you can about the context that formed them.
• See the value in expertise and approaches that have a limited scope of application.

First contribution on @gitpod
merged 🎉
I know, it's "just" on the documentation/website.
Just?
In my point of view, there is no small contribution. Even If you think you're not a 🎸"rockstar"⭐️, don't hesitate to contribute 🙂

Using Open Source is good, Donate is better

A better documentation leads to better products leading to better UX or DX ♻️👍‍

Some are

Resting awareness

• Meditation
• Mindfulness
• Reflection
• Body scanning
• Visualization
• Note-taking
• Mindful programming

and related tips for casual cases !

Funny as it may sound, sleep is a really good technique to refresh our minds and bodies.

🤣

1. I still don't know very much.
2. The hardest part of software is building the right thing.
3. The best software engineers think like designers.
4. The best code is no code, or code you don't have to maintain.
5. Software is a means to an end.
6. Sometimes you have to stop sharpening the saw, and just start cutting shit.
7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system.
8. Every system eventually sicks, get over it.
9. Nobody asks "why" enough.
10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers.
11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be.
12. People don’t really want innovation.
13. Your data is the most important part of your system.
14. Look for technological sharks.
15. Don't mistake humility for ignorance.
16. Software engineers should write regularly.
17. Keep your processes as lean as possible.
18. Software engineers, like all humans, need to feel ownership.
19. Interviews are almost worthless for telling how good of a team member someone will be.
20. Always strive to build a smaller system.

A blog post as response to it ?