265 private links
Quelle langue utiliser pour écrire des programmes?
Write code and experiment instead of talking and planning
Keep experimental and mock data alongside production code
Minimize restart times and restart the project often
Eye level is buy level
a single coding style
Compose functions and flow data through pipes
General-purpose functions
A clean work environment
Consistent naming
Keep playgrounds
There is little engineering in software engineering
Great advices
It is much easier to add features to reliable software, than it is to add reliability to featureful software.
Besides, it’s very easy to accidentally think you need features that you don’t actually need.
Write serialized test scenarios
Storing UTC events loses the timezone information.
What happens if the event changes its location timezone?
What happens if the new DST rule changes?
So what to do? Store the original user's intent! Maybe derive the timezone from the location in some cases. Then store the UTC time of that event and store that as well.
Note: timezone UIs suck generally. One option is available between a lot, and the name is not always clear...
- lead time: le temps écoulé entre le moment où tu dis “on va faire ça” et sa mise en production réelle dans les mains des utilisateurs.
- la fréquence des déploiements
- nombre de bugs critiques
- la gestion de la dette technique en 4 niveaux
- fréquence des rétrospectives
- sécurité psychologique
- autonomie dans les décisions en 4 points
- capacité à résoudre des problème en 4 points
Full of good advices.
(in the context of big tech companies)
the priority of a project is to ship!
But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.
You only know you’ve shipped when your company’s leadership acknowledge you’ve shipped.
you have to get clear on what the company is looking to get out of the project. [...] Align your work and communication accordingly!
Second, no matter the project goal, your leadership team will always have basically zero technical context about the project. They will rely on you for estimates, to answer technical questions, and to anticipate technical problems. Maintaining that trust should be your top priority.
How?
- track record of having shipped in the past.
- project confidence
- project competence
- communicate professionally and concisely. Share updates.
Then getting to production! Often a key detail is missing. Sometimes the user documents are stored in memcached and are MB large, or the data stored are unexpectedly sensitive legally sensible.
Can we ship right now?
Bring up the feature to as many eyes as possible!
If you want to ship, you need to do the exact opposite: you need to deploy as much as you can as early as possible, and you need to do the scariest changes as early as you can possibly do them.
Trying random stuff for hours instead of reading the documentation.
UX and AI, but no single speaker addressed the training data sources, the energy requirements,
But never once did the question arise of whether it’s ethical to even use these tools.
One topic was expressed: the AI slop
There’s a quote by Finnish architect Eliel Saarinen that UX designers like repeating:
Always design a thing by considering it in its next larger context. A chair in a room, a room in a house, a house in an environment, an environment in a city plan.
As Molly White states:
There are no ethical uses of current large language models.
Similar to a gardener.
Play around with ideas, follow intersting threads and see where it goes.
When something start to make sense, a TODO list follows.
As for staying motivated during the build process, while I don't have anything prescriptive I did write a post on what works for me.
Les coûts directs:
- légaux ou juridiques: amendes ou sanctions.
- les corrections
- les surcoûts techniques lorsque l'infrastructure n'est pas optimisée.
Les coûts indirects:
- la communication sur les incidents, SAV, etc...
- les pertes commerciales (dédommagement)
- la perte de productivité ou l'absentéisme
- la formation
engendrent du manque à gagner
- la visibilité (publicité supplémentaire nécessaire)
- la non fidélisation (churn) des clients existants
- l'image
Il y a aussi des coûts de surqualité !
Le sous-ensemble latin étendu a 395 caractères et pèse 395ko.
Pour le chinois ou le japonais, il peut y avoir de 3 000 à 80 000 caractères.
L'optimisation habituelle consiste à créer un sous-ensemble, mais il faut néanmoins au moins plus de 5 000 caractères pour certaines langues.
L'idée est donc de créer une police qui peut être segmentée, "contenant uniquement le sous-ensemble de ce qui est critique, puis de lui adjoindre des additions qui complètent la police en cours de route."
Un streaming de caractères de police en somme. Cette idée est actuellement un draft au W3C: Incremental Font Transfer
Optimization is not always a progress in every field
Websites to exercise typing:
🏳️⚧️ Meuf trans 💻 Développeuse web 📚 Passe son temps libre à lire des romans. 👂💍 Peut parler des heures de piercings et tatouages 💪 Active dans le milieu queer