Roger Johannesen

I was born in 1982, and I have been curious about how things work for about as long as I can remember. Not just how to use them, but what happens underneath, why they were built that way, what can go wrong and, quite often, what could have been done better.

It started with computers. BASIC at around the age of eight eventually led to assembly, Pascal, QBasic, HTML, servers, networks and programming. Since then, technology has changed names, languages and platforms more times than I can keep track of. The curiosity has remained remarkably consistent.

My professional life took a considerably less direct route.

I have worked on F-16s in the Royal Norwegian Air Force, marine engines and hydraulics, business-critical networks, automotive diagnostics and, eventually, spent seven years at Tesla working with everything from high-voltage systems and advanced diagnostics to remote vehicle diagnosis.

Along the way, safety and emergency preparedness gradually became an increasingly important part of my work. I have served as an elected safety representative, local security lead, industrial emergency response manager and discipline lead for industrial emergency preparedness. Eventually, I was given responsibility for developing the industrial emergency preparedness system across a nationwide network of facilities.

That breadth of experience is something I am proud of.

Particularly because the road there was not primarily paved with formal titles and long strings of letters after my name. I have been given roles that came with expectations, and then done what was necessary to grow into them. When I encounter something I need to know but do not yet understand, my natural response is to learn it. That probably also explains a great deal of what you will find on this website.

I like problems

Or, perhaps more accurately: I like problems that can be solved.

What drives me is curiosity and the satisfaction of making things fit together. I like taking an idea apart, understanding its individual pieces and relationships, and then putting it back together as a system that actually works. That does not necessarily mean I always choose the easiest route when I build something for myself. Quite the opposite. This website is a fairly good example. It is oversized and overengineered for what a personal website strictly needs to be. That is deliberate.

When learning is part of the objective, the shortest route is not always the most interesting one. I learn more by challenging myself, building things I do not already know how to build and, occasionally, making something considerably more complicated than it ever needed to be.

But knowing when not to do that is just as important.

Overengineering one of my own projects is a conscious choice because learning is part of the objective. In a customer project, applying the same philosophy indiscriminately would simply be poor engineering. A solution should not be as advanced as the developer is capable of making it. It should be as simple as it can reasonably be while still solving the problem properly. The depth and complexity of the code have to match the customer's needs, technical starting point, available resources and, importantly, their ability to operate, understand and maintain the solution after the developer has left the room.

To me, knowing where to stop is therefore part of being a developer. Knowing what you can build is one thing. Understanding what you should build is far more important.

And if I am going to put something extra into a customer's solution, I would much rather spend that effort on the things they will hopefully never notice: quality assurance, error handling, debugging, security and sensible mechanisms for when things do not go according to plan. Those are rarely the most spectacular parts of a system. They are, however, often what separates an impressive demonstration from a genuinely good solution.

The best code is not necessarily the code that demonstrates how clever its developer is. It is the code that does its job, fits the environment it was built for and continues to behave sensibly on the day something goes wrong.

My own projects are different. There I am free to turn every knob and take the Reodor Felgen approach: add another gauge, or install a button that "takes over where the other one stops." A great deal of my competence has been built precisely that way. By actually making things.

"But we've always done it this way"

Few things frustrate me more than good ideas that stop halfway.

Systems with obvious potential that are never developed any further. Functions that have become bottlenecks, but remain bottlenecks year after year because, technically, they still work. What particularly bothers me is seeing essential or socially important systems remain outdated while comparatively insignificant services can be intuitive, polished and technologically modern.

Something working does not necessarily mean it works well. And "but we've always done it this way" has never struck me as a particularly convincing argument. My immediate reaction tends to be: "Right. Maybe it's time we changed it, then?"

Many of the things I build therefore do not begin with a desire to write software. They begin because I need something. I look for it, discover that it either does not exist, does not do what I need, or somehow manages to make a simple task unnecessarily difficult.

From there, the distance between:

"Why doesn't this exist?"

and

"Fine. I'll build it."

can be remarkably short.

AI changed the tools, not the job

AI is one of the subjects that fascinates me most about the modern world, although not without a healthy amount of scepticism. I use it actively as a developer and see enormous potential in the technology, but also important questions about control, responsibility, creativity and where the boundaries should be. Rather than filling my entire About page with thoughts on AI, I decided it made more sense to give the subject an article of its own. Read it here:

When I'm not doing any of this

Fortunately, I am not quite this systematic all the time. Family comes first, and outside work and technology I enjoy cooking and spending time outdoors. I am interested in photography, I build and repair things in metal and wood, and I have a particular fascination with history. History appeals to me for much the same reason troubleshooting does.

You have fragments of information, sources that do not necessarily agree with one another, and pieces that are simply missing. Your job is to put them together into a picture that can withstand scrutiny.

That is also why I run a local history archive project where I combine research with development. I can be fairly particular about details. If you put on a film in which the laws of physics are treated as friendly suggestions, there is a significant chance I will point it out. This does not necessarily improve the viewing experience for everyone else in the room.

I also like to think I am funny. There are people around me who have yet to confirm this, but that may simply be a lack of technical understanding on their part. The common thread is probably that once something genuinely catches my curiosity, I find it very difficult to leave it alone.

A problem I really want to solve can develop into something resembling a minor obsession. I need to understand why. I need to figure out how. And once I understand it, there is a fairly good chance I will want to build it too.

That explains quite a lot about this website. The easiest path does not always offer enough resistance to be interesting. The real skill is knowing which path will produce a result you can be proud of.

