An other another personal blog about programming :)
Mostly about Cypress and testing stuff, also related to web development.

Great tips indeed

Code itself won't tell you about the decisions and rationale behind it, nor about about higher-level structures and abstractions. All this needs elaboration in documentation.

👍

Séparer les dépendances au maximum

You have already a lot of features, so don't loose your time.
That's what I think.

And I also totally agree with this blog post

Your produc­ti­vity is now less impor­tant than the produc­ti­vity of the whole team.

If one univer­sal talent sepa­rates success­ful leaders from the pack, it’s commu­ni­ca­tion skills. It doesn’t matter whether you choose to dive deep into tech­no­logy, or become a mana­ger — if you can’t commu­ni­cate and listen to what other people are saying, your career growth from this point on will suffer.

On s’adresse à tous ceux qui veulent progres­ser au delà du stade de déve­lop­peur senior à 5 – 10 ans d’ex­pé­rience.

Les katas "sont pensés pour permettre d’introduire une idée ou une pratique bien précise, mais je ne pense pas qu’ils permettent de progresser très loin"
Et les problèmes spécifiques aux entretiens d'embauches: "sont un autre cas : certains couvrent des sujets fondamentaux d’algorithmique (écrire un arbre binaire…), d’autres sont plutôt des puzzles où la connaissance nécessaire pour les résoudre n’est utile qu’à la résolution de ce type de problème."

La répétition est aussi peu utile.

Une manière de s’entraîner, mais j’ai l’impression souvent peu structurée, est de faire des mini-projets, par exemple en réimplémentant des versions simplifiées outils qu’on a l’habitude d’utiliser.

Cependant, l'apprentissage n'est pas le même pendant ce mini-projet.

Ma suggestion, pour les personnes qui développent des mini-projets et qui veulent en parler, serait donc de documenter ces éléments (durée du projet, domaines couverts, moments où on apprend le plus de choses) pour que d’autres puissent en profiter.

This role requires you to have a good sense of the overall archi­tec­ture of your systems and a solid unders­tan­ding of how to design complex soft­ware. It proba­bly also requires you to be able to unders­tand busi­ness requi­re­ments and trans­late them into soft­ware. »

Un facteur souvent oublié est le prise en compte des besoins de l*entreprise.
Les facteurs sens commer­cial, stra­té­gie de déve­lop­pe­ment, parte­na­riat, vélo­cité, coûts représentent des finalités par rapport au simple outils que sont la dette technique ou nos qualités techniques.

Le senior s’ar­rê­tera à « il faut faire comme ça » alors que j’at­tends des rôles de lead et de staff la reflexion de « oui mais ce dont nous avons besoin aujourd’­hui c’est … ».

Comme enseigné et illustré en cours d'agilité:

Commu­niquer au plus tôt de la façon la plus trans­pa­rente possible. Non seule­ment ça permet­tra de répondre au problème plus tôt, mais ça dimi­nuera le stress de tout le monde.
La règle : On ne blâmera jamais quelqu’un pour lever de façon construc­tive une alerte, y compris très tôt. On pourra par contre repro­cher de ne pas l’avoir fait.

L’im­por­tant n’est pas de poin­ter l’ex­per­tise, de savoir que vous décou­pez mieux le code ou que vous faites moins d’er­reur d’ar­chi­tec­ture. L’im­por­tant est de savoir quel est l’im­pact que vous avez dans l’équipe.

Vous pouvez avoir un fort impact par votre seule exper­tise tech­nique. C’est possible mais diffi­cile, parce qu’il faudra une sacré exper­tise tech­nique pour justi­fier qu’elle vous fasse passer au niveau suivant. Il est probable que, même avec une exper­tise de pointe, les compé­tences humaines comme la commu­ni­ca­tion avec les autres, votre volonté à prendre des respon­sa­bi­li­tés ou la façon dont vous les gérez, ou encore votre propen­sion à faire gran­dir les personnes autour de vous, vous retienne d’avoir l’im­pact auquel vous préten­dez. Ce sont ces compé­tences là qui vont jouer le plus.

Ulti­ma­tely, the value of plan­ning isn’t that you execute the plan perfectly, that you catch every detail befo­re­hand, or that you predict the future; it’s that you enforce the self-disci­pline to think about the project in some depth before diving in and seeing what happens. […] The plan itself, howe­ver accu­rate it turns out, is less impor­tant than spen­ding time on the act of plan­ning. »

