Time to plan and work!

By now, I hope you have at least a starter idea of what you want to do. Your goals will differ as you go along, so now is the time to figure out your process. If you don’t have an idea yet, read our idea guide first.

These are not well-defined steps, and you’ll find yourself going back and forth in an actual workflow quite a lot. Finding a workflow is a complex skill to learn, but practice makes better, as always. Over time, you’ll figure out your working style that may differ from mine or anyone else’s. This is good because everyone is different, but inspiring strategies from others and constantly experimenting is a good thing.

But for now, here’s a sample workflow to get you started.

Start defining the idea

Ideas are fun because they’re fun to play within your head. It’s easy to get lost in the possibilities and all the cool things you can achieve.

However, the brain is incredibly good at fooling itself, and if you keep your ideas in your head, you won’t realize how vague the idea is. It doesn’t matter where you take notes (notebooks, documents, mindmaps, Github issues, a kanban board, etc.), but you should start fleshing out the idea. At first, just brain-dump. Then, start thinking in terms of features, User Stories, roadblocks, potential challenges, and technical tools.

At first, you’ll start writing things down quickly, but then the pace will slow down as you realize that you didn’t have as complete an idea as you thought you did. Keep working out the details, searching up things (and noting down what you want), and organizing your initial idea.

This phase doesn’t have to be too long. It can be 15 minutes, an hour, or at longest a day. It’s important to reflect on planning a little, and you shouldn’t get stuck in “planning hell.” At that point, leave your planning work written somewhere you can come back and expand on it later.

Figure out what’s important

This part is hard, and even very experienced people get this wrong all the time. It’s easy to come up with a neverending list of features and requirements, but doing them all will take you forever, and you will not finish. Even if you do somehow complete them, your result might be overly complicated or hard to use. Being picky about what you want makes your life easier and makes your actual users happier. It’s a win-win.

The standard advice is to figure out what is needed for an MVP (Minimum Viable Product). What’s the bare minimum that you can do for this project? What’s the (perhaps embarrassingly) early version of your idea? From the list that you made already, try to pick out the features that hit these criteria. Learning how to do this will take some practice, so don’t worry if you can’t do it perfectly. The rule of thumb for a feature X: think back to your idea, and if you can remove feature X and still have your software hit your concept, it’s not part of the MVP.

Create a rough ranking of what to do and work in that order

Your primary goal is hitting an MVP. You need to start simple and work in the order of the MVP list that you figured out. As you work along, you might realize that you don’t need feature X, or that feature Y is more important than you initially thought, or maybe you figured out an even more fantastic idea. At every step of the way, keep your users in mind. If your ideal user is you, then getting that instant feedback is easy. If you feel embarrassed and underwhelmed by your MVP, but it kinda works with your problem statement, you’ve succeeded.

Once you’ve fulfilled your MVP, you can start picking more things to add to make it more excellent. The goal now is incremental development. Complete each task one at a time (Add a feature, improve a look, create some documentation, fix some bugs, automate), and ensure that everything is working fine. Rinse and repeat. If you have test cases (we’ll cover a bit of pytest and mocha), this process can become faster and easier.

As you work along, you’ll unlock more ideas and start to understand some of the technical hurdles. Keep adding them to your initial list and expanding on. You can do this with Github issues, making it easy because you can keep adding issues for things you need. This kind of list also allows other contributors to potentially come in and identify parts that they can start helping with. Feel free to use any software, but the important thing is to keep writing this down somewhere.

Your list will almost always be longer than the program you have, and you will never implement a lot of features at all. This long list is natural and part of almost every real-life project (unless it’s exceptionally narrowly defined). Even the 125-weekly-projects GitHub repo that the site is running from will always have more issues to solve. Long lists are good because it lets us pick and choose how we’re moving forward. Most software is never complete.

False Starts and Mistakes

You will have false starts early on, and you will make bad decisions at first. This is okay, normal, and honestly part of the process. Feel free to restart a few times if it feels off. Still, be careful not to get in a loop of restarting since any “meh” foundation is a better starting point than no foundation at all. The rule of thumb is that your fourth restart should be your last one until you get a working MVP. Make sure to save all your planning and code work somewhere so that you have a more solid base to work from with each restart. No matter how bad it is, don’t delete it (you can archive it somewhere out of sight if you want).

It is also natural to make mistakes, ruin something, or waste a few hours with a feature that you realize is hopelessly complicated. This is okay, normal, and part of the process of working as well. Learning software like git is a big help since it’s designed around this. git is basically like a time travel machine of your project. Each commit is like marking a point that your time travel machine can come back to. git even supports creating multiple parallel universes of your code via branches, which is a valuable feature in practice when making actual software.

Have fun

Seriously, don’t ignore this. Doing projects on your own should not be a chore or something you’re doing for the sake of someone else (if you’re making software for the sake of someone else, at least make sure to get paid a competitive rate for it). Different people are drawn into computer science for various reasons, and everyone will like different parts of the process. Part of your goal is to start figuring out what you want and what you don’t.

Good luck!

Good Advice from others

https://peterlunch.com/how-to-plan-and-build-a-programming-project/ - Peter Lynch. Honestly, this is a great blog post and one of the big things that inspired this entire summer initiative. I shared the idea with them as well, and I got nice validation. Instead of Trello, as he suggests, you can also check out the Github Projects built into every repository.

Contributors: Harsh, Drshika, Maaheen, Nehal