When I'm working with a client, I respect their time and energy by keeping things simple and easy for them. I make as many decisions as I can, and try not to bog them down with every complex decision I have to make.

I've learned to trust my instincts, and to escalate important choices only when the trade-offs are truly business decisions.

This is a story of when this instinct led me in the wrong direction.

A static link to a static zip file

I often work on projects with fixed-price and flexible-scope. What this means is my clients know exactly what a project will cost, but I'm also okay with the odd surprise.

That day, I was working on a web app that was powered by static data files. I was working on the simplest task of the project. The client wanted to add a link so users can download all the data files in a zip file. Sounds straightforward, right?

Commit #1: "NEW: add data download"

<a href="data.zip">Download Data</a>

I could have just zipped the data files up on my laptop and called it a day. However, I didn't want to be in a situation where I forgot to update the zip file if the data changed. I decided to automate the process by creating the zip file during the automated deployment pipeline.

Commit #2: "NEW: create zip file in deployment pipeline"

"scripts": {
"build": "npm run build:download; ...",
"build:download": "cd public/static/data; rm -f data.zip; zip *.csv data.zip"
},

I pushed that change and the pipeline failed immediately.

sh: 1: zip: not found

Seriously? I looked at the pipeline configuration in bitbucket-pipelines.yml. It was running off a seven-year-old container that didn't have zip installed.

I could have made a new, custom container that had everything we needed. I decided that would give the project another thing to manage over the long run, which I thought it'd be best to avoid. Instead, I thought I'd simplify things by using the official node.js container.

I added a line to the pipeline to install rsync (to upload files to the staging server) and zip. It would only add a few seconds to the pipeline, but then we wouldn't need to maintain a custom container.

Commit #3: "FIX: use latest node.js container, install rsync and zip"

image: node:latest
pipelines:
  branches:
    main:
      - step:
          script:
            - apt-get update
            - apt-get install -y rsync zip

The pipeline failed again.

> npm run build:download; webpack --mode=production --env.router hash --env.appPublicPath public --config ./production.config.js

Error in bail mode: Error: callback(): The callback was already called.
    at context.callback (/opt/atlassian/pipelines/agent/build/node_modules/loader-runner/lib/LoaderRunner.js:106:10)
    at processTicksAndRejections (node:internal/process/task_queues:103:5) Error: callback(): The callback was already called.
    at context.callback (/opt/atlassian/pipelines/agent/build/node_modules/loader-runner/lib/LoaderRunner.js:106:10)
    at processTicksAndRejections (node:internal/process/task_queues:103:5)

What the heck?

The web app was being built with Webpack v4, a very old build tool. Turns out Webpack v4 breaks on newer versions of node.js.

I decided to try using an older node.js container. After some experimentation, I found that Webpack v4 needed node.js v16 or older. Of course, once I had the right version of node, the build in the container still failed!

E: The repository 'http://deb.debian.org/debian buster Release' does not have a Release file.
E: The repository 'http://deb.debian.org/debian-security buster/updates Release' does not have a Release file.
E: The repository 'http://deb.debian.org/debian buster-updates Release' does not have a Release file.

This time it was because this old node docker container is built on an old and outdated version of Linux. The operating system is so old that I couldn't even install rsync and zip on it without some serious workarounds.

If you come to a fork in the road, take it

At this point I knew I was going in the wrong direction. Getting old versions to work together wasn't the simple & quick solution I had hoped it was. I wasn't going to spend any more time getting five-year-old software to play nice together. The best solution was to modernize this legacy project by replacing Webpack with Vite.

My client had surely never heard of Webpack or Vite, and they certainly would never have asked me to make the switch. I knew it was way outside the scope of this project. I also knew it would take me way longer than I estimated.

But more than all of that, I knew it was the right solution for this moment, and for the project in the long term. If I didn't deal with this properly today, the system would remain fragile, and only get worse. More problems like these would surely arise in the future, and I didn't want that burden and risk to persist.

I decided to push forward.

Commit #4: "FIX: replace Webpack with Vite"

