Except those years of experience and knowledge are important.

Software engineers have done themselves a disservice by years of talking about “beautiful code”, “code ninjas”, and “tech wizards”. It has given outsiders the perspective that code is an art, something that has no significant meaning beyond cultural significance. Expect, it’s not.

Code turns logic into a tangible artifact, a repeatable pattern. Mathematics does the same. But the level of abstraction is high enough in code that we can nitpick over naming or styling. Regardless, code is a manifestation of logic.

As non-developers get their hands on LLMs, they’re ignoring the logical engineering approaches which software engineers follow. Their AI claims it is right, after all.

Should we blame the vibe coders for ignoring these practices? If they’re using production data, or deploying to production, a little bit. But the root problem doesn't go away by pointing fingers at early adopters. The root problem is that software engineering is not understood.

Drawing rivalries of “us vs them” isn’t useful. The vibe coders will continue regardless of how loud anyone protests, even if the protesting comes from experts or reporting lines.

While I’ve personally found generative AI largely low quality, I still think it can be a useful tool. In software engineering, we’ve spent years debating different tools. We know the saying “when all you have is a hammer, everything looks like a nail”. Vibe coders don’t know about the screwdriver, the drill, the spanner. They also don’t understand the limitations of the hammer.

Not every vibe-coded app requires expertise. If it’s a prototype thrown away after a week, then there’s no harm in terms of software engineering. But when you give people the ability to create things or solve problems in exciting ways, they become attached to their creations. Vibe coders will not throw away their smashed up wall, no matter how many holes it has in it. They aren’t aware of the holes. Again, their AI tells them it can fix anything and everything.

So, what can software engineers do?

I have no idea. And it fills me with existential dread to see all the things I value being torn down:

• open source code has been shamelessly cloned by those who were trusted to look after it, and is now polluted beyond repair

• the natural filter of ideation and development via a bottleneck is replaced with “let’s do all the features”

• small features have large, messy code

• security, intentional slowness has been replaced by “get X out the door ASAP”

• resilience and reliability doesn’t exist when someone ships code they don’t understand

• experts are being ignored, and companies are pushing ahead on hype alone

The clear path ahead, to me, is filled with chaos, security and privacy breaches, and downtime. We are already seeing the consequences of AI code reaching production: downtime across Big Tech.

We can’t educate everyone with access to an LLM about software engineer. If you give them things to read, they’ll ignore it. Software engineering has never needed degrees to be accomplished: but it has required experience and understanding, usually earned through interest. Generative AI tools lets vibe coders skip the experience and the understanding.

I don’t know the right answer. But I know that software engineering needs vocal voices to speak about the expertise, because being software engineers, we are often too eager to jump onto whatever the most fashionable tool is without much consideration for is this right?

I have some hope. After all, this isn’t the only inflated hype bubble that we’ve run into. I think the clearest path I see:

• Move away from Big Tech models ASAP to cut through the massive moats being built through huge amounts of capital

• Unions and academia should work to define what it means to do software engineering as it is in some countries. It should be a licensed activity. Anything else is “sparkling vibe-based text generation which happens to look like code”. Clearly define the difference between engineering and vibing. There are plenty of good use cases for AI. Deploying to production is not one of them. The practices of software engineering need to be clearer to non-developers.

• Educate the vibe coders as quickly as possible, so they actually understand the impact of their code on companies, systems, and worst of all - their software engineering expert colleagues.

• Run vibe coding tools remotely, in containerized environments via a web browser. Definitely not running code on local devices.

I don’t know.

Subscribe now

Share

Brooke’s law:

Adding manpower to a late software project makes it later.

As the manpower for a project increases, the amount of coordination increases. A team of 8 people will often find themselves needing to fix merge conflicts, talk with each other about features or bugs, and decide who works on what and when. A single person project might produce less overall code, but the entire context lives inside that person’s mind. Adding one extra person completely changes the dynamic. “2-pizza teams” are approximately 8 people, usually with some split expertise. The overhead is substantial, but many find it a good balance between overhead and production.

Open source projects scale to many more contributors, but the number of core contributors remains relatively low. There just aren’t that many people who know the codebase in-and-out to the extent that mass collaboration is possible, therefore pushing collaboration to the conceptual level, or one-off-issues.

The bus number for a single person project is 1. Far too low for anything intended for large scale production. If that person is gone, the project is dead. Even for huge open source projects like the Linux kernel, the bus factor is very low. It is difficult for contributors to have the complete overview. The evidence from corporate and open source coding reveals a learning: a well maintained project cannot have hundreds of key people, but it also can’t have one key person only.

Over time, teams or open source communities identify better ways to work together. If they don’t, then they stop existing. Routines, habits, and interactions become codified as a way of working.

So what does all this mean in the context of AI agents?

First, let me try to define my personal definition for the sensible production use of generative AI for code. What does generative AI do? It takes some input, usually text, and produces an output, usually text. This is not anything new. Parsers and compilers have existed as long as high-level programming languages have. Is the logic linear? Is the logic repeatable? Nope. It is more similar to search than a parser - ephemeral results from a known input. It is not deterministic.

IDEs have had auto-complete for decades. Generative AI is a fancy auto-complete that seems intelligent. But it’s not intelligent. “Reasoning models” don’t reason. “Thinking models” don’t think. They take text, run it through a model trained on code, and produce similar output to what they have been trained on.

Therefore, I would define sensible production use of generative AI for code as “the use of AI to produce code in a controlled manner such as an auto-complete suggestion, or search, with a human software engineer in the loop”.

If AI for coding is used sensibly, a software engineering human will review and own the code before it is pushed to production. The AI produced code becomes just another way for a software engineer to transfer their ideas into code. AI auto-completion falls into this category. The software engineer takes responsibility for any bugs or security issues introduced through their code. There is no additional manpower added to the project, but the manpower may get more efficient. Brooke’s law does not apply in this case.

But the flow with AI agents is substantially different. Rather than an auto-complete, AI agents go away, figure out some code they deliver, and the human’s input is minimal except for describing the feature and finally reviewing the code. The output of the AI agents adds “AI power” to the project, which triggers Brooke’s law. A human may merge the code, and therefore take responsibility, but here’s the thing: software engineers are bad at reviewing code they didn’t write. A sensible project will require strict reviews, QA, testing of any AI produced code. Humans are just not good enough at reviewing code. Maybe one day we will be, but the tools we have available to us today are built with producing code in mind, not reviewing code.

I’ve used and tested AI agents. I’ve read the docs, I’ve listened to people who claim they’re able to produce high value code through them. I suspect I have a higher threshold for code merges than most people, particularly on solo projects. AI agents are being hyped as a way to code without needing to write it yourself. Spin up an AI agent, send it off, done. I have not found that to be true. Every single change and commit needs manual verification. Every single change and commit has the potential to introduce code so harmful to the codebase, either due to poor readability or poor implementation, that I have reflected multiple times why does anyone do this? Why am I doing this? I could’ve saved myself time by writing it myself.

I acknowledge that my own threshold to merge might not be the same as others. However, there’s some things I value both in my own work, and the work of others.

• Minimalism. Code that only exists because it has to. Low-noise, high-signal.

• Architecture driven by good types and data structures.

• Changes that are easy to understand or rollback.

• Security as a guiding principle, not an after-thought.

• Human verified. Natural ways to interact with the product (e.g CLI, TUI, GUI, APIs).

• Code I can read, understand, and change.

The AI agents I’ve tried have all failed in these regards. Even with instructions, they have produced incredibly noisy code.

Inventing new functions when a function already exists that will serve the purpose. Comments that mean nothing. Inlining code where it adds nothing. Types which have been ignored. Repeated bad habits that I would expect a junior to learn from. Changes which are just too big to understand. Pull requests that end up with hundreds of comments before it’s worth merging. Security issues while asserting “this code has been generated with security in mind”. Agents that tell you confidently “I’ve fixed the problem”, while the problem is still clearly there.

I would be ashamed to push that code to production. But most concerning, it would introduce AI-produced code that would slow down the humans working on the project. Either as the reviewer, or as the poor soul who would then have to work with such a codebase.

Suddenly the overhead increases from beyond merge conflicts, or schedule management. It becomes a factor of something unintelligent made this code. Something, not someone. Something that doesn’t actually understand what it did, or why. Something ephemeral, where learnings are brief unless it is retrained or has added context. Something that can’t take responsibility. Something that needs human coordination. Therefore, the overhead with AI agents is larger than that of a human. And no, getting AI agents to review code made by other AI agents is not a fix for the problem. It just means you’re shipping code you don’t understand, but you are responsible for.

Just like the mythical man month, the mythical “AI agent” month remains just that: mythical. Not everyone will realize the myth right now. But in 2 years time, when they can’t find anyone to work on their nightmare codebases, they will.

Subscribe now

Share

When I use software, I find bugs. When I find bugs, I want to report them or fix them.

If I find a bug on a small company’s website, I email them with the fix1. Often it’s something small, like bad contrast. Sometimes it’s even smaller, like a typo. If it’s bigger, I’ll usually include some description of how I think they can solve the problem. Very rarely, I’ll offer to implement a fix for the company. I’ve almost always done this entirely free in the past. If the site is one I use often, I want it to work well. And if it’s not one I use often, then it’s neat to be able to say “I did that” occasionally.

As a company grows, I am less likely to send them feedback. The biggest factor is that it’s hard to give feedback to a larger company. A smaller company often has one email address, and you’ll get an actual human replying to you. Figuring out who to email inside a bigger company is so difficult that people used to take to Twitter in order to get any traction. If I’m spending time to report an issue, I want to know my time has been well spent and worthwhile.

Most bugs are minor annoyances I can live with, but bigger bugs are something I want to follow closely.

When the code for a tool I use is open source, I will usually either make an issue or submit a pull request. From there, I can see the entire chain between issue creation, code merging, and release. I can even run a branch locally. I cannot do the same in closed-source code. I must wait and hope that the bug is fixed.

There’s been many times where I’ve encountered a bug I know I could fix if I had access to the codebase. Problems I’ve reverse engineered to find a solution, often out of my own personal curiosity.

I follow the mantra: “leave things better than when you found it”. Open source allows me to leave things better - to clean up bugs, to write documentation, or partake in feature discussion. I find the collective energy in open source communities inspiring.

To all those forgotten unpaid maintainers, to all those people who help lift up a project, you are all collectively leaving technology a better, more useful, place than how you found it.

Open source is where I learnt to be a developer. It’s how I learned to interact with developers and assume good intentions. It’s where I learnt how to develop languages, it’s where I learnt that one piece of code can have a big positive impact. It’s where I learnt how to manage backlogs. It’s where I learnt to approach new communities with an open mind. But most of all, it’s where I learnt how to be passionate about code.

