cekrem.github.io

I’ve been having a week off from working with my book, mainly to celebrate the initial completion of parts I and II (out of IV).

I’m not that addicted.

I’m writing a book about Elm for React developers.

TypeScript won’t save you from yourself.

I’m rewriting Chapter 2 of my upcoming book, An Elm Primer for React Developers.

As my newsletter subscribers suspect and my Ensō colleagues already know by now, I’ve recently started writing a book.

A Pragmatic Fork Link to heading In my previous post, I explored the challenge of reacting to Shared model changes in Elm Land.

Update: Since publishing this post, I’ve taken a more direct approach to this problem.

Dear subscriber Link to heading I haven’t forgotten about you.

My phone is not dumb enough Link to heading I’ve been touching on the general topic of digital minimalism from time to time on this blog, not least in the post about dumbing down my iPhone and disabling its built-in browser.

The Accidental Teacher Link to heading I’ve been thinking about discipline lately.

Back in May, I introduced a tiny Elm package of HTML utilities focused on reducing boilerplate and improving readability.

I originally wanted to write a post about Server-Sent Events in general, and how delightfully cool they are.

Sometimes the best solutions emerge from the ashes of failed approaches.

Most applications don’t fail because algorithms are hard—they fail because our models allow states that make no sense in the domain.

At KotlinConf 2025, the Kotlin team showcased progress toward Rich Errors with union types.

Most of my day-to-day work is in Elm.

I just returned from four weeks of vacation—no laptop, no programming books, and a phone that could barely do more than call and text.

If you’re using Elm with Tailwind CSS in NeoVim, you’ve probably noticed that IntelliSense doesn’t work out of the box.

Update: I’ve written a follow-up exploring how AI degrades the institutions where theory-building happens: Part II: When Institutions Crumble In 1985, computer scientist Peter Naur wrote a prescient essay called “Programming as Theory Building” that feels…

Sometimes the best solution isn’t the most elegant one.

Last week, I watched two very different developers encounter Claude Code for the first time.

It’s awesome to learn Elm by building a side project, you absolutely should.

It’s Friday, and I’m up at 4am, wide awake, head filled with thoughts on recursive data structures and how to efficiently deal with them in our client’s Elm application.

In the Elm ecosystem, the browser is treated like an I/O device.

In the world of React development, we often find ourselves writing components that are tightly coupled to their dependencies.

We all know we should write clean code.

As I continue to build more Elm applications, I find myself creating small utility functions to overcome common pain points.

Recently, Shopify’s CEO Tobi Lütke shared his thoughts on AI’s role in coding, stating that “reflexive AI usage is now a baseline expectation at Shopify.”

Update: While simplifying a complex code example shortly before publishing, I messed up some details.

The Promise of Memoization Link to heading When React applications start to slow down, React.memo, useMemo, and useCallback are often the first tools developers reach for.

Introduction Link to heading When dealing with large lists or complex DOM structures, performance optimization often feels like a complex puzzle.

One of the most common questions I get about Elm is: “How do I integrate it with existing JavaScript ecosystems?”

I recently added a new feedback widget to this site – Feedback.one – and I’m impressed enough with it that I thought it deserved its own post.

Introduction Link to heading When it comes to React performance optimization, React.memo is often the first tool developers reach for.

In a world dominated by React, Vue, and Svelte, it might seem strange to highlight Elm – a niche language that has existed since 2012 but has had fewer releases since then than React has in a year.

In part 1, we laid out our Clean Architecture vision.

From Hugo to Kotlin: The Journey Continues Link to heading In my previous post, embarked on a bold and ambitious journey to replace Hugo with a custom Kotlin-based blog engine built using Clean Architecture principles (to the letter!).

Let’s make a blog engine, ey?

Introduction Link to heading We’ve covered Dependency Inversion, Interface Segregation, Liskov Substitution, and Open-Closed.

My First Encounter with a Kotlin UseCase Link to heading One of my responsibilities as an Android Developer in Vipps (Mobilepay) was to do tech interviews.

Staff Engineer & Senior Consultant Phone: +47 45 80 65 89 | Email: christian.ekrem@gmail.com Summary Link to heading Christian Ekrem is a software developer with over 12 years of experience in backend, frontend, and mobile development.

Introduction Link to heading After exploring Dependency Inversion, Interface Segregation, and Liskov Substitution, let’s tackle the Open-Closed Principle (OCP) in the context of modern React applications.

Introduction Link to heading After exploring Dependency Inversion and Interface Segregation, let’s tackle perhaps the most misunderstood principle of SOLID: The Liskov Substitution Principle (LSP).

Following up on my previous post about books software engineers should read, I want to highlight one particular book that I believe could revolutionize how we approach work in software development: Cal Newport’s “Slow Productivity: The Lost Art of Accompl…

Introduction Link to heading In our previous post, we explored the Dependency Inversion Principle and how it enables clean, modular architectures.

Introduction Link to heading Update: this has become a series, the next entry can be found here: Interface Segregation: Why Your Interfaces Should Be Small and Focused I’ve lately enjoyed revisiting the SOLID Design Principles.

What follows is a non-ordered & non-exhaustive list of great programming books that I’d recommend every ambitious software engineer.

My favorite consultancy Link to heading I’m thrilled to share that I’ll be joining my favorite consultancy this coming February!

The problem Link to heading TL;DR: I need a phone, for a couple of obvious reasons.