If It Ain’t Broke, Fix It? (And Learn)
So its a typical grey Monday morning in July for UK, which means its time to blog!

Its the start of week 4 of the pre-course at Makers Academy. Next week it’ll start for reals and I’ll be commuting down everyday just like a real job. I’ll have to wake up early just like “normal” people do, which will be tough for me!
But I really look forward to it. One of my main reasons to do Makers was the networking aspect of it, which is difficult if you are learning by yourself at home. I’ve already had a few meets with my fellow cohorts and even a cohort above me and everyone seems cool. We all seem to have a similar attitude of learning and self improvement.
This week we built our first Ruby program. Playing around with menu screens, data entry with the ability to save and load files. Its pretty overwhelming looking at the final code since its quite long, but starting out small and then adding things bit by bit logically it becomes more manageable.

One thing that I’ve tried to get used to is to be willing to go into my code and change it. This is something that is difficult to do because once we get something working, we don’t want to break it. One missing character, one missing end word to a loop, or even the odd curly bracket that is a bracket can stop the whole thing from working!

Its the balance between getting something working at all when we start out, to slowly improving it, by refactoring it to more efficient structures and functions to work with.
I have found though it has gone too far sometimes on forums. I see a lot of arguments over millisecond efficiencies and it starts out with a beginner asking a basic question. Coming from the poker community, another very smart community, its going to be hard to run away from the “I am correct [in a black and white way of thinking]” mentality of some people. Lets hope that I don’t end up like that.


It has been tough finding the balance between learning and looking at the answers to learn. On CodeWars, its a great place to practice by completing the exercises, and we’ve been encouraged to level up.
On some of them I have spent hours and hours trying to make it work and in the end give up due to the time restraints we have to undertake in order to complete the week’s work set. It can be a hit to your ego to give up, and also hugely annoying that your unsuccessful 12 line code was completed by a 2 liner that used a method that you’d never seen before!
Such is the process of learning! Learning to learn is one of the biggest skills we should have not just in programming but in all walks of life. Enjoying this process gives me much more satisfaction then caring for the result only.
Code happys ppls! Til next week…