Subscribe now

Share

As an enabler, I become involved in many different discussions between different people in the organisation. When people reach out to me, it can be considered a reflection of how much value they get from my assistance. At the same time, it can reflect a lack of documentation, a lack of established workflows, or a lack of a shared overview.

In the last couple of years, I’ve taken a full vacation out of season. In the Nordics, summers and school holidays tend to leave offices empty. I work during those periods, and travel when most people are at work.

The great thing about going AWOL for so long is that it forces the company to function without me. Many things will either become irrelevant, or solve itself through people connecting directly. Anything else can wait. It's unhealthy when a company that can’t handle a couple of key people being gone for an extended period of time.

I’m a strong believer in constantly trying to make manual work I do redundant. The more of my time I free up, the more involved I can be where it matters.

To prepare people for my absence, I let the people I work with the most know ahead of time. This year I created an offboarding document, exactly as I would if I was leaving the company. I went through the topics that people reached out to me about in the last 2 months, and listed who they should talk to in my absence - defaulting to a channel rather than an individual. I put a status for each project I was involved with, and provided links to reports or docs people often ask me about. I shared the document with everyone, giving them a couple of days heads up to ask any questions before I’m gone.

Some of the value of my role comes from all the extra bureaucratic issues that I can reduce. Two groups of people should be most effective when talking directly, but a wide range of reasons can introduce significant overhead. In these scenarios, I can help clear cultural or organisational barriers, or provide direction and alignment with the company strategies and goals. I see this as reactive: a team has a need, and reactively I work to help them solve that need. But I want to be redundant in these scenarios too, which leads into proactive work to establish and grow the culture and processes.

It is hard to go away for a month, but it’s very much worth it for me personally. I’ve been burnt out a couple of times in the past, so vacation is highly crucial for me. My family and friends mostly live far away, making short week vacations difficult. 7 days when 3 of those days are spent travelling isn’t really a vacation in which I can relax. But a month where I know I have no work obligations is a true vacation for my brain. A clean handoff means that I won’t be worrying about paintings half painted, questions waiting for my answer.

Subscribe now

Share

In my role at work, and in Tekna, I constantly try to push the needle. If something is not working, I want to fix it. If something is not good, it needs to be changed. Not everything can be fixed, and fixing things takes time.

Sometimes that can come across as a strong opinion. Sometimes, it is. I try to back my opinions with facts, but I’m human - sometimes I like things just because I like them. I try to be as introspective, and question why I like things. Sometimes I figure it out, sometimes I settle for being human.

Pushing the needle needs strong voices. Europe is undergoing a drastic change in relation to the USA, and we need voices in Europe who can guide the way. I don’t think that is necessarily me, but until there’s a clear path ahead, I will be sharing my voice. I’ve spent a lot of reflecting on my opinions, and a lot of time gathering data.

However, collectives of people begin to suffer when fear, uncertainty, and doubt set in. If colleagues *feel like* they can no longer depend on other teams to act in the best interest of each other, trust is broken. When trust is broken, it is extremely damaging to an organisation. In open source collectives, damaged trust is enough to kill projects or collaborations. In work collectives, it eats up so much time and effort to undo the damage.

Often employees would rather leave than to remain working with those they no longer can depend on - worse still, sometimes they’ll stay in the company but sever all ties and actively work to avoid each other.

I take the time to get to know my colleagues. I don’t want to doubt them, I don’t want them to doubt me. I want them to feel certain that they can depend on me to do my job, and I want to be certain I can depend on them to do their job effectively.

Every time a decision is made behind closed doors without good technical or culture insight, I’ve seen it cause fear, uncertainty, and doubt (FUD). Every time I've seen FUD set in, it’s created a waste of time, energy, and resources. It takes so much effort to establish trust, and so little to destroy it.

My advice is always the same: talk to people, bring them along for the journey, and actually understand the problem you’re solving. Most people have good intentions by default. But a failure to communicate or introspect turns good intentions to bad implementations. Don’t give fear a chance to grow.

Subscribe now

Share

A note: I’ve simplified some concepts and some names.

Code

Code is the fundamental part of all software engineering. It represents an idea, a flow, a behaviour.

Programming languages

Standardized ways of writing code so that the machine can run them are called programming languages. Programming languages define a syntax and grammar, which are then implemented by parsers, compilers, and interpreters. Programming languages allow a human to turn ideas, concepts, or thoughts into structured code that a machine can understand. Each language has a different mental model, and a different feel. As this is a direct form of creativity, many developers have strong feelings about the programming languages they use.

There are different families of related or derivative programming languages. Languages within the same family will share many of the same concepts, but may differ in implementation or syntax. Knowledge in one programming language in a family will usually greatly help a developer understand other languages in the same family. Programming language design is highly iterative, developing concepts from other languages.

Functions

The repeated use of certain pieces of code can be turned into logically distinct reusable code called functions. Depending on the language, they may also be referred to as methods or procedures. There are small differences in the definition of each, but regardless, they serve the same purpose - to describe a specific behaviour that operates using specific data. That behaviour can be reused in multiple places by running the function.

Functions may take arguments or parameters. Arguments allow data to be used from elsewhere in the program. A good function has a clear purpose, with a limited yet useful set of arguments. A function that serves too many purposes makes code harder to understand.

Types

The structure of data informs the usage of the data. Types provide both humans and computers with information on the structure. The structure guides the implementation of functions. Types also enforce contracts between code, so that invalid or incorrect usage is caught during development rather than when the program is running. At a basic level, types ensure the data is of the correct family (numbers, strings, booleans). At an advanced level, known as type driven development, types provide restrictions on possible values of data so that there’s only a specific subset of values.

Every mainstream language has a form of types. The way that types work, known as the type system, often share common behaviours and features across a family of languages. However, the idiomatic usage varies greatly between languages. TypeScript, Python, Java, C, Rust, Haskell all have very different approaches to types, even with considerable overlap. The choice of language therefore impacts the structure of data, and therefore impacts the architecture of your program.

Schema

Data may have a known structure called a schema. A schema, much like types, ensures the properties of data for both human purposes and machine purposes. A human uses a schema to understand data, whereas a machine uses a schema to verify the data it receives is of the correct structure.

Lists and arrays

Lists and arrays provide a collection of related data in such a way that each item in the collection can be used or manipulated via iteration. Arrays are typically the most efficient collection storage with the lowest overhead, leading to their prevalence as a concept in most programming languages. In some languages, lists and arrays must contain elements of the same type. In others, the elements may have different types.

Hashmaps and dictionaries

Maps provide a structure where a collection of elements can be accessed via a label very quickly. They are often used for data where there are named fields which the developer may not know when they are writing the code. Most languages have some type of map collection.

Objects

Data may be combined with functions that work specifically with that data. In object-oriented programming (OOP), objects are the main concept used to define behaviours and limit access to data. Objects have different implementations in different languages, while the purpose usually remains the same.

The structure and relationships of objects may be defined through a constructor called classes. Classes may have relations to other classes or types.

Not all languages have classes, though most have a construct that serves a similar purpose.

Scope, local vs global

Reducing the cognitive load of code uses scope to limit where different code is used. Most languages have some distinction between the scope of data, functions, and types. Scope allows for different data to be referred to by the same name, or limit what developers have access to elsewhere in the program. Scope restrictions guide architecture, and reflect architecture. Local scope refers to items within a small block of code, such as a function. Global scope refers to items accessible throughout the entire program or file. The majority of items should be within the local scope of a function or class, with very few items in the global scope.

When considering performance optimization, items within the global scope are difficult to optimize as they must be accessible in more situations when compared to those in the local scope. This plays a factor when reducing the memory usage of an application, as garbage collection will cleanup data that no longer needs to be accessible.

Object-oriented programming

Programming languages that focus on objects and classes are known as object-oriented programming languages.

Functional programming

Programming languages that focus on the use of functions belong to a paradigm of languages known as functional programming.

Immutable

A value which cannot be changed is known as immutable. Immutable values allow a programming language or framework to apply optimizations, while also reducing unexpected behaviour due to unexpected changes of data. Some programming languages, like functional programming languages, may have every value stored as immutable data. Others may not have any immutable values.

Engineering

Code is only part of engineering, with software engineers needing to know many adjacent topics.

Security

As code allows for applications to scale to millions of users, it also provides a way to scale security exploits to millions of users.

Humans make errors. AI makes more errors. A good software engineer will acknowledge that they are not perfect, and take steps to reduce potential security attack surfaces, and use tools to automate security analysis.

Logging

To aid with debugging and optimization, applications should provide logs to developers. These logs typically include metadata about a user’s device, any actions taken, and communication between services. Logged errors help a developer identify the root cause of a problem.

Logging too much data can create privacy and security breaches. A typical example is logging passwords or accessing tokens in plaintext, therefore leaking them.

Supply chains

The security of the program applies to all the code that the program uses, not only the bespoke code written for the program. For frontend code, that includes libraries used in user-facing code and the build chain used (e.g esbuild). For backend code, that includes libraries, tools, and the operating system itself. Software engineers have a legal obligation to ensure that libraries are up to date to prevent security risks. As a result, using fewer, well-trusted libraries reduces the attack surface.

Performance

Different languages, frameworks, and libraries have different performance levels. Choosing the right tool for a problem is something a software engineering team will balance against what is enjoyable, and what they know. Performance is a trade-off to consider along with other reasons to use a specific tool - rarely is the fastest tool is the most used tool. When comparing tools, it’s important to compare apples to apples. Two different frameworks in two different languages are mostly irrelevant unless a team is willing to rewrite the codebase to a new language.

Even within the same language, a performance-optimal implementation of logic might be rejected in favour of a more readable implementation. A good software engineer will know when and where to apply performance optimisation. Before time is spent on optimising performance, gathering metrics on the runtime ensures that time is spent on the right parts.

Compilers and interpreters

Code written in high-level languages must be turned into a form that can be understood by a computer. There are two main forms: compilers and interpreters. A compiler will turn high-level code into machine-compatible code before the program code is run, whereas an interpreter will turn high-level code into machine-compatible code as the program is running.

It is easier for a compiler to apply type checks, syntax checks, and performance optimisations than for an interpreter as the entire program is understood (parsed) before the code has been run. However, interpreted code is typically faster to begin running as there is no step before running required to parse and generate code.

The differences between the two aren’t as significant in modern development as they used to be. However, the difference in mindset remains an influence in development. Interpreted languages like JavaScript or Python come with an expectation of a fast turnaround for development, whereas compiled languages like C or Rust come with an expectation of a fast runtime after the program has been compiled. As a result, interpreted languages tend to involve a faster loop testing out ideas, while compiled languages have a lot of surrounding tooling.

Abstraction

