Five Rules For Your First Personal Project
Hi all,
Tackling your first coding project with some real size can be daunting. Making the leap from coding small throwaway assignments (or just learning how to code in the first place) will teach you a lot - and reading this post can’t replace the importance of actually building something. My hope is that sharing a few notes can make the process a bit easier, less stressful, and more rewarding.
This post is geared primarily toward developers who are tackling their first personal project, but the lessons here also apply to developers with significantly more experience. Including me - sometimes I still need a reminder about what I should/shouldn’t be doing 😉
Think Before You Code
This sounds incredibly obvious, but if I’m being honest - I can’t imagine I’m the only one guilty of this…
You get a great idea, and within five minutes you’ve started hacking away on a new project. That’s great! But when it comes to building something bigger, a little bit of thinking now can save you a lot of time later.
Depending on what you’re building, this process is going to look different, but here’s a few examples of things you might want to brainstorm:
Who is the target user of what I’m building? Is this just for me, or for someone else?
What kind of tech stack makes sense for this type of app?
Does this project have a user interface? If so, what kind?
What’s the core functionality that makes this project usable and useful?
What kinds of design patterns make sense for what I’m trying to build?
Are there any third-party services that I need to hook into to make this work?
…etc.
Especially for your first project, you probably don’t need to overthink things - but one thing you will want to think about is how not to code yourself into a corner. This is incredibly common when you jump in without thinking through a problem first - and it generally results in one of the following outcomes:
You hit a wall…and need to rewrite a bunch of code (wasting a lot of time)
You hit a wall…and have to do a lot of unnatural things to get around it (fragile/messy code)
You hit a wall…and give up.
My first project involved a lot of unnatural things to work around issues. In hindsight, this was primarily due to a lack of knowledge about iOS development, but it was also a testament to my decision to jump in without really thinking through the experience.
Even if you’re careful, there’s a good chance you’ll still hit some walls - it’s just part of the process of learning to write software. Solving problems is a huge skill, and resist the temptation to give up when it gets tough - you’ll learn a lot more that way, and you’ll be one step closer to finishing your first personal project.
Pick a reasonable scope
Especially for your first few projects, it’s important to limit your scope to something you can actually finish. It’s tempting to jump straight into a complicated project - the hard ideas are typically the ones that sound the most exciting - but taking on something that requires too steep of a learning curve is a recipe for getting frustrated and giving up before you can see results.
The first “real” project I ever built was a simple math app for kids. I had done worksheets when I was growing up to learn my math facts, and I created a level-based way to do randomly generated problems. If it wasn’t already obvious - it was a very simple app. But for someone who had virtually no experience with iOS development (and had only been coding for about a year), it was hard.
The truth is the original scope for the app was even smaller than that - my initial plan was to make an app that only supported adding, and later I built out the other operations when I realized it wouldn’t require too much extra effort. But because I had kept it simple, I was able to finish and publish it in a few months (and I even had people pay to download it!).
A few months is still a pretty long time for your first project - and if I’ve learned anything over the past 10 years of building personal projects, it’s that my projects that stretch out more than 6 months rarely get finished. Especially if you’re working (or a student) and this is something you do in your spare time, progress will be slow. Pick something small for your first project, get it to a “done” state (though “done” is often hard to define…there’s always more you could do), and pat yourself on the back for actually finishing a project. It’s easy to get started - but hard to make it to the end.
Use source control
It’s a lesson you only have to learn once for it to sink in, but in the hopes of saving you the pain of going through it - use source control!
Things like GitHub make it easy for beginners to get started with source control (for free). Checking in your code protects you from catastrophic losses of important parts of your project, but it also lets you do things like:
Collaborate more easily with branches and pull requests
Safely delete things that you might want later…but shouldn’t be leaving behind as stale code in the meantime
Track analytics about your repo
Run pipelines/tests/actions on your code every time you push changes
Realistically, almost any development job today will involve using source control, so it’s also a good idea to get some exposure to it before needing to use it in the field. I was fortunate enough to learn about source control very early in my development journey (I originally used Subversion before switching to Git), and I’ve used source control on every major personal project I’ve done over the past ~10 years.
Figure out the hardest pieces first
This is a lesson that I only learned in the past few years, but it’s something that I always remind myself of when I start a new project. It’s tempting to jump into the “fun stuff” - whether that’s designing a slick UI, wiring together different services, or anything else - but if there’s one key piece of your app that’s going to be really difficult and you’re not sure you’ll be able to do it…do that first.
The reasoning is that if you’re not able to get that one thing working, then the rest of the app falls apart (or you’ll need to do a hard pivot). If I’m building a tool that relies on me being able to extract data from a specific source, I should probably make sure I can actually get that data before I build anything else. Otherwise, if you can’t get it to work, you’re left with a bunch of supporting code that doesn’t really do anything.
For your first project, there might not be anything that falls into this category - there might be things that are challenging or new to you, but nothing that can’t be figured out with some help from Stack Overflow or your favorite AI assistant. Even if that’s the case, I’d still recommend that you start with the hard stuff first - it’s a good habit to practice for anything you build, and it’ll save you a lot of time on later projects when you first start poking around to see what’s feasible and what’s not.
Share it!
For some projects, secrecy makes sense - but building in public is a great way to learn, make connections, and get noticed by potential employers or collaborators. This might involve making your project open-source and allowing other people to work on the code, writing tweets or newsletters about what you’re building and learning, or just making your app available to download so other people can use your creation.
When I released my most recent app, I wrote a few blog posts about it here - it was my first time publishing an app in several years, and I had intentionally picked something small in scope so that I could finish it within a month. I’ve since started working on a new project and shared some details about the process of deciding what to build and establishing an MVP - I’ve learned a lot reading about how other developers build software, and writing about what I’m doing is my chance to contribute to that.
That’s it! There’s a lot more I could say - but this should be enough to get you going in the right direction for your first project, and you’ll learn the rest along the way. Now…go build something!