The Wrong Approach to a Programming Project

Image by Ashkan Forouzani on Unsplash

The most difficult part of a good programming project is coming up with a good idea in the first place. Why? Because millions of people know how to code and some of them are very good at it, and there are countless ways to efficiently learn how to code but any tips for coming up with ideas are inevitably vague.

Say you’re entering the typical hackathon. You have a certain amount of time to write a program and present it to a panel of judges. In this limited span of time, how do you maximize your chances of winning an award? Chances are that you have programmed before this specific event, meaning you have some experience with certain techniques. How about blockchain? Let’s use blockchain. You know how to do blockchain. You’re so familiar with blockchain that you would feel more comfortable doing a project using that technique rather than learning something totally new. Not to mention, you would save time. All valid points.

Now that you’ve decided the type of solution, you need a context by which to implement it. You make a list of some common topics: environment, medicine, biology, robotics, games, etcetera, etcetera, etcetera. While looking through some Wikipedia articles on these kinds of broad topics you have an idea, an epiphany. What if you implement blockchain to make an online election system? With such a fitting idea there is no question of getting to work immediately, grinding away until you have some semblance of a working demonstration.

Preparing your presentation, you need to explain the background of the problem you chose as well your solution to it:

“Well, you see, some problems that are in the current election system are laziness of people to vote, threats of election interference, and the cost of running election locations. blockchain is a recent technology that has been successfully implemented in this, this, and that. My project harnesses this technology to potentially solve all of these problems. As you can see in my demonstration, I used blockchain and made an election program and it can count votes. Therefore, my project has the potential to potentially innovate the field of blockchain and bring a new era of technology and election security, if more work is done in the field."

This may just be the best project the judges have seen all day, and they nod their heads and ask what libraries you used and commend you for using such an advanced technique and tell you that you have a bright future ahead. You win your award and never see your program again and next time you write a resume you talk about all of the hardship and learning you went through to get this award. The end.

If you can read the satirical undertone of the paragraphs above, you can certainly tell that something significant is wrong. The problem is that you have started with a solution, then looked for a problem to solve using it. This might not be bad on its own, but when you’re looking to optimize both the grandeur of the problem and the flashiness of the solution, it becomes very difficult to make a cohesive link between them. The correct approach is to pick a problem and ask the unanswered questions: Has this been done before? How do you measure the resistance of your program against hackers and election frauds? What about the reasons that online elections have not been implemented yet? Either nobody asks these kinds of questions, or they’re answered in vague terms that are so vague you can’t disagree with them. Answering these questions would be very important in an actual implementation, but within the realm of competition they’re easily deflectable.

This is the single most common pattern I see in student projects, and one of the few incorrect ways to approach one.