Skip to content

Instantly share code, notes, and snippets.


Marc Sallin msallin

View GitHub Profile
msallin /
Last active Oct 3, 2021

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
View example_annik.r
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)
View QuizParsingExample
String[] ExtractQuestionBlocks() {
// Do extract
for(block in ExtractQuestionBlocks()) {
Question question = new Question();
msallin /
Created Jun 2, 2019 — forked from wojteklu/
Summary of 'Clean code' by Robert C. Martin

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