That's a short post, but here is the TL;DR: Before jumping into code/project, plan it before hand, take a look at what might need to be changed, what might need a refactor and take notes about it. Follow your plan and you'll be way more efficient.

If you don't want to read the reasons about why you should have a plan, just jump to How to create a good dev plan.

We, developers, love coding. Nothing can be more boring than a working day without a single line of code and it's very common that this love make us a bit anxious for coding and when we see a shiny new project/task/ticket, we're like dogs wagging our tails looking forward to get started.

There's nothing wrong with that, we're developers and love coding, but have you figured that by doing that we're often more inefficient? I'll tell you why.

Why we're more inefficient when we start coding right away (without a dev plan)?

You've probably faced that before: you get a new ticket to work on, right away you jump into coding and start working on that and after a couple lines of code, you see that the lines you've added are not in the correct file (maybe because of architecture decisions or just the wrong file). Then, you delete your changes and find the correct file, apply the changes, but wait, your lizard brain tells you that there's something wrong, you need a refactor before adding that code.

So, you start doing that refactoring and that takes all your day, by the end of the day, you figure the refactor wasn't needed and you get back to your first strategy (or try a new one) and that cycle repeats until you get your project done!

Can you see how inefficient that dev approach is?

We're way more inefficient when we start coding right away, because our ideas of what needs to be done aren't in the right place yet, they're not connected to each other, also unless you're starting a brand new project, your new code usually will need to communicate and fit to other parts of the codebase, if you start coding without a plan, how do you know which parts of the codebase that may affect?

So, what could we do to help ourselves to be more efficient? Add a plan step before you start coding!

Benefits of having a dev plan

Before flying an aircraft, pilots are requested to create a flight plan, they never (shouldn't) fly without a plan, there are a lot to consider before taking off, landing and flying: Aircraft weight, winds, best route, altitudes, weather, speed etc. By doing a flight plan, pilots are able to find the most efficient way to go from A to B safely and efficiently.

And if you're not sold yet, here are some benefits/reasons for having a dev plan:

• Having a dev plan before dev kickoff helps you to understand what you're supposed to do, before you actually do; where you will apply your changes; and what should be the desired result (code wise).

• Having a plan before you actually start coding, helps you to communicate to your teammates what they should expect when pairing or reviewing your code. By doing that you've shorten the feedback loop (yeah, the feedback loop is everywhere, either if you're pairing or someone is reviewing your code).

• Having a plan helps you to be way more happy when coding, you know exactly what have to do!

How to create a good dev plan

Hopefully, you should be sold that you need a dev plan, right? so how can you create good one? Here are a few things to consider when creating your plan:

1. Make sure you understand all the requirements, if you have questions, ask them before coding, never try to find the answers while coding, you will end up writing code that will be changed or even deleted, be efficient! I recommend that the first section of your dev plan should be a summarized description of the project requirements, that also helps you to have them more clear in your mind and it's also a good rubber duck.

2. Go to the codebase and look for what needs to be changed to get your project done. Will you change how a component works? Write that in your plan. Will you need to refactor a whole section to prepare the code? Write that in the plan. Will you this only need new code and nothing will be changed? Write that in the plan.

3. After you know what to do, and how you will do it. Plan the best route to get that done! Does the refactor needs to be done before all other parts, list it! Organizing what and how you will do it in steps will make you way more efficient.

4. Sometimes the project we're working on has a limited time scope, so saving a refactor to another time is helpful, right? Even if you're not doing that refactor/change along with your project, you should still write that in your plan.

5. Run your plan by your teammates and ask for their ideas and approval. Your teammates might be aware of what is going to be changed, how and why. Having another set of eyes in your plan might help you to decide and change the route to get that done, and the best part, before you've written a lot of code.

6. Sometimes is really hard to create a plan, you need to test something new, the code is a bit messy. In those cases, create a plan for a prototype or investigate, let people and you know that you're going to do that before jumping into the real code. After you know what to do, update your plan with your new strategy.

When you don't need a dev plan?

Not always you need a dev plan, sometimes a bug is really easy to fix, or a feature is easy to get done. In those cases, go for it and CODE it. But if something that was supposed to be easy, is not going as you expected, stop it, and write a plan! (or maybe you should've done it before 😬)

Always remember: Coding without a dev plan, is like flying an aircraft without a flight plan, you can get there, but this can be way more expensive than you expected.