Lines updated +2778 -8272

This was the deepest part of the rabbit hole, but I was happy to finally be rid of Webpack. The project was much better off for it, no longer stuck on outdated versions and tools. I was bracing myself for a huge task, but it didn't take as long as I feared, and I was very happy with the result.

Finally, I was able to use the latest versions of everything in the deployment pipeline, and it worked!

Delivering the download button

After all this, I sent my client an email and let them know the download button was in place. I explained that the zip file was being built automatically in the deployment pipeline. Best of all, I had modernized the pipeline so it was running the latest versions of everything and would even be a bit faster.

The client thanked me and asked, will the zip file update automatically when they upload new data files?

Damn, of course not. The deployment pipeline is used during development only, when I push changes to the staging server. Once the web application was live, I had assumed the client would create zip files manually whenever they uploaded new data files. It was a bad assumption on my end, and of course I was happy to deliver a better solution that works well for my client.

Commit #5: "NEW: use jszip to generate the zip file in the browser"

async function download() {
  // import jszip only when needed
  const JSZip = (await import('jszip')).default;
  const zip = new JSZip();

  for (const filename of CSV_FILES) {
    zip.file(filename, await fetchFile(filename));
  }

  const zipBlob = await zip.generateAsync({ type: 'blob' });
  const url = URL.createObjectURL(zipBlob);
  const link = document.createElement('a');
  link.href = url;
  link.download = 'data.zip';
  document.body.appendChild(link);
  link.click();
  document.body.removeChild(link);
  URL.revokeObjectURL(url);
}

I deleted all the zip stuff from the pipeline, but of course I kept the modernization. I switched to creating the zip file on the fly in the browser using the jszip library. The download button was working great.

Simplifying things for my clients

When given a problem, I'm always looking to deliver the simplest solution. I'm willing to do the hard work to keep things simple for my clients, and for the users of the software.

At the start, having a static zip file seemed like the simplest solution. In the end, the best solution was the one that worked best for my client, and I was happy to deliver that instead.

By keeping things simple for my clients, I took on a lot of complexity. I went further down this rabbit hole than I had to, but I'm glad this legacy web application ended up being modernized in the process.

This easy task ended up taking way longer than I had expected, but my client never needed to know that. My client was very happy with the result. From their perspective, their project had been modernized, but I still finished everything on budget and on time.

In 1998, when I was seventeen, I had my first job at a movie theatre. On my break, I would fantasize about starting a web design company. I wondered if I could charge $10 per page. Maybe that was too much to ask?

In 2001, when I was twenty, I got my first real programming summer job while attending the University of Waterloo. I learned ColdFusion and web development. I got to design and build an entire Content Management System. I even spoke at a couple conferences and was published in ColdFusion Developers Journal. I loved this world and knew that this was exactly where I wanted to be.

The first pivot

As much as I loved coding, I saw my bosses spend their time in meetings and writing emails, and I felt like they were superior to me somehow. In 2005, at twenty-four, I moved to Berlin, started this blog, and bought Consulting for Dummies. I wondered if maybe consulting work would be a step up the success ladder. I started freelancing, and everyone only wanted to pay me for coding. Since that's what I loved to do most, I didn't complain. I unpivoted, and thought I'd revisit the consulting idea another time.

The second pivot

My freelancing business grew, and I had to say "no" to a lot of people. Then I read "The E-Myth" and Peter Drucker, and decided my company needed to grow. At some point I had a dozen developers working for me, and even hired a Project Manager or two. I was able to say "yes" to everyone. I had pivoted to growing an agency, moving closer to this idea of success I kept reading about.

Then it stopped being fun. I would start off chatting with a new client, but turn it over to a PM when it started to get interesting. I was juggling so many projects in my mind, I barely had time or energy to do any coding. It felt like driving a car from the backseat.

One time, I had a developer stop answering emails, and had to jump in to save the project. I read through weeks of emails back and forth between the frustrated client, the project manager and the overwhelmed developer. The project became clear in my mind and I quickly built exactly what the client wanted in a weekend. I was back in the driver's seat, working directly with my client to build a web app.

