Balancing Craftsman Life with Software Income Streams

I split a cord of firewood last Tuesday morning before my first standup call.

That's not a humble brag. It's logistics. In Caswell Lakes, Alaska, heating your cabin is a non-negotiable daily task from October through April, and sometimes into May if the spring decides to be cruel about it. The wood doesn't split itself. The code doesn't write itself either. And both need to happen, every single day, or something important breaks down.

I've been living this dual life for a few years now — software engineer by trade, semi-competent Alaskan homesteader by necessity. And the thing nobody prepared me for is how deeply satisfying the combination is, and how brutally difficult it is to balance.

---

The Myth of the Cabin Coder

There's a romantic narrative in tech circles about the developer who escapes to a cabin in the woods and writes brilliant code while surrounded by nature. I see it in blog posts and Twitter threads all the time. They imagine someone sitting by a fire with a laptop, snow falling gently outside, writing elegant algorithms between sips of artisanal coffee.

The reality is that I spend at least three hours a day on tasks that have nothing to do with software. Hauling water when the pipes freeze. Clearing the driveway after a snowfall. Maintaining the generator. Checking the propane levels. Dealing with the fact that a moose knocked over the satellite dish again.

These aren't optional activities you can schedule around your sprint. They're time-critical infrastructure maintenance, and they happen on the infrastructure's schedule, not yours.

This forces a kind of brutal prioritization that I think is actually healthy for a software career, even though it's uncomfortable. When you have genuinely limited hours for code, you stop wasting time on things that don't matter.

---

How I Actually Structure My Days

I've tried every productivity system. Pomodoro. Time blocking. Deep work chunks. Getting Things Done. They all assume you have uninterrupted control over your schedule, which is a luxury I don't have.

What actually works for me is what I call "energy matching." Different tasks require different kinds of focus, and different times of day give me different energy levels.

Early morning (5:30-7:00 AM): Physical work. Firewood, snow removal, water hauling. This is when my body is willing but my brain isn't sharp yet. Manual labor doesn't need sharp thinking — it needs endurance.

Morning block (7:30-12:00): Deep technical work. This is when I write the code that matters. Architecture decisions. Complex debugging. New feature development. I protect this block ruthlessly. No email, no Slack, no meetings if I can help it.

Afternoon (1:00-4:00): Meetings, code review, administrative work, writing. My focus is fragmenting by now anyway, so I match it with tasks that can handle interruption.

Late afternoon (4:00-5:30): More physical work if needed, or lighter technical tasks. Documentation, planning, updating project boards.

Evening: Nothing. I'm done. Trying to code at night after a day of physical and mental work produces garbage that I'll just rewrite tomorrow.

The total deep coding time is about four and a half hours. That sounds low compared to an eight-hour office day. But here's the dirty secret of software engineering: almost nobody actually does eight hours of deep technical work in a day. Most office engineers do three to four hours of real work surrounded by meetings, Slack conversations, and performative busyness.

I just cut out the performative part.

---

The Income Stream Architecture

Living remotely with significant physical demands means I can't rely on a single income source that demands constant availability. I've built what I think of as a portfolio of income streams, each with different time requirements and reliability profiles.

var incomeStreams = {
  consulting: {
    type: 'active',
    hoursPerWeek: 15,
    reliability: 'medium',
    scalability: 'low',
    notes: 'Primary income. Requires scheduled availability.'
  },
  products: {
    type: 'semi-passive',
    hoursPerWeek: 5,
    reliability: 'medium',
    scalability: 'high',
    notes: 'AutoDetective.ai, book sales. Revenue after initial build.'
  },
  content: {
    type: 'semi-passive',
    hoursPerWeek: 5,
    reliability: 'low',
    scalability: 'medium',
    notes: 'Articles, affiliate income. Long tail revenue.'
  },
  contractProjects: {
    type: 'active',
    hoursPerWeek: 10,
    reliability: 'variable',
    scalability: 'low',
    notes: 'Project-based work. Feast or famine.'
  }
};

function calculateWeeklyCapacity(physicalHoursNeeded) {
  var totalWakingHours = 16 * 7;  // 112 hours per week
  var physicalWork = physicalHoursNeeded;  // 15-25 depending on season
  var meals = 7;
  var personalTime = 14;  // Reading, rest, sanity
  var availableForWork = totalWakingHours - physicalWork - meals - personalTime;

  return {
    totalAvailable: availableForWork,
    deepWorkCapacity: Math.floor(availableForWork * 0.5),
    shallowWorkCapacity: Math.floor(availableForWork * 0.3),
    bufferHours: Math.floor(availableForWork * 0.2)
  };
}

