Jessie's Portfolio

Agile code, refactoring, and FOSS projects

2025-11-12T00:00:00Z

Developing 11tyCMS has taught me so much about the impact of agile code on productivity. In early alpha, the code was inconsistent and difficult to follow. There were many quirks, all causing frequent bugs, slowing down debugging and draining my energy. It was starting to put me off working on it.

tedt

I spent so much time in "MVP mode", I lost sight of the quality I was aiming for: adaptable code that worked with me, not against me. But, knowing I'm opening the source code soon motivated me to refactor. I wanted a code base that other developers could work with, without worrying they'd struggle to understand everything. A FOSS project can only be as good as the contributors you're lucky enough to have!

Knowing when to refactor

None of this is to say working toward an MVP is bad. On the contrary: as a kid, I used to start with achieving perfection, getting the perfect code... Thing is, this is literally impossible when you're starting from nothing. Worse yet? I never finished any projects. I got so obsessed with trying to create the perfect end product from zero that it froze me. You have no idea what the parameters of your problems are until you've got an MVP out the door. Once everything functions, you have a better idea what the scope of your variables, functions and files should be. At this point, you can think about rewriting what you've done to be more elegant, reusable and understandable.

There comes a stage after you've reached MVP where inspiration floods in for new features. You get excited, there's so many ideas. You get to work, let's implement that new feature! But you find that your code is a little inflexible and difficult to read. It's not impossible though, it just takes more effort. You spend a few hours implementing this new feature, maybe adding a few extra quirks to the code to make it work. The new feature works! The code could use a refactor. But time is short and it's a side FOSS project after all. A week goes by, you get busy with your job. You have less energy to work on your project now, the code's rigidity and quirks kinda puts you off. It feels like you're fighting with your code, and you just... Give up for a bit.

3 months pass, work has died down a little and it feels like you have more time and energy for your beloved FOSS project. So you fire up your IDE, and start working on yet another feature. You're really excited, there's so many ideas to work on! But then you realize what you left behind all those months ago: inflexible code that's difficult to read, with quirks bolted on top to implement the other features. It becomes clear: you can't implement these features until you've refactored the code. Not without wasting precious time and energy, which are already at a premium for side projects. It's at this point you start thinking about how you can refactor.

The power of refactoring

The problem with the refactoring phase is that... It depends on how late you left it. For many reasons, the MVP stage and all the quirks that come with it may have well overstayed its welcome. If your project is still small and there's not too many files and lines of code to change, its not too painful. But if its a bigger project? The devil you know starts looking very alluring. Particularly with all the friction involved with restructuring everything, and relearning your muscle memory to work with the refactor. Thankfully though, my relentless drive for writing maintainable and clear code makes it difficult to NOT do this early on.

A good example of this is my Electron project: 11tyCMS. It was a project I started on holiday, I rarely had the energy or time to work on it outside of work, as is often the case for many FOSS project maintainers. This also contributed to a vicious cycle. The time I can spend on it is very sporadic, and refactoring looked like such a huge task, it felt difficult to justify. But I hit a wall: there was that feature, one I literally couldn't implement unless I did some major refactoring. So I made a start... I began restructuring how I did IPC in my Electron app.

In Electron, your app is split in two: you have the "main process" and the "renderer". Main is where all the Node JS code is, the renderer is where the "browser" side of things are. IPC is the mechanism allowing the main process and the renderer to communicate with each other. So in 11tyCMS's case, this allows me to call NodeJS functions from my React code.

In Electron, you have to register every function if you wanted it exposed via IPC. You register it under a channel in the main process, and then you expose it to your renderer via the preload file. Each time you have to refer to your functions perfectly, with the correct channel name, and all the correct arguments (baring in mind that, in preload, you have to get the order right with event being the first argument). This made creating new functions a nightmare. I would frequently mess up the order of arguments, forget channel names. This meant constantly switching between different files to confirm I was getting things right, that there were no typos. This needed to change!