Re-usable code and data is often abstract. Instead of applying for a very specific set of values, an abstraction may vary in the values used. A function with arguments and a return value is a form of abstraction, as are types and classes.

A software engineer will need to balance code between abstraction and specificity. Abstract code comes with benefits such as simplify code reuse and relationships, but may introduce cognitive load and performance issues.

Code duplication

When code is repeated, it adds more places where bugs or changes must be implemented. To avoid tech debt, a developer will seek to replace duplicated code with one, more abstract piece of code. This is known as DRY - don’t repeat yourself.

Architecture

The design of technical systems is known as the architecture. Interactions between different services or code are guided to the architecture of the system. At the highest level, the architecture might be represented by diagrams or specifications. The architecture of a corporate codebase is often a reflection of the organisation (Conway’s law). However the architecture of open source codebases often reflect the personal preferences of the contributors, as libraries reflect the needs of many different corporate or non-corporate entities.

Workflow

A software engineer’s workflow is vital to their success. A messy workflow often results in messy engineering.

Debugging

The process of identifying and fixing bugs is known as debugging. Debugging is a skill built up through familiarity with the tools used (languages, frameworks, libraries) and the project itself. There are many tools for debugging, often language or framework specific. The concepts of debugging are roughly the same across all tools however.

A software engineer should be able to both recall bugs they’ve encountered before (and sometimes avoid repeating them), and find new bugs they haven’t encountered before. While senior developers might have a larger set of bugs they’ve encountered, junior developers can still be highly skilled debuggers through adaptive learning.

Tests

Automated reproduction of behaviour and validation of the results are known as tests. Testing too little reduces the confidence a developer may have in changes they made. Testing too much slows down development. A collection of tests are known as a test suite. Good test suites are run frequently, covering enough of the behaviour of the program that possible unintended changes or implications of behaviours are caught. If a test suite is too large, it will take a long time to run. If it takes a long time to run, developers will run the tests less often - reducing the value of the test suite.

Different types of tests are used for different scenarios. Tests which only test a specific function in isolation are known as unit tests. Tests which test an entire program are known as end-to-end tests. Tests which test a specific interaction between two elements of a system are known as integration tests. Each form of test has a well-suited purpose.

Unit tests could be used to verify one part of an algorithmic calculation. End-to-end tests could be used to ensure that a mobile app behaves as intended. Integration tests could be used to verify parts of a complicated system. A large production codebase normally needs a mixture of different types of tests for different parts of the system.

Source control

Every change a developer makes must be stored in a way that allows easy understanding of changes. A patch describes the changes to some code at a specific point in time. A patch will be attached to a commit which contains metadata about the patch, such as a description by the developer. Multiple commits may be combined to form a pull request which describes some set of feature changes, including bug fixes. A pull request is typically reviewed before it is added to a codebase by a merge. A pull request review provides feedback for the developer, often with changes requested to address an issue with the proposed patches.

The history of a codebase is represented through the commits, aiding developers in understanding when and why things were changed. Understanding the context of changes allows developers to fix or prevent bugs with greater ease.

git is the most widely used form of source control, though many other forms exist.

Open source

Unlike physical commodities, a critically significant portion of code is made freely available. This is known as open source - I.e, the source code is openly available. There are four fundamental freedoms granted by open source: the right to access code, and the right to use code, the right to modify code, and the right to redistribute modified code.

There are many forms of licenses that apply these freedoms to the code of a project to varying extent. The most common license families are BSD, GPL, Apache, and MIT. Different communities will default to a particular license. The license chosen has a significant impact on the potential users of a library, as some licenses impact the copyright of associated code.

Without open source, the rapid growth of the digital era would not be possible. Even more relevant to the reader, without open source, LLMs would not have been able to train on enough data to be useful coding assistants.

The majority of open source is hosted on Github, which provides a platform for managing source code versioning. Other platforms exist, however Github achieved market dominance several years ago. Open source projects have trouble with funding. For the value they provide to society, they are severely underfunded. Licenses of Github Copilot do not provide any compensation to the open source projects the LLM models are based on.

Tech debt

The choices made to implement a feature have an impact on the rest of the features you later implement. The accumulation of these choices is known as tech debt. Tech debt slows down feature development, and introduces bugs. Tech debt has many forms, including code for old features which are no longer used, data which is no longer accurate, or systems that have not been updated.

Pair programming

The process of two software engineers working together synchronously is called pair programming. Pair programming has many different forms. Pair programming aids knowledge transfer between two software engineers, often acting as a form of review in real time. Larger groups of software engineers are known as mob programming. Mob programming requires good coordination and facilitation to be productive.

Continuous integration

When a change is made, it must go through verification that the changes are valid. The verification is usually some combination of automated tests and manual tests. Different industries have different forms of verification. Once the changes have been verified, they are merged to the codebase.

Continuous deployment

When changes are merged to the production codebase, they need to be deployed to the user. Products that involve some input from the user to update (e.g operating systems) often deploy their changes to production on a regular basis. Web applications, where the user does not need to update anything themselves, are typically deployed as soon as the changes are merged through continuous deployment. Continuous deployment keeps application up to date without any additional overhead for the developer when compared to a release management.

Rollbacks and reverts

If a change is found to have a bug, there are three options: 1) fix the change and deploy the fix, 2) acknowledge the bug to be fixed later, or 3) rollback the current deploy to the previous deploy.

Small bugs with known fixes are often fixed and deploys. Bugs that don’t impact the overall user experience can wait. Bugs that will take longer to fix and have a critical impact should be rolled back. Rollbacks require that the previous code is able to run correctly, which may not always be possible. For example, if the broken latest commit modified data to a new schema, the data must be modified back to the previous schema before the previous code is able to run correctly.

This post will be a living document, and I’ll revisit sections in the future.

Subscribe now

Share

That previous downtime was frustrating for the newsroom. Elections are one of the biggest nights in any newsroom. Being unable to reach users during an election, for Norway’s biggest news site, is painful.

Several factors had changed since last time. We learned from our mistakes. We benchmarked and tested. We pulled in resources from the entire organisation to ensure we didn’t have a failure point we couldn’t fix in moments. We handled the tech side so the journalists could focus on journalism.

Not only did our biggest news site stay up, but all our sites did. And our coverage of the results were ahead of every mainstream publication in Norway.

I took the role of incident commander - both in the lead up, and during election night. I prepared with a sleeping bag, a change of clothes, snacks and paracetamol. Since the previous election's downtime had caused uncertainty, it was important to communicate to the newsroom that we were here and ready to fix any problem that might happen. Not just on our messaging apps, but physically in person. The newsroom needed to be confident in us. By showing that we were ready to be there all night if needed, we were telling the newsroom: we are here with you.

Almost all the work was done long before the election. We had changed infrastructure, we had changed code and config. And we were wiser. There was one factor out of our control though: in previous years the media houses would receive the results prior to them being announced. This year, all the results would go public at the same time as the media houses received them. It introduced some anxiety in our team, but we were ready.

09:00 - Raise awareness of the incident channel for stakeholders. We want those invested to know where to find us. We wanted all the issues in one channel.

09:40 - State the rules, timing, and contact methods in the incident channel. Make it clear how things will be done.

17:00 - Go to the communication leads of the newsrooms and let them know we were there. Instill confidence not only in the technical solution, but also in communication and resilience. The newsroom needed to know they could reach out to us, any time, with any problem.

20:00 - We setup a physical meeting room where the newsroom can see us, but we’re apart enough to be able to focus.

20:40 - Get all those on-call into a digital meeting room. Assign tasks to everyone - mostly monitoring to begin with. Keep morale up, keep the tone jokey but serious. We all know the gravity of the situation. Inform everyone when the big expected traffic peaks will hit.

21:02 - Results start coming out. We verify, verify, verify. Is the election API working? Are the widgets displaying correctly?

21:30 - The editor-in-chief of VG comes to our on-call room with the biggest smile and loudest praise. Also, candy. The director of engineering relays that all the editors-in-chiefs are very pleased.

22:00 - We take a break. We get out of the room, take a snack, go check on the newsrooms.

22:50 - The election results are called. Traffic begins to drop. We summarize and head home for the night.

Our systems are heavily intertwined. These are big systems with long, historical codebases. To prepare we involved people from all possible areas, and made sure there was a plan. A repeated phrase from the newsrooms: “we have backups for our backups”. Every backup we had was tested. The newsrooms told us we’d never been as prepared as we were this year. Good! That’s how we wanted them to feel.

Part of being incident commander is managing time and resources. Not only of yourself, but others. This is a high stress scenario. I encouraged people to take breaks, and saved my energy for the election night. As incident commander, my role isn’t to fix everything. It’s to guide the efforts, and make sure we don’t drop the ball. An important philosophy I follow: shut up when smarter people are talking.

While a lot of things could’ve gone wrong, they didn’t. The time and energy we invested into ensuring that we had a good default while also being ready to quickly adapt. These learnings go into our dedication to journalism. It’s not just the journalists who are dedicated, or the financial operators, or the editor-in-chiefs. It’s everyone, and it’s one of the beautiful things that make me proud to work at Schibsted.

Subscribe now

Share

Correctness, for me, means code that doesn’t break. My usual approach to writing hard-to-break code is through good types and good tests. Pragmatic, for me, means code that enables whatever I, my team, or others are trying to accomplish. Pragmatism in code sometimes requires compromise in correctness. If correctness was valued higher than pragmatism, then the industry would be using dependently-typed languages, or those like Elm which promise no runtime errors. We certainly wouldn’t be using JavaScript or AI-generated code.

When a large shift towards TypeScript happened, I felt like it had some good compromises between correctness and pragmatism. But it still had lots of gaps.

This post is part of Lobste.rs’ blog festival, the prompt is: What have you made for yourself?

That began my collection of TypeScript libraries, called hiraeth.

Hiraeth is a Welsh word, meaning a sense of loss, nostalgia, and longing for something that used to be or could've been. I chose this name to reflect my longing for simplicity that I once found in Elm. Elm's still a great language, don't get me wrong, but I simply end up using Typescript in more work projects than I do Elm. So to me, Hiraeth became home-from-home. I have two naming standards for projects: cutesy, Welsh words (e.g bach, coed) as project names when I think the project is novel but better alternatives exist, and to-the point explicit names (e.g ts-core) when I think a project is useful outside of Hiraeth.

Bach1 was the first. A lightweight pytest-style testing framework that’s TypeScript-native. At the time, jest and other similar test runners were heavy, slow, and required `expect(x).to.be(y)` style tests. Bach focused on making it simple and quick to write tests. Something I could drop into any project without too much overhead. Since tests are a big part of my desire for correctness, a good testing framework helps accomplish that. I’ve add some features when there’s a proven need for them - async tests, filtering of output, running tests in batches, and snapshot tests. If I had a similar need in 2025, there’s plenty of alternatives built into Node/Bun. I probably would’ve never made it. But it’s been the hiraeth library I use most consistently.

