The technical problems are rarely the real problems. The real challenges are sociotechnical: building software with humans, creating teams that work together instead of against each other, aligning what we build with what actually matters.

Why Building Better Teams​

In 2022, I moved to Berlin to challenge myself and started consulting. Most product engineering organizations are stuck in unsustainable processes—chasing aggressive growth, dropping in methodologies without understanding constraints, treating people like resources. I bring the human factor into the productivity equation with methodical, practical solutions that lead strategically to profitability.

People often mistake me for a product manager because I think about customer needs and bring product techniques into daily work. I'm also often assumed to have a business role because I bring business frameworks like Theory of Constraints into engineering contexts. This systemic vision lets me intervene where others haven't looked: understanding the whole system, not just the code.

What I Write About​

Team dynamics, organizational design, scaling patterns, and the practical reality of building software with humans. Industry and tech-stack agnostic because the fundamental problems of coordination and value creation are universal.

You'll also find hobby projects, code tinkering, and perspectives from outside the business world.

Based in Berlin, working with teams globally. If you're dealing with Team Topologies, Conway's Law, breaking down silos, or figuring out how to ship software that matters, I write for people who've been there and want to build something better.

Most companies have some kind of code challenge in their interview process. While you may like or dislike this practice for different reasons, one thing that can easily remove a bunch of headaches here is to stop asking for zip-files of that project.

Git Bundle: A Better Solution​

Git already provides a wonderful feature called a "git bundle". It is a way to package a git repository into single file which contains the entire git repository, and even branches. Generating one is the easiest thing imaginable. If your present working directory is inside a repository, you can simply run this command:

git bundle create your_name.bundle --all

How to Use the Bundle​

Ask the candidate to send you the file (I haven't had any spam issues with gmail so far). On your side simply download the file and clone it to a new folder somewhere:

git clone <path_to_bundle_file>

This works exactly like doing any normal git clone: a new folder is created with the entire project, except the "origin" is a local file (the bundle) instead of a web address to something like GitHub.

Interactive tutorial​

Additional Resources​

Of course, there are many more use cases for this feature than simple code interview submissions, and additional features I haven't described. For more details, you can also review the Git Bundle Documentation.

The answer is simple: it's nonsense. Nobody hires exclusively the best, nor should they. We don't even have industry-wide objective metrics to measure developers consistently.

This post explores how to build strong teams focused on total throughput instead of hiring based on abstract criteria where you can only hope for the best.

Learning from Baseball Economics​

In 2002, a pathologically losing baseball team in California faced a death blow: losing their star player. The 2011 film "Moneyball" documents how this revenue-poor team completely changed their hiring strategy and started winning games, permanently changing how team managers think about talent acquisition.

Oakland's team budget was $44 million, regularly competing against teams spending over$100 million. They achieved the same results with a fraction of the resources by applying basic math and statistical analysis to player evaluation.

The movie is really about math and business management rather than sports. It demonstrates how focusing on the right metrics can overcome resource constraints through smarter decision-making.

Rethinking the Goal of Hiring​

Your company's ambitions eventually exceeded what your development teams could deliver, forcing you to hire. The ultimate goal should be helping your team match your business ambitions.

Hiring "the best" seems obvious, but reveals two hidden traps:

The widening capability-vs-ambition gap: If business ambitions grow constantly, they'll be out of sync with team capabilities. More work enters the system than can be completed. Reducing business ambitions to match team throughput makes you less likely to grow your product or innovate.

The Individual Excellence Trap: Team throughput fluctuates due to upstream product changes, unclear direction, technical challenges, debt, process issues, and focus dilution. Hiring a brilliant individual may not address these systemic problems. Your "10x developer" could have their productivity divided by 10 when placed on a dysfunctional team.

The traditional view treats developers as interchangeable units with different capability levels ("Senior" or "Junior"). This ignores the open secret that one Senior Developer may be capable of wildly different things than another. This mindset implies individual contributors act as teams of one, rather than members who set each other up for success.

A Better Hiring Framework​

Business success requires positive return on investment over time. If hiring aims to increase throughput, the correct investment should maximize total business throughput, not simply add individual capability.

The goal isn't increasing "lines of code per day" or tickets completed per week. It's improving overall business delivery capacity, which may require changing business processes themselves.

Skills Matrix Done Right​

Most teams have Frontend/Backend developers, and hiring often focuses on increasing role specialization. However, teams need non-discipline-specific skills to function effectively. These sometimes surface in culture interviews, but we can do better with stronger focus.

A skills matrix becomes powerful when used correctly, but degenerates into trivia contests about algorithms, data structures, and syntax when used poorly. Focus your matrix on things teams do regularly:

• Technical discussions
• Code review
• Architecture decisions
• Scaling solutions
• Testing practices
• Code quality maintenance
• Mentoring others
• Pragmatic problem-solving
• Collaboration and motivation

Not all of these are technical skills, reflecting the reality that software development involves human factors as much as code. Choose skills meaningful to your specific organization.

Map these skills against mastery levels:

• Developing: Uninformed but learning
• Proficient: Consistently applies skill well
• Expert: Mentors others and leads thinking

This framework clarifies your next investment decisions. Should you hire to cover specific team weaknesses? Which team members need training? Can you run peer mentorship programs? Do you have unchallenged experts with no growth opportunities?

The Power of Focused Thinking​

Consider typical brainstorming sessions. Someone (usually the boss) stands at a whiteboard asking for random ideas, makes on-the-spot judgments, and after four hours the consensus covers only obvious or undesirable options.

Edward de Bono's "Six Thinking Hats" system addresses this problem by focusing intellectual effort into specific modes that ensure multiple perspectives. Teams using this system generate more innovative solutions faster and understand exactly what skill balance various tasks require. A team of average people can achieve amazing results without requiring 150+ IQs.

Apply this focused, specialized thinking to team building. Look for lateral solutions rather than always hiring more developers. Demand for "top x%" talent is highly competitive, time-consuming, and expensive.

Scale Horizontally, Not Vertically​

Instead of always seeking individual excellence, consider:

• Process improvements that multiply team effectiveness
• Tool investments that reduce friction
• Training programs that elevate team capabilities
• Collaboration structures that leverage diverse strengths
• Clear communication that reduces rework and confusion

The goal is building teams where the whole exceeds the sum of parts, rather than collecting individual superstars who may not work well together.

Focus on total team throughput. Measure what matters for business outcomes. Invest in the combinations of skills and people that will actually move your organization forward.

Sometimes the best hire isn't the most impressive individual contributor. Sometimes it's the person who makes everyone else more effective, or fills the gaps.

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. – Douglas Hofstadter

Developers and managers both want scope and delivery time to align, but despite working toward a common goal, they rarely do. The gap is often so large that deadlines are missed, products become irrelevant, and teams face burnout.

Three major schools of thought explain why Hofstadter's Law persists in software development.

Three Theories of Software Delays​

Software is Art​

This perspective treats software development as an inherently unpredictable creative process. Since we lack centuries of established practices, we're prone to underestimating challenges and struggling to predict timelines accurately. While some claims in this school are debatable, they correctly identify that our industry struggles with measuring work, which is fundamental to measuring success.

Software vs. Entropy​

This theory focuses on complexity accumulation. More moving parts make software harder to grow, maintain, understand, onboard new developers to, and ship quickly. As systems evolve, technical debt and interdependencies create friction that compounds over time.

Productivity Declines​

This approach attributes slowdowns to talent, process, and environment factors. Great developers with mismatched processes, inadequate developers for specific needs, or environments that prevent focused work on mentally challenging tasks all contribute to declining throughput.

Research: Perspectives on Team Velocity​

To understand these dynamics better, we surveyed 50 professional programmers and managers about their daily experiences. While the sample size was small, it revealed telling patterns about how different roles perceive development challenges.

We asked participants about:

• Software release frequency
• Their role (manager, developer, or both)
• How often specific issues slow them down
• What improves or hinders their work

Key Findings​

Perception Gaps: Developers and managers experience the same problems differently. When we ranked issues by perceived severity, clear patterns emerged:

• All groups identified interruption and lack of focus as major problems
• Monthly+ shipping teams saw changing product requirements as their biggest challenge, with fewer technical debt issues
• Daily shipping teams had minimal design change problems but frequent technical challenges
• Weekly shipping teams struggled across all categories

Role-Based Biases: Developer-managers perceived all issues as more frequent than peers filling only one role. Managers focused on business-side bottlenecks, while developers emphasized technical constraints.

The Communication Divide​

This reveals a fundamental disconnect. Developers constantly request time to refactor or rewrite systems, which could indicate either:

• Communication breakdowns about technology and product trade-offs
• Biased memory toward familiar technical challenges

Driving vs. Restraining Forces​

What Helps Teams Move Faster:

• Agile methodologies (overwhelmingly supported across all roles)
• New frameworks and design patterns (developer favorites)
• Process automation, especially UI testing and build improvements
• Clear communication and stable priorities

What Holds Teams Back:

• Managers: Changing priorities, communication failures, constant meetings
• Developer-Managers: Slow automated processes, poor culture, firefighting
• Developers: Context switching, unclear processes, overloaded sprints, technical debt

The Theory of Constraints in Software​

These perception gaps reflect a deeper organizational challenge. The Theory of Constraints describes two approaches to improving throughput:

Cost Accounting: Maximize individual step efficiency, keeping everyone at full capacity Throughput Accounting: Optimize total system output, allowing individual steps to operate below capacity

Cost accounting feels intuitive but creates competition between teams rather than collaboration. This mindset has caused manufacturing plants to fail, and it's equally problematic in software development.

Human Bias in Problem Identification​

Our research reveals a predictable pattern: managers blame business-side issues while developers blame technical problems. Both groups attribute challenges to what they're most exposed to.

This isn't malicious. It's human nature. Without objective data, correctly identifying problems requires perfect memory, unbiased reasoning, accurate interpretation, immunity to social influence, and complete objectivity about one's own performance.

Loss Aversion compounds these biases. We feel stronger pain from losses than equivalent gains. In software terms, cutting quality control feels like gaining speed, while upfront design work feels like losing development time. NASA research shows how this creates exponentially expensive defects later in the process.

The Data Imperative​

Individual perspectives are too narrow to identify true bottlenecks. We need broader, objective measurement to understand what's actually happening.

Consider our finding that daily-shipping developers complained about build processes. Are these safeguards slowing total business throughput, or preventing production bugs that are orders of magnitude more expensive? Without data, we're just guessing.

Meaningful metrics should answer questions like:

• Did our process changes improve outcomes?
• Are we over-polishing features at the cost of shipping?
• How do all-hands meetings affect productivity?
• Which engineers created the biggest impact?
• How much effort went toward technical debt?

Moving Forward​

Software engineering is notoriously difficult to measure, and easy metrics are often vanity metrics or unfair comparisons. But difficulty doesn't justify giving up on measurement entirely.

As Peter Drucker observed, "If you can't measure it, you can't improve it." Without data, we're stuck with guesses, opinions, and office politics.

The solution isn't eliminating human judgment, but complementing it with objective measurement that cuts through bias and subjectivity. Only then can we identify true constraints and make improvements that actually matter for total team throughput.

Meaningful data transforms subjective debates into objective problem-solving, helping teams align around what actually drives results rather than what feels important to individual roles.

You'll learn how to use the Rumprun toolchain to build a unikernel that hosts your static website served by Nginx. This tutorial focuses on giving application and web developers practical steps to get running with Rump Kernel-based unikernels.

This assumes you're on a GNU/Linux or BSD system and familiar with command line basics.

What We'll Build​

We'll create a complete unikernel-based web server by:

1. Setting up the Rumprun toolchain for building Rump Kernels
2. Compiling Nginx to run as a unikernel on QEMU
3. Configuring networking so you can access your site
4. Adding your static content to the unikernel
5. Setting up HTTPS support

This is experimental technology, so some troubleshooting may be required. We'll explain the tools in enough detail that you can debug issues if they arise.

1. Setting Up Rumprun​

The Rumprun repository provides everything needed to develop unikernels based on Rump Kernel: debugging scripts, compiler tools, and NetBSD drivers as dependencies.

First, download the repository and its dependencies:

git clone https://github.com/rumpkernel/rumprun
cd rumprun
git submodule update --init

You'll need GCC installed (Rumprun doesn't yet support Clang). The exact package varies by distribution.

