Behaviors of an Amateur Rails Developer
The end of this month marks 6-months since I began my career transition into software development and 6 weeks since I began using Ruby web frameworks. The biggest challenge I’ve found so far in web app development has been keeping my base behaviors from leading me astray. After working in Rails for the last few weeks I’ve found that there are so many aspects of the framework to keep in mind that I feel like I’m in the minotaur’s labyrinth. Time and again I lead myself into a corner and feel utterly lost inside the application’s code. In order to combat this I’ve began to pay attention to my behaviors and develop strategies to combat those that get me lost.
Make a Map
My default behavior for most of my life has been to just wing it and trust that my skills will get me to the finish line. Winging it became my default, because up until this point it has worked. In Software, that strategy ends up leading me astray quickly. Without a map, I find myself building out random features that I come up with while building out functionality on another. My strategy to combat this has been with the use of user stories to guide my work. I take a user story, write a test for that piece of functionality, then implement the code. The user story > test > implement strategy has taken serious discipline to follow and I still find myself going off-script. Upon reflection of this behavior this leads me to the next strategy.
Record Feature Ideas
It is a challenge all creatives have, an idea pops into our head and we need to get that idea down before it is gone. I know I’m not alone in having lost an idea because I didn’t do anything with it in the moment. However, resisting the temptation to completely drop what I’m working on to implement that idea is important. This is the strategy, simply record that idea and revisit it later when you’re not in the middle of another task. Since I began using this strategy I’ve noticed that most of the ideas aren’t complete and need significant time to fully realize what they are. Additionally, it relieves that instinct to drop what I’m working on out of fear of forgetting the idea.
Revisit ‘Completed’ Work Frequently
This behavior has been a thorn in my side since elementary school. I excelled in math early on, but I would frequently score below my ability level. There is a certain amount of pride that comes from getting something right the first time and being able to say, “Yeah, I didn’t even have to check my work”. This has bitten me in the ass more times than I’ve liked to admit, but I’m finally starting to learn from my mistakes. I find myself compulsively reading through user stories or clicking through my site to make sure I’m not forgetting a test case for an idea that I implemented off-script. I don’t plan on stopping this anytime soon and it has saved me from publishing quite a few (but definitely not all) embarrassing bugs. I often hear that voice in my head that says “This is a waste of time”, but just as the story of the tortoise and hare taught is, sometimes slow is fast.
Conclusion
Just as Theseus used a string to prevent himself from being lost in the labyrinth we need to develop strategies to prevent ourselves from being lost in our code. Identifying my detrimental behaviors and building strategies to combat them is just part of the process of mastering this new skill. It isn’t an easy task, but definitely one that is worth the time to practice.
