Mistakes – Like Riding a Bike…
There comes a point in your progression of learning to
This is especially true if you’re simply writing test scripts in your role, which may not always demand the most technical of code to be written. That’s not to take away from the accomplishment of coming from no programming experience to writing test scripts, however.
The trouble with getting caught in this mindset is that it’s all too easy to quickly waste all that hard work you put into getting to that point in the first place. Programming, no matter how experienced you are, is something you absolutely must do regularly. Whether you’ve been a software developer for thirty years or a hobbyist for thirty days, a lengthy spell away from your favourite IDE will see you quickly hit a mental block when it comes to writing your next piece of code.
You might think “it’s like riding a bike”, and that may be true to an extent. While you’ll never forget the problem-solving skills you learn and the logical approach required for programming, it’s the syntax required to write the code to solve those problems that you forget.
Let me give you a personal example of what I mean. LINQ and lambda expressions in C#, I remember when I’d see those in other peoples code, it would make me feel so stupid. I just could not wrap my head around how they work, every time I thought I was starting to understand them, I’d see a really lengthy expression that would just put me back to square one. However, I was determined to learn and started to use them myself, and over the course of a few weeks, I was starting to include my own LINQ lambda expressions in refactored code. It was finally starting to click and I could write them pretty comfortably without relying on Intellisense to guide me through.
At this point, I was finishing up refactoring the code I was working on so was no longer going to be writing these lambda expressions regularly. I felt so comfortable with them though that I just assumed that next time I needed to write one, I’d just pick up where I left off. How wrong I was…
It had been a good couple of months before I had to use them again properly, and the second I was required to write a complex piece of LINQ code, I went right back to feeling like I had no idea how to use them, and had to rely heavily on Intellisense to get me through. It wasn’t that I didn’t understand the logic any more, it was the syntax required to put that logic into practice.
Moving away from the impact for a second, there is another cause for all the above to happen…the internet. There’s a joke among modern programmers that you don’t even need to know how to code these days to be a software developer, you just need to know how to use Google. While I don’t believe that to be entirely true, the sheer amount of knowledge available at one’s fingertips with a good search term does
You can Google any programming problem these days, and whether it be a video tutorial, a blog article or a StackOverflow post, you will likely find a number of ways to approach that problem. If it’s the latter, you don’t even need to write the code to solve your problem, you can just copy and paste and make a few variable naming adjustments if you find the right answer.
So, if what I’ve just said is true and everything you’ll ever need to write code is available online, why is any of what I said at the earlier part of the article about forgetting and needing to constantly use what you learn, even an issue?
Because coding via Google teaches you nothing. That might sound controversial and I’m sure many would disagree, but simply recycling the code from a forum post and not understanding why or how the code works will simply mean that while you’ve fixed the problem that time, next time you’ll just hit the same issue, you haven’t learnt what it was about that code you used that solved your problem. To truly learn how to code, you need to write code and write it often.
One problem with writing code often, is that if you’re not coding at work, when should you code? Sitting in front of a blank IDE and expecting to write meaningful code is just something that isn’t going to happen. You need a problem to solve or a project idea that gives you purpose and a reason to write code. It doesn’t need to be the next Flappy Bird or Adobe Photoshop, find something you do regularly on your computer, no matter how small of a task it might be, and create a small program to do it. I’ve written far too many console applications that do virtually nothing of any use to anyone else other than me and the way I use my computer, but they gave me a reason to write code and use things I’ve learnt again and again to keep them fresh in my memory.
Even if you do the above, but you ever feel like you’re comfortable and you’ve learnt “enough”. Believe me, you haven’t. When it comes to coding, you can never know too much. Find ways to improve what you do, with language features or libraries you wouldn’t normally need to use. It’s also worth mentioning, the syntax in any language evolves so fast that you almost need to learn just to stay relevant. Going back to my earlier LINQ and lambda expression article, back before C# 3, this wasn’t even available in C#. When these features were introduced, it would have massively reduced the amount of code needed for tackling certain problems, but if you didn’t bother to learn, you’d just be stuck doing things the old and clunky way.
Even if you think you’ll never need to use a particular language feature, take the time to learn it. Because while it might seem pointless now, it could be the perfect fix to a problem down the road and not only that, it’s only going to improve you as a coder to have more tools at your disposal.
One last thing to say is that by relying on a good understanding and a strong pool of knowledge to work from, you’ll be a far better coder and automation tester both in the short and long term. There are times even today when you can’t rely on the internet to bail you out, a technical test in an interview is a perfect example of this, so while it may be tempting to just Google that problem “just one more time”, don’t.