Thoughts, observations, insights, mostly from my experience in software engineering
I find it difficult to “teach” staff-level software engineering work (system design, technical planning, etc.) as there are no hard and fast rules. On the contrary, it’s about knowing when to break the rules, which requires experience and getting comfortable with ambiguity. These kind of skills are best acquired by working on real projects, with real constraints, and expert guidance.…
... or, why LLMs have no place in internal communications of high-performing organizations. Organizations depend on their inner relationships. The quality of these relation­ships often make or break an organization’s mission: Is there enough trust between peers to collaborate? Are leaders able to motivate and inspire? Are we willing to make sacrifices for each other? Relationships are shaped…
Some time ago, I helped build a small translation feature. Our users regularly needed to translate some of their assets, and we figured it would be straight­forward to integrate translation right into our platform. In the morning, I received a UI design file and got to work. In our backend, translation was already available as a reusable primitive. Based on that, implementing a user-facing…
I often follow the functional core, imperative shell way of constructing software: Isolate business logic into a set of pure functions (the functional core). Implement side-effects and mutable state in a thin layer around the core (the imperative shell). This not only shapes how I write code, but also how I think. When designing a software system, I’ll assume the functional core and the imperative…
Recently, a colleague asked me for a code review on some complex UI changes. The idea was to make an error-prone form easier to use by displaying warnings in the right moment, and automating various state changes in the background (think “smart configurator”). The requirements were given upfront, so my colleague was in execution mode, turning these requirements into code. Glancing over the pull…
I find it useful to treat agile software development as an outcome , rather than something we can adopt . Taking that perspective, we can invert the problem and ask: What is making us less agile, right now? The answer is often surprisingly tangible, and rarely about missing agile methods. It is about the concrete friction we encounter when trying to get work done. For example: Slow builds…