Learning to code is like exercise. Exercise requires commitment, consistent practice, challenging yourself, and fueling with a proper diet. Likewise, coding requires that you commit yourself and practice constantly. Beyond just practice, you also need to push yourself and try new challenges. You may fail but like exercise you will adapt and learn new things along the way. In this analogy, the fuel you use for your body translates to the resources you use to learn new concepts in coding. As in real life, this is the most important factor in progress. The internet provides a plethora of sources but that’s not always a good thing. If your resources are bad, you will not get the maximum return on the time an effort you have put in.
One of the most difficult aspects of methods and variables in Ruby is scope. Since most of the errors when beginning to learn Ruby will be scope related, it is an essential concept to understand. I like to think of scope as accessibility. Which variables and methods are accessible at a specific spot in the code? As I continue to progress, I find that having a solid understanding of my current scope is essential to good and efficient coding. This ultimately begs the question of why programmers put any restrictions on scope. There is a global scope so why wouldn’t we just make everything available in all parts of our code? The most obvious issue with global scope is variable naming. When working on large scale applications, it is highly likely that different programers will use the same variable names with different assignments. Doing so, would break one side of the code. There is also the issue of app security. Beyond increasing the likelihood of breaking the application, it is not prudent to provide all programmers access to all methods and all variables.
There was no light bulb that went off in my head. There was no single moment of inspiration or clarity that made me decide to learn software development. The calling had been lurking in the background throughout my life. From making websites in the early days of the internet to landing an internship in at an upstart soft drink company that required me to help build a site on the fly, all things were pointing toward this path. Maybe I’m hardheaded or the time wasn’t right but I chose a different path, and then a different one, and a different one after that. While I value the lessons from each path I’ve chosen, the end result was the same for each. I was always left unfilfilled and unsatisfied. I love to build. I love to be challenged. I love to learn. I love to create. Software development checks all those boxes and always has.