Two quotes sum up quite a lot, and the first comes from Solan Gundersen:
"For Solan, difficulties are trivial, and the impossible is merely a challenge."

The second is associated with Jack Sparrow:
"The problem is not the problem. The problem is your attitude about the problem."

Two fictional characters who, to be fair, probably should not be placed in charge of occupational safety or project management. Still, both capture something I have carried with me. Problems look different depending on where you are standing. Experience from one discipline can be precisely what allows you to notice something that people in another have stopped seeing. That is why I value the breadth of my experience at least as much as the depth of the individual disciplines.

I have had the opportunity to work with aircraft, boats, networks, cars, people, safety, emergency preparedness and code. Those experiences have taught me different ways of looking at the same problem. And perhaps that is ultimately what I want this website to show.

I am curious, analytical, fairly particular, adaptable and genuinely enthusiastic when I get to work on something I find interesting. I like learning. I like building things. And I like people who are willing to ask why something works the way it does.

I have no ambition to know everything. There is an old idea that the moment you believe you understand everything, you probably understand very little at all. Besides, imagine how boring life would become if there were nothing left to discover. But when I encounter something I do not know, I usually want to find out.

KERNELPANICMODE and the early computer nerd

In my early years of programming, I used KernelPanicMode as a kind of digital stage name. For a programmer, it is perhaps one of the less reassuring names you could voluntarily choose. A kernel panic is not an ordinary application crash. The kernel is the most fundamental part of an operating system, responsible for things such as managing hardware, memory and the processes everything else depends on.

When the kernel encounters a serious condition it cannot safely recover from, it stops the system. It is essentially the computer saying: "Something has gone so fundamentally wrong that the safest thing I can do now is absolutely nothing."

So the term is not exactly associated with stability, control and reassuring software engineering. If I tried to market myself today as a professional developer or systems architect under the name KernelPanicMode, it would be roughly equivalent to an electrician opening a company called Short Circuit Ltd., or a pilot introducing himself as ControlledCrashMode.

Technically relevant, absolutely. Reassuring, perhaps not. Fortunately, the story behind the name is considerably less dramatic. I was called a computer nerd by my classmates for about as far back as I can remember. It was neither particularly kindly meant nor especially enjoyable at the time. As an adult, however, I carry the label with a certain amount of pride. Because being a computer nerd in the late 1980s required a very particular kind of stubbornness.

I started exploring computers and code at around six or seven years old, roughly 1989. This was long before the internet could rescue you, before YouTube could show you how to do something, and roughly three decades before you could ask an AI why your code did not work. When something went wrong, there was no search engine waiting for you to paste the error message into. No eleven-year-old forum thread where somebody had experienced precisely the same obscure problem. No video titled FIXED!!! 100% WORKING!!! with a thumbnail of somebody pointing in disbelief at an error message. Most of the time, there was not even anyone to ask.

If you were lucky, you had a manual. If you were exceptionally lucky, the manual actually contained the answer. Naturally, it was in English, a language I was still in the process of learning. So solving a problem could first require figuring out what the problem was called, then understanding what the words meant and finally working out what on earth the computer expected you to do about it.

Everything else had to be solved with curiosity, logic, trial and error and a fairly substantial amount of patience.

I actually learned a significant amount of my English through computer games, particularly the old Sierra adventures. Their text parsers had very little sympathy for the fact that the player was just a Norwegian kid doing his best. The command had to be right. The words had to be right. Preferably, they also had to be spelled correctly. The computer was a merciless but surprisingly effective English teacher.

Programming worked much the same way. You tried something. It did not work. You tried to understand why. Then you tried again. Sometimes you learned something. Other times you managed to make the entire machine die. Yes, it really could feel that dramatic.

And that is where KernelPanicMode comes from. For the early computer nerd, errors were not merely obstacles between you and the objective. The errors were much of the education. Without an answer sheet, you had to learn to break unfamiliar problems into smaller pieces, look for relationships, form hypotheses and systematically eliminate what could not be causing the problem.

You also learned something I still consider important: "I don't know" does not necessarily mean stop. It simply means the next task is finding out.

That way of thinking has stayed with me.

Being a "computer nerd" in the early computer age therefore meant more than simply liking computers. You had to learn how to structure problems you had never encountered before, understand systems without necessarily having the documentation you needed, make assumptions, test them, discard them and try again.

Not because somebody had taught you a formal method of problem-solving. Because the alternative was that the problem remained unsolved. Perhaps that challenge was also part of what made being a computer nerd, if not always living as one, so fascinating. Technology has changed beyond recognition since 1989. The tools available to me today would have looked like pure science fiction to six-year-old me.

Today I can discuss a problem with an AI, analyse code in seconds and retrieve more technical documentation than I could read in a lifetime. Yet the actual process of solving a problem remains strangely familiar. Understand the system. Find the logic. Break the problem apart. Make an assumption. Test it.

Discover why you were wrong. Adjust. Try again. Build on what you learned. The tools have become dramatically better. The need to understand what you are doing has not disappeared. So yes, KernelPanicMode is named after the moment when a computer system has, for all practical purposes, lost control and decided that the only responsible course of action is to stop everything.

Somehow, I thought that was an appropriate name for the guy who spent most of his time trying to figure out why.

Bulletin board systems were, in many ways, the predecessors of what we now think of as websites. But unlike the internet, you did not simply go online and suddenly have access to the entire world. You dialled a specific BBS directly, using its telephone number and a modem. That machine was your destination.

If you wanted to visit another BBS, you disconnected, found another number and called another computer.