How to Start a Code Project in 5 Easy Steps

let’s create something.

Scenario: You’re on the couch scrolling through Twitter. You notice buzz around a topic and…EUREAKA - INSPIRATION STRIKES! You just thought of the PERFECT way to solve the problem using code. You turn on your Macbook and open up VSCode. And then…you stop. You have no clue as to what comes next.

Sounds familiar? I believe we’ve all been there when we first started learning how to code. When inspiration strikes for a coding project, honestly, the very LAST thing I do is turn on the computer. Because think about it - what are you going to do? You’ve just barely conceputalized and have done little to no research.

You see, when you fail to plan, you plan to fail. These words could not be more true when it comes to starting your own coding project. Below, I’ll walk you through the steps I take when starting a coding project. We’ll be using the I Gotta Take This project I created using Twilio Autopilot and Twilio Studo.

1. Determine your Objective

Figuring out your objective early on will help keep you on track to build what you initially intended to create. Doing this step helps to ensure that the decisions you make later down the road are within scope of the project.

When I created I Gotta Take This, I told myself that I wanted to create a way for someone to send a text message to a number and in return receive a phone call from an AI Bot. The AI Bot would hold a fictional conversation with the user and would give the impression that the user is holding a real conversation with someone on the phone.

2. Find the Knowledge Gaps

Regardless of whether or not you’re using technology in which you’re familar with, it’s best to take inventory of the skills that are necessary to complete your project. You don’t want to complete 80% of the project only to realize that you need to push your launch day out by a month due to not understanding how something works. Take note of the technologies that will be used for your project and determine whether or not you’re in need of learning something new. If it turns out that you need to acquire a new skill along the way, reach out to your network for how-to resources or just do a simple Google.

For I Gotta Take This, I initially wanted the user to send a text to the Twilio number set to a Twilio Programmable SMS script. The user would be asked at what time should the phone call be made. The user would provide a time and the outgoing call would be scheduled. From there, the Twilio Autopilot assistant would take over via Twilio Programmable Voice.

I knew for a fact that I was missing one key important element - a scheduler. I began to search for Twilio integrations with schedulers and came across Zapier. However, as I started to test out the integration, I realized that I couldn’t (a) trigger a scheduled call based on user input and (b) select the Twilio Autopilot assistant as the voice output.

So, I headed back to Twilio to see what products were able to possibly help me acheive this goal. I found Twilio Studio and read the documentation on how the product work. To come close to fulfilling my objective, I had to scale back my functionality a bit. I decied to forego the scheduler and instead do the following:

The user would send a text message to the Twilio phone number. This would then trigger an outgoing call via Twilio Programmable voice. From there, the Twilio Autopilot assistant would engage in a conversation with the user.

When I took this approach, I soon hit another brick wall. I didn’t know how to trigger the Twilio Autopilot assistant. I tried a few options out but ended up making myself more confused than when I started. I could understand the logic but just didn’t know how to properly execute. Fortunately, the folks over at Twilio Support were able to assist and I was well on my way to continuing on with my project.

3. Decide on the Features and Workflow

Once you’ve determined your knowledge gaps, check to see if your objective is still in tact. Did you need to modify the scope of the project? If so, it’s not the end of the world. It’s better to figure out these things early on rather than near completion of the project.

Take your objective (or refined objective) and consider the features of whatever it is that you’re building. Also take a moment to brainstorm the workflow of you. Those features will help you determine what actually needs to be created.

After I modified the objective for I Gotta Take This, I came up with the following list of features:

  • Natural conversation design

  • Use of open-ended questions

  • Acceptance of various responses from user

I also wrote out the workflow to help determine just how many tasks had to be created with Twilio Autopilot. The workflow ended up as such:

draw this

4. Break Your Coding into Phases (or Sprints)

Rather than pick any ol’ step in the workflow or feature and start coding, you’ll want to break-up your coding into either phases or sprints. The best way to execute this step will vary by project. You may find that it makes more sense to prioritize the easier coding first and save the tough parts for last. Or you may determine that it’s better to just start with very basic features and add onto the project at a later phase.

Prioritize your features list in a way that’s conducive to your coding style and end goal.

I decided to type out all of my Twilio Autopilot assistant tasks first in an Excel spreadsheet. Within that spreadsheet, I created columns for the file names, sayings and a column to indicate whether or not a task was complete.

attach this (but need to make it first)

I then worked from top to bottom to create all of the tasks. After creating the initial greeting, I decided it would be best to code everything for one path and then code everything for the other path.

5. Create a Timeline

Are you on a time crunch? Or are you just doing this project for fun? Regardless of your answer, I urge you to set some time parameters around your project. Only you know the level of effort it’ll take for you to complete something. Be realistic in your timelines and add some buffer in case something goes wrong or if you decide that you need a coding break (or extended hiatus).

So what if you’re coding for fun? I still urge you to set some time parameters. Otherwise, you may end up with a project that’ll never get finished. I strongly feel that the act of completing a task increases endorphins and honestly - who doesn’t wanna be happy?

I start I Gotta Take This rather spur of the moment. I was sitting on Twitter one day when inspiration struck. I had finally figured out what I wanted to build with Twilio Autopilot. I was hoping to have come up with an idea before the year ended because I wanted to apply to become a Twilio Champion. With less than 2 weeks to complete the project, I began to schedule out time on my Trello board to complete everything.

graphic for time %

So as not to feel rushed, I spent 50% of my time on planning, 30% on coding and 20% on testing. I knew that what I was creating wasn’t difficult to code. I have Twilio Autopilot templates saved on my computer so that I could replace the text as needed and push to Twilio. Dedicating more time to planning was most beneficial for me because it enabled me to identify risks early on and set myself up for success as I started to code.

Working coding projects is a fun way to flex your coding skills and show the world what you’re capable of creating. Rather than stress yourself outside, take the time to properly plan out your projects before heading to the code editor.

CodingApril Speight