Like many software developers when I think about creating a side-hustle, or generating passive income, I often default to thinking about website contract work.

But how do you start building a client-base when the vast majority of your career has been spent building software behind closed doors? When your entire portfolio is locked behind NDA's or are parts of a much wider whole?

I honestly have no idea 🤷‍♂️

But I'm hoping creating and selling themes for popular blog-engines is a start. A way to provide value, to build a public portfolio and hopefully attract opportunities for bigger work.

So this mini-series will document my journey creating the theme for this site - and how I'll go about making it usable for others.

Project setup + developer environment

This site runs using the popular blog engine Ghost. Their ThemeStarter does a great job introducing the basic concepts of a ghost theme and their robust official documentation covers any missing gaps.

Throw in a brief guide from LayeredCraft on how to setup TailwindCSS and we have a basic development environment up and running in 15minutes.

Basic design

Going into this I knew this site was going to be a weird mix of my all previous attempts; a personal portfolio, a resume, a software development blog, a place to talk about my hobbies and even display my photography.

My own little corner of the internet to represent my whole self.

With such an over-complicated mission-statement I wanted the design to be as minimalist as possible. To focus readers on the content and let the theme fade into the background.

That left me with a few core requirements:

• As a portfolio - I wanted a two-panel layout on the home page to showcase both the site-content and who I as an individual
• As a software-development blog - I wanted posts to be able to support long-form articles with complicated nested headings
• As a hobby-blog - I wanted the theme to not feel too corporate or overpowering, as a lot of my writing won't be formal
• As a resume - it should be 'professional-enough' that I wouldn't feel awkward showing colleagues, clients or employers
• As a place to showcase my photography - I needed few (or no!) colours that would skew how photos were perceived.

Those requirements ultimately resulted in the minimalist card-based layout you see now.

• a) minimalist design without overbearing colours or typography
• b) two column layout on the home page that makes it clear this is a portfolio
• c) one-to-two column layout on posts to support both professional and casual content
• d) 'tag' pages to offer views for the different kinds of content
• e) photo gallery support

Next steps?

With the basic design up and running it's time to focus on making it usable by other people - a genuine 'MVP'.

After doing a little research on what Ghost themes have in common on Themeforest I put together this short-list of must haves:

• Responsive / Mobile Friendly
• Light/Dark Mode
• 404 Page
• Robust Recommendations / 'Read Next' section
• Optimised page load speed

And to keep this fun for myself I've added a few extra bells & whistles:

• Customisable type-face options
• Customisable 'read-next' sections (bottom of page vs sidebar)

Tune in next time as we make this theme ready for sale.

Introducing - inspiredcharactersheets.com. A relatively simple character sheet builder that;

• Helps players create custom character sheets from a set of common components and designs
• Auto-saves character info entered into the sheet so you can use it at the table
• Prefer the tangible feel of paper and pencil? Print your sheet straight from the browser

Or at least - that's the plan. I have most of the core sheet functionality operational and will be working on the designable components next.

Follow along as I finish building the application and build an active user-base.

Roadmap

• Basic auth [Done]
• Rudimentary pre-designed character sheet using common components [Done]
• Auto-save functionality so sheets can be used during gameplay [Done]
• Printable character sheets straight from the browser [Done]
• Sheet components can be added, remove and re-arranged [In Progress]
• Sheet components come with a variety of customisable styles (borders, colours, font etc) [To Do]
• Share a read-only version of your sheet with your DM and other players [To Do]

Creating a new character is one of my favourite parts of playing D&D. It's a fresh start, an opportunity to try something new, a time of limitless possibilities.

Except my actual character sheet always looks the same.

Why doesn't my elven sorcerer feel different to my halfling barbarian? Why do spell slots take up so much space when my warlock will never learn that many spells? Sure, I could design a custom sheet for each character, but who has the time (or talent) for that?

Introducing - inspiredcharactersheets.com. A relatively simple character sheet builder that;

• Helps players create custom character sheets from a set of common components and designs
• Auto-saves character info entered into the sheet so you can use it at the table
• Prefer the tangible feel of paper and pencil? Print your sheet straight from the browser

Or at least - that's the plan. I have most of the core sheet functionality operational and will be working on the designable components next.

Follow along as I finish building the application and build an active user-base.

Roadmap

• Basic auth [Done]
• Rudimentary pre-designed character sheet using common components [Done]
• Auto-save functionality so sheets can be used during gameplay [Done]
• Printable character sheets straight from the browser [Done]
• Sheet components can be added, remove and re-arranged [In Progress]
• Sheet components come with a variety of customisable styles (borders, colours, font etc) [To Do]
• Share a read-only version of your sheet with your DM and other players [To Do]

