Checklist for New Programming Projects

There are lots of different things that people should always do before diving into something new, whether in or out of programming. Without planning and preparing, a lot of the projects that I’ve previously worked on would turned completely pear shaped.

I decided that I’d compile (pun intended) a checklist that I and other people like you could refer to as a reminder and reference on how to prepare appropriately for new projects.

 

1. Think About Your Idea

Whether this is something you’re programming as a personal project, for work, or for something completely different, you always need to have a good think about it. Mainly, you should think about how you’re going to go around solving whatever problem you’re tackling.

If you’re going to be working on something that you’ve never dealt with before, make sure that you consider if you can do it with technologies that you already have knowledge with. This includes programming languages, documentation, style of programming, and more depending on the specification of your project.

If you have experience in similar projects, make sure you still think about how you can apply your work from said projects to this one. This could be something as small as the project being written in the same programming language – to being able to reuse the majority of your code again.

Another thing that needs to be researched and majorly considered during this stage is if somebody has already implemented your project before. There have been multiple projects that I’ve started only to find out that my efforts are wasted due to duplicates already existing. If your project has already been implemented before, what are you going to do differently? Most importantly, what are you going to do to make it better?

After you’ve had thought about your project, you should have a better idea of how you’re going to go about it in your head. If you’re working as part of a development team, you should be communicating these thoughts and see what the other members of the team are thinking for themselves.

2. Get some planning down on paper

This is a very important part of any project. Formally, this should be a set of requirements that all members of the project can refer to on some sort of project’s wiki. Informally, this can be anything from post-it notes on a bedroom wall to bullet points in a text document saved on your desktop named “plan.txt”.

No matter the format of the planning, it is always good to have something to refer back to as your original list of priorities. Depending on the software development method that you’re following for the project, these might be concrete requirements that can’t be changed, so this is a very important step in the planning of a project.

You can organise the first steps towards the final solution based off this plan, and go from there.

3. Set up and use a code repository

Namely, I use GitHub or BitBucket for my code storage and version control. This is important not only to back up your code so that you don’t lose it, but also so you can keep a record of every change. Depending on the version control system used, there are many different features built in such as ticket tracking, branches, and collaborative access for projects in which multiple people are working on code at once.

This will be a place for you to “push” all of your changes to and other members of the team (unless you are working alone) can “pull” your changes from.

4. Clean code wherever possible

There are many different reasons why clean coding should be implemented as much as possible and followed very closely. Namely, readability for yourself and other programmers. Your code should be written well enough that it can be classed as “self-commenting” so that it doesn’t need explained to other programmers for them to understand it. This is very important if the code is going to be added to in the future by other programmers. If they can’t understand it, then they won’t be able to add to it easily.

In preparation for your project, make sure that you read up on clean code if you haven’t before. The book that taught me more than I could ever need about it is: Clean Code by Robert C Martin.