Less is more. Less is also more effort. Is it worth it? We keep talking about incremental development, but we don't talk enough about decremental development. When we talk about refactoring, we often speak optimistically and vaguely about improving code and cleaner code. In the real world the main activity of any significant clean-up is throwing out and reducing. The less code you have, the less you will have to optimise, to secure, to debug, to rework, etc.; the more of a codebase you will be able to fit in your head and understand and reason about.
What can you remove? Dead code, speculative generalisations and needless abstractions. What can you reduce? Accidental complexity, verbosity and first-draft thinking now that we know better. What you do to motivate and improve decremental development? Attend this talk.
It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a paradigm also represents a way of thinking. Having only way to think about problems is too limiting. A programming paradigm represents a set of patterns of problem framing and solving and contains the ingredients of software architecture. As Émile Auguste Chartier noted, there is nothing more dangerous than an idea when you have only one idea.
Perhaps even more problematic than being stuck with a narrow view of paradigms, is being stuck with a dysfunctional view of each paradigm. For instance, many developers working in languages and frameworks that support object orientation lack a strong idea of the principles of interaction, data abstraction and granularity that support an effective view of OO, and instead surround themselves with manager objects, singletons and DTOs.
During the day we will explore the character and style of different programming styles, patterns, paradigms, languages, etc., with examples and opportunity for discussion.