Developers want to keep getting paid for what they already know and use. We worry that today’s optional technology will become tomorrow’s job requirement. That fear isn’t irrational - look at job boards today and count how many React positions you see compared to jQuery.

The guy made some cool things: sshx, Bore, Rustpad, and many other things.

Blog: https://www.ekzhang.com/writing

A simple question

Pour passer de passioné de code (hobby) à métier, il faut que l'activité s'inscrive dans un cadre: des compétences techniques, de la formation pour en acquérir, un cadre métier, des engagements, délais ou coût à respecter, des pratiques parfois historiques, un jargon, cadré par une vision stratégique et des tactiques.

Tout cela se passe dans des équipes.

La série de contraintes entre un feedback et son implémentation

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.