Develop by describing the problem (not the solution)
Every test should describe the problem & not the solution, every program should do both.
Most of your current programs describe only the solution to a problem long forgot in time.
Let us change this, let us write programs that are a description of the problem (as much as possible).
Let us program by describing the results we seek instead of how to meet them.
Let us embrace the declarative style of logical/relational programming! But do so without switching our current language of our current legacy project. Using MiniKanren (exemples in clojure, but works in your lang too)
Fight the System making your code sad
(Workshop, half day, Beginner)
Try to create a code you will not consider “legacy”.
I’ll play the role of your client and use around 20 techniques to make you fail.
You will fail.
We’ll then discuss what techniques I have used, how they happen in real life, how to fight them in your project.
All languages welcome. Bring your own laptop with your environment. We’ll split into small teams.