Back To Blogs
Oliver Partridge 21st May 2018

Debugging your perspective: I know what it does, I made it!

We’ve all been there. Sometimes when developing you will hit a problem that feels like it doesn’t make any sense. It should have been easy, it should be working, and you should be able to see the problem- but you can’t. You try increasingly complex solutions to more far-fetched potential problems, desperately clutching at straws trying to work out what is wrong. Scrapping the thing and starting again is becoming more appealing by the minute. You summon a colleague to make sure you aren’t going completely mad, and they immediately point out the problem.

It’s like you just spent hours trying to fix a car by checking that every part of the engine is working, only to have somebody walk into the room and point out that the wheels are sitting in a neat pile on the ground. It can be an excruciating experience. It is very easy to get carried away pursuing a line of thought while trying to fix a problem. The aim of this blog post is to help you shift your perspective in a somewhat organised manner without the need of a colleague. I’m going to stick with the car analogy because I feel it illustrates very well how ridiculous a bad approach can be, but also because I’m trying to focus on approach in general rather than any particular scenario. In addition, I have left a debugging checklist at the bottom of the article to make things easier. So, let’s get started!

What causes these problems? I find they are usually rooted in one of two beliefs;

  • Firstly, the belief that you know what the thing you have built actually does, or…
  • Secondly, the belief that you were ever looking in the right place to begin with.

On the first point, when developing you have a few ideas in your head at once – you know what your project needs to do, and what you’ve put in place to meet those aims, but this isn’t necessarily the same as what is being done. The thought process is effectively “I know what it does, I made it!” and this makes sense – we let our brains make assumptions and fill in blanks to speed up the development process, especially regarding the basics because we use them so often. As for the second point, it’s tunnel vision. When we encounter a problem, a common first action is to check our immediate vicinity for the cause, i.e. what we were just working on or looking at. This isn’t too bad if you are doing lots of little iterations, but if you’ve had to set up three different components together and then tested the lot, you might assume it was the last thing you worked on that went wrong because it was based on the other two.

No assumptions!

The engine is running… the handbrake is off… you are pressing the accelerator… so the car should be moving! But at what point did you ask “Does the car have any wheels”? Assumptions can be helpful at times, but in debugging they can be a curse. There are of course things you don’t need to regularly check, but if a problem is persisting your first course of action should be to ground yourself. Is this definitely the right car? Does it actually have wheels? Did you put back everything that you removed so you could start working? But most importantly, can you prove what you believe to be the case? If not, you could be creating a red herring for yourself. The basic and obvious nature of these questions is why they don’t always come to mind, but there is a technique you can use to conjure them. Ask yourself, “if I showed this to a colleague, what would be the most embarrassing reason for it to not be working?” Making your way through the list of answers and checking them can be very beneficial. This is still a bit hit and miss however, which leads into my next suggestion…

Be specific – take notes and debug distinctly!

Memory is fallible, so taking notes on mysterious problems when you are debugging can be a great help. The key information that lets you diagnose problems is often in the details of when a bug occurs, so it really pays to write down exactly what happened. Don’t just take down whether or not it worked, too – take note of your input, whether or not the desired effect happened, the route you took to get to your test and any side effects that you notice. You can also sort these methods into groups and record your results that way, if it’s more convenient. Pseudocode to compare your real code against is another good bet. It is effectively a loose plan of what needs to happen and, much like rubber duck debugging (which I will come to later), it will help to bring to light any obvious flaws or missed sections in your code. It is also a great benefit during early stages of development as it will help you to think about the structure of what you are creating in detail and spot problems before they have a chance to manifest. The weakness of this however is that it will not help you to spot any in depth technical issues with each piece of code you try to use.

It’s also a very good idea to fill your code, workflows or anything else you are debugging with big obvious messages detailing what is going on when you move through a process. Break points are great, but it’s often much easier to make a big debug message with a variable in it pop up whenever you do something significant – success, failure and any stage in between. Just be sure to specify exactly what is triggering the messages that are popping up, and only comment them out or switch them off again when you are sure that part of whatever you are doing is working. It can also be handy to make them display related variables as they pop up, as they can provide more clues.

Don’t be afraid to ask for help

It can be difficult to ask for help for a number of reasons. You might feel like you are disrupting another person’s work, wasting their time with a silly problem, or that you should simply be able to fix the problem yourself. You should of course make a serious attempt to debug before calling in help, but it’s also important to weigh up your own time against any disruption you might cause. A five minute interruption isn’t ideal, but if that saves you spending hours trying to fix something then it’s almost certainly worth it. On top of that, both you and the person helping you might learn something and should remember the solution to the problem if it ever occurs again. There is of course an (often preferable) alternative to asking a co-worker for help; asking a rubber duck. This is an extremely effective method for finding where you have gone wrong, but it doesn’t see nearly as much use as it should. In essence, by explaining line by line what your code does to a duck in simple terms so that it can understand you, you can look at things from the duck’s perspective instead of your own and hopefully uncover your problem. The best part is that the duck will never judge you and will always be understanding. There is no need to fear asking it for help and if the duck was unable to help you, you’ve got a strong case for asking a colleague. There are websites dedicated to this kind of debugging that better explain it, and I strongly recommend you visit https://rubberduckdebugging.com – it even has a “Talk to a Duck” section in case you don’t have access to a real-life rubber duck!

Debug Checklist

This list will by no means be exhaustive, and some of the points will likely not be relevant to you, but it may catch some problems for you. Remember, only check these off the list if you can actively prove them!

Facepalm Worthy:

  • Are you connected to the internet/intranet?
  • Are you in the right repository?
  • Are you looking at the right script/workflow/table/car?
  • Have you saved/checked in/deployed your changes?
  • Are you looking at the right version of your work?
  • Are you looking at the right environment (test, acceptance, production…)?
  • Is it supposed to work in this hardware/software combination? 64/32 bit?
  • Have you copied and pasted in something you didn’t need by accident?
  • Are there any misspellings/typos/mis-matched brackets/bad capitalisations/bad whitespace or end of line characters?
  • Did you remember to trigger the function/workflow/script you just created?
  • Have you refreshed/executed the page/your view since making your changes?
  • Caps lock?

Common Problems:

  • Does your test user have the right permissions to use or even see your work?
  • Have you accidentally used American/British spelling where you shouldn’t have?
  • Are your localisation settings the same in all your environments? This includes your web browser if you’re a web dev!
  • Have you included all the libraries (and the right versions of them) that you need?
  • Are your config/settings files correct?
  • Is it a styling issue (invisible/behind something/off the page/disabled/the background colour…)?
  • Have you accounted for null values?
  • Have you initialised the thing you are trying to use? Are your references correct?
  • Are you using the correct version of an overloaded function?
  • Have you cleared your cache? (Ctrl F5 for a refresh and cache clear on most browsers!)
  • Is your screen resolution/zoom/scale moving or squashing things?

Data Problems:

  • Are your database credentials correct?
  • Is your data actually there? In this environment?
  • Are you sending/receiving/using the right data type?
  • Are you sorting or filtering your data correctly?

External Problems:

  • Are your changes conflicting with anybody else’s?
  • Is anybody else using the same data as you?
  • Have settings for the network you are on been changed recently?

Exotic Issues:

  • Has everything broken immediately after daylight savings (very suspicious)?
  • Hardware failure? Can you smell smoke?
  • Solar flare?

Related Blogs


Leveraging machine learning capabilities in application development

In recent years, the digital sector has been transformed by artificial intelligence (AI). With tools such as ChatGPT and DALL-E, public access to AI resources is at an all-time high.

Find Out More

Git integration in Mendix

Mendix has chosen Git as their standard for version control going forwards. Explore some of the differences between using Git and SVN and walk through how developers use Git version control when creating both new applications and when converting existing Mendix applications.

Find Out More

From graduate to expert developer | Matthew Pratley’s Mendix journey

Ever wondered what it takes to reach Mendix Expert level? The Expert certification process is quite different from the other certifications (Rapid, Intermediate and Advanced) and is not only proof of a Mendix developers knowledge, but it also confirms their expertise, proves that they have applied what they know about Mendix in their day-to-day job and shows that others trust their knowledge.

Find Out More

Kick-start your Mendix learning!

As part of my Maths course at University, I studied some modules in which we used traditional programming. With some exposure to programming languages, I had an awareness of software development, but low-code application development wasn’t something I had heard of before joining AuraQ.

Find Out More

Why low-code IS a matter for the board

Before I speak to customers about their technology requirements, my first question is: “What are you trying to achieve as a company?” A quick look at their annual report and the evidence is clear to see – since corporate strategic objectives are set by the board and published to the markets. Almost without exception, these objectives will be aligned to growing revenue and reducing cost.

Find Out More
Drag