|
🔗 From the web |
|
|
|
How to make low code work long term |
|
|
Low-code tools don’t always equal long-term solutions. Here's how businesses can make low-code tools work for the long haul. |
|
|
|
|
|
|
Notes on an Observability Team |
|
|
An Observability Team should be a compliment to, not a replacement for, a strong Observability culture with an engineering team. It's an easily misunderstood team within a company. Not every company is going to need an Observability team, but at a certain scale, it becomes a reasonable investment or full-time focus. The goal should be that the benefits of Observability tools get out of the box and get useful to your organization. The Observability is being able to derive insights about your software systems without having to go back after the fact and change the system. |
|
|
|
|
|
|
We Learn Systems by Changing Them |
|
|
Michael C. Jackson, a systems scientist, contrasts action research with old-style hard science, which tries to study a system from the outside. In the social world, there is no outside: we participate in the systems we study. Jackson continues: To ensure scientific rigor, this demands a close analysis of the initial situation, clearly documented action to bring about desired change and continuous monitoring of effects, and careful analysis of the end results of the action. This is also noticeable in code: when it comes to an existing codebase, we get a handle on it by changing stuff. |
|
|
|
|
|
|
Does the Linux Kernel need software engineering? |
|
|
For those looking for a short answer: yes, it does. The article details why in a more elaborated way. |
|
|
|
|
|
|
In Praise of Stacked PRs |
|
|
“Stacked PRs” is the practice of breaking up a large change into smaller, individually reviewable PRs which can depend on each other, forming a DAG. Stacked commits use a single commit as the unit of atomic change. Github encourages the Stacked PR approach, whereas tools like Gerrit encourage stacked commits. |
|
|
|
|
|