To help make Bach, I also made ts-assert. ts-assert simply wraps Node’s assert module with types that enforce both arguments to have the same type.

I needed a way to represent Maybe and Result types, so I wrote ts-core to provide some of the functional APIs and types that I loved in ML-family languages. There were other big libraries that provided these types, but they tended to include too many features, and too much code, for me to feel comfortable using them. I’ve mostly stopped using ts-core and tend to just roll my own `Result` type in each project as needed. In TypeScript, I didn’t use `Result.map` and the other functional programming APIs that much.

Benchmarking is a natural companion to testing, so I wrote mainc2. mainc’s focus is to be lightweight, much like bach’s focus. Writing a good benchmarking engine is pretty difficult to get right though. Getting consistently statically-meaningful data out of benchmarking is a pretty tough problem, and it’s not one I was planning to solve. So other than for quick estimates, I don’t use mainc. That’s a problem that I don’t have direct knowledge in, and time spent earning that knowledge would’ve been better spent elsewhere. There’s lots of other great tools out there that I use for benchmarking - but I’m very much on the user side of those tools rather than the creator.

Part of my approach to pragmatism is to focus my energy and time. Too often in the past, I’d get so distracted by creating a framework or library that I’d forget what I was actually making it for. Instead of making a game, I’d make a framework to make games, finishing neither. Instead of writing a blog post, I’d make a static site generator. These days I do the opposite: start with what I want to achieve, then abstract out any frameworks or libraries that I created along the way. Dropping mainc fits into this philosophy: instead of creating a benchmarking tool, I create the things I want to benchmark instead.

geiriadur3 is a documentation generator for TypeScript libraries. I frequently run into JavaScript or TypeScript libraries which completely lack any kind of documentation, and when they do - they make it difficult to jump to the source or see the types. geiriadur gives the raw TypeScript function definition, inlines the jsdoc comment, and gives a link to the source for that specific function. Very handy for working with big, unfamiliar codebases.

coed4 is a functional html library backed by a virtual-dom. It’s the 4th or 5th virtual-dom library I’ve implemented, but it’s probably my favourite so far. I’m not a fan of React, Svelte, Vue, or Angular. If I’m writing basic html, I’ll do that as html. But if I’m making an SPA (a real SPA), I prefer everything to be code. No fancy transpiling or strange configuration tricks, just normal JavaScript function calls. It supports static rendering and hydration. One of the reason I’m pretty happy with it is because the patching and rendering is relatively to understand. This PR shows roughly the step-by-step process to implement a similar virtual-dom algorithm.

adeilad5 provides an Elm-style JSON decoding/encoding API for TypeScript. Used in combination with amddiffyn6, which can generate adeilad decoders from example JSON, it provides a way to move data from the edges of TypeScript into the fully-typed ecosystem (i.e avoiding JSON.parse(x) as User). adeilad was inspired by my work on Elm’s decode-pipeline library, and amddiffyn was inspired by my work on json-to-elm.

baner7 is a flag-parsing library. I’d used yargs a bunch before TypeScript, and I liked the adaptability and simplicity. But once TypeScript became my go-to, I craved a typed alternative. Thus baner was born. While I use baner in a lot of my projects, I’m not a fan of the API I created for it. The creation of parsers is easy, but using the parsed information is very verbose. I would prefer a typed API that would return a typed tuple. When I get time and motivation, maybe I’ll do that.

All these small libraries lead to one destination: Derw8, my Elm-inspired language with native TypeScript support. Derw is intended as the ultimate solution to my hiraeth - a way to write code in the way I like, with both the correctness to ensure things work, and the pragmatism to get things done. As I increasingly worked with TypeScript codebases, my desire to use an ML-family language while still getting things done felt pretty important.

Derw was fun to write. Since I already had many of the pieces I needed to create a full stack language, the majority of time initially were spent on writing the compiler instead of libraries. Derw uses almost all of the Hiraeth libraries I’ve mentioned.

Derw in a nutshell:

• ML-family language (closest inspiration: Elm and Haskell. Next closest: Go and Python)

• Fullstack, both backend and frontend

• Majority of the compiler is self-bootstrapping (written in Derw itself)

• First-class interop with TypeScript and JavaScript

• Compiles to TypeScript, JavaScript, Derw (itself), and English (for useful error messages).

• Elm-style virtual-dom html library with server side rendering and hydration (via Coed).

• Auto-formater (i.e derw format) built-in like Go’s

• Testing framework (i.e derw test) built-in (via Bach) much like Go’s

• Syntax highlighting

• LSP integration

• Git-based package management

• The compiler (and majority of tooling) works both locally and in the browser

One of the neat pragmatic features of Derw is that I avoid doing too much irreversible optimization. There is very little optimization done on the output of the language itself, instead preferring to optimize the APIs of the libraries it provides. I wanted developers to be able to switch out from Derw at any point they wanted. All the generated TypeScript and JavaScript could be used as a starting point to switch the codebase over to straight TypeScript, reducing the time to rewrite and avoid vendor lock-in. I’ve evacuated some projects from Derw to straight TypeScript very painlessly.

When writing a niche language, I was mindful of the fact that 1) few people will use it and 2) they would be annoyed if the project died. Success, to me, was only defined by my personal satisfaction of having made a language that solved some of my pains with Elm, and my pains with TypeScript. If npm is to be believed, derw gets around 20 downloads per month on average. That’s perfectly fine with me. I don’t think there’s an active community using it, that’s also fine.

In an alternate reality, Derw would’ve been the next big thing for functional programmers after Elm. I would be spending my time doing compiler things. But that never happened, and that’s okay too. The knowledge I’ve gained from Derw has been insightful.

While I already knew how to write compilers, Derw took my knowledge to the next level in writing compilers that worked both on-device and in the browser. A good example - how to detach as much I/O from the core compiler while still having a compiler with good performance.

Generating TypeScript which would be performant, type-safe, and human-readable was an interesting challenge. The biggest lesson I learned: keep the TypeScript types simple, and don’t try to be too clever. While many of TypeScript’s utility types are useful, they came with a performance cost for the TypeScript compiler. I probably stuck too closely to keeping things simple though, and as TypeScript’s gotten faster, I’ve started to adopt more of the utility types.

gwe9 is a compile target language I wrote with the intention of compiling Derw to WebAssembly. gwe is intentionally written as an intermidatery between immutable ML-family languages and WebAssembly. I’d been wanting to write something big in Rust and WebAssembly for a while, and it seemed like a natural fit for this. It’s not fully finished - life got busy, and gwe become lower priority than the other things I was doing. From a Rust perspective, gwe is a very beginner project.

jump-to is a vimium-style navigation tool for Chrome. I used to use vimium a bunch to minimize the amount of time my hands were away from the keyboard, but I couldn’t find a Chrome Extension made by a provider I trusted. I generally don’t use Chrome Extensions unless I’ve fully verified who made it. It’s often easier to make my own Chrome extension, plus it gives me a reason to learn how they work.

gweld10 is a python http.server inspired dev-server with live-reload. I made it after being dismayed at the amount of code that the majority of popular live-reload dev servers used, and needed a way to stream video files as chunks. It uses only the built-in Node standard library. A big part of my hiraeth is the desire for straightforward low-code solutions to common problems.

amser11 is a opinionated simple way to keep track of projects changed during a session. Since I have a lot of different projects when I’m doing hobby code, I needed some kind of idea how I split my time between them. Like gweld, amser uses only the Node standard library.

gobaith12 is a mental health tracker I originally built for myself, and didn’t open source. While I usually release things as open source by default, I avoided it with gobaith. I was not in the mental state to support others, and I needed something that very specifically helped me with my mental health issues. It had been my plan for years to publicly release it, but the thought of being responsible for writing code that took good care of a user’s personal mental health data was intimidating. I delayed releasing it, month after month. Eventually after meeting some others with the same condition, in the same place where I had been years ago, I decided I should release it. For them. So that I could at least help a little with their recovery journey.

I had two main concerns before release:

1. How do I make something they’ll actually use?

2. How do I ensure it’s robust enough to succeed?

I sat down with my fellow sufferers, and listened to what they needed. I read paper after paper on trends, behaviours, and patterns on our conditions. We drew things together, we discussed research papers and therapy techniques. In the end, I combined what I knew worked for me with the insights from my friends. I couldn’t make it work for everyone, but I could make it work for people like me, and give others the keys needed to adapt it for their needs.

A robust tracker needs to avoid data loss at all costs. Since the data lives only on user devices, I needed to ensure that any updates wouldn’t cause them to accidentally lose their data. gobaith is very forgiving - each migration of the data store avoids any actions that might lose data, providing logs if the migration would fail. gobaith works in the browser, in Electron, or as an app on Android. The test suite via Playwright runs on all three platforms, helping to keep features in-sync. The data can be stored either in IndexedDB, a server-based backend, or both. The test suite is data-storage agnostic too.

I’ve rewritten gobaith’s rendering layer a few times. The first version, which I built only for myself, was pretty messy. Lots of DOM manipulation, no TypeScript. The second rewrite switched over to a frameworkless model-view-update (MVU) approach I sometimes use: every view function returns both the html body as a string, and event handlers to attach to the DOM, enforced through types and the API. While that frameworkless approach is actually pretty good performance-wise, it’s not ideal for maintenance. In the third rewrite, I switched it all over to use my coed library. Way easier to maintain, and avoid little errors like misspelled tag names.

The latest big thing I’ve done with gobaith is to prepare it for an Google Play store release. As Google is going to make it harder to side-load apps, I figured I should just put gobaith on the Play Store. Unfortunately, that costs money, and I’m already making a loss from releasing it. I’ll have the gobaith app at some low one-time fee, like $3, to help cover some of the costs of development. All the code will always be open source and available for people to use and build themselves, and I’ll give free keys to anyone who wants the Google Play store version but can’t afford it. My goal isn’t to make money, but to avoid losses. I also have Github sponsors enabled for that same reason: it’s costly, both in terms of time and resources, to develop open source things for others.

Games are something I left out, but I’ve made a lot of little games for myself too. Pico8 has been my tool of choice, often making visualizations or novel experiences. Psychotris is intended to finally answer the question on everyone’s mind: what would Tetris be like if you had psychosis and hallucinations? It starts out pretty normal, but the visual effects quickly ramp up.

Some others, a Baba Is You clone:

A depression/anxiety/mania simulator:

As a final reflection, I realized while writing this that I spend a lot of time making things for myself. I release them for others to use, sure, but I usually have 0 ambitions of actually getting others to use them. In the past, when I was active in the Elm community, it was the opposite. json-to-elm, elm-html-in-html, elm-html-test, server side Elm were all things I made intentionally for others to use. Maintaining those, especially when I moved away from Elm, became a chore. Something I didn’t enjoy doing, and something I didn’t really get any kind of return on. These days, I’m happy watering my plants in my open-source garden. I trim some leaves, and if others would like to take a look, they’re welcome to. I hope you enjoyed reading about my garden!

Subscribe now

Share

Some choices in software development come down to personal preferences. Is there an objective measure for which editor is the best? Is there an objective measure for which language is the most enjoyable? Not so much. Most papers I’ve read which attempt to measure these qualities struggle with defining good metrics. Other choices have data to back them up. How many deploys have happened in the last week? How quickly were incidents resolved?

As an enabler, I often have to use both perspectives to shape discussions. The quantitative (data) vs qualitative (experiences) mindset is something drilled into UX research3 work. Numbers don’t tell the full story, while experiences could just be anecdotes. Combining both is an important factor in behaviour analysis and change, which is why I prefer to combine both. Measure for raw data, collect experiences to shape an opinion.

To give an example from the news industry, we have many metrics that measure the success of an article. Typically that would be clicks, completion rate, and the number of shares. Once those are combined with the demographics of users, it can give a sense of success. However, it’s only a partial story. For example: short clickbait titles where the body text is only 2 paragraphs would result in high clicks and completion rate, but would harm the user’s overall opinion of the news site. There is no metric that can measure at scale “how did you feel about this article?”. We can make approximations, but they’re numbers to fit a trend rather than understanding the reasons for the trend.

Let’s say we track the number of users who keep coming back to the clickbait articles - if they don’t like it, the weekly active users should drop right? But there’s many factors that could impact that metric. Adverts, subscriptions prices, traffic source, the content topic itself, the thumbnail used, whether the reader has an emotional attachment to the topic, etc. Too many variables make it hard to assess, and too much “human” makes the insight only measure what they do, not why they did it.

At the same time, people are bad at expressing themselves. It’s hard collect accurate user assessments of what they’ve done. They forget things, or they’re unable to provide insight into why they did or didn’t do something. Often they’ll believe they did things that they didn’t.

These are the exact same problems I face when shaping an opinion that represents a collective - both at my day job, and in my volunteering role as the leader of Tekna's Network for Developers.

I don’t have an objectively correct solution to solve this problem, but here’s how I approach mixing experience-gathering with data-gathering:

1. Don’t be afraid to admit what you don’t know. There are big pockets of empty space in my knowledge - they won’t get filled if I’m not willing to listen to others. I don’t particularly care about me being personally right. I care about things being done well. If it’s not my way of doing things, that’s usually fine4.

2. Reflect on my own opinions. Why do I have them? Where did they come from? What would cause me to change my opinions? Are my opinions valid, or something I can’t justify?

3. Empathy. Understand and listen to others. Let others share their opinions without judgement. The more others trust me, the easier it is to have a good understanding of what they believe, and why they believe it.

4. To figure out difficult problems, there has to be chaos. Chaos can be uncertainty, unclarity, or unknowns. Any difficult problem will have things that could be unknown unknowns. Share little views into this chaos with others. Ask questions about difficult topics to a wider audience. The insight that others can provide often reduces the unknowns. At the same time, don’t introduce too much chaos. It’s tiring for others, and it can be damaging. My job involves often finding sense in chaos - it’s something I enjoy and I’m good at. But not everyone enjoys that5. Keep it to limited subsets of chaos where you need input from others.

5. Identify the qualities that can have metrics, and gather as much metrics as possible. Challenge your assumptions - don’t settle for the first metric that seems to prove an opinion right. A diversified combination of sources leads to a richer understanding of trends in data.

6. Don’t be afraid to challenge opinions. Both your own, and others’. If you approach it with both empathy and good intentions, others will respond well. It helps when you admit to questioning for sake of debate, rather than disagreeing to form an argument. Be vocal about your own opinion, but in the right settings. Opinions form debates - debates are incredibly important for behaviour change. My worst nightmare is a team of people working together who can’t have productive disagreements.

7. One data point is not enough to form an opinion on. If people’s experiences could be an anecdote, so can one data point. If you want to make a claim, back it up with as much data as you can.

8. Metrics shouldn’t be goals, but they can inform what to set as goals.

9. Sometimes, you have to just trust your gut. Generalisations simplify the process of talking about a problem. There’s a line between being too general and being too specific. Sometimes you should say “based on what I know and feel, this is what I believe”. An opinion shapes direction - but don’t be afraid to change both your opinion and direction when more data and experiences comes available to you.

A mix of data and opinions make my role easier. It takes time to establish both the collection of data and experiences, but I think it makes my input richer. I could do everything based on my own personal gut-feeling, but I’d probably make assumptions for a lot of decisions that weren’t accurate.

Subscribe now

Share

You can try it out here. Here's a screenshot of it running:

Some context for non-Norwegians

Ruter is the public transport company for Oslo and the surrounding areas. While they have always had period tickets (especially for students), they introduced a discount format based on usage in the last couple of years (Reis). Reis provides an increasing discount for each travel you make within a rolling 30 day period. The highest discount it provides is 40%.

Ruter has faced criticism in recent years due to high costs and aggressive ticket checks. A tool like this allows people to make informed decisions when buying tickets, something which I've been personally missing for a while.

Reviewing the code

I didn't read any of the code until I'd gotten the prototype working, replicating the expected workflow of non-technical people. I avoided giving any instructions that mentioned technical details. The prompts I used were prompts I'd expect a non-technical person who was familiar with generative AI to write.

The full review can be found as a pull-request on Github, but I left a lot of comments - approx 41. I tried to review it as if it was created by a human, but I sometimes found myself writing a comment if I was talking to AI, which weirdly uses wording question their decision (e.g "why did you do this?" instead of "why is x like y?"). Here are some of the most relevant comments.

The code wasn't bad quality, but the parts that contained logic were hard to read - a combination of poor variable names, weird loops, a lack of types, and a lack of comments. The AI had hallucinated a bunch of data, which is kinda to be expected from generative AI. I hoped for better, though. Once I explicitly provided the correct data without relying on the AI to read the webpage, it corrected the data. My main concern would be the factual correctness of the web page. It seems like a review step from a new AI context might've helped.

I think I could change the system prompt to ensure:

• Code has some form of type checking (either TypeScript, or jsdoc types)

• Avoid creating unnecessary structures (e.g weird while loops, a class that didn't need to be a class)

• Enforcement of contracts across function barriers

Either way, it took me about 30 minutes to go from idea to a working prototype. Another hour to review and correct the mistakes AI had made, but all considerably less time than a human developer would've taken. For journalism, the incorrect usage of facts means we need to manually review every data point the app uses. That will take a considerable amount of extra time - though for prototyping an idea, it’s good.

The journey of a vibe coded journalistic app from idea to production probably would look something like this:

Some things to note:

• Ideation takes longer with just a human, as the feedback loop is quite large. A lot of people sit on ideas for a long time before raising it with developers who could actually implement it. Once it’s on the backlog, it might take a long time before it’s picked up.

• Prototyping takes longer for the human: they need to design the UX and implement the code. It inherently takes longer because AI is able to make an attempt at UX and code without needing to consider design systems or existing code.

• Testing takes a considerable chunk of time with AI. The human in comparison will test things along the way, as they develop. AI will invent numbers, APIs, and data and run with it.

• The time to move an AI app to production is longer vs a human, as the human has likely considered things like existing infrastructure, scaling and security practices, and tested along the way as they developed it.

It’s interesting to see AI used for providing enriched journalistic content. I wouldn’t trust it yet, which gives me my next goal: figure out how to implement some practices that will reduce the amount of time spent testing and turning the code into production-ready code. Subscribe if you want to follow that journey!

Subscribe now

Share

Appendix: User Input Summary

These are my questions / given input to Claude.

Initial Request

Let's make a frontend-only website that helps people figure out which discount they should use using Oslo's Ruter public transport.

You should allow users to enter how many trips they expect to make per week, then show them the discount they might get.

The details on Reis are here: https://ruter.no/om-vare-billetter/reis-enkeltbilletter-med-rabatt

Feature Requests

Period Ticket Comparison

Okay, great. Now add a way to compare against the period tickets. The period ticket information can be found here: https://ruter.no/om-vare-billetter/periodebillett

Zone Selection

Allow the user to put in their Ruter Oslo zones. Use the information found on the websites I gave you to add the correct zone information

Current Discount Level

Allow the user to specify their current Reis discount, so that the calculation can take that into account

Time Period Options

Allow the user to choose time periods of:

• 24 hours

• 7 days

• 30 days

• 365 days

Use the information from the Ruter site I already provided you.

Layout Changes

Section Reordering

Can you move the Discount Breakdown section to the bottom of the page?

Break-Even Analysis

Can you also add a section that explains at which point (i.e how many trips) it becomes cheaper to use Reis vs period tickets?

Documentation Request

Can you summarize all the questions and input I've give you, and put it into a file called "chat.md". Only put in my inputs.

What’s an open source office?

Small companies can have open source as a normal thing they do. Bigger companies need some way to coordinate their efforts. They might be publishing their own packages, contributing to others with manpower, or contributing with finances. An open source office allows a big company to enact a shared strategy regarding open source across the entire company.

Why is open source beneficial for big companies?

There’s a multitude of reasons for commercial companies to be active in open source, but the main motivators for us are:

1. Increased brand awareness within the developer communities. i.e better hiring potential. Norway and Sweden have relatively small, tight knit developer communities. Companies that actively promote their open source contributions tend to be more attractive than those that don’t.

2. Developers want to be free to contribute to open source in their personal time. A huge portion of developers spend their personal time coding, so a culture that encourages or supports their ability to do that is beneficial to the company. Happier employees, happier company.

3. Many things that we developed didn’t benefit from being closed source. I think it’s debatable whether or not open source projects are of higher quality, but a well-made open source project often contains several factors that have higher quality. Good documentation, good tests, issue management. Since a lot of our code didn’t provide us a competitive advantage, why not open source it? We’re a news media company, not a big tech company.

4. We run into bugs with browsers quite often1. When that happens, our interactions in the open source community can help find fixes for them. We rarely create the fixes, since we’re a news media company, not a big tech company with C++ browser engine experts. But we can provide excellent write-ups of problems, and help debug things.

5. We wouldn’t exist if open source didn’t exist. Revenue for news media companies is a constant struggle. HBR published a paper, with a quote from their findings: “Firms would need to spend 3.5 times more on software than they currently do if OSS did not exist”. Quite frankly, news media companies cannot afford to spend 3.5 times more on software. We are a news media company, not a big tech company. While it’s not our obligation to contribute to open source, if every company took the Apple route of limiting employee open source contributions, then open source simply wouldn’t exist.

I repeated a phrase a few times there: We are a news media company, not a big tech company. Our focus isn’t designing world famous data structures, pouring research into low-level algorithms. Our focus is delivering news to people - when they want it, what they want to read, and how they want it. Everything we do in tech is to enable that. Traditionally, a lot of the developers in the news industry approached things with the typical hacker mindset: get things done quickly, at scale. There’s a big overlap in the “hacker mindset” community and the open source community.

Why would employees want to contribute to open source?

There’s many motivations from employees, but I’ll sum them up as: a) career growth or b) philosophy. I don’t think that needs too much clarification, but to expand a little:

1. Share code with others - or a future self. Make it easier to show others what you did, or come back to what you’ve done.

2. Raise your public profile - so others know who you are. Get involved in communities that could lead to skill development, social network growth, or career opportunities.

3. Provide a public record of your coding - simplify interviews. If you’ve got a lot of high quality open source repos, you can often skip interview steps.

4. Engage in bigger technical projects.

5. Develop new skills and specialisms. Often your day job can be radically different from your actual nerdy interest outside of work. In my case, outside of work, I love designing programming languages. I can’t really do that at work.

What does the open source office do?

The open source office originally was composed of 3 of us: 2 developers, 1 tech management. Together we’d work to build a community around open source, while also establishing and clarifying procedures.

We host monthly talks based on different aspects of open source. There has been a mixture of internal speakers, sharing their own experiences, and external speakers. Some of the speakers we had in: Varnish, Unleash, Whisper as a Service, Arch Linux and NixOS contributors, Derw. When something big happened, like xz’s backdoor, we held a session on it.

One of the concrete problems that developers encounter in their daily workflow is usage of external libraries. By default, most developers pull in any library they find, without considering the license. In my experience, young, small companies especially tend to disregard licenses. As companies become bigger or more mature, the legal risk from incorrectly using open source projects becomes a risk that the legal department wouldn’t be okay with2. So to address that, one of our core resources is a policy explaining which licenses were legally okay for the company to use. We’ve built some tools to map out licenses we use, and created license-specific advice.

Tools like SBOMs are great for this - so you know what code you’re actually running in production.

The other main concern developers have is “how do I release open source projects”? I’ve written up some tips with a very practical real-world example.

Without going into too much detail, at a high level the process looks something like this:

Open source repos don’t need to be on-going living projects to be useful. In fact, several of our successful projects are those who were released as finished projects. Very little work has gone into them once we released them - but we did release them, giving them to the community. Our ideal combination of released open source projects would include “finished” projects, on-going projects, and short-lived experiments or workshop material. Unless a repo is of particularly low quality, it’s not harmful to have old or archived repos.

Inspirational companies leading open source in Norway

Within Norway, some companies are absolutely fantastic at open source. The IT organisation for Norwegian labour & welfare, Nav IT, in particular is fantastic. A huge amount of things they develop are open source, and they’re truly impressive. They also released the platform they built internally for themselves, aimed at other public sector organisations. While Schibsted is quite different from Nav3, their open source contributions are inspiring. I frequently bring them up as something to replicate and celebrate.

Much like Nav’s release of their Nais platform, Schibsted had a hand in the early days of both Varnish and Unleash. These products were born out of a need that we had, becoming big enough to support a company of dedicated employees to those products. Fully building and funding these tools within Schibsted itself would’ve been costly, and they probably would’ve died off after some time - again, we are a news media company, not a big tech company. Varnish is now used by a huge portion of the web - it deserved to scale beyond Schibsted’s uses.

Definitions of success

Success can mean many things, and I don’t think we had any particular OKRs to keep track of our open source contributions. While we have gathered a number of metrics in the past, the majority of time spent doing “open source office” things are to build a community. Many of our developers have this interest, so showing that the company is supportive of open source is great for motivation. The talks we’ve held have had a good audience, and the number of repos we’ve released always increases after we talk about our support of open source. We aim for T-shaped developers where possible, and open source tends to provide the chance for specialists to gain knowledge in other areas.

Some specific metrics that might be useful for strategy:

1. Number of public repos (active, archived)

2. Number of dead repos (i.e those who aren’t active, and provide little value)

3. Open Source talks given internally

4. Number of open source libraries used (mapped by which license they use)

5. Time the company has spent on open source (also: money, if you can afford it)

While none of these metrics are perfect for representing the organic open source community within a company, they can give some insight. I consider the open source office to be successful if others have looked up our open source projects, if developers are able to learn or share their niche knowledge, and if there’s a mindset of “open source by default”. Open source by default can be controversial, but the majority of things we build in isolation aren’t what gives us our competitive advantage. Again, we are a news media company - not a big tech company. Our competitive advantage comes from our approach to journalism, combined with our journalists.

Closing thoughts

To me, the open source office is the combination of mandate, guild/culture building, and strategy. It has the mandate to clarify key parts of development: what licenses we use, how we build and release products. It supports the culture of open source, forming a guild. And it has the capacity to advise on strategy topics specifically related to open source. While each of these could happen in isolation, I think it’s likely that a strange bystander affect would happen: nobody would do open source since they expect others to, or because they don’t know that others are doing it, or because they don’t know how to do it. I don’t think there needs to be a open source office in every company, but I’ve seen success from our initiatives and culture since we started ours.

Subscribe now

Share

What is Coder.com?

Coder.com is a hosted environment for managing hosted dev environments with editors, terminal access, and AI agent tooling.

Here’s a screenshot of one of the test apps I “vibe-coded” through it:

Why Coder?

For me, it comes down to main selling points: it can be hosted in your own infra, and it’s open source. The combination of cloud-hosted code editors (code-server, Claude Code, Windsurf, Cursor, etc) with optional local editors (VSCode, Vim, Jetbrains, etc) makes it handy for both developers and non-developers.

I’m pretty impressed with the platform so far. It’s not perfect, but nothing is. The rough edges seem to be both docs, and user management (currently part of the Premium features). The docs are getting better every day though - and they’ve launched a bounty program for their open source issues, which is great.

Knowledge needed to manage your Coder.com

• Terraform (used for creation of workspaces + managing Coder.com itself)

• Docker (used for dev environments)

• How to use your hosting platform (AWS, GCP, Azure, etc)

• How to use AI APIs

• OpenConnect (auth management)

It’s also beneficial to if you know how to ssh in and do some old school debugging.

Starting on AWS

We use AWS, so I’ll focus on that, but the same things apply to any cloud provider. Coder provides an AMI on the AWS marketplace. The recommended EC2 instance size is t2.xlarge, but I managed to test successfully with t3.large without any issues. Make sure to assign a lot of disk space though: 10gb per user seems to be about the right size to me.

Security groups

On AWS, Coder’s docs recommend to use the default Security Group. You will probably want to lock this down. I chose to limit both http(s) and ssh to specific IPs. Since Coder uses DERP and STUN, you’ll need to allow https and UDP to specific STUN servers. Coder uses Google’s STUN servers by default, so you can limit to those IPs.

Naming limitations

Coder uses a combination of app name, agent name, workspace name and username to create the hostname for each workspace. Since there’s a DNS limit on subdomains to 63 characters, make sure your username + workspace name are short. I’d suggest using ID numbers for users, since it’s separate from their email or display name. That way workspaces can still have meaningful names.

Templates

The easiest templates to work with are those based on the Docker template. The aws-linux template needs additional permissions, including IAM roles that allow for ec2 instance management/creation. For that reason, using the Docker template is easier. I suggest managing templates on the ec2 instance rather than by the web UI, so that way it’s easier to use your normal workflows/deployment systems (Terraform, Docker, git, etc).

Claude Code with Bedrock

If you’re planning to run everything under your enterprise agreements, you might want to use Bedrock. The tasks-docker template has everything you need to setup a Claude Code instance running with a RealWorld Django app. However, if you want to use Bedrock or Vertex to run Claude, you might run into difficulties as the template expects an API key. Follow the Claude Code settings guide to figure out which env variables you need, and remove the Claude API key env var.

In my case, I needed:

• CLAUDE_CODE_USE_BEDROCK

• AWS_ACCESS_KEY_ID

• AWS_SECRET_ACCESS_KEY

• AWS_REGION

• ANTHROPIC_SMALL_FAST_MODEL_AWS_REGION

• ANTHROPIC_MODEL

• ANTHROPIC_SMALL_FAST_MODEL

Make sure that you’re able to use Bedrock with the cross-region inference profiles within your legal area (e.g EU), as they have the best performance and the lowest cost. Other models don’t have prompt caching, so end up costing considerably more when used with Claude Code. You can use Bedrock’s guardrails to enforce security best practices too.

Once you’ve tested the demo, I suggest making your own template that starts from a very basic repo. Make sure to follow Claude Code’s best practices.

Final thoughts

It was pretty easy to set up. I got everything working as a PoC within a day. Now we’ll evaluate how our non-technical users find it, and after that see if we can scale it up, or try something else. I’ll probably share a blog post after that, too.

Subscribe now

Share

With that in mind, here’s a war-story from my days running an R&D startup when we lost all the data we thought we gathered from a psychology study.

I founded an R&D startup that worked closely with psychology researchers. We would build tools for gathering data from psychology exercises, which the researchers would use in their studies or assessments.

One of these tests was the Stroop test - users would get shown four words in different colours, with one of those colours shown in the middle of the 4 words. The user would have to respond as quickly as possible to pick the right word, through pressing the up/down/left/right keys on their keyboard. The user would be asked to do this with some test words (usually colours, office supplies, words without significant meaning to the user). Once they had an average response time within an acceptable range (in milliseconds), we would introduce some words that we wanted to measure the user's reaction on. For example, if a user was particularly addicted to tea, then their reaction time would be different when "tea" is one of the words they get to choose from than a control wordset without any mention of tea. These tests require complete concentration for a significant period of time.

We built the Stroop test tooling to work with any group of users that the researchers wished to analyze. Sometimes it'd be those addicted to substances, sometimes it would be to measure the societal factors (e.g fear of terrorism). In the normal workflow, we'd get the users to add their study email address so that the researchers could follow up with their results. We'd also send the participants their own results via email, in case they were curious. The tech was boring: a PHP backend, MySQL database, and a minimal JavaScript frontend. The results would be sent after the user had completed the full test, then stored in the database.

One of the studies assessed a group of people who worked in a high security workplace. They would not have internet access, and we would need to provide a locked down device that would only be used for the study. No problem, we setup a laptop with a locked-down Linux install, and put the code on there to run locally just as had in development. We disabled WiFi, Bluetooth, and anything else we could. These instructions came on the same morning as the test: so as we drove to the location, we were fixing the code and testing.

