Four principles of software engineering

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

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.

Code reviews

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.

TODO How to do a code review | eng-practices

[2019-10-07 Mon 10:44]

Pair programming   pair

TODO On Pair Programming

[2020-02-12 Wed 09:21]


TODO Porn, Zen, and .vimrc

[2020-09-17 Thu 08:36]

Could be on it’s own entry on editors

TODO Higher-order functions are like inheritance

[2020-09-18 Fri 11:29]

TODO Good comments are to the point and flow well

[2019-12-12 Thu 18:03]

The Wrong Abstraction — Sandi Metz

A really interesting article about a really good point : sometimes duplication is better than the wrong abstraction !

TODO Constraint Driven Development | Trineo

[2020-03-29 Sun 06:15]

TODO Your syntax highlighter is wrong

[2019-12-12 Thu 13:35]

TODO Why I’m leaving Elm -

[2020-04-09 Thu 19:48]

TODO Text Editors – Andrey Orst

[2020-05-14 Thu 12:31]

TODO The secret skills of productive programmers

[2020-05-15 Fri 14:33]

TODO Simplicity (mostly) guarantees security

[2020-05-16 Sat 15:17]

TODO The Mediocre Programmer   #read

[2020-05-25 Mon 11:10]

TODO Michael Feathers - Testing Warranties

[2020-06-23 Tue 17:39]

TODO My thoughts about editors in 2020 –

[2020-09-07 Mon 10:28]

Because I think the speed doesn’t matter when programming, I think the most important part to remember here is the comfort: the wrists don’t move and my fingers fly around the keyboard, whatever the speed.

TODO 3 tribes of programming

[2020-09-23 Wed 12:12]

TODO Code Only Says What it Does - Marc’s Blog

[2020-10-27 Tue 16:22]

TODO End-user programming   inkandswitch

[2020-02-08 Sat 18:02]

TODO Functional lessons learnt | 8th Light

[2019-11-06 Wed 09:29]