3 Mistakes I Made With My First Coding Project

I started my first real coding project way back in 2002.

Really, I had a few sample projects when I was first learning to code. Those projects helped prepare me to think about the bigger picture, but there is nothing like sinking your teeth into a live business project that has real impact to a business.

And while my coding business turned into a 6-figure a year business, I made a ton of newbie mistakes along the way that held it back in the early years.

In fact, there are 3 critical mistakes I made that I don't want YOU to make with your first (or 5th) coding project. If you can avoid these, you can not only grow better as a coder but grow faster.

One of the first projects I worked on was with a Basketball Magazine company. I was tasked with architecting and developing both the front-end and back-end of an online magazine entirely in ColdFusion and MSSQL (along with HTML, CSS and JavaScript). This provided a complete online magazine with online transactions for purchasing subscriptions, client/session management, a customized User Management tool, Online Article Management System, and a code/database Dynamic Photo Gallery.

It was a big task and I completely underbid it. I didn’t make a plan, but got the requirements from the client and just started to run with it. This was a mistake not only for my part financially, but led to much wasted time for the client including much frustration. 

This was before Wordpress or other content management systems existed and you had to build out those yourself. It was brutal!

I made many a mistake along the way, but here are 3 big ones:

#1: Writing Code Without A Plan

One of the worst things you can do is to start a project without first making a plan. Dave Ramsey often quotes this verse related to winning with money. “For which of you, intending to build a tower, does not sit down first and count the cost, whether he has enough to finish it” Luke 14:28. Just as you need to start with a budget when winning with your home finances… in business, a plan is essential.

Start with understanding your client’s pain points. You have to really get into their business to understand what processes are knowingly and unknowingly causing the client pain.

“It’s not that I’m so smart, it’s just that I stay with problems longer.” - Albert Einstein

When you sit down with your client long enough to not only understand what they are asking for, but what pains they are experiencing, then you can begin to formulate a strategy and a plan that will not only give them what they are asking for, but solve some major pain points that they are currently experiencing.

One thing that will help you (that I failed to do starting out) was to get familiar with flow chart tools and start mapping out the design of what you want your code to accomplish. You can use lucid charts or even just a white board and drawing boxes to create a mock-up of your plan.

Once you have it mapped out in flows, you can then start writing pseudocode for each flow in your favorite text editor. Pseudocode is basically just writing out your code in plain language descriptions rather than coding syntax. Doing this will save you a ton of time!

#2: Repeating the Same Code

When you first start writing code you will learn that some of the actions you want to do will be easily repeated and so you just just copy and paste that code to start a new line of code.

One of the basic principles of coding is learning to reuse blocks of code through methods, functions, for loops, etc. Repeated code can make maintaining that code very difficult and cumbersome. It can also lead to performance issues in code, long load times, and negative user experiences.

#3: Not Asking Questions

When you initially meet with the client and find out what they want to build for you. That is just one of many, many meetings you should have with that client over the course of your coding project. Best coding practices today call for at least weekly meetings (and some even daily depending on the size of the project).

When I was first starting out I thought I was the expert and had to figure it all out after that first meeting. However, the client is the expert at their business and they need to be involved all along the way during the development. Gone are the days of the developer getting the requirements and heading to the basement for 3 months and ascending from the abyss with the final project.

Today’s businesses are expecting short sprints, with iterative development. It will also make you develop a product that is more what the client wants.

Of course, this means that a thorough SOW (Statement of Work) should be drafted after the initial meeting(s) and signed off on before ever starting the development work so that if there are any changes to the SOW, those can be then documented in what’s called a Change Order, so that you are getting paid correctly for the work that you provide.

Close

50% Complete

Get our latest tutorials, tips and tools to help you learn to be an Apex Programmer!

Every week I'll update you on the latest from Apex Coding Academy and you'll get first access to new resources, offers and events.