// Winter reality
console.log('Winter capacity:', calculateWeeklyCapacity(25));
// { totalAvailable: 66, deepWorkCapacity: 33, shallowWorkCapacity: 19, bufferHours: 13 }

// Summer reality
console.log('Summer capacity:', calculateWeeklyCapacity(15));
// { totalAvailable: 76, deepWorkCapacity: 38, shallowWorkCapacity: 22, bufferHours: 15 }

The buffer hours are non-negotiable. Things break. Weather happens. The truck gets stuck. If you schedule yourself to 100% capacity, the first unexpected event cascades through your entire week.

---

What Physical Work Teaches You About Software

Here's something I didn't expect: doing physical labor every day has made me a better software engineer.

Not in some vague "it clears my mind" way. In specific, practical ways.

Sequencing matters. When you're building a woodshed, the order of operations matters. You can't put up the roof before the walls. You can't put up the walls before the foundation is level. Software developers think they understand dependencies, but when you've actually had a structure lean because you didn't level the foundation properly, you develop a visceral understanding of why shortcuts in foundational work always cost more later.

You can't undo physical mistakes easily. Cut a board too short and you need a new board. In software, Ctrl+Z has made us casual about errors. When every mistake costs material and time, you measure twice. I've started applying this to architecture decisions — spending more time thinking before I start building, because I've internalized that rework is expensive.

Weather is the original deadline. You have to get the firewood split and stacked before the first hard freeze. You have to clear the driveway before the snow compacts into ice. These deadlines aren't arbitrary — they're imposed by physics. It's given me a useful framework for distinguishing between real deadlines and artificial urgency in software projects.

Maintenance is the real work. Everybody loves building the new cabin. Nobody loves re-chinking the logs, replacing the weatherstripping, or crawling under the foundation to check for frost heave. But that's 80% of homestead work — maintenance. Software is the same way. The glory is in the new feature. The value is in keeping the existing system running well.

---

The Isolation Problem (And Solution)

The biggest challenge isn't the workload. It's the isolation.

Remote software work is isolating enough when you live in a city. When your nearest neighbor is a quarter mile away and the road to town is iffy half the year, the isolation can become genuinely problematic.

I've learned that I need deliberate, structured human interaction or my work quality degrades. Not because I'm lonely in some emotional sense — I'm actually quite comfortable alone — but because software engineering in isolation leads to blind spots. You need other people to tell you when your ideas are stupid.

My solution has three parts:

Weekly video calls with other developers. Not standups. Actual conversations about what we're building and why. I have a small group of engineers I've worked with over the years, and we do a weekly roundtable. No agenda. Just "here's what I'm working on, here's where I'm stuck."

Open source participation. Contributing to open source projects forces you to write code that other people can understand, respond to feedback you didn't ask for, and stay current with how the broader community thinks about problems.

Monthly trips to Anchorage. I drive to the city once a month for supplies, and I deliberately schedule in-person meetings and co-working time. It's a four-hour round trip, but the face-to-face interaction is worth it.

---

The Financial Reality Nobody Talks About

Let me be honest about the money side, because the "escape to a cabin" narrative usually glosses over this.

Living remotely is not cheaper than living in a city. Not even close.

Fuel costs are higher. Everything gets delivered, so shipping costs add up. Equipment maintenance is constant. Internet is expensive and unreliable — I pay more for satellite internet that delivers maybe 50 Mbps than most people pay for gigabit fiber. When something breaks, there's no calling a repair service. You either fix it yourself or you pay someone to drive hours to get to you.

The financial model only works if your income is significantly above rural cost of living, which means you need the kind of income that typically requires living near a tech hub. It's a paradox: you need city-level income to afford country-level living.

That's why the multiple income streams matter. Consulting alone would be enough in a good month, but consulting work is unpredictable. Adding product revenue and content income creates enough stability to absorb the months when consulting is slow.

