Tell me if this sounds familiar. You get a project idea that you’re excited about, create a new GitHub repository, and dive headfirst into coding. Instead of coming away with your new pride and joy, you end up with just another repo in your archive. Well, this has happened to me too, too many times! 

With my university projects, I could always produce a good piece of work. But university projects didn’t teach me how to see a project through to the end. The impending deadline was enough to get the project past the finish line. However, sticking with a project without that deadline stressor is an entirely different challenge. My internship project taught me how to rise to that challenge.

Dig into the ‘why?’

A key factor in staying motivated is clearly understanding why you are working on your project. Although personal curiosity is a good starting point, knowing the value of your project will keep your momentum going in the long run. 

With that in mind, here’s a rundown of my internship project. My ultimate goal was to help the marketing team with attracting more customers to join FreeAgent by revamping how we give first-time users introductory deals, such as discounted subscriptions for their first few months. 

When you are building something for someone to use, you want it to be good quality. I made a point of reaching out to the marketing team with questions to ensure that what I was going to build would be useful for them. The better you understand the benefits your project will bring, the easier it is to stay motivated and bring the project to new heights. 

Create building blocks with user stories 

Once you know your intentions for a project, you need somewhere to offload your ideas from your mind. Otherwise, when coming back to a project after a break, resuming work could feel daunting when you lack an organised plan. User stories are a powerful tool in solving this very issue.

User stories help you translate your unformed idea into small, manageable steps that will deliver value one stage at a time. User stories are typically broken down into two parts: the ‘why?’ and the ‘how?’. The ‘why?’ section is where you describe why implementing this feature will matter to users. The ‘how?’ is your acceptance criteria. The acceptance criteria will explain how you will know when you’ve reached your goals and delivered value to users.

I found that user stories are a great way to achieve more frequent wins. If you try to tackle all the user requirements in one go, every setback will be a big hit to your productivity and motivation. By using short and sweet user stories, each task you tick off will give you that dopamine hit to keep going.

User stories also let you develop a Minimum Viable Product (MVP). MVPs are extremely useful for distinguishing which features need to exist now, and which can be built later. By dividing my user stories into incremental phases, I got the best of both worlds. As I have limited time as an intern, it’s reassuring to have future phases planned out for someone else to iterate on. This gives me confidence that my brainstorming has been valuable, but also that I will have a solution to show after my internship.

Getting your hands dirty: code spikes and prototyping

While planning is important, you don’t really know how things are going to work until you start coding. This is the purpose of doing code spikes. A code spike gives you a playground to explore your codebase, tackle uncertainty and refine your plan within an arranged timeframe. I often start working on a code spike by aiming to implement a user story. When I run into a problem, I revisit the user story and decide if it’s a problem that’s vital to solve, or if spinning off a new user story would work better. The off-the-cuff nature of code spikes lets me work out the code and iterate towards a more solid solution. Unexpected scope creeps don’t leave me blocked as I know that I can return to my user stories and adapt. 

Code spikes also keep your users involved when you use them as a space for prototyping. Code spikes give you the freedom to Frankenstein together your code and get a picture of what the project will look like. Even if you are the only end user engaging with a prototype, seeing your project being functional helps to gauge your feelings on how your work is shaping out. 

I used a code spike to mock up a user interface (UI) for introductory offers and sent screenshots to the marketing team for feedback. Making the UI through a code spike instead of a mockup meant that, not only could I give the marketing team something to look at, but I could also have code to look back on to see how I built the UI. Visuals help users realise what they want, and the prototype helped me understand the marketing team’s needs through what I coded. 

The magic formula? 

Failing to plan is planning to fail. So, next time I start a personal project, I’ll put my experiences into practice. This means mapping out my ideas and breaking them down into small, manageable steps to stop the project from getting too overwhelming. Keeping that plan in mind, I’ll use that hands-on exploration with code spikes and prototypes to help me continually refine my vision for the project.

The most important thing for me to remember for my next personal project is the reason I started the project: you start projects to improve your or other people’s lives and make their day-to-day a little better. Adding value to the world is a skill worth developing.