What They Don’t Tell You About Becoming A Software Developer — Part 1

Written by Michael Rode on Aug 7 2016

Part 1: The Technical side

“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” theproject yesterday, a little bit longer than either of us had planned on.

  • So what the hell happened?
  • How did the project take SIX times longer than expected?

Well, I had no clue how much work a real production level application would take to launch. Being naive feels so good though.

Building apps is easy, right?

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, iscompletely 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.destroy_all is for anyway

The last 10% takes the longest

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.

This is not what I signed up for

I am not going to lie, at first, I hated this. I became intimate with binding.pryand 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.

Starting to see the light

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.

Part 2 coming soon!

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.