It’s pretty exciting to create your very first ruby app or gem. It kind of makes you feel like you belong on a minimal, low level but belong none the less. When we decide we want to become a developer, we strive to be seen as worthy. Imposter syndrome is not a joke. Once you have something complete that works and was created by you; You feel like you are part of that community. It is then that you can look back on what you did to learn from the positives and negatives of creating that gem. This article explains some of the lessons I learned while doing this and hopefully help someone else down the road.
-
Prepare and write out a plan. I tend to have ideas and would instead action items then prepare to do them. However, without proper planning, those ideas are fraught with errors. When coding, it is imperative to have a plan so that you don’t go down a rabbit hole. My first attempt at creating a gem wasn’t appropriately planned and thus failed. I just wanted to get some information, but it was unclear how I was going to get it. It would be best if you also had an idea of what the completed product looks like so you can determine the best path. In this particular gem, I had a good idea where I wanted to get to, which helped me determine how to get there.
-
Be flexible. The road to completion is paved with good intentions. Sorry I used the quote differently! We all think we know what we are striving for and how we are going to get there. Unfortunately, we sometimes can’t finish the project the way we think. That thought pattern happened to me, and I fought it tooth and nail, which caused a long completion time. If I hadn’t been so stubborn about my gem and the way it should go, I would have slept a lot better! Another critical fault of not being flexible is that you are blind to other ways. If you open your eyes, you may be able to change the code and get to get completion better and faster.
-
Work in Small Batches, Use Fake Data. When you are in the zone, you usually want to go and go without doing anything else. Put the head down and plow through all the tasks while the getting is good! WRONG! I had a short time where I coded like that and didn’t worry about whether the code was working. I came back to troubleshoot, and it took forever to go through. Unfortunately, coding doesn’t work this way. Too many actions depend on other actions, and it takes forever to debug. I have found you are far better stopping frequently, git add and make sure your code is working. Small snippets allow you to quickly find any bugs as you don’t have much to review. The next part of this idea is to use fake data if you have to first. In my project, where we were scraping data, it was easier to get the method to work with fake data first. If it works with the data, it is a lot easier to bring that data into the app. Finally, Commit often and check to make sure it works!
-
Break up the Code. Breaking up code into small boxes works simultaneously with working in small batches. Always try to have one class do one thing well, and each method does one thing. It seems this is a standard in OOP, but many developers like to have these vast classes or methods which are too hard to read, let alone figure out how they work. By compartmentalizing as much stuff as possible in a box, it makes it easier to see what it does. I also think this makes it easier to reuse code in other areas. Finally, when doing this make sure you appropriately name these conventions so it makes sense to someone down the road.
-
Binding.pry. I don’t think debugging is taught enough in development. When I watch good developers, they seem to spend as much time in pry as writing original code. While I never fully grasped the beauty of binding.pry, it was indeed a lifesaver in my app. Being able to see what methods are available through the use of ls command was great for starters. Next, I was able to use CSS selectors to see what would come up in my code. Finally, I can run it to see what the value of an argument is and if that is what I want and need. I am missing all the uses, but suffice to say this is something I will spend a lot more time on.
-
Have a Mentor. I don’t mean you necessarily have to have a paid coach or anything expensive. You do need a place to ask questions and bounce off ideas. In case you get stuck, you also can have someone look at what you are doing, shake you up a bit and then turn you down the right path for completion. For me, that was my section coach at learn, Beth Michelle Schofield. For others, that coach/mentor can be Reddit, Quora, or StackOverflow. Just make sure that you have a place to vent a little, ask for help, and listen to advise. You will be able to accomplish whatever you are doing much faster with a thoughtful set of eyes looking at your work.
I just shared with you six ideas I had on how you can improve your workflow and app building. These are not the only ways, but they stood out to me. Do you have any to share?