#softwaredesign

How long time would it take you to write the exact same system again?

Software is an evolving entity, not a finished product. You need to edit your code to improve.

Early returns can be seen as a form of pattern matching.

An example of how collection pipelines can help solving an Advent of Code problem.

Mocks encode our assumptions, which might differ from reality.

The more you add, the harder it becomes to understand.

Two design patterns that I’ve found helpful when designing systems to deal with untrusted data.

Compose types and use them to represent complex data in a clean and type safe way.

To make something easy to understand, its parts should be at the same level of abstraction.

Create abstractions to communicate intent to your fellow programmers.

Unless you can predict the future, stick to what we know today.

Learn to move from imperative while and for loops to declarative collection functions like map and filter.

Use creation methods when a constructor fails to fully capture the programmer’s intent.

A deep dive into unit testing looking to answer why, how much, and what.

Testability and reusability goes hand in hand. When you test a function, you run the code in another context than it was built for.

How to avoid “temporal dependencies” where things must be done in a certain order.

An example of how just a little typing can help avoid several real-world problems.

A selection of functional programming concepts that I feel are helpful to all developers.

Almost by definition, a suggestion by an LLM represents the least surprising solution.

How replacing validation functions with types can make your code safer and more expressive.

Concrete tips on how to write robust tests that survive a refactoring.

An example of how moving logic and data together can result in a better design.

The need to test a private method often indicates a new class waiting to get out.

To make code easier to understand and test, try to move complex logic away from code with many dependencies.

Most complexity should be in classes with few dependencies, and most dependencies should be in classes with little complexity.

Don’t try to test code which calls static methods, try to get rid of the static methods.

Let the method signature describe “what”, the body “how”, and the caller “why”.