function assessFinancialStability(streams, monthlyExpenses) {
  var totalMonthlyIncome = 0;
  var reliableIncome = 0;

  Object.keys(streams).forEach(function(key) {
    var stream = streams[key];
    totalMonthlyIncome += stream.monthlyAverage;
    if (stream.reliability === 'high' || stream.reliability === 'medium') {
      reliableIncome += stream.monthlyAverage * 0.7; // Conservative estimate
    }
  });

  var runway = reliableIncome / monthlyExpenses;

  return {
    totalMonthly: totalMonthlyIncome,
    reliableMonthly: reliableIncome,
    coverageRatio: runway,
    status: runway >= 1.0 ? 'STABLE' : runway >= 0.7 ? 'CAUTION' : 'AT_RISK',
    recommendation: runway < 1.0
      ? 'Reliable income covers only ' + Math.round(runway * 100) + '% of expenses. Build passive income or reduce burn.'
      : 'Reliable income covers expenses with ' + Math.round((runway - 1) * 100) + '% buffer.'
  };
}

I aim for a coverage ratio of at least 1.3 — reliable income covering 130% of expenses. Below that, I start taking on more consulting work. Above 1.5, I invest extra time in product development, which is lower short-term income but higher long-term value.

---

The Seasonal Rhythm

One thing I've embraced is that my productivity has a seasonal pattern, and fighting it is pointless.

Winter (November-March): More indoor time means more coding hours, but also more physical maintenance. Net effect: slightly above average code output, with a heavy lean toward focused deep work because there's literally nothing else to do when it's dark by 4 PM and minus twenty outside.

Breakup (April-May): The worst season. Everything is mud. The driveway is impassable some days. Infrastructure needs attention after winter damage. Code output drops significantly. I schedule lighter work during this period — documentation, planning, refactoring rather than new features.

Summer (June-August): Long days. Eighteen hours of daylight. Physical work shifts to construction projects, gardening, and preparing for the next winter. But the extended daylight means I can work earlier and later. This is when I launch new things.

Fall (September-October): The best season. Weather is stable, physical prep for winter is urgent but manageable, and there's a natural energy that comes with the urgency. My most productive coding months, consistently.

I've stopped pretending that my output should be constant across the year. It varies by 30-40% between peak and low seasons, and that's fine. The annual output is what matters, not the weekly output.

---

What I'd Tell Someone Considering This

If you're a software engineer thinking about making this kind of move — not necessarily Alaska, but any kind of remote, physical, craftsman-adjacent lifestyle — here's what I'd want you to know.

First, try it for a month before you commit. Rent a cabin. Bring your work. See how you handle the combination of physical demands and remote knowledge work when the novelty wears off and you're just tired and the internet is down and you have a deadline tomorrow.

Second, your income needs to be established before you move, not after. Building a client base from a remote location with spotty connectivity is exponentially harder than maintaining an existing one. I had fifteen years of professional relationships before I moved out here. Those relationships are what keep the consulting pipeline running.

Third, get comfortable with the idea that your career trajectory will look different. You're not going to climb a corporate ladder from a cabin in Alaska. You're not going to attend industry conferences on a whim. Your LinkedIn activity is going to crater. And that's fine, because you're optimizing for a different variable — one that doesn't show up on performance reviews.

Fourth, the craftsmanship transfers both ways. The patience I've developed splitting wood makes me more patient with hard debugging sessions. The systematic thinking from software architecture makes me better at planning homestead projects. They're not separate lives — they're complementary skills that reinforce each other.

And finally: it's not for everyone, and that's not a failure. Some people thrive on the energy of a team environment, the convenience of city infrastructure, and the clear boundaries between work and life. Those are valid priorities. The cabin life works for me because of who I am at 52, after thirty years of something very different. It would have been the wrong choice at 30.

---

The Bottom Line

I don't have a tidy conclusion here, because this isn't a solved problem. Every day is a negotiation between the software work that pays the bills and the physical work that keeps the cabin functional and my sanity intact.

Some days the balance tips toward code and the firewood pile runs low. Some days a broken water pump eats my entire morning block and a client deliverable slips. The system is always in tension, and I've learned to be okay with that.

What I can say is this: the combination of physical craftsmanship and software engineering gives me a kind of fulfillment that neither one provided alone. There's something deeply right about writing code that solves real problems in the morning and splitting wood that keeps you warm at night.

It's hard. It's sometimes lonely. The internet goes out at the worst possible moments. And I wouldn't trade it for the best corner office in Silicon Valley.

Shane Larson is the founder of Grizzly Peak Software and AutoDetective.ai. He writes code in a cabin in Caswell Lakes, Alaska, where the nearest neighbor is a moose and the WiFi is powered by stubbornness. His book on training and fine-tuning large language models is available on Amazon.