We arrive, set up the test, then the study participants all come and take the test. It all seemed good, each participant managed to complete the test successfully. We left feeling good.

As we arrived back at the office, we realized that the data was missing. All of the data. We had not saved any of the participant responses, and it wasn't clear why. The code had worked locally on the machine when we tested, but not in the secure location. We did, however, have logs. The logs seemed okay, nothing particularly special. Then we decided to test without internet access. The problem became clear.

function saveResults($userEmail, $results) {
    sendUserTheirResults($userEmail, $results);
    saveResultsToDatabase($userEmail, $results);
}

function saveResultsToDatabase($userEmail, $results) {
    ...
}

function sendUserTheirResults($userEmail, $results) {
    mail($userEmail, 'Results', $results) or die();
}

PHP had a popular pattern: do_something() or die(). If do_something failed, then the program would exit early. We used mail() or die(). When the email failed to send since there was no internet access, the script would exit before saving the results to the database. We used or die() incorrectly - we should've handled the error gracefully instead of exiting the entire script. We had not saved any of the data from any of the participants. And worse: to run the study again, we'd have to book more time in their calendar, with approval steps all over again.

Our first idea was to see if we had logged the user interactions somewhere. The frontend would log the results in the console, but since we had many participants, we would run each session in an incognito window, then close the window. We looked at the backend: we had logs, but the requests were sent as POST, with no logs of the body. The good feeling of "we pulled this off" turned into the bad feeling of "we've messed up".

There was no choice but to own the error, and run the test again. The second time, we made sure to test on-site before getting any participants in. The only change in the code was to replace or die() with some proper error handling.

While this bug was a costly mistake, we learned from it. Whenever we would deploy code-last minute, we'd try to test it more rigorously. If we were running a study without internet access, we'd make sure to test in the same environment. We hadn't accounted for the environment change, partially due to the short notice for the locked-down machine, but also just because we didn't test with the exact same restrictions.

But we also started moving all of our backend code away from PHP. It was too easy to make a simple but costly mistake. Our main languages became JavaScript, Go, and Python.

Consider the same pattern in Node.js:

function sendUserTheirResults(userEmail, results) {
  if (!mail(userEmail, "Results", results)) {
    // this would be a very weird thing to do
    process.exit();
  }
}

The design of languages, APIs, and frameworks can often lead developers to make mistakes. It applies outside of code, too. When you see a trashcan with a circle hole next to one with a rectangular hole, you know instinctively that the bottles go into the circle hole, while other trash goes into the rectangular one. In psychology and design, this is known as an object's affordance. To go against an object's affordance feels unnatural. It feels wrong to push on a door that has a handle for pulling.

The same effect applies to code: you could call process.exit() when an optional part of the program has an error, but why would you? That feels wrong. Whereas extending a line with or die seems like a natural choice in a language where that's already an established pattern.

A principle I follow out of this experience: If you don't make it easy to do the right thing and awkward to do the wrong thing, people with good intentions will do the wrong thing.

If this chapter was fun to read, feel free to sign up for my book waiting list. This is one of the chapters that will be included in a section dedicated to moments that shape my philosophy. It will be released for free as HTML when I'm done - with ebook/physical editions available for a minimal price. The waiting list is just a handy way for me to let you know “the book is ready”, with a pre-release copy. Otherwise, have a great summer!

Sign up for my book's waiting list

Share

So I've decided to write a book! I already have approx 60% of what I have planned. It's a book I can summarize by these two paragraphs, from a previous blog post:

At the start of my career, my ego was absolutely my worst quality. I had to be right, every time. I had to “win” every disagreement. I suspect it was big-fish-small-pond syndrome. Through learning to disagree with my peers and friends in healthy ways, I've mostly ditched that. No longer do I care about being right. I instead care that things are done in a way that improves the organisation, the code, and employee happiness.

I take joy from things being done well, by people who enjoy what they're doing. If I can lift people up so that they can do both, I have succeeded in my role as “Tech Enabler". The essence of Egoless Engineering.

Once finished, I will release the HTML version for free, with an ebook/print version for some minimal cost for those who might want it. I don't plan for huge success, I just hope I can help others do some things better.

If that sounds interesting to you, sign up to be notified when it comes out here.

To give you a taste of some chapters so far:

• Philosophy

  • Principles for tech enablement

  • In the background vs in the foreground

• Teambuilding

  • Creating lasting teams

  • Overcoming difficult situations

  • Arguments vs disagreements

  • Taking an authoritative voice

  • Mentorship

• Frameworks and tools I use

  • Lean, BMC, RAT, etc

  • Design thinking

  • Cynefin

  • Facilitation

• Hands-on development

  • How I code

  • Open source

• Warstories

  • The time a service hit MAX_INT on index key on a write-heavy DB

  • Malware that only worked on 3g

  • Exiting a user-response script if they had an invalid email without saving their responses

  • When a domain was not set to auto-renew

I have more planned, but I intend for the final thing to be a mixture of stories, practical advice, and reflections.

So yeah: sign up to be notified when it comes out here.

Subscribe now

Share

Hackathon participants tend to fail in one of three stages: ideation, scope, and interest.

Interest needs the idea of a hackathon to captivate the participant. While many in tech will know what a hackathon is, those outside of tech won’t - and therefore will probably not be that interested. Vibe-coding is a great way to make hackathons more accessible. But the framing and naming is still tricky. If you managed to get people of all industries to a hackathon, you’d be able get them to make some interesting prototype with vibe-coding. The real challenge is getting them there in the first place. I don’t have a good answer for this, though I try to get a “champion” within each unit to encourage people to join. Someone they know, respect, and trust.

Ideation is where most teams drop out after showing up. If they can’t come up with an idea they like, they won’t really want to take part. I picture it as the same dilemma of those who work in an industry they’re passionate about vs job where they’re just there to survive. If you are passionate about an industry, you’ll be highly engaged. If you’re just there to survive, you won’t want to do anything other than show up. If someone is unable to come up with an idea they’re passionate about, they won’t want to take part.

Breaking the barrier of ideation usually comes down to making the participant aware of the possibilities. I usually sit down with them, ask them what they do, and what they’re passionate about. Most of the time, it’s just a matter of linking what a person has been thinking about to something they could feasibly do in a specific time-frame. A great thing about vibe-coding: it reduces massively the time needed to successfully pull off an idea.

Scope doesn’t usually make people drop out, but it can be demoralizing so that they don’t end up demoing what they did. Participants try to tackle everything possible, setting the scope way too big to accomplish something meaningful in the short time a hackathon typically has. There’s always unexpected blockers. I spent one entire hackathon upgrading packages from Python 2 to Python 3 - I was meant to be making a multiplayer Spotify DJ. As a facilitator, your goal is to help the participants to narrow the scope and prioritize. Don’t let people spend time upgrading packages if that’s not what they had in mind at the start. If there are demos involved, visual elements are more appealing than looking at code or backend things.

Vibe-coding can be very accessible to people, but the problems of people new to hackathons are amplified by ambition, goals, and both too much of them and too little of them. If you’re facilitating a hackathon with non-tech people, make sure to help the participants filter through their ideas into something that could work.

Subscribe now

Share

Sidenote: during this hackathon, I only had 1.5 hours for myself. I decided to make an entirely vibe-coded Turing-complete Scratch clone. I’ve called it VibeCatLine.

Here’s FizzBuzz in it:

Vibe coding is great for prototypes. Skip the cost of getting designers or developers to build something you've been thinking about. But if you want to run something in production, it should not be vibe-coded. You do not understand what it does. You do not know all the systems it depends upon. You do not know what it does with your API keys, with your data, or with your machines.

Looking through the codebases generated by vibe-coders, I’ve found numerous problems: severely out of date dependencies, logging of sensitive information / API keys, unnecessary amounts of code, bizarre API calls. These problems exist in human code too, it’s natural. But vibe-coding is at a different scale.

Vibe-coding is the equivalent of running random programs you found on the internet. You don’t know who created it, you don’t have any kind of protection from what it does. If it breaks something, if it steals something, it is your fault. You are the human. AI can’t take responsibility for anything. But you, as a human, must.

Imagine you are walking through an airport. You see luggage without an owner. You don’t know what’s in it. It’s probably just clothes. But it might be illegal weapons, drugs, etc. Would you be willing to take it through the airport and the rest of your journey? Would you be willing to take it to your family home?

I would assume the answer is no. After all, airports remind people not to leave their luggage alone. If you see some luggage, you’re meant to report it to the nearest security staff.

You, as a vibe-coder, don’t know what luggage AI is giving you. You might not even know how to recognise signs of suspicion. You definitely aren't equipped to investigate: the luggage is locked, and you don’t have the key required to open it. The key is knowledge of software engineering. A key that software engineers have spent years earning.

My objective advice:

• Treat AI generated code as if a complete stranger wrote it. After all, the training material has been written by a stranger. Thousands, maybe millions of them.

• Have 2 human software engineers review the code.

• Do not give AI API keys. You don’t know what servers it will give those API keys to.

• Limit the number of libraries it uses those that have been vetted and approved.

• Run AI generated code inside of a container (e.g docker) to reduce the possible attack vectors. Do not run it natively on device you wish to protect.

• Inform those in your company responsible for security, GDPR / data protection, and legal.

• Establish company-wide prompt regulations for AI tools.

Compared to AI-assisted code, these guidelines are a little more strict. AI-assisted coding tends to have a human at the wheel. Vibe-coding only has the human as a passenger.

AI’s given us a great power. We must use it wisely.

Subscribe now

Share

If we look at “coder” first, the implication is someone who writes code. I’ve seen profile bios on BlueSky where people describe themselves as “I write code for a living”1. But that's a bit misleading. Software engineers turn designs and business logic into functioning tools and products. Code is one way to do that. But the end goal is never to have a large codebase: it’s to have a codebase that accomplishes the business goals2.

There’s the hidden implication that you are paid in direct correlation with the amount of code you produce. But that’s almost never the case. You are paid in direct correlation with the features and bug fixes you contribute to. Your ability to deliver features or bug fixes might indeed be through code: but it might also be through infrastructure, through reducing tech debt, through simplifying codebases, or through empowering others to solve those problems.

What about “developer”? Someone who develops things. Develops implies something ongoing, something improving over time. Usually “the situation is developing” implies that additional things are happening. But the other side of development is that things become refined, and improved. Sometimes through reducing features, a product can become better at delivering value to users or the business. Through reducing the amount of code, the complexity of a codebase can become easier to work with.

Finally my personal preference: “programmer”. I used to take this to mean someone who creates programs, but I like the idea that it refers to someone who creates, configures, cleans up and manages a program. I do still have the connotation in my head of creation being the main aspect, so I’m not thrilled at that.