Legends of the last age speak of awe-inspiring Magic and Ancient Wizards who shaped the world as they willed. History has long-forgotten the cause of the Cataclysm that shattered magic, but whether by some arcane experiment gone wrong or the jealousy of the Gods, the magic of old is no more and we are left with nought but splinters.

With their powers gone the old empires fell, and with each splinter of magic recovered, a new kingdom rose to take their place.

In recent months the minor Ashwood Mercantile Company rediscovered the Lost Continent of Ellos. Once the seat of power for an ancient Magocracy it is now little more than monster-infested ruins and barrow fields. The Ashwood Company is funding an expedition to Ellos in hopes of scavenging some piece of Lost Magic and raising itself into prominence.

Whether it be the lure of ancient magic, the possibility of making a fortune, or the excitement of a new adventure, you are one of the desperate few who have signed on.

You board your ship and begin the months-long journey to Ellos.

Shattered Magic is a high-fantasy setting designed for the Genesys Roleplaying System.

Creating this setting was motivated by my desire to experiment with a sandbox style game, where the players are free to dictate the course of the adventure and where every action could have dramatic scenario-changing consequences.

The core idea of the setting comes from the idea of playing with a hard-magic system that breaks up the stereotypical 'Arcane' magic into smaller more thematic components. The magic systems initially available to the player characters is only a fraction of what they will eventually encounter.

Concept

The players are mercenaries who have signed up with a mercantile company that is seeking to plunder a recently rediscovered land.

The Lost Continent of Ellos is full of strange and wonderful magic that harkens back to the last age, as well as terrifying monstrosities that are the result of ancient magical experiments.

High-fantasy exploration with strange magic and lethal encounters. With a slice of settlement building between adventures to encourage players to focus on more than just killing monsters.

Aim

Protect the company's outpost, scout the surrounding countryside, and scavenge ancient ruins and tombs for Lost Magic.

Build up yourselves and the outpost and then explore further afield.

Tone

Action/Adventure, Fantasy Pulp, Mystery

Themes

Brave adventurers exploring a strange land. Weird and ancient magic twisting the surrounding environment and creatures. A fledgeling town on the absolute border of the wilderness struggling to survive.

Major Factions

The Ashwood Mercantile Company is a small-time shipping company that survives by delivering goods to hard to reach locations. Rumours have reached your ears that their shipments often miraculously avoid the usual bandits and riffraff.

You aren't quite sure how they found Ellos, but you are certain they intend to milk it for every piece of gold they can.

Major Locations

The First Outpost is a short journey inwards from where the Ashwood Company first made landfall. It serves as your home away from home and is currently the only safe location on Ellos.

It's little more than a lakeside inn, freshly named the Hunter's Alehouse, with a freshly planted garden. It will do until you have the chance to build something greater.

Major Personalities:

The Bursar Fendrel Wheatflow is your point of contact when you land at Ellos. Don't let his aged stature and balding head fool you, Fendrel is an experienced merchant and skilled administrator. He is in charge of the First Outpost and responsible for seeing it survive the year.

The Quartermaster, Gavin Hawe, is an enthusiastic young halfling who joined the expedition hoping to strike it rich. His curly auburn hair makes him easy to spot inside the Hunter's Alehouse as he ensures everyone is fed and watered, all whilst peddling his own wares.

Little is known about The Noble behind the Ashwood mercantile company and the expedition. You know they are based in the ancient City of Silver, and you can guess they have some skill in magic to find Ellos. You are thankful they aren't coming with you, better to keep the nobles and their games as far away from honest folk as possible.

Major Species Types:

Humans can be found in every known corner of the world, but have made their home in the Republic of Ondoriel. Once a collection of loose city-states connected by a maze of rivers and channels, the invention and proliferation of Hydromancy allowed the states to merge into the Republic.

The so-called demon-blooded Halea, from the Deserts of Heru, are a colourful and hardy bunch. They dress in bright robes dyed with clay taken from the enormous Sandworms that share their home. It was from these Sandworms that the Tribes of Heru rediscovered Geomancy and they have used it since to tame their dangerous home.

The Elves of the Unseen Forests are as mysterious as the wildlife that make up their home. Few outsiders are ever granted entry and they guard their borders jealously with tamed monstrous creatures brought into reality by their unique Summoning magic.

They say never get between a Halfling and their coin-purse, and this is never more true in the City of Silver. A bustling metropolis of nobles, merchants and scoundrels it is often considered the heart of commerce between the many races of the world. It was here, in an attempt to recover the magic of old, that Rune Magic was discovered.

Half-Elves call no single place home and instead are driven by their nature to journey from place-to-place in small troupes. Many believe it is this flighty nature that allowed these nomads to so easily intent Aeromancy.

