Guide to Your First Software Project

What good is learning to code if you never use it to make a project? At what point are you even ready to start a project? What’s even possible to make?

Well, if you’ve learned even just the very basics of programming, you’re already ready! Taking on your first project is the best way to accelerate your skills as a programmer and developer.

While this is labelled as a “guide”, nothing can really guide you through your project step by step. The whole point of starting your own project is to charter new territory on your own. It’s time to let go of the safety net of assignments or tutorials and to make something from your imagination.

This post will serve only as a starting point. A gentle nudge to send your raft into the ocean blue. While I’m far from an experienced developer, having recently started my first medium-large project, I think I’ve learned a few lessons that are valuable enough to pass on. 😊

Do It On Your Own

While there’s certainly value in working as a team, your first project will probably be small enough to do entirely on your own. And it’s probably for the best, since you’ll get the most out of the learning experience if you complete everything yourself.

The point of the first project is to cut the umbilical cord to the hand-holding you might be used to as a beginner. So the experience of choosing, designing, and building something entirely open-ended alone is a valuable one.

Along the same idea, avoid (as much as you can) simply Googling answers to problems you could solve on your own. As a rule of thumb: try it on your own first, and if you’re absolutely stuck, StackOverflow is your friend.

Scope

The first thing you’ll want to do when starting your project will be to decide on a scope, (what it’s about).

Maybe you’ve already got some good ideas floating around in your head, or just a vague idea of the “flavor” you want. Either way, take some time to decide on the general scope of what you’d like to make. Have you always wanted to make a game? Is there a command-line tool you think will make life easier? Maybe you have an idea for an app you want to throw on the app store?

Remember to choose something you care about! It’ll be much easier to stay motivated and see it through to completion!

Side note on clones: clones of existing things are fine for educational purposes, but you can always do better. Coming up with an original (or at least semi-original) is always better than making (yet another) Pong clone. Also, don’t worry if you feel like what you’re making is lame or has been done before. As long as you avoid directly copying someone else’s project, yours will surely come out unique, and you’ll still learn valuable first-project lessons.

Size

Now that you’ve decided on the type of software you want to make, and maybe even have an idea for the specific program, it’s time to decide on a timeframe.

Of course, the larger the project the more oportunity for learning, but striking a balance is important. How much time do you have? How soon do you want to move on to another project?

If you’re a university student, or have a full-time job, odds are you don’t have much time to be spending on your side-project, so it’s important to pick something feasable. Software is notoriously hard to predict when it comes to completion time, but that doesn’t mean it’s not useful to set some rough targets.

Keep in mind that your skills will progress greatly over the course of the project, and that you’ll probably be capable of a much more impressive project before you finish the first. For that reason, it might be a good idea to pick something that you can finish sooner rather than later, so you can start on the next project as soon as you’re ready (while still completing the first).

Choosing a smaller project will be easier to complete, and the gratification can be used as momentum into the next, bigger project!

Top Down

While imposter syndrome is real, there’s also the opposite issue of beginner over-confidence.

It’s almost impossible to know what you are and aren’t capable of, and it’s easy to “trap” yourself within your current capabilities. To avoid this, and to stretch your abilities, I think a good approach is to start with the big idea and work down.

Start with the grand vision, and deconstruct it down to find out exactly what you know how to do and what you don’t. Doing this in as much detail as possible will give you the best overview of what you need to do to start your project!

An Organized Project is a Good Project

One of the biggest lessons I learned from writing my first game was that it’s very easy for the project (and therefore the code) to get really, REALLY messy.

I was just writing features as I thought of them, making new classes as I needed them, and not refactoring code unless I absolutely needed to.

A good way to avoid this is to get a little notebook to journal/map out your ideas and sketch the framework of your project.
This will do a few things:

-You’ll have a record of every idea you’ve had (good and bad)

-You’ll be able to visualize the project as a whole

-You can then organize your ideas into a cohesive plan

-You can work through problems on paper before jumping into the code

-Your code will be nice and organized as a result.

Don’t undervalue the drawing board. It’s a very VERY useful tool.

A few tips on keeping a notebook:

Every rough sketch needs a clean one. I’ve experienced the pain of drawing out a new feature in my notebook in all its messy, arrow-filled glory, only to completely forget what the heck I drew the next time I looked at it. Make it readable.

Sketch details as well as overviews. It’s a good idea to sketch out small features in as much detail as possible. The more detailed the plan, the less time you’ll spend coding (and hopefully debugging).

Spend some time organizing the class-hierarchy (if object-oriented). Putting some thought into how your classes will be organized will save you a lot of time when it comes to using them in the rest of your code. Deliberately making your methods static vs non-static, using interfaces and abstract classes when appropriate, organizing your objects in an intuitive way, etc. will save a ton of time and headache.

Don’t Stop Until It’s Done

A finished project that kind of sucks is still better than five half-finished ones. Showing that you’re able to stick it out till the end says a lot about you.

It’s normal to feel overwhelmed, frustrated, and completely underqualified. Just keep putting in the time, and take a break to do some learning if you have to. The point is to learn remember?

Of course, if the project is beginning to feel like a complete waste of time and you know there’s something more valuable you could be doing, don’t be afraid to cut non-essential features and wrap it up early.

If you need an example project to look at to get started, the Rain Animation I made in Java a few months ago is a great starter one! I made a step by step guide for it, and it’s completable within a few hours.

Also, the source code to my current project, ConsoleAdventure, is up on my GitHub if you’d like to look at something a little bigger.