Choose your target platform. We'll use "hw" (hardware) rather than "xen" because it's easier to get started with. Even though we're building for hardware, we can test using virtual machines.

Build the toolchain:

./build-rr.sh hw

If this fails, you may need to install binutils on your system.

This compilation takes time as you're building both C and C++ components. When complete (it will say "build-rr ran successfully"), add the tools to your PATH:

export PATH=${PATH}:$(pwd)/rumprun/bin

Note: This PATH assignment is temporary. You'll lose it when you close the terminal or open new windows.

2. Building Nginx as a Unikernel​

Now we'll build a Nginx unikernel using an existing Rump package:

git clone https://github.com/rumpkernel/rumprun-packages
cd rumprun-packages/

Configure the package builder to use your Rumprun toolchain. Copy the configuration template and update it:

cp config.mk.dist config.mk

Edit config.mk and set:

RUMPRUN_TOOLCHAIN_TUPLE=x86_64-rumprun-netbsd

(Don't add -gcc or other suffixes)

Now build Nginx:

cd nginx
make

You'll need genisoimage installed (often in a package called cdrkit) to build ISO files for bare metal deployment.

After the build completes, "bake" the unikernel. First, see available platforms:

rumprun-bake list

Use hw_virtio for cloud deployment. Bake your unikernel:

rumprun-bake hw_virtio ./nginx.bin bin/nginx

Test the basic functionality:

rumprun qemu -M 128 -i \
    -b images/data.iso,/data \
    -- nginx.bin -c /data/conf/nginx.conf

You should see QEMU launch with debugging text. Success means no "panic" messages (though "rumprun: call to sigaction ignored" is normal). Rump Kernel has a different understanding of signals than you would expect on an operating system.

3. Setting Up Network Access​

To access your web server, we'll create a TAP network device. This provides more flexibility than simple port forwarding for complex applications.

Create and configure the TAP device (may require sudo):

ip tuntap add tap0 mode tap
ip addr add 10.0.120.100/24 dev tap0
ip link set dev tap0 up

Choose a network range that doesn't conflict with your existing network. Verify the device works:

ping 10.0.120.100

Now launch Nginx with network access:

rumprun qemu -i -M 128 \
    -I if,vioif,'-net tap,script=no,ifname=tap0'\
    -W if,inet,static,10.0.120.101/24 \
    -b images/data.iso,/data \
    -- ./nginx.bin -c /data/conf/nginx.conf

This command:

• Runs QEMU as the emulator
• (-i) Attaches guest console on startup
• (-M) Sets memory limit to 128MB
• (-I) Creates guest network interface with iftag
• (-W) Configures VM network address (different from TAP interface)
• (-b) Mounts data.iso as block device on /data
• (--) Starts nginx with specified config

If successful, you can visit http://10.0.120.101 in your browser to see the default page.

4. Adding Your Static Content​

Your website files go in ./images/data/www and Nginx configuration in ./images/data/conf. Simply replace the www directory contents with your static site.

For static site generation, consider tools like Jekyll, Hugo, or Sculpin.

To see new content:

1. Stop the running unikernel
2. Rerun make in the nginx directory
3. Re-bake with rumprun-bake
4. Launch with rumprun qemu

Important: Don't modify the filesystem image while the guest is running. Use different image names when building new versions.

If you have connection issues, verify your tap0 device hasn't lost its IP address or gone down when you killed the emulator.

5. Adding HTTPS Support​

Configure SSL in your nginx.conf under the server { section:

listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /data/conf/ssl-cert.crt;
ssl_certificate_key /data/conf/ssl-cert.key;

Generate a self-signed certificate or use your production certificates. Place the certificate files in the conf directory.

After updating the configuration:

1. Remove build artifacts in ./build/
2. Run make
3. Re-bake with rumprun-bake
4. Launch with rumprun qemu

Your site will now be available over HTTPS.

6. What You've Accomplished​

You now have the fundamentals to host unikernel applications based on Rump Kernel. This approach offers several advantages:

• Fast scaling: Unikernels boot in milliseconds, enabling rapid scale-up and scale-down
• Resource efficiency: Minimal memory and CPU overhead compared to traditional VMs
• Security: Reduced attack surface with only necessary OS components
• Deployment flexibility: Can run on cloud hypervisors or directly on hardware

You can build on these basics to create more interactive applications, run PHP applications in immutable images, or deploy applications directly on hardware without a traditional operating system.

Resources​

• Rump Kernels Project
• TUN/TAP Interface Tutorial
• Rumprun GitHub Repository

Yet despite these advances, we've hit a wall.

The Diminishing Returns of "More"​

As a programmer, I prefer dual monitors, but there's a limit to how much screen real estate actually helps. My two Acer monitors cost under $150 each, have lasted over three years without dead pixels, and provide roughly four feet of working display. Adding more screens beyond this point creates more problems than solutions: suddenly I'm moving my head constantly, losing track of windows, and spending more time managing my workspace than working in it.

The market has responded by pushing the same tired metrics: bigger screens, higher contrast ratios, more pixels. You can find 70-inch monitors on Amazon, waterproof displays, wall projections, but this approach misses the fundamental purpose of a display.

Innovation Has Stalled Where It Matters Most​

Display technology has lost interest in solving the real problem: how humans actually interact with information. Instead of innovating toward better human-computer interaction, manufacturers keep fighting for incremental improvements in image quality. Innovation continues, but those pushing meaningful boundaries face enormous momentum from an industry focused on specs rather than usability.

Many people speculate the next "big thing" will be headache-inducing "3D" displays. Put on glasses, stare at interlaced images, or endure other visual tricks. You can buy these TVs, but most people simply don't care whether their advertisements jump out of the screen. There's a long way to go before we reach Star Wars-like holograms with R2D2 projecting videos in mid-air.

Even genuinely impressive technologies like laser-based holographic projections that create points of light in midair address the wrong problem. These systems focus on visual spectacle rather than the fundamental reason we need displays: to facilitate meaningful interaction between humans and computers.

What Happens When We Focus on Human Interaction?​

When we shift perspective to human interaction, picture quality becomes less important than usability and value. The most promising developments focus on displays that adapt to human needs rather than forcing humans to adapt to the technology.

Take f.lux, a simple application that automatically adjusts screen brightness and color temperature based on time of day. It eliminates the jarring experience of staring into blazing white light late at night, helping maintain natural sleep cycles. This represents exactly what displays should do: fit the human like a glove.

The Real Problem: Displays Don't Fit Humans​

Current displays fail because they don't consider that users are human. We're stuck staring into boxes of light in an interaction model that works well for photos and videos but falls short for most other computer tasks.

Right now, you have to hunt for windows you just minimized. Your eyes painfully readjust when switching from a dark website to a bright one. You scroll through tabs searching for a single piece of text. You navigate past banner ads and company branding just to reach your content. These problems stem from displays that force humans to adapt rather than adapting to human needs.

The Solution: Responsive, Adaptive Displays​

Future displays should do more than show content: they should intelligently present it. If I'm about to search for something online, my computer should anticipate this need and organize my workspace accordingly. It should consider my experience level and adapt the interface to match.

This requires separating content from presentation design. Instead of websites dictating exactly how information appears on your screen, displays should analyze multiple content sources and determine the most intuitive way for each individual user to absorb that information.

Consider displays that eliminate jarring transitions between light and dark content, that organize information based on your current task, that learn your patterns and adapt accordingly. This approach focuses on creating interfaces that wrap around human behavior rather than impressive visual effects.

The Path Forward​

We're already struggling to make websites work across different devices because we've locked presentation and content together. Displays focused on photo-realistic contrast struggle to deliver user experiences that demonstrate real value.

The future belongs to displays that understand their users. The first step is exposing content in ways that allow displays to intelligently mix and present information tailored to individual needs. Only then can we create display systems that truly fit humans like a glove: natural, intuitive, and focused on delivering value rather than visual spectacle.

The technology exists. What we need now is a paradigm shift from hardware specifications to human-centered design.

There's something we lost when HTTP became the only game in town. Before the web browser dominated everything, the internet was a diverse ecosystem of protocols, each designed for specific purposes. We had telnet for raw connections, Gopher for clean content delivery, and text-based worlds that fostered creativity in ways the modern web struggles to match.

Understanding these "old ways" isn't just nostalgia. It reveals how much richer the internet could be, and why our current web-centric approach may be holding us back.

What Telnet Taught Us​

Telnet gets a bad reputation today, dismissed as an insecure relic. But calling it just "telnet" misses the point—we're really talking about the foundation of all internet communication: sending raw text over TCP/IP. Every protocol, from HTTP to SMTP to IRC, builds on this simple concept.

This simplicity was educational. When you connected to a server via telnet, you weren't hidden behind layers of abstraction. You typed commands, got responses, and understood exactly what was happening. The internet wasn't a magic box that rendered HTML into pretty pictures. It was a conversation between computers using plain text.

The Rich World We Abandoned​

Multi-User Worlds​

One of the most engaging examples of pre-web internet culture was Multi-User Dungeons (MUDs, MOOs, MUSHes, and MUCKs). Born in the mid-1970s, these text-based virtual worlds had no graphics or special encodings. Just a stream of text that created immersive experiences for hours.

What made them special wasn't the technology, but the culture. Many MUD servers exposed programming languages to players. You could log in, write code that manipulated the game world, and watch other users discover and interact with your creations. We had user-generated content as the focus of the internet in the 1970s, decades before "Web 2.0" claimed to invent the concept.

I ran one of the most popular sites focused on Message Parsing Interpreter (MPI) when I was twelve. Players would write complex interactive objects and export that code to other servers. The Discworld MUD, based on Terry Pratchett's novels, has been online for almost 20 years with 50-150 players logged in at any time. These communities built lasting social connections around shared creativity and imagination.

Pure Content Delivery​

Before HTTP conquered everything, we had Gopher: a protocol designed to deliver pure content without design chrome or spam. The Gopher manifesto reads like a post-mortem now, but its vision was compelling: just the knowledge, without the sparkling prettiness of bad web design and ad-filled "news" sites.

Gopher would have made our current "mobile site" problems irrelevant. When you're only delivering content rather than layouts, backgrounds, animations, and advertisements, everything works everywhere. It's tragic the protocol died, because had it evolved with the same effort as HTTP, we might have a cleaner internet today.

The few remaining Gopher servers exist in near-stasis since 1991, but they demonstrate what we lost: instant access to information without visual noise or commercial interruption.

Why HTTP Won (And What We Lost)​

HTTP's dominance wasn't accidental. The web browser provided a unified interface for multiple protocols, solving real interoperability problems. Instead of needing different software for every service, users could access everything through one application.

But this convenience came with costs. We stopped innovating at the protocol level and started forcing everything through HTTP, regardless of whether it was the right tool. Today we have SOAP monsters and RESTful APIs trying to recreate functionality that specialized protocols handled more elegantly.

The deeper loss was educational. When protocols were visible and diverse, technically curious people learned how the internet actually worked. Now those mechanisms are hidden inside browsers, creating a generation that sees the internet as magic rather than engineering.

The Knowledge Gap​

Most people don't understand internet protocols because they've been abstracted away. This isn't because protocols are complicated—SMTP is simple enough that you can manually send emails by typing commands. The complexity is hidden, tucked inside software that "just works."

This knowledge gap has serious implications. When politicians propose blocking DNS or making encryption illegal, those who understand the internet's architecture immediately recognize how misguided these policies are. But that understanding is becoming rare, concentrated among a shrinking group of specialists rather than being widely distributed.

Understanding protocols also reveals possibilities. If you know that HTTP is just text commands like "GET /Resource," you realize you could create something similar. The internet isn't a closed system. It's an open platform for experimentation.

What We Could Build​

Imagine internet protocols designed for today's needs rather than retrofitted into HTTP:

• Efficient content delivery: Pre-computed DOM trees instead of HTML documents that require additional resource requests
• Batch communication: Multiple documents sent simultaneously rather than the current request-response cycle
• Purpose-built interfaces: Discussion protocols that work naturally in text environments, unwrapped from web browser chrome
• Structured data: Native JSON protocols instead of encoding everything in markup
• Academic publishing: Direct TeX format delivery for mathematical and scientific content

We don't pursue these possibilities because HTTP's inertia is massive. But that doesn't mean enthusiastic hackers can't reclaim some of that experimental spirit.

The Path Forward​

I'm not suggesting we abandon the web. HTTP solved real problems and enabled unprecedented global communication. But we shouldn't let its success prevent us from exploring alternatives for specific use cases.

The protocols that built the early internet were designed by people who didn't know what was impossible. They experimented freely, creating tools that served distinct purposes rather than trying to make one protocol do everything.

Today's internet giants understand this. They've moved beyond HTTP for internal systems, using specialized protocols for performance and functionality. The rest of us are stuck in browsers, accepting the limitations of a document delivery system pressed into service as a universal application platform.

Learning these older protocols isn't just historical curiosity—it's preparation for building the next generation of internet tools. When you understand that the internet is bigger than the web, you start seeing possibilities that browser-based thinking misses.

The internet belongs to those who understand it. The more people who learn these fundamentals, the more likely we are to see real innovation rather than endless variations on HTTP-wrapped services.

Start with telnet. Pick a simple protocol like SMTP or IRC. Write a basic client. See how much you can accomplish with just text and creativity. The internet is still out there, waiting for the next generation of protocol pioneers.

Problem 001​

On the popular programming challenge website Project Euler, the first problem seems quite trivial. However, with deeper examination we can discover layers of complexity as we try to generalize the problem.

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000.

It looks almost like a generic screening interview problem. The problem should be solvable anywhere between 1 and 5 minutes by any developer. It's a simple loop, some logic, and addition.

function sumMultiplesOfThreeAndFive(n){
var sum = 0;
for (var i=1;i<n;i++) {
  if (((i % 3) === 0) || ((i % 5) === 0)) {
    sum += i;
  }
}
return sum;
}
console.log(sumMultiplesOfThreeAndFive(1000))

Solving every set of multiples​

Looking at the code it's quite obvious 3 and 5 are replaceable with any set of other numbers. All we need to do is tweak the code to support accepting an array of multiples that will be tested.

function sumMultiples(n, multiples){
var sum= 0;
var isMultiple = function(n, multiple){
  return ((n % multiple) === 0);
};
var commonMultiples = function (n,multiples){
  var isCommon = false;
  for (var i=0;i<multiples.length;i++){
    isCommon = (isCommon || isMultiple(n, multiples[i]));
  }
  return isCommon;
};
for (var i=1;i<n;i++) {
  if (commonMultiples (i,multiples)) {
    sum += i;
  }
}
return sum;
}
console.log(sumMultiples(1000, [3,5]))

Fixing the performance issue​

Every time it searches for a higher number it ends up taking longer to run. So how else might I try to solve this? I recalled a story a high school math teacher told me about the Mathematician Gauss. His teacher punished him with the daunting task of adding together all the numbers between 1 and 100. Gauss solved it in minutes, because saw a simple pattern which he invented called the Arithmetic Sum.

The formula for an arithmetic series is:

$S_n = \frac{n}{2}(a_1 + a_n) = \frac{n}{2}(a + a \cdot n)$

Where:

• $n$ is the number of terms
• $a$ is the first term
• $a_n$ is the last term

The sum is equal to the first and last number in the series, multiplied by half the count of numbers in the series.

What's amazing about this is it scales at O(1), there's no Ifs or Loops here. It works the same way for 100 as it does 10e100.

If we find the sum of 3s, we just find the number of times 999 can be divided by 3, then apply the arithmetic series formula. The same for 5s. This does however introduce a slight problem: just adding the two values together is higher than the final result. We need to subtract all multiples that are common to both 3 and 5 (to avoid double-counting).

So, in summary, find the sum of 3s, 5s, and subtract once the sum of 15s (since 15 is the LCM - Least Common Multiple - of 3 and 5).

function sumMultiplesOfTwoOrThree(n){
var sum= 0;
var arithmeticSum = function(a, n){
  return (1/2)*n*(a+a*n);
};
var arithmeticSumFromSeriesMultiple = function(series, multiple){
  series -= 1; //Euler problem #1 wants numbers less than 1000.
  var a = multiple;
  var n = Math.floor(series/multiple);
  return arithmeticSum(a, n);
}
sum += arithmeticSumFromSeriesMultiple(1000, 3);
sum += arithmeticSumFromSeriesMultiple(1000, 5)
sum -= arithmeticSumFromSeriesMultiple(1000, 15);
return sum;
}
console.log(sumMultiplesOfTwoOrThree(1000))

Solving all combinations with performance​

Thinking back to set theory and Venn diagrams, there's a visual intersection between 3s and 5s that is clearly just the set of 15s that need to be negated once. In more generic terms, if provided A and B, the script must run sum(A)+sum(B)-sum(AB).

Using two for-loops this is an easy task, but again leads to a slow running solution. The real problem here is finding a way to generate all permutations for a set. There's a great way to do that: simply counting in boolean and assigning a place-value to each element in the list of multiples.

That sounds a bit confusing so visualizing here will help. Let's look at this set of multiples with 3s, 5s, and 7s.

So there's some overlap between all these sets:

• 3s and 5s
• 5s and 7s
• 7s and 3s
• 3s, 5s, and 7s combined

So in this case I'd have to: sum(3)+sum(5)+sum(7)-sum(3×5)-sum(3×7)-sum(7×3)+sum(3×5×7).

As mentioned above, another way to look at this is binary mapping:

001 = C      (cardinality 1: ADD)
010 = B      (cardinality 1: ADD)  
011 = BC     (cardinality 2: SUBTRACT)
100 = A      (cardinality 1: ADD)
101 = AC     (cardinality 2: SUBTRACT)
110 = AB     (cardinality 2: SUBTRACT)
111 = ABC    (cardinality 3: ADD)

Simply knowing this mapping we can generate all the combinations of sums needed. If it's added or subtracted is simply a matter of how many 1s are in a number: odd numbers get added, even gets removed.

This follows the inclusion-exclusion principle, which can be expressed mathematically as:

$\left| \bigcup\limits_{i=1}^n A_i \right| = \sum\limits_{i=1}^n | A_i | - \sum\limits_{1 \le i<j \le n} | A_i \cap A_j | + \sum\limits_{1 \le i < j < k \le n} | A_i \cap A_j \cap A_k | - \ldots + (-1)^{n-1} | A_1 \cap A_2 \cap \ldots \cap A_n |$

For our specific case with three sets (multiples of 3, 5, and 7), this becomes:

$|A \cup B \cup C| = |A| + |B| + |C| - |A \cap B| - |A \cap C| - |B \cap C| + |A \cap B \cap C|$

So with this known, we simply need a combination generator. This will take ["a", "b", "c" , "d"] and return ["a", "b", "ab", "c", "ac", "bc", "abc", "d", "ad", "bd", "abd", "cd", "acd", "bcd", "abcd"] (all combinations of ABCD).

/*Generate a list of all Combinations*/
function getCombinations(list){
var combinations = []; //All combinations
var combination = []; //Single combination
var quantity = (1 << list.length);
for (var i = 0; i < quantity ; i++){
  combination = [];
  for (var j=0;j<list.length;j++) {
    if ((i & (1 << j))){
      combination.push(list[j]);
    }
  }
  if (combination.length !== 0) {
    combinations.push(combination);
  }
}
return combinations;
}

/*Generate a product from a list of numbers*/
function listProduct(list){
var product=1;
for (var i=0;i<list.length;i++){
  product *=list[i];
}
return product;
}

/*Return the arithmetic sum*/
function arithmeticSum (a, n){
return (1/2)*n*(a+a*n);
}

/*Generate the arithmetic sum of a series based on a multiple*/
function arithmeticSumFromSeriesMultiple (series, multiple){
series -= 1; //Euler problem #1 wants numbers less than the range.
var a = multiple;
var n = Math.floor(series/multiple);
return arithmeticSum(a, n);
}

Now combining everything together the result is something like this:

/*Generate a list of all Combinations*/
function getCombinations(list){
var combinations = []; //All combinations
var combination = []; //Single combination
var quantity = (1 << list.length);
for (var i = 0; i < quantity ; i++){
  combination = [];
  for (var j=0;j<list.length;j++) {
    if ((i & (1 << j))){
      combination.push(list[j]);
    }
  }
  if (combination.length !== 0) {
    combinations.push(combination);
  }
}
return combinations;
}

/*Generate a product from a list of numbers*/
function listProduct(list){
var product=1;
for (var i=0;i<list.length;i++){
  product *=list[i];
}
return product;
}

/*Return the arithmetic sum*/
function arithmeticSum (a, n){
return (1/2)*n*(a+a*n);
}

/*Generate the arithmetic sum of a series based on a multiple*/
function arithmeticSumFromSeriesMultiple (series, multiple){
var a = multiple;
var n = Math.floor(series/multiple);
return arithmeticSum(a, n);
}

function sumMultiples(range, multiples){
var sum= 0;
var subsetSums = [];
var multiplesCombination=getCombinations(multiples);
for (var i=0;i<multiplesCombination.length;i++){
  //Generate product from combinations of multiples
  //and
  //Find individual sums of all combinations.
  subsetSums.push(
    arithmeticSumFromSeriesMultiple(
      range,
      listProduct(multiplesCombination[i])
    )
  );
}

for (var i=1; i< subsetSums.length + 1;i++){
  //Check if i is an even base 2.
  if ((i & (i - 1)) == 0){
    sum += subsetSums[i-1];
  } else {
    sum -= subsetSums[i-1];
  }
}
return sum;
}

console.log(sumMultiples(999, [3,5]));

Results​

A quick check of performance yields these results:

• Using really large numbers, the math approach is much faster.
• Using really small sets, the simple for-loop is faster in 2020, but I remember it was slower in 2012 when I originally tested this.