The Dwarves of Nom Montrim are widely considered the best artisans and smiths to be found. It was the near-eruption of the volcano at the centre of the Montrim mountain range that forced them to re-invent Pyromancy, and they have used it ever-since to advance their craft far beyond the other nations.

Next Up

I intend to explore this setting in a series of articles that provide a mixture of setting detail and useful game mechanics. Next up will be a in-depth exploration of the races and careers available in Shattered Magic.

I've spent a lot of my adult life resonating with the idea of being a 'life-long learner' without actually putting anything into practice.

Whilst growing up I loved the process of learning. It was addicting, entertaining, and productive all at once.

But somewhere between finishing university, and diving straight into my first experience with professional burnout, I lost that joy. I still identified as a 'life-long learner' but I had stopped learning.

Fast forward a few years, and a whole heap of experience both good and bad, I suddenly found myself a member of a work bookclub reading through 'Atomic Habits' by James Clear. I loved the book, its lessons resonated with me, but again I didn't change my behaviour.

Years later I found myself trying to kick-start a regular gym habit, and whilst looking for something to drown out the physical effort, I stumbled across the Atomic Habits audiobook. I figured I would give it another shot but probably quickly default back to Spotify.

Except this time something was different.

The book didn't just resonate. It stayed with me throughout that workout, the next, and even the one after that. Its core idea - "every action you take is a vote for the person you wish to become" - sunk in more than it had before.

I went beyond just listening and started practising. If I wanted to be a 'life-long learner' I had to learn my whole life. Or more accurately - I had to learn every day.

If I wanted to be a 'gym rat', a writer, or anything else in the future, all I had to do was start voting for that identity with small daily actions. And through those actions author my own identity.

I had read those same words before but walked away without any genuine understanding. It was only upon re-reading them years later, as a different and (hopefully) wiser person, that they finally stuck with me.

So don't be afraid to revisit things you think you know. You never know when you might learn something amazing you missed the first time.

Throughout our careers as software engineers, it's tempting to jump straight to coding when starting a new project. This works fine when projects are small and uncomplicated, but as complexity increases we quickly find ourselves forgetting details and making mistakes.

Preparing even a simple project plan before starting development can help minimise these mistakes and ultimately save you and your team a lot of time.

These project plans don't just help you keep the technical details straight, they provide enormous value by:

• engaging your stakeholders and ensuring they understand why this work is important
• holding you accountable to resolving concrete real-world problems (and not just delivering software without purpose)
• providing a way to discuss the project with other engineering teams
• benefit and learn from others' experience

As a general rule of thumb - any time your work is "architecturally significant" it's worth preparing a concrete plan before you start active development.

Imagine a basic service architecture diagram and ask yourself; "will this project change any of the lines on this diagram?" If the answer is yes, then you need a plan.

How to Plan

Resist the temptation to try and plan your entire project upfront. Instead build up your plan steadily through talking with your stakeholders, your team and any other impacted teams.

The process outlined below is a rough guide on how I typically build up a project plan over time:

1. Start by describing the problem. Before you even begin thinking about possible solutions make sure you can clearly articulate what problem it is you are trying to solve.
   
   Validate this problem statement with your stakeholders before moving into solution territory. If you can't agree on what problem you are trying to solve - then it doesn't matter what you build as it won't actually resolve your users pain.
   
2. Brainstorm 2-3 solutions with your team and jot them down in rough dot-points. These should be super high-level descriptions and not dive too far into the detail on any individual solution.
   
3. Seek feedback on your solution ideas. This step is absolutely crucial and is really tempting to skip over. Before you spend huge amounts of time trying to write a perfect document spend some time sharing your ideas with anyone directly impacted by your project.
   
   This might mean another team that maintains a service you will integrate with. Or potentially a Lead/Principal Engineer in your domain. If your company has a Solutions Architect make use of them!
   
   The more people you get to challenge your ideas the stronger they will become. Throughout this process, you will find yourself coming to a firm decision on which solution works best.
   
4. Fill in the Details. Now that you have a reasonably concrete direction start filling in all the details on what you need to do. Stay reasonably high level and spend most of your time focused on the portions of your project which are the least well-understood or riskiest.
   
   You may choose to simultaneously perform 'tech spikes' to help you investigate specific technologies/problems that your team has not encountered before.
   
   You should continue to engage with your team and stakeholders as you go about developing this detail.
   
5. Seek Feedback again. At this point, you should have a solid project plan with a well-understood problem and a clearly defined solution. Validate the project plan as a whole with your stakeholders and any other interested parties.
   
   Proactively ask for feedback on the portions of the plan where you are the least confident.
   
6. Get Started!

