My two greatest challenges while learning software development

“The greater our knowledge increases, the greater our ignorance unfolds.”
― John F. Kennedy

I studied Computer Science in school. Specialised in the software side of it. After graduation, I felt like I knew quite a lot. I’d done a couple of projects in class, and a few side projects so coding wasn’t really new to me. Now I could be paid to write software, right? Wrong.

What I didn’t know was that there was a lot more that went into software development than just writing code that worked. There was a lot more that I needed to learn. And I mean a lot.

OOP

I hated Java and C++ in school. Why, you ask? Classes, objects, methods. I never understood them, and didn’t care to. Why should you complicate your code? Just write a function that takes care of what you need. You need something else taken care of? Write another function. It could be because my first language was C, but writing code in the traditional top-down approach of structured programming just worked for me. I stuck with Javascript after C because I knew I could get away with sticking to functions 😅.

Long story short, I couldn’t get away with it for long. There are a lot of benefits to going the OOP way. I knew this, theoretically, but it really hit me when working on a bootcamp project developing an api with Python. I realised there was too much repetition in my code. Files were getting really large and things were getting out of hand. There must be a better way to do this, I thought. Classes. Methods. Inheritance. I had to learn OOP.

Getting to wrap my head around it has not been easy, but since I did, programming has never been more enjoyable. I feel like I have a better understanding of the codebase, and everything just fits together so nicely. Which brings me to the next thing:

TDD

Yes, I learnt about testing in school. Blackbox testing. White box testing. All the theory. But I never thought of testing in terms of test driven development. I thought testing was for users. Just write the software and see if it works. If it does, release it and work on improvements later. If someone says it doesn’t work, well…

Again, I heard to learn this from scratch. It was pretty hectic since it was completely new to me. I just couldn’t follow the process: write failing test, write code to make the tests pass, refractor. I preferred my own way: write code, write tests to pass, refractor. But I found that that also didn’t hold up very well when I found out my tests passed even when the output was wrong. There’s a reason to the systems that exist.

I’ve learnt that writing tests first really gave me a wholistic overview of the task at hand, and kind of like a goal that I had to achieve with the code I was writing. This helped in my productivity since I have to focus on one thing at a time, making my code cleaner.

In conclusion…

Theres a lot more that I keep learning with each passing day but I’d say the most important thing I’ve learnt is that if you never get yourself out there to learn new things, you’ll never know what you don’t know. If I never pushed myself to engage in bigger projects than the ones I was used to, I never would have seen the importance of OOP. If I didn’t push myself to get into professional development, I never would have seen the importance of tests. It’s possible to just sit and think you know how things work, but there’s always more, a lot more that you probably don’t know. If you feel like you’ve not learnt something new for a while, you’re probably settling into mediocrity. Never settle. Keep growing.