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.