The story of an internal SVC system developed by one engineer that leaves the company, and the team afterwards fails to deliver.

Regardless of its age, SVC is textbook legacy software because, more often than not, a question posed about the system, to any team member, results in the same answer: I don’t know. [...] The code may tell the what and the how, but it doesn’t tell the why.

In his Software Aging paper, David Parnas warns against putting software in the hands of developers who haven’t contributed to (and thus don’t understand) its design.

Our job is to explain, over and over, the meaning of our software. We must tell a story about what our software is, and what it’s expected to become. When understanding software, we tell that story to ourselves. When changing software, we tell that story to others. Software which is complex takes a long time to explain.

The death of a program happens when the programmer team possessing its theory is dissolved.

Most people can do that (become a software engineer) but NOT EVERYONE can become a good one. To be a good software engineer, the most important thing is that you try to understand things how it works, you really really try hard to understand HOW IT WORKS, MAKE IT WORK — XT at Google

The author feelds a disconnect with web developers who knows only JS frameworks to build a website as SPA...

One dev thought it would be a good idea to put everything into the cloud without estimating the bill :-D

Every program has dependency, even C builds.

The real thing with toools like go, cargo and npm is they move that library management out of the distro’s domain and into the programmer’s.

Just remember that you can always add more, but you can’t take it away.

A summary of comments about maintaining projects over decades

About documentation:

This does not tell you however WHY things are like this. What is the idea behind how the system works? Is there a philosophy? Is there a specific reason why we do these non-obvious things? Why is the solution split up the way it is?

code definitely needs comments. Especially why a function is like that. Other feedback was to work on commit messages

Example code is often simple because it lives in a idealized world. Use defensive programming to relates possible errors.

Scaling to power of 10s is challenging. As harmful to build for the system for the future as it is to build an inefficient system for the present.

Sources of complexity:

1. leaky abstractions
2. model/reality gaps: first and lastnames; unicode...
   • fix it, hack around it or ignore the problem
3. hyperspace: multiple runtimes, various screen sizes, multiple network speed, multiple version, etc...
   • example: 3 browsers with their 4 last versions each, 3 screen sizes on 3 platforms = 108 combinations
   • try to unify the environment: electron apps. Avoid NxM complexity.
4. Complexity (homeostatis) over time
   • some people tolerate more or less complexity
   • a valuable system is worth putting up with more pain (resources, ...)

Software architecture degrades [with] changes made to the software...
Find dependencies and eliminate them
Complexity isn't always bad! i.e. Legend of Zelda Breath of the Wild's "chemistry engine"

Living with complications

• The Gordian Knot: solve your problems by changing the rules.
• Just start over
• Do less with less (reduce scope)

A head-start at the author's company?

• Local-first software: runs on your computer, but collaborates with other people.
  • In-browser with IndexedDB
• Automerge (with portable versioned JSON-like data structure)

what’s the right number of hours to work in a week

is a question behind work/life balance.

Longer days

there is a mounting body of evidence showing correlation between number of hours worked and decline in both mental health and physical health

Longer workweeks

A friend of mine who read an earlier draft of this article also made the excellent point that 2 hours at work often aren’t equivalent to 2 hours at home

Burnout

The graphs above show that you can indeed get more stuff done by working more, but only up to a point. Beyond that point, you end up with a compounding negative return. But therein also lies a clue: crunch time is fine as long as there is a recovery period afterwards.

Exerting back-pressure

Perversely, this happens more in companies where the employees feel particularly dedicated to the company’s work; employees absorb more work and tighter deadlines by working harder because they care about what they’re working towards.

I want to stress that back-pressure does not mean “just say no”. Instead, effective back-pressure is all about negotiation. [...] when you’re near capacity and someone approaches you with more work, you should present them with what work would need to be dropped in order to take on their work instead.

Working smarter

The first is to get a given thing done faster.
The second is to better choose the order in which you do things such that your time is spent where it matters most. [...] The most needed; is blocking other people; or the closest to completion.
The third is to be more cognisant of what you work on.
the fourth is to be strategic about when you work.

As a wise mentor of mine has pointed out repeatedly to me, working smarter helps, but the real superpower is resting smarter. [...] The important thing is that you feel like that time is replenishing the same batteries you exhaust at work.

Finding the time

The important thing is that you feel like that time is replenishing the same batteries you exhaust at work.

Il a fallu remettre certains systèmes d'équerre pour que les futures mises à jour soient plus rapides.

"Faire bien" du premier coup, c'est mission impossible avant d'avoir fait le tour du métier assez longtemps.

C'était soit ça, soit construire sur des sables mouvants.

Le besoin de simplicité pour prendre des billets de train n'a jamais été aussi grand.

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.