Friction is defined as the difference between military theory and reality in the book On War.
There are plenty of such frictions in software development, for example:
- API's that does work quite as you though it did, or it changed
- Bugs. Security alerts. A breaking dependency upgrade.
- Someone gets sick and information is lost.
- Requirements are unclear, or a client changes what they want, during of after development.
- Laptop breaks or gets stolen.
- Tooling breaks.
How to avoid that?
- smaller scopes and shorter iterations
- more autonomy
- redundancy
- better planning
- automation
- experience
- gaming
- checklists and runbooks
Wow!
I’m designing for the web. The infinitely flexible web. The web that doesn’t have one screen size, one browser, one operating system, or one device. The web that can be used by anyone, anywhere, on any internet connection, on any device, on any operating system, on any browser, with any screen size. I’m designing with the web. Using the web platform. I have a deep understanding of HTML and its semantics. I love CSS, I know how and when to utilise its many features, and I keep up-to-date as more are added. I have a strong understanding of modern JavaScript and most importantly I know when not to use it.
Also an accessibility specialist. My expertise goes beyond what web designers need to know. I’m also a design system specialist. I’m a systems thinker. I love standardizing things to simplify the web development process. [...] I love human-centred design and co-design—nothing about us without us.
I think programming is like running a dishwasher. It always takes longer than you think and some stuff is never as clean as you expected it to be.
It simply handles it. The service is a simple binary in Rust 😃
Just.... yay it's not that simple.
What’s easy for you might not be easy for others. There’s always a trade-off.
Simplicity is a luxury. It’s really hard. And it’s never “just”.
We should try to understand what makes it hard. And make it easier.
- Interop project https://github.com/web-platform-tests/interop
- Open Web Docs through contributions to MDN https://openwebdocs.org/
- WebFC Community group https://www.w3.org/community/webdx/
Still competitions on the web, but without fragmentation.
We want to make it easier for developers to track the list of features that are widely available and those that are under development.
To contribute:
- WebDX Community Group
- Ideas on github repositories
Le flow n’est pas seulement un état où j’ai besoin de calme, il s’agit d’un contexte à part entière. Il me faut une problématique connue, qui est définie avec des contours relativement flous, davantage une intention qu’une direction. Si j’ai déjà eu l’occasion d’être précédemment frustré par l’implémentation en cours, cela me donne beaucoup de motivation pour plonger. Parfois la zone est atteinte en n’étant pas devant un écran (en courant, sous la douche, etc), une forme d’Eurêka ! qui annonce la libération du flow à venir.
Memory safe languages.
Better metrics to measure software security. One example is through time: how fast a vendor patches to a security vulnerability.
A great feedback
All engineering is reverse engineering if you document things poorly enough.
I also agree: if you act alone on your free time, then go for simplicity. You have a limited time budget and it should be fun.
Trying new ones when they are needed makes also sense, but only when they make sense.
The article is well written and connects multiple topics: line of code and care work to the software, computer architecture and speed, its industry and more.
Debian 12, for comparison, is 1,341,564,204 lines of code. For comparison, Google Chrome is about 40 million lines, which is in the same ballpark as the Linux kernel these days. No one, even a team, can read these entirely.
Computers aren't much faster now than they were a decade ago, and they will probably never again return to the rate of performance improvement they had for 60 years up to the mid-noughties.
The thing is, that doesn't scale very well. On the desktop we have four-core machines and now we're moving to eight-plus cores, but a single person can't use that very helpfully, so instead, we're getting computers with a mixture of high-performance but hot, power-hungry cores, and lower-performance, cooler, but more electrically-efficient cores.
A limit to multiple cores is the Amdahl's law: even if a program can be made 95 per cent parallel, the maximum speedup you can get is about 20 times, no matter how many processor cores you throw at it.
What is the maintainable way to build things?
For CSS, how do you structure tokens?
- Naming things: --umap-color-darkBlue?
- Give a meaning to names: --color-primary: var(--umap-color-darkBlue);
Lorsqu’on envisage un commun sur ces 10 prochaines années, comment trouver une stratégie maintenable qui s’inscrira dans la durée avec enthousiasme ?
Le contraire de Tailwind :/
In honor of Valentine’s Day, here’s a thread of pickup lines for the programmer in your life♥️
- Are you a CLI benchmarking tool? Because you’re looking
hyperfine
today - Do you write Rust? Because you clearly care about my safety🦀
- Do you write JavaScript? Because I bet you know what
this
could mean - Has anyone ever called you pnpm? Because you’re my favorite package manager 📦
- Excuse me, is your name @vite
- Because you’re the best development I’ve seen in years.👀
- Let’s trade—you buy me dinner and I’ll buy you a new domain name.💰