367 private links
Try writing a tax code in chat messages. You can’t. [...] That’s why we use documents
You program by writing documents instead of chatting.
It follows https://chriskiehl.com/article/thoughts-after-6-years. 4 years later.
A software system's structure is essentially a formalized bet on change patterns you anticipate having to deal with in the future.
- know your audience
- careful with breaking changes
- document your way to features when the feature is out of scope of the project
- follow the tag on StackOverflow
- Micro-optimizations can matter
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.
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.