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

The permission system should handle folders and files.

Strategies:

1. (naive) read-time permission queries
2. A simple table (RBAC role based access control).

-- RBAC: Pre-computed permissions
-- access_type: 'owner' (full control), 'shared' (read only), 'path_only' (visible but no access)
CREATE TABLE permissions (
  user_id INTEGER NOT NULL,
  resource_id INTEGER NOT NULL,
  access_type TEXT NOT NULL,
  PRIMARY KEY (user_id, resource_id),
  FOREIGN KEY (user_id) REFERENCES users(id),
  FOREIGN KEY (resource_id) REFERENCES resources(id)
);

3. Attribute-Based Access Control

This approach is very clear and composable. It works great for single-resource access checks: "can user X access resource Y?" It struggles when listing resources, as we would need to execute the policies for each resource and can't directly query the resources table with simple filters.

4. Zanzibar and ReBAC

Avec l'IA, l'ingénieur ne va plus dans un premier temps rechercher obligatoirement la solution, mais mettre en place le cadre, les outils, la surveillance, les docu­men­ta­tions, la chaîne de produc­tion et de livrai­son.
Dans un second temps, il va rester artisan. L’enjeu est de remon­ter partiel­le­ment la chaîne, se concen­trer sur ce qu’on veut produire, pourquoi, comment, et traduire le besoin.

La plupart des artisans purs vont alors se raréfier. "Il y a toujours des arti­sans potiers, céra­mistes et porce­lai­niers aujourd’­hui. Peu, mais il y en a. Ils répondent à des demandes diffé­rentes. Certains sont experts pour des demandes hors normes. D’autres, plus nombreux, visent des objec­tifs non utili­taires : le luxe, le tourisme, les cadeaux, les symboles, l’hé­ri­tage histo­rique, l’art."

Alors que deviendra l'artisanat logiciel?

Peut-être à des systèmes critiques où la confiance exige une main humaine. Peut-être à des créa­tions où l’in­ten­tion artis­tique prime sur l’ef­fi­ca­cité. Peut-être simple­ment au plai­sir de comprendre ce qu’on construit, ligne par ligne. Il y a un métier à trou­ver, ce ne sera pas tout à fait le même et il sera proba­ble­ment plus l’ex­cep­tion que la règle.

Coté développement, il y a toujours eu un énorme terrain de jeu hors professionnel avec l'open source.

Baseline in action is a collection of articles and demos showing you some of what's possible with features that are now Baseline.

Enter the “rule of three” — the actually actionable, pragmatic principle that elegantly combines how you should be thinking about YAGNI, DRY and premature optimisation. The rule of three states that you should only refactor (or optimise) code once you’ve written the same code three times.

At the first time of writing the code, code that’s fast and optimized is great, but if it’s hard to read and reason about, it will slow us down in the long run. Here, I like to apply another principle: “Make it work, make it right, make it fast”

It works while iteration though. In some cases, you want to leverage engineering: make it right the first pass. It happens for API validation for example, or logging correctly in case of failure.

Gall's law: a complex system that works is invariably found to have evolved from a simple system that worked

Functions should be as idempotent as possible: all it really means is that a function always does the same thing when given the same arguments. Note idempotent functions are different from pure functions. pure functions are guaranteed to not have side effects.

Then there is this single responsibility principle. It avoid changes on the entire codebase. "A small trick to check for single responsibility is to describe what a function/module/class does in a single sentence. If you find yourself saying “and”, then it probably has multiple responsibilities and should be split up."

One efficient implementation is to operate on one level of abstraction. See a function implemented in three functions. I would still be critic on this one, because the tradeoff is not worth it from time to time.

These code principles are similar indeed. "All good code is alike; each bad code is bad in its own way."

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

The beautiful thing about software is that the size and complexity of "intellectually manageable programs" can change over time as we develop better technologies.

But here’s what happened while everyone celebrated the democratization: the real challenge should have shifted from “how do we build this?” to “what should we build that people actually want?”

The barrier to building dropped to zero. The bar for what users expect shot through the roof.

Skills that matter now:

1. Understanding real user needs (not assumptions)
2. Business literacy (understanding the economics)
3. Communication skills (translating needs into solutions)
4. Craft and polish (building something truly outstanding)

When the market gets flooded with mediocre-but-functional products, users become more discerning, not less. They start caring more about how products make them feel, not just what features they have.
Start optimizing for user understanding, clear communication, business value, and thoughtful execution.

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.