Coding to improve yourself
This post is part of the beauty of programming series, and it's been a while since my last post, but that was due to the private obligations I had. Just a quick reminder, this series of posts are not technical, they are more about me and my attitudes towards programming as a craft and the aim of articles is to inspire and encourage people to code with more passion and love.
So, what do I mean by coding to improve yourself? Well, the beauty of programming is the coding itself, it's a path of constant improvements, it's never the same, you always learn something new and gain new perspectives. This statement is well known to most developers so why bother mentioning this? Because that's just the surface, this goes way deeper.
For example, at the beginning of my programming I saw abstraction as something too theoretical, I knew what abstraction is by book, but never through code (to those who may not know, the abstraction is the process of hiding implementation details). Today I see abstraction everywhere, not just in coding, I'm amazed how humans can abstract something to that point that you don't have to know a thing on how it's working, you just use it. Let's take a mobile phone as an example, you don't need to know anything about operating systems, networking, protocols, etc., all you have to do is to swipe with your finger, isn't that amazing? Or the human body itself, you don't need to know what internal organs you have in order to use it, you simply use it. Isn't realizing these facts through programming is actually the beauty of programming?
So, how do you improve yourself through coding?
- You gain a new perspective on the world around you.
- You develop planning skills over time
There are quite more improvements, but these are the ones I'd like to emphasize.
Gaining a new perspective on the world around you
As I mentioned above, one of the new perspective I gained is looking through the lens of abstraction. I simply look at something and think to myself: "I'd never come up with that idea, that's amazing! This is how giving knowledge works, you abstract the complexity and give it to someone else to use it without making them bear the burden of that complexity".
How is this beneficial to programming? You realize that you have to write a code in a way that other developers can reuse the code without having to peak into class/method in order to use it, they should be capable of simply using it, otherwise, that code is not abstracted.
Another thing I realized on my road of programming is that standardizing is the key to universal happiness. Why? Take as an example OSI (Open System Interconnection) model, it's simply a conceptual model that standardizes communication layers. What did we gain by this? Well, my computer and your computer can communicate without a lot of hassle, but without OSI standardization you and I would have to pay a lot of money just to make our computer capable of communicating with each other.
What did I learn from this? I learned that having something everybody agrees upon saves up a lot of headaches. This can be applied everywhere, you can standardize the food that is being prepared for cooking. Why would you do this? Because this way you're sure that each meal is prepared with equal preparation and you can be sure of the quality.
How is this beneficial to programming? If everyone wrote the code in their own way it would result in a total mess, maybe not at the beginning, but lately for sure once the code piles up. Take the pile of clothes as an example, put pants and shirts together and you'll separate them quickly, but putting a huge pile of different clothes makes it more difficult to find what you are looking for. The same principle applies to code, without some coding standards and practices, it can lead to chaos.
Gaining planning skills
As a first-year student, I rushed to code anything that has been assigned to me, and now I'm realizing that was normal, I was just too excited about the stuff I'm about to build or the solution to a certain problem.
Now I do have those moments of course, but most of the time I do planning first. Not having a plan is like wanting to visit some far distant place without a map, you can do it on the fly of course, but in most cases, it will be messy. Having a plan for a piece of code is like having a sight of the road that needs to be traveled and the business requirement is the final destination. If your road is a little bit longer you can consider using shortcuts, which can turn positively depending on the type of a shortcut.
A practical way of looking into this metaphor of the road is a requirement to build service for sending email invitations. Let me take you on a journey: Imagine you are working on a web platform for planning a lot of different events like birthdays, anniversary, wedding, etc. and everything works perfectly, UI is perfect, customers are satisfied because there are no bugs, but there is one vital piece missing, you have no way to notify people about the event, so you get a task to build a service for sending email invitations. And let's imagine you rushed a little bit, built the sending invitations service and everything works flawless, sounds cool? Well if that's the end of the road, then indeed it is, it's awesome. But one day your customers want you to send notifications on Facebook Messenger. This is the moment when you sweat because the system you designed in a rush cannot support Facebook Messenger without some refactoring, oh, and let's take this one step further: there are no unit and integration tests! Sounds like hell? Indeed.
So this thing can go further down, customers can latter on require to send notifications on Slack, Skype, WhatsUp, Viber or similar. Without planned class structure and way to test, this can be a road of chaos. You may be tempted to say: "I planned the road to the request that was given to me and I fulfilled it, it sends the email notifications." and I got to say that you are right, but I got to say that's because you planned to stay on that place where you were traveling instead of planning the next destination. If you've just planned to go further you'd see that other services will come forth.
As you can see, programming is a journey, and if you don't enjoy traveling, you may miss providing exceptional service. Caring for your craft will bring you visions for your craft, a plan, so build as you would build it for yourself and all pitfalls and roads I've mentioned will be seen in the vision, and those obstacles will be overcome.
Final notes
I hope I inspired you to approach to programming with more passion and love, that I have shown you that programming is not just dry typing into a keyboard, but instead constant improvement of yourself.
Seeing the beauty in your work and craft is crucial for a quality, but most importantly: your happiness. The main aim is that you improve yourself because of that beauty you see.
Thank you for taking the time to read, I really do hope you've enjoyed it.