I decided to unpivot. I stopped hiring. I sent my developers off to work with some of my clients directly. I wound it all down until it was just me building for a few good clients. I was back on the path again.

The third pivot

I'd always wanted to be a teacher. I was thrilled when my friend invited me to teach a programming course at Georgian College. I poured myself into teaching and loved everything about it. Even though I was teaching part time, all the prep work and marking really cut into my freelance work, and my income. At the end of the term, I asked my wife to remind me that I should probably say "no" next time.

Of course, I didn't say "no", because I was thrilled all over again the next time I was asked. And the next time. And the next time. I taught a half dozen classes over the next years, and absolutely loved helping students. I loved thinking about how to explain programming concepts to my students.

But I was spending so much time creating assignments and tests, and marking the students just to give them an arbitrary grade. I loved teaching, but I was never passionate about the college system. I decided it wasn't worth it anymore and unpivoted again.

The fourth pivot

The teaching itch never left me, so I decided to start teaching online. That way I could help students directly without all the tests and marking. I started making YouTube videos, streaming on Twitch, and even developed and launched a video course, The Joy of Svelte. I started a newsletter and imagined this as the start of a series of courses.

Making a course took a lot more time and energy than I expected. It was also missing something from teaching students directly in the classroom. I was procrastinating my course development and spending all my time coding for clients. I felt bad about this, like I was stuck in a rut. Eventually, I realized I wasn't stuck at all. I was doing the thing I loved the most, helping people directly.

I stopped feeling bad about it, and let go of pressuring myself to be a course creator. I had unpivoted back to focusing on the thing I love the most, working directly with clients to build web apps.

The fifth pivot

I was watching YouTube videos and listening to podcasts about business. They talked about "hands-on" work as being undesirable. These motivational speakers made me feel bad for wasting my limited time coding when I could be helping more people with my knowledge and experience. They convinced me the only way forward would be to pivot away from coding and to focus on being a coach & consultant.

I put on a blazer, had business cards made, and attended a tech conference. I told everyone I was like a "personal trainer for developers". I had this vision of using my experience and teaching skills to help development teams.

Every time I worked with a team to coach them on how to build or fix things, I ended up just building prototypes for them. I found it way easier, and frankly more fun, to build things instead of just telling people how to do it themselves.

I realized the best way to help people was the way I always had, by building things for them directly.

Learning by experimenting

I learned that I crave challenge and novelty. With each pivot, I followed my curiosity, or my insecurities, and tried out something new. Even when it didn't work, I learned something new about myself.

Each time, I'm glad I only experimented by dipping a toe in the water and never dove in completely. I'm grateful for those clients that stuck with me from the beginning, some of whom I'm still working with to this day.

Having gone through this cycle so many times, it's now comically clear that I've always done exactly what I should be doing. I'm a Web Developer, I build web apps for my clients, and I've been doing it non-stop since 2001.

I've stopped looking for greener pastures, and can now see how wonderful things are right now. I don't need anything different. I get to do even more of what I love, what I've always loved.

At least until the next pivot comes along.

The great thing about the web is that web pages from thirty years ago still work fine. So you can imagine how surprised I was when a new version of Chrome broke my client's web app in production.

Business as usual

The web app is a data visualization tool with a colourful d3 SVG map. Hovering over a country brings up a tooltip, and clicking a country brings up a larger panel with data. Although the application was originally developed in 2013, I took it over in 2022.

I was working on some changes to the web app a couple of weeks ago. I run Linux (Arch btw) so I always have the latest version of everything, including Chrome. I spun up the development site one day and suddenly the map tooltips and clicking stopped working.

Did I install something new that broke the interactions? Maybe one of my Chrome extensions was messing with something? I tried rebooting, as one does when they're out of ideas. Still didn't work.

I loaded up Firefox. Everything worked fine. I grabbed my mac and tested it out in Chrome. Everything worked fine there too. I sent off my changes for the day for my client to review, and they didn't say anything about it being broken.

I could have left it at that, but it didn't sit right with me. That evening I started digging into it more.

Classically debugging a hard bug

First thing I did was add console.log statements to the d3 event handlers.

I could see that the mouseenter and mouseleave events were working, but the mousemove and click handlers never fired. I tried remove the mouseenter and mouseleave handlers, and suddenly the mousemove and click started working again.

I put back the mouseenter and mouseleave and looked for something that could have been responsible. Then I found this suspicious line:

// bring it to the front and maintain full stroke
path.parentNode.appendChild(path);

I removed it and it started working again! But that line was written six years ago, before I ever worked on the app. Why would that be to blame? What changed?

It Is Never a Compiler Bug

There's a trope in programming that "it's never a compiler bug". As a web developer, we would say "it's never a browser bug". Well could it be this time?

I was running Chrome v144 so I found the release notes. It came out on January 13th, so the timing made sense.

I scrolled and skimmed and finally found something that sounded like it might be relevant:

Interoperable pointer and mouse boundary events after DOM changes

After an event target is removed from the DOM, the logical target of the pointer, as implied by the Pointer and Mouse boundary events (that is, over, out, enter, and leave events), should be the nearest ancestor still attached to the DOM.

This led me to find a bug filed for Chromium v144, Regression in Chrome 144: Moving event target in "mouseenter" handler breaks click+mouseleave events. It was a Chrome bug! The example code even matched mine almost exactly:

redSquare.parentNode.appendChild(redSquare);

It seems like this is a permanent change due to a refinement of the spec. It's apparently a feature-not-a-bug, called BoundaryEventDispatchTracksNodeRemoval, so it's probably never going to be fixed.

There's fortunately a suggestion in a comment of how to fix this on my end though:

if (elem.parentNode.lastChild !== elem) {
    elem.parentNode.appendChild(elem);
}

Makes total sense! I made the change, and everything was working just as it had been a couple of weeks earlier!

Always trust your gut

I'm going to resist blaming the browser next time I have a bug, but it's very interesting to be reminded that it can and does happen.

The important takeaway is that when I see something wrong on a client project, I'm not going to be able to rest until I figure out exactly why. I needed to be sure it was limited to my computer, because if it wasn't, the last thing I'd want is for my client to find out from one of their users.

I of course pushed the change that night and let my client know what had happened, and that the production site was already being affected. Fortunately, v144 hadn't been fully rolled out. Even as I write this, less than 4% of users are running v144. This also underscores the importance of developers testing using the newest versions.

As a developer, I always want to fix bugs before my client notices, and definitely before their users notice.

You know what I do love? I love pouring my creativity and insight and empathy into a project. I love designing architectures and solutions that actually make things better for users. I love getting in the flow state, cranking away at a problem, building brick upon brick until the creation comes to life.

If you're not careful, AI tools will have you spending all your time doing code review. It's very hard to get into a flow state when you're waiting on your agents and reviewing what they do. Fortunately, I've found a way to use LLMs to do a lot more of what I love.

Curiosity and excitement

Since I was a child, I wondered how it was possible that humans were able to get a computer to do so many things. It felt like magic, and I wanted to be that magician. Forty years later, that feeling still guides me through my software development career.

While LLMs stir that curiosity and excitement, they also threaten to take it away. If, like me, you have very mixed feelings about it all, you might be both excited and worried about the potential.

I've found LLMs to be very helpful ever since Copilot came out in 2021, and they have definitely made me more productive. My views on coding with LLMs haven't changed much along the way. Five years later, I wanted to share with you how I'm using LLMs today, and how they're making my job more fun than ever.

A workflow that lets you work in flow

The secret is to find a workflow that works for you, that keeps you engaged and in a state of flow. I've found the following workflow that works really well for me. I use it every day for almost every multi-step coding task I work on. It basically starts with the following context:

When the user gives you a task specification:

1. Explore the codebase to find relevant files and patterns
2. Break the task into a small number of steps. Each step should include:
    a. a brief, high-level summary of the step
    b. a list of specific, relevant files
    c. quotes from the specification to be specific about what each step is for
3. Present the steps and get out of the way.

When the user says "done", "how's this", etc.:

1. Run git status and git diff to see what they changed
2. Review the changes and identify any potential problems
3. Compare changes against the steps and identify which steps are complete
4. Present a revised set of steps and get out of the user's way.

Important:
- Be concise and direct, don't give the user a lot to read
- Allow the user to make all technical, architectural and engineering decisions
- Present possible solutions but don't make any assumptions
- Don't write code - just guide
- Be specific about files and line numbers
- Trust them to figure it out

You can paste this in a new chat, or set up a "custom agent" or "skill" if you want to be fancy. I use a Claude Code skill for this, but it'll work with any LLM coding tools. Ideally it'll have access to your codebase and can work as a search engine to point you in the right place. I find this really speeds me up, especially on new codebases, or code I haven't touched in a long time.

With this workflow, I'm not spending hardly any time waiting on the LLM to generate content. I find this approach uses the LLM for what it does best. Hallucinations are almost non-existent, because everything it needs is available in the present context. There's very little sycophancy, and not much back-and-forth chatting at all.

I specifically don't want to be reading through pages of markdown. If it makes a mistake at a high-level, I can easily spot and correct it, or just choose to do something different.

Often I'll still decide to ask the LLM to write code for me, but I keep it limited to a small step in this process at a time. I sometimes have it scaffold out some empty modules for me while I work on a different step. Often the steps are very simple or mechanical, so it's actually easier to have the LLM complete it for me. I'll use it where LLM-generated code can speed me up, where I'm not wasting time babysitting or directing it to do better. I'm in full control of choosing which parts I want to work on, and which I don't. Either way, I'm staying fully engaged, and I know what's happening at any given moment. It's like wearing a jetpack that I'm steering, rather than a team of minions that I have to manage.

This workflow is easy to modify. You can change it to suit your preferences, and add rules that make it work better for you. You can do less of the coding if you want, or even use it as a planning step in your vibe coding.

It's also dead simple to understand, with nothing special you have to learn. You're not messing around with prompt engineering. There are no MCP servers to install, no special plugins. It works with all models, even cheap or local models. You don't have to keep up with the latest techbro videos to make a workflow that works for you.

Find your own workflow

I invite you to find a workflow that empowers you to do your best work while staying out of your way. Stay more engaged, lose track of time, reduce friction, solve problems and do your best work.

Please share what works for you, and if you have any suggestions to make coding with LLMs even more fun. I hope we can all learn from and inspire each other to make coding more fun than ever.

I'm also careful not to over-commit. I leave myself room to breathe. If I decide to go beyond that and work extra, everyone's happy. If I don't, that's okay too.

My day is a blank canvas. I get to decide how I'll fill it. What am I most curious or excited about? What do I want to work on, if anything?

Being able to set your own hours as a freelancer doesn't mean choosing 8-4 vs 10-6. It's being free to take a day off to play with your kids or finish an exciting book. It means being able to live the cozy life you need for a healthy body and mind.

Ultimately it means my work is higher quality because I'm not rushing, I'm well rested, and I love the work I do.

A weekly cadence won't work for all clients, nor for all freelancers, but it suits me and my clients perfectly.

I just dropped my son off at school, and now I feel it's time to start a new season of focusing on my business again.

But I feel the need to bring that coziness back into my professional life and find ways to do bigger things while still being restful and relaxed.

It'll be a big challenge, but it's very important to me to get this right.

I don't want to hustle. I'm not desperate to be more successful. What I desire is more creativity, more freedom, more fun, following my curiosity and joy and excitement through my work. I want to help more people, particularly freelancers like myself. I want to go beyond my client work and work on projects for myself.

In the past it's been hard to juggle that stuff with my need to trade hours for money. That's where the challenge comes in, to do more but to keep it fun and cozy and stress free.

I think I've come to see how lowering expectations for myself really helps to take the pressure off. I'm hoping to thread that needle of doing more in some areas, maybe doing less in others to compensate, and being very mindful and measured in making sure I'm able to handle it all gracefully.

I barely pulled it all off thanks to my wife's support. When the project was delivered and the course ended, I desperately desired something different.

I desired rest, comfort and relaxation. I desired simplicity. I desired peace and quiet. I desired being fully present with my family.

What I really desired was a different quality of life, one that I'd only experience on holiday. I wanted to wake up with a clear and quiet mind, to hear the birds chirping and the breeze in the trees instead of worried thoughts. I wanted to move slowly, with all the time in the world.

I've always set ambitious goals for myself. I feel like I've been going as fast as I could for years. For the first time, I had a different goal: to live a cozy life.

Sure, I had major constraints: we had a new baby, an older son, and I still needed to do freelance work.

I didn't have to work on any side projects, though. I could let my blog and newsletter go quiet for a while. I could say no to filling up my calendar. I could stop making To Do lists and allow myself to do a lot less.

I had to remind myself that the bare minimum is, by definition, good enough. As long as my family was taken care of, as long as I was making enough money to cover our expenses, I was doing okay.

Within days I was daydreaming about new big projects I could start. I had ideas for courses I wanted to launch, books I wanted to write. I had to learn to say "no" to myself too.

After a week or two, I started to get really bored for the first time in a long time. I decided to limit myself to low-stakes activities, things that didn't matter if I did them or not. I was happy to read books, especially books that I started long ago but never finished. I enjoyed playing video games, and I even finished the original NES Final Fantasy I'd started 30 years ago!

I started getting excited about programming again, and I found myself watching videos and reading about web development. I was enjoying work more too, because I wasn't stressed out or in a rush, and I was able to enjoy the interesting challenges.

Every day that went by, I felt myself recharging. It felt like I was unlocking new levels of rest, new mental states I hadn't had access to in a long time. The less that I did, the more I could do.

I had the cozy life I wished for, and I finally had room to breathe.

I was already dreaming of starting my own business before I ever got my first job. My very first job was at a movie theatre in the late twentieth century. In my breaks I would brainstorm ideas for starting a web design business. I would fantasize about proposing to redesign the movie theatre's website. When the boss wasn't looking, I would sketch out my web site and my pricing on scraps of paper.

Later, I got my first programming job, working on a content management system. I learned a lot about business at that job. The company would always be bringing in new clients. Even then, I would fantasize about being able to have my own clients one day. I would read books about self-employment and consulting. I'd read anti-work websites and dream of getting out of the rat race.

A few years later, I met my future wife and moved to Berlin, Germany to live with her. I had the best excuse for quitting my job back home, and saw it as a chance to start my own business. Almost exactly twenty years ago, I registered a business name, "The Future of the Web", bought thefutureoftheweb.com, and started blogging about web development.

Unfortunately, I had only three months to find a job in Berlin before my tourist visa would expire. I went to an Internet cafe every day and applied to 3+ job postings, hoping my Java experience would make up for my inability to speak German. Extremely luckily, I was hired by Strato Rechenzentrum, a major Internet hosting company. When I received my work visa, I was surprised to see that it had two conditions: I was approved to work at Strato, but I was also permitted to do freelance work ("freiberuflich arbeiten").

While at Strato, I continued to fantasize about breaking free of employment and working on my own terms. I would read every article I could about self-employment or freelancing. I would listen to audiobooks and podcasts, and just surrounded myself with content that inspired and motivated me.

One day, I got up the courage to tell my manager about my work visa condition, and to ask whether Strato would allow me to do freelance work on evenings and weekends. My manager saw no issue with it, and he verified this with HR. I was given the green light to go ahead.

I had already been blogging about web development for a little while, so I updated my blog to make it clear I was available for hire. I published "Hire an Ajax Freelancer" to boldly announce that I was available to take on some JavaScript and Ajax work.

A month later, someone found me and asked me to do a small UI thing. I charged $100/hour, worked for three hours, and billed the person $300. He paid me on PayPal a few hours later. It was the best feeling in the world!

I continued doing work for this person, and the next month someone else contacted me for a small job. I was soon making $500-1000/month in my free time, on top of my full-time salary work at Strato. It was tiring, but I was so highly motivated and inspired, I knew that I had to push through to make it to achieve my dream.

When my then-girlfriend finished school, she wanted to take six months off and live in my hometown in Canada. I quit my job at Strato and announced I was Freelancing Fulltime This was the ultimate test: could I survive off of freelancing alone? If it failed, I felt like I would be able to go and find another job, but I was hoping it wouldn't come to that.

I put the word out privately among friends, and my friend's uncle hired me for a much larger project. I continued blogging regularly to try to promote myself by sharing my expertise. I was fortunate to have people contact me for new projects every few weeks. Two months in, I published Freelancing: First two months. I was approved to speak about Unobtrusive Ajax at The Ajax Experience conference in Boston, and got to meet my idols like John Resig and Douglas Crockford. Eight months in, I published Freelancing: First eight months.

It was a wild experience, and the momentum was growing. It was in the following months that I found three clients in particular that I would continue working with for years. Two of them are still my active clients that I'm working for this very moment.

Do you also dream about leaving your job and starting on a similar path? There are a lot of things you can do right now, while you're still working in a full-time job:

1. Be clear about your goals, and visualise the life you want to live.
2. Surround yourself with content that inspires you and reminds you of moving towards your goals. These could be books, social media accounts, YouTube channels, podcasts, etc.
3. Start putting out content that demonstrates your knowledge and expertise. Share everything you learn. Share resources and tips. You could start a blog, a professional social media presence, a mailing list, a podcast, or whatever you feel inspired and motivated to do.
4. Start a business. Depending on where you live, you'll need to register a business name, have a lawyer give advice and help draft a standard client contract, learn about taxes from an accountant, and probably purchase extra business insurance.
5. Find out if your employer allows you to freelance on evenings and weekends.
6. If so, put out the word on social media, and put the word out amongst friends and families so they know what you're looking for.

Worst case scenario, you get to learn whether or not self-employment is really something for you, and hopefully get to earn some extra money on the side. Best case scenario, you'll be laying down the foundation of your new business and a path to freedom! I'm very excited for you and wish you all the best of luck! If you choose to go on this journey, please let me know and keep me updated!

Dear Recruiter,

Thank you for contacting me, but unfortunately I am not interested in a full-time job. There is no way in hell you'll find me in an office nine-to-five Monday-to-Friday. I've been there, done that, and it was a living nightmare.

No, you don't need to circle back in three months to see if my situation has changed. I'm not available for employment, and I never will be.

Yes, I understand that the position offers benefits. My position offers many more benefits. I can work whenever I want, wherever I want, and for whomever I want. I can have a two-hour nap in the middle of the afternoon if I want to. I can go out with my wife for three hours on a random morning. I can pick up my children from school and go to a playground.

You think it's cool that you have a daily standup meeting at 10am? I haven't had a meeting in months. I have nothing work-related in my calendar at all. I talk to my clients over email. Sometimes I ask them for a phone call, and I'm always happy to hear their voices. They leave me alone to do my best work and they never give me deadlines. They have no expectations for me on any given day. They trust that I'll make good, steady progress every week. They know that in an emergency, I'll drop everything to help them.

Your company is offering a competitive salary? I make more than that working part-time. I raise my rates every few years and simply let my clients know. Sometimes they choose to stop working with me, which is sad. But it's okay because I have other clients who happily pay more. It's not as tragic as your upcoming layoffs would have been.

Your company has management opportunities? Sounds terrible. I work one-on-one with business owners who I've worked with for decades. We trust each other and have become good friends. I understand what they want and need, and the trade-offs they're willing to make. There's no game of telephone trying to guess what upper management wants. No waiting for approval from board meetings. No politics at all.

Your company will pay for me to move to another city? You must be joking. I work from my home, and I always will. Well, sometimes I choose to work on an airplane, or in a waiting room, or in a coffee shop. One place you'll never find me is at a desk in an office building.

So no, I'll never be interested in joining your growing team. I'm in a very happy long-term relationship with my clients. There's no way I'm going to leave them high-and-dry to become a cog in your machine.

I wish you good luck on your search. And I wish all the best to whomever you manage to enslave.

Sincerely,
Jesse Skinner
Freelance Web Developer

When a client asks me to make a change to a website, I have two choices. I can go and make the change. Or, I can set things up so that the client can make the change themselves.

It's not always obvious which of these two will be a better use of my time. If it's a one-time change that will never need to happen again, of course it's better if I go make the change. But sometimes it's obviously something that will need to be changed again and again.

Sometimes the change is so small that it's a quick copy & paste, so there's almost no benefit to adding a content management system. Often, the changes can be more complex, and require a lot of back-and-forth communication, asking for clarification, testing, reviewing, etc. I have a pretty low tolerance for this before I insist on building a tool for my client instead.

Pretty much every system should have some kind of administrative login area, where the client can go in and access these admin-only tools. It might be as complex as a content management system, where they can create whole new pages, and change all the text in the system. It might be where they manage other users, or get the answers to questions they might have otherwise asked me for.

In one case, I had built a system that had a complex set of rules, basically if/then statements, and it was evolving rapidly. Every week I was being asked to make changes to the logic, and also asked to remind the client about what it was already doing. So, in a few days, I designed and developed a Domain-Specific Language (DSL) that allowed all of the logic to be captured in a single text file. It wasn't a programming language, because my client isn't a programmer. Rather, I designed it to be intuitive for him, so it would be easy for him to read, edit and publish changes to the logic in the system. Many years later, he is still actively working with this same DSL.

I have another client who is more technical, and has some experience with basic HTML and CSS. They wanted to make broad changes to the design of the site, and to the text that was hardcoded throughout. I gave them two options: either they could provide me with a long list of these changes, or I could bring them in to collaborate on the code. They had no experience with git, GitHub, Svelte, or even with using an IDE. I thought it was worth a try, so I sent them a long list of instructions for installing all the software they'd need. I sent them a few YouTube videos about using VS Code with Git, and had them create a GitHub account. I explained how the site was architected, and the basics of Svelte components.

Within a week, they were making changes to CSS and text and committing and pushing changes to GitHub! It was so exciting! Just looking at the long git diff, there were literally hundreds of changes. If they had tried to write out those changes in a Google doc, it would have required dozens of screenshots. It honestly would have been painful for me to carefully go through and implement all of the tiny changes. And chances are, I would have screwed up more than once, and they would have had to make new screenshots. They would've felt like a bother to ask me to increase the font size by 5%, or change a border to a different shade of grey. More than likely, they would have just accepted my poor attempt as "good enough" and said thanks.

Instead, they are now empowered to go in and make changes themselves whenever they want. As the site evolves, over the coming decade, they'll have the confidence to go in and make all the updates they need. They were even able to use AI to generate a snippet of Svelte code in order to add a second button to the page!

No, I'm not worried about my job going away. I'm happy to be focusing on the hard things, and empower my clients to do as much as they can on their own. They are delighted to not have to "bother me" for small changes when I'm working on bigger features for them. They're able to save money and time. It's truly a win-win.

Another client had a very complex system that was built by a third-party vendor and written in Python. They brought me in to help simplify the system. In this case, they actually did have developers on the team, but the developers didn't have much Python experience. I actually rewrote the entire system in TypeScript. It was a fantastic opportunity to clean things up and simplify. I wrote it in a way that it would be intuitive to them, so the training only took an hour or two. I was delighted to see the developers confidently making changes to the system themselves for the first time ever, and with ease.

A Chinese proverb says, "Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime." I say, "Make a change for a client, they'll be happy for a day. Empower your clients to make changes themselves, they'll be happy for a lifetime."