Programming

• Go
• Python
• Lisp
  • Clojure
  • Emacs Lisp
• Rust

Software should be robust. It should be designed to accommodate all known edge cases. In practice, this means predicting and handling all known error cases, enumerating and addressing all classes of user inputs, reasoning about and planning for the performance characteristics of your program, and so on.

Software should be reliable. It should be expected to work for an extended length of time under design conditions without failures. Ideally, it should work outside of design conditions up to some threshold.

Software should also be stable. It should not change in incompatible or unexpected ways; if it works today it should also work tomorrow. If it has to change, a plan shall be written. Stakeholders (including users!) should be given advance notice and should be involved in the planning stage.

Finally, software should be simple. Only as many moving parts should be included as necessary to meet the other three goals. All software has bugs, but complicated software (1) has more bugs and (2) is more difficult to diagnose and fix. Note that designing a simple solution is usually more difficult than designing a complex solution.

This (short) article is based on a Mastodon post I wrote a few weeks ago.

From: Four principles of software engineering

programming is terrible — lessons learned from a life wasted — is a very interesting website. I’ve tried to extract a few links from it with my comments in here.

• Stop Blowhard Syndrome — programming is terrible Yes, Yes, Yes !

• How I write software — programming is terrible Write boring code !

  My favourite property of good code is boredom. Dull statements one after another, no surprises, no tricks, no special cases, and absolutely no meta-programming. Boring code is the easiest to debug, to verify, and to explain.

  Boring code usually doesn’t use global state, has very precise effects, and isn’t strongly tied to the project it lives in. Boring features like single assignment, where each variable only holds one object, and not relying on changing the world around it. Boring code will only do what its asked of it and does not rely on implicit behaviours.

• Nothing is more indicative of a bullshit job than… — programming is terrible
• What makes good and what makes bad programmers? — programming is terrible Some thoughs about good/bad programmers — and really, is there good/bad ?
• Write code that’s easy to delete, and easy to… — programming is terrible
• Write code that is easy to delete, not easy to… — programming is terrible
• Write code that’s easy to delete, and easy to… — programming is terrible
• modules + network = microservices — programming is terrible
• How do you cut a monolith in half? — programming is terrible Some thoughts one cutting monolith in several pieces
• Scaling in the presence of errors—don’t ignore… — programming is terrible

Code review is one extremely powerful tool in a software developer team’s arsenal, yet it’s often neglected or used in a way that leads to toxic behavior, causing more harm than good.

The primary purpose of code review is to make sure that the overall code health of your project code base is improving over time. All of the tools and processes of code review are designed to this end.

An list of code-review article and tools aronud code revîew : awesome-code-review.

Articles around workspaces remote or localhost and dev experience.