Ever since I joined 8th Light 4 years ago as an apprentice, our apprenticeship has been changing. Sometimes it had to adapt to the needs of the mentor being on client site most of the week. Or it had to adjust to the skills and talents the apprentices brought with them. I have a few ideas to highlight learning outcomes, provide more structure, yet keep the apprenticeship individual. And yes, this will be yet-another-app.
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
