DEV Community

Cover image for 10 Tips To Get Out Of Your Own Way And Start That Side Project
Rohov Dmytro
Rohov Dmytro

Posted on

10 Tips To Get Out Of Your Own Way And Start That Side Project

Let's START working on our «Dream Projects»!


My last 10 years of coding had its ups and downs. To have more ups I've implemented tiny habits to be more productive. It's time to share! If one of them will make you 1% more productive everyday — I am taking it!

Beware! Some of the tips might be silly (or against best practices). But in my personal experience they DO make me more productive. At least in my case.

And hey, ultimately, productivity is a speed of achieving our dreams. Let's do something about it!


How To Finally Start Doing Your Dream Project


I am defining the problem of starting as a problem of mental walls. Let me explain.

I have a medium size personal goal — to acquire 10 000 people to use my products that will help people to become MORE self-aware. THAT is my personal realistic dream.

But! I am not sure which tools exactly I will build (AND people will use). Not cool. And understanding yourself in not an easy task. But in order to figure out the tool to build I need to iterate on my ideas (and hypothesizes). And in order to iterate I need to... start and to... finish.

To start the WHOLE project and to finish the whole project. Daaamn. :)

I want my week to look like this:

Schedule
And NOT like this (irony):

Schedule, bad

Hey, naming convention of my variables IS important (from some perspective). But while looking at a bigger picture there are more important problems I want to face. For example. Am I delivering real value to the people with my products?

Mental bottlenecks are the places we feel like we need to make a good decision but it might not be THAT important from a bigger stand point.

My opinion:

One the most most important meta-skills is the ability to start and to finish.

Cause overthinking is not fun. Momentum is!

And hey, hey, hey! I'm sharing my real-life experience. IF you are interested in building side projects that would challenge you to become better & stronger — join me, join my newsletter.

To the tips.

Tips


Picking The Idea

We need good idea. But good ideas does not come from nowhere. They should be based on something. So my current idea is not based on data. I simply don't have real-life product data. That's why my current idea is simply based on intuition (consider this as an inner source of data).

The idea is: tracking daily stuff in a fun way using... emojis.

And then I am telling myself:

Let's spend some quality time to find the perfect shape for this idea in order to test it in the wild.

Let your first idea be based on intuition. You will get experience and data later.

Naming is hard. Avoid it!

Naming a project is hard. But it should not be hard to name things while in active development. What I do is I give temporary technical names. For this project I chose the name «Trackerion».

Sometimes I name projects literally. My previous project was called: «habits-with-feelings».

And that is fine. You might have a perfect name while working or talking to people. Just don't get stuck with this initially.

Biggest Tip To File Organization

All I am starting is a single file — App.js. And only later — everything.js else on/demand.js. And that is fine. The structure will happen later.

And that's all.

Don't Stuck With Your Tools

I can easy imagine this conversation, happening in heaven:

— What was the last thing that you remember?
— npm install

Sometimes you can get older while installing all the android tooling or NPM packages. But there is a hack. Don't get stuck with your tools! Do other stuff in the context of the current task / project.

  • Visualize the problem
  • Plan the code
  • Priorities features

Super ultra prototype

For example, while some script was spinning, I've started exploring uploading my app to the Google Play Store and this is what I've found.

Warning
This simple act won be a couple of days because I've realised that I need to upload my app as soon as I can.

Don't stuck with your tools. There is always something useful.

Expect The Unexpected Things

So I was at the peak of excitement during the development when my phone's screen got smashed. And I've just set up everything to develop with it.

Yikes!

How to win in this situation?

The win is to put as least attention to the bad news and keep going.

Found my very old phone, set up everything again, send my broken phone to the fastest repair service.

Feeling sad, feeling bad, accepting life, moving on.

Minimise Style Fapping

This one is golden. I think this rule is one the biggest time saver for me. This rule saved me DOZENS of hours.

Don't. Play. With. Styles.

I've stopped tweaking paddings, margins, colors etc. For some reason I was doing this during the active development.

No-no-no-no.

Instead, I have this rule:

Put UI blocks onto their places.

Minimising time to tweak styles, tweaking. Focusing on building a clear screen/page structure.

Prototype

color: green is fine, color: red is fine.

Resist The Urge Of Upgrading To The Latest & Greatest

Upgrading to «latest and greatest» is... tricky. Cause you ofter run into some compatibility issues...

Upgrading feels good, dealing with issues takes time.

Landing Page — Just Find The Reference

To complete a basic version of the landing app I usually go with some clear reference.

Landing

You can transform doing a landing page into a rocket science, it is important. But you are fine to start having the basics.

Done is better than perfect.

Have a Distraction Paper

When I write on a piece of paper solving a particular task, I always get somewhat irrelevant thoughts. They feel good, but they are distracting. The solution is to have a «distraction paper». That paper where you write «everything else».

It really, really, really helps.

Manage Technical Challenges

This one is a big one.

I've noticed a tendency to look for technical challenges. Yeah, learning as a programmer is fun. But here is a tricky part: it is not nesesarry helps you to finish. If you have a clear goal to learn something new — that is fine. But otherwise it's not wise.

While you are some fancy term shared by a speaker who was solving a $ 100k business problem, time goes by.

Every step can contain a challenge that can take weeks or months. And that is a lot of time!

Build The Everyday Momentum With Some Sweet Stuff

Most of the time I am quite strict with myself in terms how I spend my time. But! If you have a bad mood... If things don't go so well... If it's an early morning and one cup of coffee was not enough...

Gain momentum with some soul healing refactoring.

:)

or...

Play with styles. A little bit!

Cause we are all human beings.

The End.

This is part of the series. I have multiple ideas for the next articles! If you are interested in some of them — let me know in the comments.

  • How to overcome the middle launch crisis during the development. About restoring the faith in your project if it starts upsetting you. Basically, it's about a meta-skill of finishing. :)
  • Why coder will NEVER launch a good product. This one is about different roles (hats) we should use to move forward with our personal projects. And a high price I've paid to understand that.

Let me know in the comments! And if my words are relevant to you, follow me somewhere (or everywhere).

Cheers!

P.S. What stops you from starting?

Top comments (8)

Collapse
 
ssimontis profile image
Scott Simontis

I think it really depends on what your goal is. If you just want to finish an application of a certain size or requirement, these tips apply. But most of my projects are about picking up new technologies, trying new coding styles, and other experiments. I don't care if I finish or not, once I learn or make an informed decision I'm golden.

Collapse
 
rohovdmytro profile image
Rohov Dmytro

Yeap, totally valid.

Although in some cases learning is also becomes more efficient if you finish the Thing. For example, you can realize that the database does not work in real world that well, or the stack is not that scalable, or it was a too complicated stack.

Learning within small (complete) iterations has its upsides!

BUT! Learning is good anyways. :)

Collapse
 
darksmile92 profile image
Robin Kretzschmar

The distraction paper was new to me and a very good advice, thanks for that!

Collapse
 
rohovdmytro profile image
Rohov Dmytro

It really works! It's an immediate thought dumper that gives a relief and helps keeping the focus.

Collapse
 
tao profile image
Lewis Lloyd • Edited

"Naming is hard. Avoid it!"

Project <Random Word> always comes through 😜

Collapse
 
manishkrai profile image
manishkrai

Good advice

Collapse
 
rohovdmytro profile image
Rohov Dmytro

Thanks. I hope it helps, at least a little bit.

Collapse
 
rahulreddy75 profile image
Rahul

Nice article, but I am confused about the weekly calendar part though. Couldn't understand what you were trying to say there.