A few useful tips to keep in mind as you go about following the process above:

• Share early and share often! The more feedback you get the better your plan is going to be.
• Don't polish your plan too early! Keep the document as rough dot points for as long as possible. Ask your peers to focus on reviewing content and not grammar/sentence structure.
• Adjust the complexity of your plan based on the complexity of your problem and solution.
• Don't over-plan specifics. If you find yourself talking about class relationships or database table structures you are probably being too specific.
• Diagrams diagrams diagrams. A simple service dependency diagram can save you 1,000 words trying to describe the same thing.

Most importantly:

• Don't hide in a corner for weeks preparing a perfectly polished document. That just makes it hard to accept feedback.

Plan Format

The structure below is the format I use for almost all of my projects. You can find a standalone version of this as a Notion template here.

Projects don't always need all sections. Feel empowered to remove headings (or add new ones) if they aren't appropriate for your project.

Problem

What problem or circumstance necessitates this project? Articulate the problem you are trying to solve, not the solution.

The less you talk about software, the more you talk about your end-users, the closer you are to understanding the real underlying issue.

You might also find it useful to include the following:

• Success Criteria: A list of measurable outcomes you can use to ensure you have successfully solved the problem.
• DACI (Driver/Approver/Contributor/Informed): A short list of people who care about the project and need to be involved.

Proposal

The core of the project plan and where most of the detail will reside. Whilst in brainstorming mode this is where you should dot-point out your initial solution ideas.

Proposal - Overview

Briefly outline your preferred solution in broad detail. This should be a very high-level description of what the solution will involve.

Include a service-architecture diagram that shows what the architecture will look like once the project is complete. If your architecture is complicated it can also be useful to include a 'before' diagram as well.

Proposal - Custom Headings

Depending on the project this is the part that is likely to vary the widest. Any part of your project that is particularly complicated, risky, or involves new technology likely deserves its own section.

Essentially - any part of your overview that is likely to get lots of questions should get expanded in one of these.

Here are a few common examples that would likely deserve their own section:

• We will be integrating with an external API
• Why we need this specific new database technology
• How we will migrate data from Service X to Service Z
• How we will safely deploy this without downtime
• We are using a brand-new caching strategy

If your project has relatively clear 'phases' that need to be done in sequence you might choose to use this section to define explicit project milestones.

Proposal - Infrastructure

Outline any infrastructure you need to deploy or modify. This isn’t about providing exhaustive detail - it’s about ensuring you have thought about the impact of your change.

Will your project change traffic patterns? Does the reliability of preexisting infrastructure meet your needs? What about performance?

Proposal - Impacted Services

Describe any impact you are going to have on nearby services (or teams). Will you need to integrate with other services (internal or external)? Will this project require work from other teams?

Cost

Estimate any additional costs that this project may incur. In particular, consider the cost of any new infrastructure or changes to traffic patterns.

Wrap up

And that's pretty much it. Remember - the point of a project document like this isn't to write some perfect project plan that captures all possible scenarios.

It's about helping you engage with your stakeholders, collaborating with other engineers to define a broad solution structure, and identifying the genuinely hard parts of your project.

Check out this notion template for a standalone version of the format above.

I thought it was initially going to be about infrastructure but that topic never held my interest long enough to make it worthwhile.

More recently I've been focused on what it means to be a minimalist - and what lessons we can learn from minimalism in our work lives. Going beyond that, I think I have found what I want to share.

Throughout our careers as engineers, we encounter the same problems over and over again. From small technical issues like broken pipelines, misconfigured CORs or poorly optimised DB queries. To the bigger problems like dealing with mountains of legacy services and rushed architectural thinking.

Even the really hard people and organisational problems tend to repeat. How do you motivate a team? How do you rebuild psychological safety after it's been destroyed? How do you articulate your strategy so business stakeholders don't just understand it but genuinely believe in it?

So that's what I want to talk about. All of the problems (big and small) I've encountered over my career, how I solved them, how I failed to solve them, and what I learnt along the way.

To remind myself. And to hopefully help you along your way.

When running games I am a huge fan of using maps. Even with games that aren't reliant on grid-based combat I find a map helps set the scene and ground the players in the world.

This works great if I am well prepared, but when players go off the rails I'm often left scrambling trying to pull together an encounter with nothing but a digital whiteboard.

InspiredBattlemaps.com is be my answer going forward.

It allows anyone to upload and share maps they have created, and provides an easy search experience for frantic GMs trying to find the perfect map mid-game.

To get things started I have been commissioning maps from artists and I'll be continuing that over the next few months. I hope to establish a community around the site where fellow game-masters and artists can share their latest projects.

If you have some maps you want to share please register and try it out!