Continue reading

For a new project I’ve been thinking about an idea/abstraction/pattern that is really not new (few things are anyway) but I thought might be worthwhile writing about before running off and executing on it: A Pipeline in Elixir.

Today we talked through a rewrite of a largish chunk of legacy code. This code had been written over the past few years, with a fair amount of hard-codings, rules, and decisions baked in. Precisely those hard-codings, implicit rules, divergent decisions were the reason we proceeded with a rewrite. Our preferred approach was radically different making a straight refactoring uneconomical. Plus, our use-case was isolated enough that we could afford testing our ideas without impacting current users.

A while ago I wrote about what I thought it would take to have a code base be maintainable within a 4h window. I only got as far as wondering about certain aspects: What languages should be used? What frameworks? What about build tools? In experimenting on my code base, I have come up with what I believe to be good reasons to spend more rather than less time with your pet project.

Over the last week I’ve picked up a project I had sidelined for a while. Since I hadn’t looked at the code in while and I knew was part way into a particularly tricky pull request (changing the way a core structure is persisted to disk and read back) I looked around a bit. I was surprised that the code did not feel in as good a shape as I thought I had left it.
Continue reading

At my company, we get 4h per week (10% of our time) to work on anything we feel like will help us become better at what we do, will help the community of software developers or will help our company be a better place. I have realized that I rarely work on our internal tools myself. Most of my time goes into exploring new languages or frameworks, preparing blogs or talks, contributing to internal discussions, or working on my current-pet-project-of-the-week.
Continue reading

Today was a fairly ‘feedback-centric’ day for me. I had multiple conversations with different people. In some conversations, I was explicitly asking for feedback on a presentation that was given a few days ago. In others, people were asking me for feedback on where they currently are on their path to mastery and how to progress on it. And finally, in a different conversation we talked about our current feedback process, why we do it, what shortcomings it has and how we could improve it.
Continue reading

Today I think I may (possibly) have understood something about ELM. Before we look at some code, here is the 5sec intro into ELM: ELM is essentially a Haskell that runs in the browser. It makes an enormous effort to have a friendly and helpful compiler. And it succeeds at it! It promises zero runtime errors, has a strong type system and comes with a batteries-included architecture that is supposed to result in easy to maintain web apps.
Continue reading

We were recently talking about the backlog of user stories for a project on the near horizon. We wanted to create an exemplary backlog with meaningful stories that would allow the team to succeed. The backlog should also show the less technical side of the organisation that they needn’t deliver all functionality in one large push. When the question of which story to tackle first came up, “do the most important thing” didn’t feel good enough.
Continue reading

Over the last year, I have attended 3 or 4 Release Train Planning (RTP) meetings. In these meetings, the entire team came together and planned out the next release. A release is roughly a three month period, made up of 6 two-week iterations. The way these meetings are run is that the objective of a given release is introduced by a business representative and teams break down the work into stories which are mapped against the 6 iterations.
Continue reading