In the end? created a new file: functions.js . In here, I import all the files that have functions I want to expose to the renderer (you just need to export your functions in an object), and I pass them into an object called functionsByChannels each key being the name of the files I imported. Then, I have a for loop that checks for the names of each function in these imports: if it's name starts with an underscore, its a private function to be kept to the main process. Otherwise? put it in the exposedFunctions object that the functions file exports. In the end? I end up with an object that has consistent channel names based on the file names, along with the correct consistent function names and argument orders:

import files from './functions/files';
import site from './functions/site'

let exposedFunctions = {}

const exposeChannelFunction = (func, channelName) => {
    exposedFunctions[`${channelName}`] = func;
}

let functionsByChannels = {
    files,
    site
}

for (const channelParentName in functionsByChannels) {
    for(const childFuncKey in functionsByChannels[channelParentName]){
        if(childFuncKey.startsWith("_")){
            continue;
        }
        console.log("Registering ", childFuncKey, " under ", channelParentName)
        exposeChannelFunction(functionsByChannels[channelParentName][childFuncKey], `${channelParentName}:${childFuncKey}`)
    }
}
export default exposedFunctions

Now, in the main process, all I have to do is import the functions.js file, and register the functions to IPC:

for(const channelName in exopsedFunctions){
    ipcMain.handle(channelName, (handle, ...args)=>exopsedFunctions[channelName](...args));
}

Finally, we're now ready to expose these to the renderer:

let api = {}
for(const channelName in exposedFunctions){
  console.log('registering function', exposedFunctions[channelName].name, 'with channel', channelName)
  api[exposedFunctions[channelName].name] = (...args)=>ipcRenderer.invoke(channelName, ...args)
}
const registerApiFunction = (func, channelName)=>{
  api[func.name] = (...args)=>ipcRenderer.invoke(channelName, ...args)
  ipcMain.handle(channelName, func)
  contextBridge.exposeInMainWorld('api', api)
}

...

contextBridge.exposeInMainWorld('api', api)

And bam. Now all I need to do is call: window.api.functionName in my renderer, and I have what I need!

This tweak changed everything. Because now, all I needed to do was add a function to a file's export to have it exposed to the renderer, adding new features was WAY faster. Development picked up pace again, I had more energy to work on it, things took less time and it felt good to work with. With these energy gains, I had more motivation to do even more refactoring... So I implemented Zustand into the React side of the app.

Zustand is by far my favorite state management library for React. Its so lightweight and simple, but its impact is profound. No more drilling props through 5 different components, only to lose track of where they originated and getting weird bugs as a result. Just centralized store files for each type of data, each one integrating beautifully with this IPC system I've built up. Upon implementing this, the React side of things became joyful to work with. Everything feels so clean, and easy to work with now. If I have a problem with data? I'm not sifting through 10 different component files to find the culprit. Again, giving me even more energy and time to work on my project. So I began working on routing, which again, made it even better to work with.

Can you see the domino effect a well timed and placed refactor can have on a project? Especially for FOSS. When time and energy is so limited, you want a code base that works with you not against you. The easier it is to work on, the less energy it will take to work with. Better yet? New contributors will have a much easier time adding new features and donating their time for bug fixes. Everyone wins!

This isn't to say that the code I have now is perfect. Far from it, not even sure if that's possible! But there's one thing I'm sure of: the quality of my code base is no longer a barrier to adding new features, and I think that's a healthy sign of a good refactor.

What 3 years and 1000+ hours of mentoring taught me

2026-01-20T15:30:30Z

I started my tutoring business in 2020. The lockdowns were in full swing, lots of people were using the downtime to switch careers. This got me thinking: I should start a business teaching people to code. When I was 14, I taught my brother's friend who did web design at uni how to code. It was an awesome experience and taught me so much.

I started with a very diverse client base: a range of skill levels from total beginners to mid and senior developers who needed an extra brain to think with. It made me realise how many different skills are involved in mentoring (to name a few!):

Reducing complex problem solving into small steps, making them more approachable
Teaching with empathy and respect for the learner. Everyone has a different learning styles and experiences, so adapting your method to the person is key.
Walking your student through your thinking process, and teaching them to show theirs. This is 90% of teaching the core coding skill: problem solving.

