Articles and courses on learning to code are all over the web right now. It seems everyone wants to code, and for good reason, it’s super fun.
So I wanted to write a bit about my experiences with learning to code and what it’s like to code in the real world. This is not so much a “how to” article as it is my own personal opinion.
I started to code at the age of 12 back in the late 90’s because I wanted to create my own computer games. Back then, the Internet was a lot less helpful than it is now, although to be fair, it was still pretty good.
There were no coding websites like code.org and YouTube wasn’t around, so I had to search for tutorials and try to figure things out for myself. This was actually one of the best things that could have happened because I was forced to explore and experiment on my own.
Don’t get me wrong, all the resources we have available now are brilliant, and I use code.org and hour of code regularly to teach my kids the basics of programming, but I think having to rely on trial and error and making my own mistakes turned out to be my greatest asset in the long run because I’m used to not having the answer handed to me.
Programming in the real world is a lot less about language features and having things work the first time around, and much more about problem solving. But more than that, real world programming is about results. It would be wonderful if we could all work on whatever projects we want, using whatever new language or framework we want and have the luxury of starting from a blank canvas, but the reality is most of us who become working programmers have a boss and business requirements that dictate what we can and can’t do.
Businesses don’t generally care about programming languages and design patterns, they want you to get the project finished and out the door as fast as possible in order to generate income. A project sitting around being discussed by developers and designed using the latest software engineering methodology doesn’t make the business any money.
My first programming language was QBasic because it was freely available and already installed on the computer I had access to at the time.
Honestly I don’t remember much about how to use QBasic, but what I do remember is the process of writing a few lines of code, breaking things, trying to fix it, breaking something else, over and over again until eventually the code worked but didn’t actually do anything I wanted it to.
It was frustrating, but it was also incredibly rewarding because at the end of the day my brain became used to the debugging and testing process, which in my mind is much more important than anything else I’ve learned.
Some might want to argue with that last statement, that debugging was the most important thing I learned, but it’s true. Very rarely do we as programmers get the opportunity to have our code work first time round, and even less often do we get to work on something new. 90% of my day job is fixing or extending existing code, and you can’t do that without knowing how to debug. The language itself doesn’t even really matter, it’s the mindset and the process you go through in order complete your task. And in all honesty, debugging broken code and extending existing code are both very similar activities.
Let me explain why. When something is broken the first thing you need to do is try to recreate the issue. Often this is done by running the code and watching what happens, though obviously, the more familiar you are with the code the faster you can start to narrow down what might be wrong.
The point is, you start by testing the running application. Same goes for when you need to extend the code to do something new or different. You can’t just open up your editor or IDE and start coding, you need to familiarise yourself with how the existing code works. What’s the process it goes through, what input does it accept and what output do you see?
Often, being able to track down a bug, or the specific file of a running web application that you need to modify is the hardest and most beneficial part of the process.
For example, there’s a web application that I support that runs 8 separate business websites. The application is written in very old PHP code, is not written using a framework, stores data in multiple databases and has been gradually extended and modified over several years. It’s actually quite scary when a task comes up for this app as it’s always risky, it’s always time consuming, and modifying anything always leads to unexpected issues elsewhere in the code.
Many times over the last couple of years I’ve thought how good it would be to rewrite this monstrosity in something more modern, a new framework, and being able to start fresh. But the reality is, not only does my boss not see it that way, rewriting an existing application, especially one that has years of custom logic, is generally always a bad idea.
Millions of lines of code, much of which runs our entire society, exists out in the “real world” that will likely never be rewritten into the new popular languages. Why? Because they work, and the risks and expense of rewriting them far outweigh the task of maintaining them.
It’s unfortunate (sort of), but very true.
Which leads me to the next most important skill for a programmer is the ability to read and understand someone else’s code.
I’m not talking about reading a simple CRUD app you found on github, I’m talking about a real application. One that’s a total mess would be a great learning experience.
I learned more about software development trying to understand that beast of a code base I just mentioned than I ever did reading tutorials or watching videos. Not because it’s an example of good coding practices (it’s not), but because it’s an example of a real application that has a real commercial use and for the very reason that it doesn’t follow good coding practices. We all know the real world is not as nice and organised as we would like it to be. Software is as a much an expression of the real world as anything else humans have created, because we are messy and unorganised.
Never in over 10 years of being a working programmer have I ever had the “benefit” of working on an existing code base that was well organised in every way. Again, some might argue with that, perhaps it’s just the experiences that I’ve had, or perhaps I’m not as good a programmer as I think I am, regardless, the real world of programming often sucks.
So, if you’re a new programmer, or an existing programmer who wants to step it up a bit, what are you supposed to do?
My advice, is to not focus on learning all the new, latest frameworks and programming languages, but focus on the basics. Learn how programming languages themselves work. Write your own framework in your favourite language.
Next, find existing open source code written by someone else and study it. Try looking on github or Sourceforge. Get something (large and messy) installed and working, then try to extend it, or fix a bug.
I also recommend learning beyond the programming layer. Learn the platform and operating system your code will run on too. I specialise in Web Applications running on Linux and (more often than not) Apache. But I also know Nginx quite well and can jump between the two if I need to.
Most importantly though, is learn to experiment. Don’t just rely on the answers being given to you, learn to think for yourself. Google is a helpful resource, as is StackOverflow and Github, but trial and error, printing out variables and breaking things (just not in production) are just as important.