Skip to content

Coding Practice

My Highlights of NDC Oslo 2022

Back in Oslo at last. After an online edition of NDC Oslo in 2020 and the travel restrictions at the start of the Omicron wave in 2021, I haven't been to Oslo for a while.

Visiting in September is in many ways different from June. It is colder, and it gets dark early (around 7 pm), yet Oslo is still the same with its constant changes. The Munch museum and the new Deichman main library are now open. After seeing for years how those buildings grow, I now had the opportunity to visit them. Both are close to the Oslo Opera House and worth a visit.

NDC Oslo 2022 Workshop: Code That Fits in Your Head

Developers spend a lot more time on reading code than writing it. Therefore, if we want to get more effective, we must take a deep look at the reading part. In this Workshop Mark Seemann uses a set of heuristics to address the common obstacles developers face when it comes to understanding code.

Keep in mind that heuristics are a rule of thumb that you always should take with a grain of salt. They may be a great help for certain situations but may miss important details in others.

The Split Phase Refactoring

When we write code to solve a tricky problem, we often end up with methods that show us the whole journey of how we got to the solution: there is code to load data, followed by transformation logic intertwined with data clean-up hacks to prevent the creation of a report from exploding.

It is nothing wrong with writing code that way and to iterate until we reach the goal. The problem is that we keep everything in the order in which we initially wrote it. The developer who needs to fix a bug does not care if we found a missing default value at the beginning of the implementation or at the end. They much more prefer code that separates the different phases (load, clean-up, transform, report) and guides them towards the place where they should implement the fix.

Shorten Your Feedback Cycle

One of the most important ideas of agile software development is for me the short feedback cycle. Instead of working for weeks or even months at a problem on our own, we try to get feedback as fast as we can. That not only works with user stories; we can apply this idea to every task independently of its size.

I experienced a great example of this principle a few weeks ago. Using this example, I would like to give you an idea of how to put a principle into action. For the sake of brevity, I am using the format of a PAR statement (problem, action, result).