I’ll probably stop using all of these, in favour of "software engineer”. If we take a couple of the definitions for “engineer”:

a person who designs, builds, or maintains engines, machines, or structures.

a person who controls an engine, especially on an aircraft or ship.

So much of our focus in tech is on writing code. It’s probably what we’re best at. It’s our main unique skill that we can offer a company. But that’s not all we do - and we know that the best code is often no or little code.

As the entire industry adapts to generative AI and vibe-coding, I suspect the better place to frame our skills is that we are there to manage, control, maintain, design and build software. Notice “build” came last in that list - if vibe-coders can build things now, can they really do any of the others?

In the case of Schibsted Media, where I work, I summed these thoughts up as:

You aren’t here to make designs, write code, or manage backlogs

You’re here to deliver news to users who love our sites

In a way that makes sustainable revenue

Subscribe now

Share

It does however have an LSP. It has syntax highlighting in VSCode. It has a debugger. It has a REPL. It can run interpreted in Node, or in the browser. It can compile to native code. It has a web-based playground. It has an auto-formatter. It has inline errors.

The idea behind Tegan isn’t to be a good language. But to show how simple some features can be, if you approach a problem can be from the right direction. Often developers, myself included, try to tackle too many problems all at once. But taking a minute to pause and think about the structure of code before starting is often fruitful later.

For compilers, getting the AST for both the tokens and the expressions can vastly impact how complex it is to later add errors, multiple targets, or editor support. If you think about line numbers, indexes, or a full representation of the tokens and syntax tree of a program, so many things become easier.

The same thing applies to most programs. Before I write code, I ask myself: “what unknowns exist, and what do I already know that could be re-applied?”. With most coding, your knowledge from different domains can be applied again. Humans (and AI, I guess) tend to make code in similar ways, over and over, with slight changes. When was the last time you encountered an API that worked in a totally unfamiliar, new, and novel way for you? It’s a pretty infrequent occurrence. The structure you chose to use, based on what past experiences have taught you, can reduce the amount of time it takes to integrate with an API.

A good data structure can simplify code. Data structures with too many optional fields, unclear nesting, or mismatched impossible states tend to complicated code. Breaking things down into distinct, separate members of a union help clear up code paths and reduce the complexity in introducing safe changes. It’s one reason I start with types before I start with code, and recommend that for others.

Subscribe now

Share

Tegan itself

Tegan is a mostly a side-note for this article, but I figured I’d include further reading if people were interested. Tegan is a great example of how the right data structures simplifies everything. Beyond the parsing and runtime logic, the majority of tooling features (LSP, etc) came for free from the data structures used.

Here’s some screenshots. You could also watch the talk, or just look at the slides or the repo.

Some screenshots of the playground:

Screenshots of vscode:

The objectives

To figure out who we needed to talk to, we needed some clear objectives. Objectives that would help us understand why we needed to talk to people. Once you know why you are analyzing something, figuring out who you should talk is a bit easier to think about.

Our objectives were straightforward: objectively document why this attempt failed, to use these learnings for the future. There was considerable frustration within tech, so an additional objective was to give people a chance to air these frustrations.

The process

There were some teams that were clear we should talk to: those who worked on the central stack, and stakeholder teams that worked directly with the central stack team. We realised half-way through that it would be beneficial to talk to management, too - to understand both the concept, and how different problems were managed.

That left us with two types of retros: team retros, and individual interviews.

For both the retros and interviews, we’d take both written notes, and an audio transcription. For retros, we also had postit notes from those who took part - grouped into categories we had defined beforehand.

As the whole centralizing had caused considerable frustration, we felt it was important to avoid directly attributing any quotes to specific people, where possible. When we did directly attribute people, we gave them both the quote and the context beforehand - so they could either approve or reject the quote.

The goal was not to blame to specific people - it was to understand what happened. Much like blameless post-mortem culture, this report could be thought of as blameless analysis. However, it’s good to note - there were problems to blame, and we didn’t hold back on that. But in blameless post-mortems, you blame processes and not people.

We were sure to highlight as many problems with the process of centralizing as we could. At the same time, we also made sure to highlight any successes. For any future learning, focusing on both things that went particularly well and particularly badly is highlight valuable. Things that went badly can be avoided, or done differently. But you also want to repeat the things that were done well.

Once we ran all the sessions with teams and individuals, we then turned the notes from each session into a summary for that specific individual or team. Other than me and the other author of the report, nobody else would see the transcribed notes we had taken. Very intentionally, we avoided leaking any direct quotes.

The summaries were provided in the report, but were also used to provide executive summaries, do’s and don’t, and specific topic-basic summaries.

The report is pretty huge - so we intentionally make it possible for people to read a specific section without needing to read the whole document. Google Docs’ sections and headlines makes it easy for people to dive to a specific team, for example. We assumed that most team members would be interested in reading the executive summary + their own team’s summary.

What about bias?

Both myself and my co-author were involved in some way. Myself as a user of the platform, and the co-author as someone who was on that team. We naturally had opinions, and biases. But the objective was not “write up what Noah and Hilde think about CNP”, it was “document what went right and wrong with CNP”. We took part in two of the sessions as participants, where we voiced our opinions, but in every other session and the write up, we tried to reflect the opinions of the org. It can be pretty challenging to avoid that, on a topic you’re passionate about. However, if we were afraid of bias, we’d discuss with each other to make sure we’re grounded.

In the document, and in presentations, we made sure to explicitly mention bias. The document is mostly free of our personal bias, but in presentations, we would often include things that we felt didn’t fit in the report, but was important for others to hear. For example, our personal recommendations, or tough-but-fair feedback that management needed to hear.

Then what?

We feared when writing that nobody would read it. Or that management would ignore it. Instead, the opposite is true. Several people have read it multiple times - including management. Both me, my co-author, and others in management frequently mention or send it to others, and we know they read it.

A core aspect of why so many people have read it is that for several years, this was a heated topic within teams. People had strong opinions and frustrations, possibly for the majority of the time they were in the company. The report is a healing factor: showing the company not only cares about doing things differently in future, but also giving a voice to employees.

I’m personally pretty happy with the outcome. It took a lot of time and energy, and so much rewriting to get each phrase just right. But I’m proud that the company both gave us the time and resources to write the report, and that the company has received it well.

Share

Subscribe now

My week-to-week work prior to the layoffs is pretty diverse. I adapt to what the organisation needs - a mixture of short term tasks, and long term tasks. When there’s a problem that I see that we handle reactively, I make a note to try to turn it into something we’ve approaching proactively. Some things are fine to be reactive to, others require proactive changes to handle better next time.

These days, it’s a lot of helping individuals to understand what’s happening to them. Sometimes people just need someone to talk to. Sometimes people have questions. I don’t have all the answers, but I can ask questions on their behalf. Sometimes people need honest career advice, which I can do. I would estimate over the last few weeks, I’ve talked to around 15 people 1-to-1 on average, every day. Sometimes it’s a lot higher, sometimes it’s fewer.

It’s pretty tiring. I use a lot of my mental energy, so much so that I have no physical energy at the end of every work day. But luckily, because I’m not too worried about my own job, I can spend that energy helping others.

Days like this fall into the “reactive” category. People come to me, as more information reaches them, and I help them if I can. However, long term, I’m proactively thinking with two hats on: how can I help employees understand the information they need to make wise decisions, and how can I smooth over the cracks in the emotional safety of the company?

Some solid anchors I have:

• I’m very passionate about the journalistic mission of the company, and very passionate about the employees.

• Last time I mapped out the number of employees I’ve had a meaningful conversation with in the past, it’s around 250. Those I know well - around 80. Knowing people makes it easier for me to be a sympathetic ear.

• I know the leaders of the tech organisation well, and trust them - and their passion for employees and the company.

• I don’t have any problem challenging others - or raising concerns, which often puts me in a unique position to do so.

That responsibility obviously does not fall only to me. Nor to anyone, in fact. Sometimes, work life is difficult. That’s the nature of a capitalistic world. If there’s not enough revenue to cover the jobs we have, then those jobs have to change.

I like to remind myself of some generalities about the world:

• Most people are good people, who want the same thing. Safety, happiness, and peace for themselves, their family, and their friends.

• Change is constant, change can be good, change can be bad, but change will always happen. Change is temporary - maybe with long term consequences, but a fork in the road now does not limit the future, much.

• In the majority of cases, people manage to live good lives. Bad things may happen, but when looking at it from the whole timeline of someone’s life, things happen to work out somehow.

• In business, difficult decisions have to be made that people may be unhappy or negatively impacted by. These decisions, in Norway and Sweden, are rarely based on animosity. We have some of the most equal societies in the world - and therefore it’s not a Meta/Amazon billionaire-CEO situation.

• Mammals will often stop feeding some of their litter when there are too many for the mother to sustain. If the mother tried to feed them all, then the entire litter may suffer. However, if the mother limits her feeding, then the remaining puppies will survive. In this metaphor, the mother is a company. The litter is the employees. And the milk is the cash-flow of a company. Nobody benefits if the company collapses, or goes bankrupt.

A simplistic drawing, but it represents life well. There are always moments in life that give you a new direction - a new environment. Today you are in a forest, tomorrow a desert. It’s okay if the road you’re currently on is rough, or through an area you didn’t want to be in. One day, it will be a good, well-paved road, in an area you’ve been dreaming of.

When it comes to my own energy, I’m tired. These periods have probably been some of the most difficult in my career. But every weekend, I’ve made sure to do fun things with my loved ones. Each day after work, I relax. I go to the office far longer than I usually would, just being available for people in common areas - but when I go home, I’m mostly “done” for the day. I spend the rest of the day with my loved ones, watching things, writing, coding, playing games, and cooking. Normal things, everyday things.

Since one of my biggest drivers in life is helping others, I’m more motivated than ever. Since the world at large is going through a scary, challenging time - I’m more motivated than ever in our journalistic mission. There are often things you can’t control, changes you don’t like. I have control over my own reaction, by taking action, through helping others. I’ve struggled in the past with needing to be over-prepared for every bad situation, but much like software development, resilience is a crucial skill to have.

This morning, on the tram, there was a beautiful pure moment: a woman got up to leave, nearly to the door, when another woman who had been sitting near her began yelling. I, with the other passengers, turned to look at the yelling woman. The exiting woman had forgotten her glove, the yelling woman rushed to give it to her. The tram was just about to leave, the now-gloved woman got off. As the tram departed, the gloved woman stood by the window of the yelling woman, smiling at her with complete warmth. Two strangers, who had a better day as a result of a simple interaction. Life is full of these moments. Small factors that add up, making the world more enjoyable, memorable, and genuine.

If I can help others find their gloves, then I feel I’m doing a good job - as an employee, as a colleague, as a friend, and as a human.

Subscribe now

Share