Make it, if it's so easy.

We all have had those moments, when you have such a great idea, and you say, "Oh, that's so easy; I can easily do it!", but can you really?

I've been having countless "such" ideas for years, and I can count a total of one successful project that I actually saw through and finished, so lately I thought, what's up with that? What is stopping me from doing those projects, if they are as simple as I claim them to be?

Chapter 1: The idea

Okay, you have an idea. Great. Now do it. This is the step most of the people get stuck on, myself included.

You feel like you have a great idea, and you think you should do it. But instead of doing it, you probably start researching; if people have already done it, what language, library or framework should you use?

That in itself is fine. I believe you should have a rough outline of what you're building to make a successful project; you should have general direction, but here is the problem people encounter:

First, you're likely to tell people how great your idea is and boast about it. Only after that will you start working on the project. What does this actually mean? You're unlikely to even start the project because you already got the reward from telling people about it.

But, it actually does not end there. What if I told you, that it is often an indication that your idea may not be as great as you sought it to be? You may think, "How is that possible?! My ideas are always great!" and as brutal as it may sound, you're just as biased as anyone else. Your idea may be great, but have you considered why it's great?

Chapter 2: Motivation

Have you ever thought about why you want to make something? Is it because it is interesting, or perhaps because you enjoy doing it, or is it because of money or prestige? Perhaps making someone else happy?

The "true" motivation behind an idea, is often the major deciding factor whenever you're actually likely to pursue the idea further and make it from idea to reality. "What does this mean?" you may ask. Well, let me explain. I hope it doesn't come as a surprise to you that humans as beings are motionally driven, and without a motive, we're unlikely to do anything.

There are plenty of motives, and some of them are more rewarding than others. And in my own personal experience, building things that benefit myself more than others is often more rewarding than making things that I am unable to personally enjoy or use.

I do believe there should always be more than one motive driving your force to actually turn your ideas into fruition. Take, for example: you're building some kind of third-party utility for an already existing application.

Are you really that likely to make it if you don't use it yourself? And would you bother to keep developing it if nobody else uses it? It's unlikely; you want to be both motivated by self-interest and outside interest, which keeps a healthy balance between all sectors.

What does this mean in practice? It means that you should focus on considering what your motives are behind the project, and is it something you and other people would use?

Chapter 3: Implementation

Oh, wow! That's amazing. You've gotten this far! Most people would've already given up on the previous step. But if you get through the hurdle of trying to understand what and why, you're in for a ride!

Now that you understand what you are trying to make and why you are making it, you should consider: How, When, and Who.

You need to understand what technologies and systems you will be targeting, when you are going to do it. Then you should consider when do you have time to dedicate to the project. If you stop it half-way, you're unlikely to ever finish it. Lastly, but not least, who is it made for? Yourself, your friends, or perhaps your family. It matters because your program should be built for the needs of the audience, not the other way around.

When you're building something, be it small or large, it does not matter. You should always just do it. What that means is that when you're first starting out to make the program, you should not be fixated on the structure or the way it's written. Because your code should always be written in a manner where it can be refactored later on.

You should not take a burden during the development because you need to remember what you're trying to do to turn your idea into reality. You should take it in small steps, and then eventually combine those steps to have the final product.

If you encounter an issue and have no idea how to solve it, Google it. Let off your ego; even after years of programming, I still end up looking up basic syntax for "JavaScript string contains" because I keep using contains when it's includes, honestly. I think it should be contains but whatever, I'll let it slide.

Chapter 4: Feedback

As they say, "Consistency is a key to success.", as I interpret it, I think you should commit yourself to something and see through it, and success eventually finds you in a way or another.

"Well, what does that have to do with anything?" you may ask... To begin with, you're unlikely to stay motivated unless you have a steady supply of "motivation," because the initial candle will not hold its sparkle for eternity.

The best way to keep being committed to something is to ask for feedback from other people, constantly asking if there is a way to improve or do this differently that I haven't thought of. This engagement brings a consistent effort-to-reward ratio, which allows you to keep working efficiently.

TL;DR You really should engage with other people.

While you may not think this is an important part, once again, you have to consider your motives. Even if you're building it for yourself, you will find it beneficial to ask for feedback on your code, not because that person is particularly interested in your project.

But rather, so you can learn something new and maybe consider using this new information to change the way something is done in your program, which you may find rewarding, given learning itself is a very satisfying process.

Humans are social creatures; even the most introverted programmers are no exception. We will lose our motivation if we don't interact socially with other people, so just asking feedback on your code from someone you trust is already doing you a huge favor.

Afterthoughts

I wrote this blog, because these are the lessons I have learned lately to finally turn my idea into reality. I believe this information is very likely useful to other people who struggle with similar issues. So I am hoping this may help you out, and I also hope it reminds people that not every idea is something you should do because it's great.

This is not to discourage anyone, but rather to encourage! You should always build things you believe in, but I also think it's important to actually try to understand the process that goes behind your own thoughts. Why do you want to do it? What is there in it for you? etc...

Often, people start buildings things for the wrong reasons, and the result of that is usually nothing coming out of it. Being able to actually filter ideas you will end up making versus the ones you will never finish is something to consider for sure.