msallin

blueprint:
  name: ZHA - Philips Hue Dimmer Switch Config - V2024.11.25
  description: "Control lights with a Philips Hue Dimmer Switch (only RWL020 (US)
    and RWL021 (EU), RWL022, the one that says 'hue' on the bottom, has a different
    button layout.)\n\nThis blueprint is a simplified version of stefanroelofs's `ZHA
    - Philis Hue Dimmer Switch V2', but this one has no default inputs and with full
    configuration available. This makes the remote easily configurable for purposes
    other than controlling lights.\n\nIf you are intending to just use it for use
    as a light switch, I recommend using his blueprint, which you can find at https://gist.github.com/stefanroelofs/775e2e0a3cdb3d72a9451fb247492d59\n\nIt
    includes customizable 'on' button behaviour and default setup of the dimmer buttons

msallin

Fallacies of Software Engineering

This document is a collection of fallacies I encountered during my years as software professional.
Most of them are known from the literature in some way or the other.
The problem with them is that they might be correct according to intuition. However, lead to a lot of unnecessary spent money.
Interestingly, I see the mistakes repeated over and over again. Because of missing knowledge, due to well known cognitive fallacies or also because of opportunistic behavior and politics.

Software Development

1. Shortcuts Exist

msallin

participant_id <- c(1,1,2,2,3,3,3,4,4)
answer1 <- c(12,123,33,333,3,22,11,32,12)
answer2 <- c(12,123,33,333,3,22,11,22,11)
results <- data.frame(participant_id, answer1, answer2)
# Results looks like this:
# participantId answer1 answer2
# 1              1       12       12
# 2              1      123      123

unique_participant_ids <- unique(results$participant_id)

msallin

String[] ExtractQuestionBlocks() {
// Do extract
}

for(block in ExtractQuestionBlocks()) {
}


Question question = new Question();
question.SetText(block[0]);

msallin

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules