Writing code, whether you want to do it as a hobby or make a career out of it, has it advantages and disadvantages. I may explore the disadvantages some other time. For now, I will be focusing only on the good stuff that learning to code has to offer.
tl;dr - Coding really has a lot of benefits to offer when you pick it up and stick to it for a while. The ones I cover are how you become more mentally prepared and comfortable with dealing with issues outside your comfort zone, appreciate and encourage simplicity and clarity, pay more attention to details, look to always improve things and situations, and what I think is the most important benefit: you become more intentional, constructive and logical in how you deal with problems.
Gif from tenor.com
One of the most obvious benefits learning to code would instil in you, with time, is the "problem-solver" mentality. The one thing software solutions generally share, irrespective of target industry, is that they were built to be solutions for existing problems. So, if you decide to take up programming and you start learning about certain programming principles and software design concepts, make sure you're applying what you're learning to create something that solves a problem, no matter how simple or small, even if it means building a calculator that just handles addition, subtraction, multiplication, and division. Making a habit out of this would definitely put you on the way to becoming a "problem-solver".
Once you start thinking like a "problem-solver", you find that you would take a similar approach to solving non-programming problems. You would see yourself looking to clearly define a problem, breaking it down, tackling and solving each "mini-problem", and then finally coming up with a solution that addresses the original problem. Truth be told, we actually all solve problems in our day to day lives. Writing code just makes you become more intentional, constructive and logical about how you go about solving certain problems.
Gif from tenor.com
I must admit that early on, I didn't always like taking on software tasks I was not familiar with. But now, after being involved in a lot of software projects, the main reason I shy away from such tasks, is because I perceive that the amount of time or effort it would take to come up with a solution is just too much for me. It's usually not because I think it's impossible.
Like I stated before this wasn't always the case. At an early point in my career as a software engineer, my boss at that time showed me how a programming task I had deemed impossible was actually possible and simple, doing this with some keystrokes on his laptop and me standing behind him and watching him do it. The embarassment and awe from that moment has never left me, and it set me on the path to always looking to exhaust the options avilable to me before I accept that carrying out a task is impossible.
Also early on, whenever I came across errors in my code or software (these are referred to as bugs in software engineering literature), it used to really terrify me. I would do my best to write code so that there were no errors, but of course from time to time, there were still errors. After a while, I got to see that errors could be such useful points of learning, and I embraced them more. And yes, sometimes fixing these errors can be frustrating, but there's usually something to be learned at the end of the day.
So, while the habit of not shying away from challenges or overcoming the fear of making mistakes when doing something will take time to build, at least in my own expercience, it has been something that writing code has definitely helped with. I believe it can help you with that too.
Gif from tenor.com
The are two software engineering design concepts that new coders usually pickup quickly. They are Don't Repeat Yourself (DRY) and Keep It Simple, Stupid (KISS).
The idea behind KISS is to make your coding and progamming logic as simple as possible, usually by making sure every functionality expected of the solution is limited to units of code. As an example, say you want to create the sum of a set of numbers provided by a user. I will be using fake code (a.k.a. pseudocode in software engineering literature) to illustrate:
function sumOfSetOfNumbers() {
Get a set of numbers from a user and add them all up.
return their sum.
}
As simple as the above statements looks, there are required steps to take that are not mentioned in the above statement. First, we have to get this numbers and then know all numbers that will be in our set. Also, to carry out this mathematical operation of addition, we have to make sure we are dealing with actual numbers such as "1", instead of "one", "2" instead of "two", and so on.
function sumOfSetOfNumbers() {
If (number to be put in set is an actual number) {
put number in the set.
} or else {
ignore.
}
Add up the numbers in the set.
return their sum.
}
Now this works, but if I were to apply KISS:
function verifyNumbers(theNumbers, setOfNumbers) {
for (every singleNumber in theNumbers) {
If (singleNumber is an actual number) {
put singleNumber in setOfNumbers.
} or else {
ignore.
}
}
return setOfNumbers.
}
function sumFromSetOfNumbers(setOfNumbers) {
s = Add up the numbers in setOfNumbers.
return s.
}
function sumOfSetOfNumbers() {
theNumbers = inputs from a user.
setOfNumbers = empty set.
setOfNumbers = verifyNumbers(theNumbers, setOfNumbers).
totalSum = sumFromSetOfNumbers(setOfNumbers).
return totalSum.
}
For DRY, the idea is to cut out any repeated programming logic into a seperate unit, and where ever that programming logic is required, that unit that holds it is called at that point instead. As an example, say we wanted to expand our program to also calculate an average from a set of numbers and we only want to deal with numbers greater than zero:
function averageOfNumbers() {
Get a set of numbers from a user where all of them are greater than zero and calculate the average.
return their average.
}
Hopefully, it's obvious that while this works, we can do better, just as in the previous illustration. So to get numbers greater than zero, we will have to make sure we're dealing with actual numbers:
function averageOfNumbers() {
If (number to be put in set is an actual number and is > 0) {
put number in the set.
} or else {
ignore.
}
Add up the numbers in the set.
Divide the total by the number count from the set.
return the average.
}
You would notice the similarities that are "number to be put in set is an actual number" and "Add up the numbers in the set". This is where DRY comes in. So we change it up a bit, using the unit of code we already created to deal with those parts:
function averageOfNumbers() {
theNumbers = inputs from a user.
setOfNumbers = empty set.
setOfNumbersGreaterThanZero = empty set.
numberCount = 0.
setOfNumbers = verifyNumbers(theNumbers, setOfNumbers).
for (every singleNumber in setOfNumbers) {
If (singleNumber > 0) {
put singleNumber in setOfNumbersGreaterThanZero.
increase numberCount by 1.
} or else {
ignore.
}
}
totalSum = sumFromSetOfNumbers(setOfNumbersGreaterThanZero).
average = totalSum divided by numberCount.
return average.
}
We could simplify further, KISS, and create a seperate unit for filtering out numbers less than zero, as such:
function verifyNumbersAreGreaterThanZero(theNumbers, setOfNumbersGreaterThanZero) {
for (every singleNumber in theNumbers) {
If (singleNumber > 0) {
put singleNumber in setOfNumbersGreaterThanZero.
increase numberCount by 1.
} or else {
ignore.
}
}
return setOfNumbersGreaterThanZero.
}
function averageOfNumbers() {
theNumbers = inputs from a user.
setOfNumbers = empty set.
setOfNumbersGreaterThanZero = empty set.
numberCount = 0.
setOfNumbers = verifyNumbers(theNumbers, setOfNumbers).
setOfNumbersGreaterThanZero = verifyNumbersAreGreaterThanZero(setOfNumbers, setOfNumbersGreaterThanZero).
totalSum = sumFromSetOfNumbers(setOfNumbersGreaterThanZero).
average = totalSum divided by numberCount.
return average.
}
I hope these above illustrations gives you an idea of how DRY, KISS, and other similar programming concepts are intended to guide the coder into writing and creating software that is simple to read through the source code (the code written by the programmer) and optimised for performance. You would find that after a while of making it a habit of optimising code and software, you would begin to see tasks in your everyday life that can be simplified/optimised and how you can go about doing that.
Gif from tenor.com
In creating a software solution, especially one that has a lot of features, there would be a lot of things to keep track of and clarify. These could possibly include how parts of the software would look, if it's going to have a user interface, how users will be interacting with different parts of the software, the design for data storage if necessary, authenication and authorisation mechanisms if required, etc. After being involved in a lot software projects where all these details have to be spelt out, you could easily make a habit of keeping track of things, both large and small. When you come across everyday problems, your mind could instinctively work towards covering as much aspects and perspectives to the problem as possible, and then possibly come up with a well thought out solution to that problem.
This practice of paying attention to detail is also seriously put into use when building software in these present times and catering for the proficiency level of users that would be using your software. It's easy to assume that users that would be using your software will have satisfactory technology or computer competency, but after putting software into the hands of users a number of times you would quickly come to realise that users are not generally as competent as you would expect them to be. Armed with such knowledge about potential users of your software product, you find yourself empathically thinking about the possibly least proficient user that would be using your software. This would usually guide you into building features into the software that would help users have a better experience with your software, and features that would limit users ability to damage or totally destroy the solution, but instead make the software recover from mistakes and misuse where possible. This could translate into dealing with your daily non-coding issues, where you're coming up with solutions and figuring out how people (around you) will be dealing with or be affected by the potential solutions.
Gif from tenor.com
Even while paying attention to details, you couldn't possibly cover every kind of user that would be using your solution, nor the different kind of scenarios or conditions under which they would be using your software. And as far as I am concerned, that is a good thing. Such a limitation can make you humbly approach the process of improving your software, knowing that the software can always be better and improved upon.
Having this mentality to creating both software and non-software solutions would make the solution provider interested in and sometimes keen on getting feedback concerning solutions. You may never create the perfect solution for everyone and every situation, but handling feedback properly can bring you closer to achieving that.
There are other benefits to coding than the ones I have mentioned here, but these are the ones that readily come to my mind and I feel are applicable to other areas of life asides software. You do not have to be a professional software engineer, software developer, or programmer to gain these benefits. I believe coding as a hobbyist would bring some of these benefits to you as well. You may not pickup these benefits from your first day of coding, but with time I believe you would come to notice them and more. I hope this encourages you to find a coding beginners course or programme that you like and start your coding journey. Wherever that takes, I hope you do have fun while you're at it.
Have something you want discuss with me concerning this write-up? Or questions? Or you spotted a typo you wanted to point out to me? Contact me on Twitter, with a link to this blog post. Or, if you just want to say hello, that's fine too. š
Copyright Ā© 2019 ā 2021 Kingson Chinedu Odogwu