“Sure, that should only take me two weeks to build.”
This is a quote from a conversation I had with my soon to be boss around 3 ½ months ago. He had laid out a project for me to gauge my skill level and help me to further my software development expertise. Embarrassingly I just “finished” the project yesterday, a little bit longer than either of us had planned on.
Well, I had no clue how much work a real production level application would take to launch. Being naive feels so good though.
I had built plenty of apps before. No really, I was building apps every other day. The main thing I realized is that building a toy app, or following a tutorial, is completely different than building something you are hoping for thousands of people to use.
My mindset when building a personal project was as follows:
Oops: Users can see other user’s information.
Who cares, I am the only one who is going to be using this thing anyway.
Oops: User profile page will not load.
It’s fine, all I have to do is refresh the page 3 times in 3 seconds while clicking the “more info" link and it loads.
Oops: A User has bad information in the database.**
Thats cool, what do you think “User.destroyall” is for anyway_
My mindset was basically, work on the 90% of the application that was fun to build, and avoid the 10% that seemed like it would be a headache. Little did I know the last 10% would be the most challenging part. When I had a problem in my production application I couldn’t just say screw it and move on to the next app. I had to dig down and figure out what the hell went wrong, where that damn nil value was showing up, and how to fix it.
On top of that I had to make sure the fix was something that would work for all users, not just some hacky work around so I could move on to the next step.
I am not going to lie, at first, I hated this. I became intimate with binding.pry and would spend hours trying to track down one bug. I wanted to become a developer so I could build and create, not so I could spend 3 hours reading through Twitter’s API documentation about rate limits. Where’s the glamour and glory in reading documentation? There were countless times that I just wanted to say screw it and move on to the next project but I no longer had that freedom.
After a few weeks of this things started to change. With mentorship from my co-worker Eugen I began to take a more professional approach to development. I was floored the first time I saw how much thought Eugen put into just naming a method. I was sitting there thinking “who cares, is a method name really that important?”
I would watch Eugen work and wonder…“Why would I spend time refactoring when the code would end up doing the same thing in the end anyway?”
After a week of trying to read through old code with poorly named methods I began to see the light. That torture was all I needed to understand the importance of writing clean and maintainable code.
Now when I wanted to refactor a part of the code I found I could make the change in a quarter of the time. Doing things the right way was more work up-front, but ended up saving me time in the end. I started to enjoy the process and began to take pride in writing clean code.
Look out for Part 2 where I talk about my struggles working remote, how lack of communication issues can kill a project, and overcoming the dreaded imposter syndrome.
If you wanted it to build a product you’d find a way to get time to work on it. If you really wanted to start that new hobby you’d sacrifice something to find the time and money to do it.
I'll define a "Wannabe Entrepreneur" as someone who has never made money from their businesses. Here are the different types of wannabes.
In the past few years I've built go-carts, built a 200+ sq ft workshop, written several eBooks. How do I create a life where I have time to work on side projects?
Receive 5 Software projects mistakes we have made over the years and how to avoid them.