The problem is that there’s a tension between our needs and our capabilities. We cannot focus and coordinate at the same time. Focus demands attention toward problems, while coordination demands attention toward people. Focus and coordination are opposing forces, pulling on the single thread of awareness. This tension creates the focus-coordination tradeoff.

People strive for focus (concentrators), other for communication (coordinators)).

The best way to navigate the focus-coordination spectrum is to constantly harmonize these dimensions as they dance. We can impact it through:

• group size
• people (managers, ICs, rotating coordination responsibilities, stand-up leaders, meeting scribes=.
• how we communicate: synchronous vs asynchronous communication; medium
• time: Healthy teams know which moments require more focus, and which ones require more coordination.

These statements of architectural principle explain the thinking behind the specifications. These are personal notes by Tim Berners-Lee: they are not endorsed by W3C on anyone else. They are aimed at the technical community, to explain reasons, provide a framework to provide consistency for future developments, and avoid repetition of discussions once resolved.

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

Set expec­ta­tions appro­pria­tely before reviews are deli­ve­red. If someone is under­per­for­ming across the board, the review should not be his first time getting that feed­back.

a première diffi­culté du lead est de savoir arbi­trer son temps, et c’est bien la compé­tence fonda­men­tale pour réus­sir à chan­ger de rôle. Il doit avoir envie d'agir et prendre la respon­sa­bi­lité qu’il faut pour ça. Les anglo­phones ont un mot pour ça : owner­ship.

"Part of your leader­ship is helping the other stake­hol­ders, such as your boss and the product mana­ger, respect the team’s focus and set up meeting calen­dars that are not overw­hel­ming for indi­vi­dual contri­bu­tors."

It's hard to debate about the best technologies. So here are a summary of the arguments of the author.

Main Argument: React isn't great at anything except being popular.

• React is good.
• React laid down the groundwork for other web frameworks. Vue 3 and React hooks, Svelte's conventions from React, Nuxt from Next, ... The component based-model owes much to React-
• React’s greatness is more in what it meant at the time than what it currently is today, absent that context
• React has aged. And I don't think most people—particularly those using it regularly—realize how much or how poorly. → when you live in the React world, you only see improvements. It shields you from React's velocity compared to other frameworks.
• React doesn’t do anything better than other frameworks.

On a greenfield project, how do you make the call on the front-end framework you'll use for the next several years? Things to consider:

• Performance → Vue, Svelte, Solid, Inferno and a host of others generally provide markedly better performance than React.
• Learning curve → JSX allows HTML into a JS function. The only thing worse than using JSX with React is not using JSX with React. Many things other front-end frameworks handle for you or make trivially easy require manual intervention or significant boilerplate. React is built for Facebook, others frameworks for the world.
• Bundle size: not the smallest
• Scalability: React doesn’t have anything special here; it just has the most examples.
• Community and support: does not mean a better choice. A big community can be a downside, too, especially in the case of a so-called “unopinionated” framework such as React. It can mean too many packages to choose from, and too many different, competing opinions that you’ll have to decide between and take a stance on.
• Financial backing: Vue is one of the most successful and well-funded open-source projects in history. [Through examples] backing is not an issue among major front-end frameworks
• Developer experience: React placed behind both Solid and Svelte in terms of satisfaction in this year’s State of JS Survey results. React also placed behind Svelte, Solid and Vue in terms of interest React's satisfaction and interest have been declining steadily for years, while its usage has flatlined.
• Hireability: This is the one area where React definitively comes out ahead. If you need to hire a dev who knows your thing already, React is clearly the choice.
• vs Competitors: But bear in mind that choice also gives you absolutely no tech advantage over your competitors. They’re all (mostly) using React, too.

Why react stays on top?
Because we don’t always value the strongest choice as much as we value consensus.
One other thought here: it’s possible we’re already moving past React, but we just can’t see it at a high level yet.

Dans le langage courant, ce terme a parfois pu être utilisé dans un sens plus large : « rationner » les crédits de l’hôpital public, par exemple. Mais ce n’est pas la même chose qu’une politique organisée qui vise à protéger les consommateurs pendant une pénurie. Le rationnement, c’est la répartition des efforts, dans un objectif de justice et de solidarité.

À propos de la sobriété:

Ce discours a mis l’accent sur la sobriété, mais en détournant son sens original, pour aller vers des petits gestes. Ce terme fort, qui pendant longtemps a été un étendard de radicalité, est ici une simple réduction des gaspillages, prétendument compatible avec la croissance. En science politique, on appelle cela un conflit de cadrage : lorsque dans l’espace public, des acteurs s’emparent d’un terme et cherchent à le redéfinir à leur manière. Aujourd’hui, si on laisse s’installer cette redéfinition au rabais de ce que sont la sobriété ou le rationnement, on va perdre de vue leur sens politique et le fait qu’ils pourraient être de puissants outils de justice sociale.

Et donc, si on avait un rationnement qui autorisait X litres d’essence par personne et par semaine et que cela incluait les billets d’avion, ce sont les plus riches qui seraient clairement les plus pénalisés.

Les mesures contraignantes sont d’autant mieux acceptées quand elles sont perçues comme justes et justifiées, et quand il y a une confiance dans le gouvernement pour bien faire les choses. Lorsqu’au contraire on perçoit un double langage, quand on demande des efforts d’un côté, mais qu’on maintient des privilèges de l’autre, cela décrédibilise le message.

Mais pour l’instant, face au choc énergétique, les pistes pour répondre sont cosmétiques. Et le manque d’anticipation est incroyable. Déjà en mars, l’Agence internationale de l’énergie proposait dix mesures pour réduire la dépendance énergétique de l’Europe face à la Russie : la réduction de la vitesse sur autoroute, les dimanches sans voitures dans les grandes villes, davantage de télétravail, etc.

Aussi parler de rationnement seulement pendant l'hiver est faux, puisque

Qu’est-ce qui justi­fie une promo­tion alors ?
"Many compa­nies expect you to be acting at the next level before you get promo­ted to it."

Je suis pas mal ce prin­cipe, parce que mon métier et mon contexte, avec des équipes ayant beau­coup de liber­tés, permet à chacun d’agir au niveau qu’il souhaite assez faci­le­ment.

Avoir d’ex­cel­lentes voire d’ex­cep­tion­nelles perfor­mance à son poste ne justi­fie aucune promo­tion. Ça veut juste dire qu’on est excellent à ce poste.

Autrement dit, il faut d'abord être le rôle avant d'avoir la reconnaissance qui va avec.

Avan­cer en équipe c’est prendre la même direc­tion, même si indi­vi­duel­le­ment on aurait pu prendre des direc­tions diffé­rentes.

Avan­cer en équipe c’est non seule­ment savoir avan­cer mais ne pas ralen­tir les autres, voire savoir les épau­ler.

Faire avan­cer l’équipe au mieux c’est parfois redi­ri­ger une personne qui avance mais pas à la bonne vitesse pour le reste du groupe.

"Lead" [do other than] writing code, they hold respon­si­bi­lity for iden­ti­fying bottle­necks in the process and road­blocks to success for their team and clea­ring these road­blocks.

Son vrai rôle est de s’as­su­rer que l’équipe avance, et débloquer les autres ou travailler en amont à paver le chemin est plus impor­tant que pous­ser le projet lui-même.

• Versatile: we use the web for many things
• Decentralized: there is no one single arbiter
• Resilient: the development is hostile as there is a lot to consider such as multiple browsers, network condition, input modes, and third-party scripts,...
• Responsive: there is a responsive design on the web
• Adaptable: range of form factors, device capabilities, and specialized browsing modes.
• Accessible or at least can be accessible: It represents a rare space where a disabled individual may operate free from the immense amount of bias, misunderstanding, and outright hate that is pervasive throughout much of society.
• Inexpensive: the fact remains that you can achieve an incredible amount of functionality with a small amount of code. There is ~$40 for internet-ready smartphones.
• Diverse: the list of browsers is huge. This diversity encourages innovation.
• Standardized: with the w3c. It is well documented with the Mozilla Developer Network, StackOverflow, and blogs, ... Plus 20 years old web pages are still usable today.
• Open: the standardization and consensus are transparent. it helps to disincentive more abstract threats like adversarial interoperability. OSS FTW.

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.

Une des premières leçons du mana­ger sur une équipe : Lâcher prise. Lais­ser l’équipe faire ses choix et défendre moins forte­ment les siens, quitte à lais­ser l’équipe se plan­ter.

L’idée c’est de ne pas être le direc­teur, juste le mana­ger. C’est à l’équipe de déci­der, pour favo­ri­ser son impli­ca­tion, son initia­tive, sa respon­sa­bi­li­sa­tion, sauf à vouloir une équipe d’exé­cu­tant.

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.

Oui mais, cela dépend énormément de ton environnement. Voici pourquoi.

C'est aussi vrai, que sans rien, sans travail, sans efforts, on ne peut pas arriver non plus à un bon poste.

Si les feed­backs sont là, la revue annuelle n’en est que la synthèse, et un moment privi­lé­gié pour discu­ter de l’ave­nir.

Dire le posi­tif semble beau­coup plus courant dans d’autres cultures mais est vu comme pénible, diffi­cile, inutile et très arti­fi­ciel dans la culture française. Et pour­tant… je suis convaincu comme l’au­teure que c’est essen­tiel au bon fonc­tion­ne­ment de la rela­tion.

The social utility of a given software package is not necessarily tied to mass-market adoption. A software package can be trendy in a tight-knit community, while holding very little social utility for the mass market, and this is fine. This is the case for most software packages that exist in the world.

If a FLOSS matches the need for a small part of the community, it is then fine too !

Unfortunately, society teaches us that we should grow at any cost, which means that inexperienced maintainers can be swayed by such arguments to make harmful decisions about their projects.

The sucess of a project is measured by the biggest number: the number of stars on GitHub, amount of forks, ...

So yes, AI can bypass artists as it will be easy to generate images, arts, ...

I can see how ai-art immediately threatens freelance illustrators and concept artists.

I think ai-art, just like nfts, is a technology that amplifies all the shit I hate about being an artist in this feudal capitalist dystopia where every promising new tool always ends up in the hands of the least imaginative and most exploitative and unscrupulous people.

SQLite is a great database, but builtin functions are limited.

only 7 builtin aggregate functions: avg, count, group_concat, min, total, max, and sum

The reason you become creative in the shower is that it’s (mostly) impossible to be distracted. You’re just there—naked—with your thoughts. And suddenly you become a genius.

you can prove this by just sitting in a quiet place with no inputs for 5-30 minutes.

In a nutshell:

1. In our natural, idle state we produce a replenishing pool of creative water.
2. Being distracted siphons off that creativity into nowhere.
3. If you value being inspired, spend time alone with nothing but your mind.

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.