What I learnt over my 1000+ hours of teaching

Working with each skill level taught me something new. I firmly believe that everyone from all backgrounds and skill levels has something to teach me, and this has proven it!

Teaching beginners

As a senior, you take your knowledge for granted: you understand variables, for loops and the difference between arrays and objects. Someone new? They know little to nothing. But, you get to teach them the fundamentals, and watch as their understanding grows. They start off overwhelmed, but as you help build their understanding, they take on more and start experimenting outside their comfort zone.

Teaching beginners makes you think about how you code and why. A beginner will look at 2 blocks of code that do the same thing, and ask why one approach over the other? You get to teach them to think about they differ, and why one might be better. Another way of doing this was by demonstrating a mistake, and getting them to point out what might be wrong with it, helping them grow their problem solving muscle.

Teaching people to walk through and spot problems, is building the skill central to coding: problem solving. My students have learnt so much from me by pointing out mistakes in my code, and walking me through why it won't behave the way it should. This has taught me the importance of showing colleagues that their contributions are important, because you never know what others will spot that you won't.

It's not just problem solving or debugging, either... It's the art of project management. How do you take an idea and turn it into code? How do you make it production ready? Some beginners get so trapped in perfectionism, that they don't start their passion project. I found success in helping them to develop an MVP, then figure out improvements! After all, the more projects someone can take on (and finish!) the faster their skills and confidence will build.

A lot of them also forget learning to learn! Learning is a poorly taught art, one that few schools teach their pupils. My first lessons involved teaching students evidence based studying techniques:

Work smarter, not harder: use the Pomodoro Technique, studying in 30 minute blocks. Rest well and let your brain digest what you've learnt.
Use the Feynman technique: explain what you're learning back to others in the simplest of terms to consolidate your learning.
Leverage spaced repetition! Revise what you've learnt in increasing gaps, take advantage of shallowing your forgetting curve.

Teaching beginners, I learnt that programming isn't just languages or syntax. They're irrelevant. What coding truly is, is problem solving, project management and communication skills. Beginners can get so caught up in syntax and learning the language, that they forget the true skills are all the above.

Teaching mid-level

Teaching mid-level developers is awesome. They understand fundamentals, now they're applying them autonomously. They just need support with implementation: what tools? How do we make it scaleable? Which infrastructure choices are best?

I love working with them on projects, and guiding them and suggesting different approaches. Seeing them figure out which ones are best for them and their project is an awesome sight, you're watching them build the experiences they need to build reliable solutions in realtime!

Working with mid levels showed me that: if your fundamentals aren't sound, you'll struggle to apply your skills to new challenges. It also opened my eyes to how we should teach developers about sustainability:

Are you going to understand this code in 2 weeks time? Can others understand it?
Is it performant?
Does it work reliably?
Is the code self documenting?

These are so important, often forgotten parts of the learning process. Because in my experience if you skip any of these, you end up stuck. Your bottleneck becomes the fact you're not writing readable code, or that its not self documenting.

Transferrable skills

All these experiences have enriched communication skills. It's driven me to show my thinking to a range of different skill levels and backgrounds, helping me describe my thought process in an accessible way.

It's also helped me learn about project management. I've helped so many students manage their projects from start to finish, even starting businesses with them!

It's taught me about common pitfalls: Working with so many developers has taught me to spot common mistakes that lead to vulnerabilities, and how to avoid them.

But most of all? It's taught me the importance of leading with empathy and patience. People don't like to feel incompetent, they don't like feeling frustrated, and so many have fraught education experiences. I've learnt to adopt a teaching style that I hope centers patience, kindness and curiosity. All essential qualities for fostering a good learning experience, ones I wish I had from my mentors growing up.

Conclusion

When I started tutoring, I thought it'd be a nice side gig, with supplemental income. But it turned into working with people from across the globe, from America, to Dubai. With a diverse range of skills and backgrounds, each having something to bring to the table.

I'm so grateful for these experiences. I'm so proud to have kickstarted careers and to have helped setup my student's startups in my time tutoring. Here's what a few of them had to say: