I am not the world's greatest coder, although I am getting better every year. One thing that I'm really improving on is my ability to solve coding problems. I'm not talking about those coding challenges that you can get online or in a job interview; I'm talking about those real-world problems, like "How are we going to create an automated test for this?" Here are the seven steps I use to solve any coding problem.
Step One: Remember what problem you are trying to solve
When you're trying to figure out how to do something, it can be easy to forget what your original intent was. For example, let's say you are trying to access a specific element on a web page, and you're having a really tough time doing so; perhaps the element is in a popup that you can't reach, or it's blocked by something else. It's easy to get so bogged down in trying to solve this problem that you lose sight of what your original intent was- to add a new user to the system. When you remember this, you realize that you could actually add a new user to the system by calling the database directly, avoiding the whole issue that you were stuck on!
Step Two: Set Small Steps
I often have what I want to do in my code all figured out long before I know how I'm going to it. And I used to just write a whole bunch of code even if I wasn't sure it was all going to work correctly. Then when I tried to run the code, it didn't work; but I wrote so much code that I didn't know whether I had one problem or many. This is why I now set small steps when I code. For example, when I was trying to write the email test that I mentioned in last week's post, I first set myself the goal of just reaching the Gmail API. I didn't care what kind of token I used, or what information I got back; I just wanted a response. Once I had solved that, then I worked on trying to get the specific response that I wanted. This strategy also keeps me from getting frustrated or overwhelmed.
Step Three: Change One Thing at a Time
This step is similar to Step Two, but it's good for those times when your code isn't working. It's very tempting to thrash around and try a number of different solutions, sometimes all at once, but that's not very helpful. Even if you get your code to work by this method, you won't know which change it was that caused the code to work, therefore you don't know which changes were superfluous. It's much better to make one small change, see if it works, remove that change and try a different change, and so on. Not only will you solve your problem faster this way, but you'll be learning as you go, and what you learn will be very valuable for the next time you have a problem.
Step Four: Save All Your Work
I learned this one the hard way when I was first writing UI automation. I had absolutely no idea what I was doing, and sometimes I'd try something that didn't completely work and then delete it and try something else. Then I'd realize that I needed some of the lines of code from the first thing I tried, but I had deleted them, so I had to start from scratch to find them again. Now when I'm solving a new coding challenge I create a document that I call my scratch pad, and when I remove anything from my code I copy it and paste it in the scratch pad, just in case I'll need it again. This has helped me solve challenges much more efficiently.
Step Five: See What Others Have Done
People who are good at solving coding problems are usually also masters of Google Fu: the art of knowing the right Google search to use to get them the answers they need. When I first started writing test automation, I was not very good at Google Fu, because I often wasn't sure of what to call the thing I wanted to do. As I've grown in experience, I've become better at knowing the terminology of whatever language I'm using, so if I've forgotten something like whether I should be using a static method I can structure my search so I can quickly find the right answer. The answers you find on the Internet are not always the right ones, and sometimes they aren't even good ones, but they often provide clues that can help you solve your problem.
Step Six: Level Up Your Skills
As I mentioned in this post, I've been taking a really great Node.js course over the last three months. I'm not even halfway done with it yet, and I've already learned so much about Node that I didn't understand before. Now that I understand more, writing code in Node.js is so much easier. Rather than just copying and pasting examples from someone on Stack Overflow, I can make good decisions about how to set things up, and when I understand what's going on, I can write code so much faster. Take some time to really learn a coding language; it's an investment that will be worth it!
Step Seven: Ask For Help
If you've finished all your other steps and still haven't solved your problem, it's time to ask for help. This should definitely not be Step One in your process. Running for help every time something gets hard will not make you a better coder. Imagine for a while that there's no one who can help you, and see how far you can get on your own. See what kind of lessons you can learn from the process. Then if you do need to ask for help, you'll be able to accurately describe the problem in such a way that your helper will probably be able to give you some answers very quickly. You'll save them time, which they will appreciate.
Coding is not magic: while there are all sorts of complex and weird things out there in the world of software, an answer exists for every question. By using these seven steps, you'll take some of the mystery out of coding and become a better thinker in the process!
I've moved! I've really enjoyed using Blogger for my blog, but it didn't integrate with my website in the way I wanted. So I...
This week, we'll be talking about adding assertions to our Postman requests. In last week's post , we discussed what various API re...
As software becomes increasingly complex, more and more companies are turning to APIs as a way to organize and manage their application'...
The concept of measuring quality can be a hot-button topic for many software testers. This is because metrics can be used poorly; we've...