Upload the JSON output of the stats and visualize it

A thoughtful post about prioritizing new development in a project.

L’ar­­ticle parle de revue mais les deux points à rete­­nir pour moi c’est que l’hu­­main doit rester en maîtrise et toujours prou­­ver que le résul­­tat est le bon, sans juste faire confiance, et que le volume de code est un ennemi encore plus fort qu’a­­vant parce que l’IA est forte à géné­­rer beau­­coup de code.

(via https://n.survol.fr/n/lecture-ai-writes-code-faster-your-job-is-still-to-prove-it-works)

The website we needed

The website we needed

A good use of <picture>, sparingly creating a system to fetch the main content of the page, minification, image optimization of all formats,

The final product was lightning-fast even on the weakest data connections and most underpowered devices. Showing it off at trade shows, we found that competitive products were still displaying a loading spinner when our application was already loaded, rendered, and running.

Score: 29

You are the web developer equivalent of the quiet old man in the bar who lurks in the corner and only interjects when the main character reaches a moment of crisis. You've seen some shit, enough to know when to sit down and shut up. You are so far into nerd territory that you're now cool again.

I also discovered the blog post via ThePrimeagean.

A follow-up post is published on the blog of Turso https://turso.tech/blog/working-on-databases-from-prison

Because you, the developer is the liability. It ensures the code should work as expected, either by manual testing (and reproductible behavior), code review or automated tests.

AI can write code, but ensuring and proving it works is

3 rules to it:

• the fastest code is the code you don't run.
• the smaller the code, the less there is to go wrong.
• the less you run, the smaller the attack surface.

Rewrite to native is also an option: Atom got 10x faster with Zed.
COSMIC desktop looks like GNOME, works like GNOME SHell, but it's faster and smaller and more customisable because it's native Rust code.

The COSMIC desktop looks like GNOME, works like GNOME Shell, but it's smaller and faster and more customisable because it's native Rust code. GNOME Shell is Javascript running on an embedded copy of Mozilla's Javascript runtime.

Just like dotcoms wanted to dis-intermediate business, remove middlemen and distributors for faster sales, we could use disintermediation in our software. Fewer runtimes, better smarter compiled languages so we can trap more errors and have faster and safer compiled native code.

Dennis Ritchie and Ken Thompson knew this. That's why Research Unix evolved into Plan 9, which puts way more stuff through the filesystem to remove whole types of API. Everything's in a container all the time, the filesystem abstracts the network and the GUI and more. Under 10% of the syscalls of Linux, the kernel is 5MB of source, and yet it has much of Kubernetes in there. This is what we should be doing. This is what we need to do. Hack away at the code complexity. Don't add functionality, remove it. Simplify it. Enforce standards by putting them in the kernel and removing dozens of overlapping implementations. Make codebases that are smaller and readable by humans.

Gnome Shell is

One behind 37signals. They are currently doing great stuff with CSS.

We performed an empirical study to investigate whether the context of interruptions makes a difference. We found that context does not make a difference but surprisingly, people completed interrupted tasks in less time with no difference in quality. Our data suggests that people compensate for interruptions by working faster, but this comes at a price: experiencing more stress, higher frustration, time pressure and effort. Individual differences exist in the management of interruptions: personality measures of openness to experience and need for personal structure predict disruption costs of interruptions. We discuss implications for how system design can support interrupted work.

How to avoid "software rot"? The author describes three pillars:

1. Foundations: the first decisions we make, that all other decisions are laid upon. These are the ground upon which all other battles are fought - and here, hours of research and thinking can save months of future engineering work. Mistakes here compound like little else in the game.
2. Workflow: The environment in which the codebase has space to grow and be changed, and the digital and human I/O that enables that.
3. Maintenance: The energy, time and will that must be reserved for the ongoing care, support and security of the platform.

• choose boring technology
• automate the tedious or repetitive
• good leadership is crucial
• make it easy to do the right thing
• reward clarity in code and communication
• make it easy to recover from disaster
• take external dependencies seriously, thoughtfully and defensively
• build a team that feels co-operation is a superpower
• technical debt is a strategy

Building up means starting with a tiny core and gradually adding functionality. Sanding down means starting with a very rough idea and refining it over time.

There are a few rules I try to follow when building up:

• Focus on atomic building blocks that are easily composable and testable.
• Build up powerful guarantees from simple, verifiable properties.
• Focus on correctness, not performance.
• Write the documentation along with the code to test your reasoning.
• Nail the abstractions before moving on to the next layer.

The alternative approach, which I found to work equally well, is “sanding down.” In this approach, you start with a rough prototype (or vertical slice) and refine it over time. You “sand down” the rough edges over and over again, until you are happy with the result. [...] I find that this approach works well when working on creative projects which require experimentation and quick iteration.

When using this approach, I try to follow these rules:

• Switch off your inner perfectionist.
• Don’t edit while writing the first draft.
• Code duplication is strictly allowed.
• Refactor, refactor, refactor.
• Defer testing until after the first draft is done.
• Focus on the outermost API first; nail that, then polish the internals.

Both variants can lead to correct, maintainable, and efficient systems. There is no better or worse approach. However, it helps to be familiar with both approaches and know when to apply which mode. Choose wisely, because switching between the two approaches is quite tricky as you start from different ends of the problem

En résumé, la préférence pour le Mac chez de nombreux ingénieurs logiciels repose sur :

• La puissance d’un environnement Unix natif, qui simplifie le développement et la gestion des outils.
• Une expérience utilisateur stable et “out-of-the-box”, qui minimise les tracas liés aux mises à jour et à la maintenance.
• Une qualité matérielle et une intégration écosystémique qui renforcent la productivité au quotidien.