I totally agree. It is god damn hard to make accurate estimations about software development, because it is hard to know what will work or breaks and because the specifications are never complete until the full development

1.As a software engineer, you are not there to take requirements blindly. You are there to partner with your business and product partners. That means you have to earn an equal seat at the table on product decisions.

2. Being smart or good at what you do does not give you the right to be a jerk. Empathy as an engineer is a superpower. Caring about those you work with will do more for your career than writing beautiful defect-free code.
3. As someone in the code, every day, you will see things that others will never see. You will know what's possible; they'll guess what's possible. Some of the best product features are born because engineers found clever ways to solve something. Look out for those things.
4. You are there to add value first. All the code you wrote will end up in the recycling bin of some computer if it does not add value directly or indirectly to the business. It doesn't matter how pretty your code is or how much you love it if it doesn't add value.
5. Your code should follow this pattern: Make it work → Make it fast → Make it beautiful [make it right is included in the make it work IMHO]. Reminder: You won't have a chance to make it fast or beautiful if it doesn't add value.
6. Build relationships with engineers in other teams and other companies. Learn about the problems they are solving. Learn different architecture and designs than the ones your team uses. You never know when their solutions will save you days of work.
7. You don't need permission to add value. If you see something and know you can fix or improve it, do it. Nobody will ever say to you, "why did you add all that value? WTF is wrong with you!?" Every time I've done that unexpectedly, I've earned outsized rewards.
8. 10x engineers do exist and so do .1x engineers too. If you think they don’t exist, that’s just because you haven’t worked with any of them yet.
9. Just because you think someone shouldn’t be hired, that does not mean they aren’t a good engineer. It also does not mean they don’t have a strong work ethic. A strong work ethic is the most important thing, and it's nearly impossible to tease out in an interview.
10. Advocate for junior engineers. Without junior engineers on the team, no one will grow. Help others grow; you'll grow too.
11. Have empathy for the people you interview. You could be in that situation. The set of things to know is large, even if you only ask basics. Plus, on a whiteboard, the other person is being judged. They have a lot to lose, maybe hundreds of thousands in income.
12. Even though you work with computers, your career and future depend on people. Until AI runs things, people still run the world, and relationships matter a lot. Build relationships with people outside of engineering, listen to their problems. It will change your trajectory.

Donner les atten­dus, à la fois en compor­te­ment et en objec­tifs, c’est donner les moyens à la personne de faire le néces­saire pour y arri­ver… et éven­tuel­le­ment deman­der de l’aide s’il leur manque quelque chose ou si elle ne sait pas comment faire.

Même ensuite, les grilles de compé­tences sont un très bon outil pour expli­ci­ter les atten­dus de chaque rôle. Pas de « ce n’est pas mon boulot » ou de « est-ce que c’est dans mon rôle ? », ni en amont ni au moment du retour annuel. Ce n’est pas un cadre fait pour brider, mais au moins on expli­cite à l’avance ce qui est attendu de chacun.

Going from framework consumer to framework creator

Starting from language proficiency to data structures and algorithms to Design Patterns

A cool definition for design patterns: a solid architecture that are reusable and extensible and that are industry standards

Useful resources. I will check it out.

In fact, a good way of pricing your work is by asking yourself what salary would make you enthusiastic enough to be heavily invested in the product and deliver your best work.

People usually stay in the same company for 12-18 months (in the U.S.).

If you feel valued and appreciated, the team is great and salary is fine, consider staying in the same company for around 2–3 years.

4. Keep record of your achievements

5. Pay attention to your estimates

   6 productive hours per day

6. Test the company during the probation period

8 Think about passive income early

there was too much at stake to not write the documentation first.

Maybe for my masterthesis ? :D

Pourquoi l’équipe tech applaudit une mise en prod réussie ?
Parce que c’est le cloud du spectacle !

Junior dev → programming all day with 4 screens in a terminal
Senior dev → in a farm

Resume signals value from human to corporations.
Blog singals value from human to human.

People used to be defined by where they work, and now they’re defined by their knowledge, capabilities, and opinions.

And because of that, the resume is no longer the main artifact of your public worth. The replacement is [...] having a domain name where you put all your stuff. A digital avatar of yourself.

Le planning poker, ou "l'opposition est moins directe que des ouvrier·ère·s qui demandent de travailler moins ou de simplement maîtriser leur rythme de travail, mais c’est tout de même la même chose qui se joue."

Un pro doit avoir des demandes centré pour le bien commun.