Avoiding NEI & TLDR
By: Anthony S. Protho
Tags: Nei, Questions, Debugging, Tldr, Programming

Whether you have been programming for a few years, or are thinking about getting into programming, it is important to learn how to solve many of the problems that will occur when coding. The problem with most programmers is that we tend to be lazy, and by taking the time to document your code with comprehendable comments, the easier it is for us to not only go back and fix our own code, but can help others understand our code too. The best tip for writing comments, is to write comments that your past self would understand, so that your future self 10 years from now will understand too!

Recognize that it is okay to struggle! Struggling is a good thing, because it means that we are learning something. So in this next section we will talk about some debugging tips for helping ourselves strive over our problems. The thing that we don’t want however is for you to be stuck! So if you already know about how to debug, and are still struggling with that bug for the past 2 hours you can skip to the next section titled “How to Ask Questions”.

Debugging Your Own Code

You know your code best! And that means the person most qualified to help you, is you. So before you go on to write your question, we should first take some steps to see if we can solve it on our own.

0. Ask yourself questions: What did you expect to happen? What is actually happening? Were your assumptions about your code right? What is the error message trying to tell us? (if there is any)

Photo by Timothy Dykes on Unsplash

READ YOUR CODE! A lot of the times when debugging, there is typically a typo or two that just wreck the functionality of our code, as well, by rereading our code aloud we can clarify what is happening, and why it is happening rather than our expected output. The classic read it to a friend method works for writers, as repeating the words to ourselves in our head can sound different, and since we are typing the majority of the time, it can help us too. The most popular case of this is the rubber ducky method, in which you can read your code like you are trying to explain it to a friend. Do some research! There are hundreds if not thousands of books on programming, and 10 times as many online resources. It is very likely that someone has faced the same problem as you, or has worked on a simular application as you. DO NOT JUST COPY PASTE, but understand it, and how you can apply those same concepts to your own code. If you do copy and paste, not only have you not learned anything, but you won’t be able to understand your own code, in which you should be the expert on!

Using the search bar:

Google is our friend! and understanding how to use the search bar can help us find the results we need quicker! And what better was to learn than threw youtube.

How to Ask Questions

But what if we can’t solve our problem? What if we are still struggling? Well if you have been stuck on your programming problem for a few hours, it’s time to ask for help. Remember that coding is a team sport! And despite some of it’s competitive atmospheres we are a community of helping one another grow. Personally I love helping people when I have the time to. However, time is the most important part of that sentence. I see on many forms how many questions get outright ignored due to the size of the question, and in most cases these questions suffer from NIE and TL;DR. To correctly write a question, there should be one answer! Your goal as a question writer is to help us help you! So how can you do this?

Be Clear

If there is one thing that I want you to take away from this article, it would be this. NIE stands for ‘not enough information’, and are the type of questions I see get ignored most! This is because most coding problems are convoluted and complex. So saying something like “Does anyone have experience with Javascript” or “Why does my function not work” doesn’t get across enough information for someone to help you, and even if there is a response, it will typically be short answers such as “yes”, or “What language are you using?”. NIE creates long threads of questions in order to solve one simple problem, and takes a lot of time away from both you, and the person(s) trying to help you. Instead we will want to be specific about the things that we ask and include into our questions:

The Technologies you are using. Including Version Numbers, and. operating system version. What was Expected, what you are trying to accomplish — what you expect to happen if everything worked. Revelant Code snippets help us see what is happening, and can even spot syntax errors, or typos causing your error. Note that the person you are asking for help from as most likely never seen your code before, and probably doesn’t have the time to sort threw all the doss, so keep it well documented! It could also be useful to link your Repo, with a route to how to get to your file (“github.com/UserName/Example_Project/App/index.json line: 46”). This isn’t always an option, and you may want to keep your project more private, but in doing so, you can help those trying to help you get a direct look at your code and what might be wrong with it. Error Messages (if you have any) are very crucial for debugging process. What you have tried, explain what happened as a result, and what resources you used that just didn’t help. This helps us skip repeating things you have already tried, and find a alternative solution.

Editing your Question

Now that our question contains all the necessary information, we will want to make sure that it is both professional, and well formated so that you don’t get a TLDR (Too Long Didn’t Read), as a result of just sending a plan text email/question.

Professionalism is important in many things we do. And that includes respecting other peoples time, and the things they have to read. We want to make sure that the question we send contains little to no typos, and makes sense. As well, (as obvious as I think this should be) we must ensure that the things we send are family friendly and appropriate! If you are working on a project that may contain content unsuitable towards those conditions, either user censorship, or give a clear warning, so that those who don’t want to see it, don’t have to! This can also get your email placed in spam, or you can be black listed, so just be respectful. We want to be respectful and accepting of all people in the coding community. Titling sections and subsections of our email can help break down the large message we are trying to send. If your question is very complex it may be necessary to separate sections using bold, underline, and italics to help the reader quickly skim threw everything you have to say. People will typically take 15 seconds to examine whether or not they want to keep an email, or delete it, so make it clear what you want, so that when they have more time, they can truly look at your problem and try to help you. Delete the unnessisary words and phrases that might be making your message much longer than it has to be. TLDR. As much as we want to avoid getting sent this as a reply, we can in turn send a TLDR to the person we are asking help from. This should come at the beginning of your message, and will give a short summary about everything your email is about. Your first paragraph is typically going to be what people read first and can either attract or detract peoples interests.

Next Steps

After sending your question, you should be patient, and not ask the same question. Time constraints are definitely stressful, but remember that we are all very much busy people.

Eventually you should get an email back with some proposed solutions to your problem. However, these solutions don’t always work. So this is the time for collaboration!

If: the proposed solutions don’t work for you, simply show them that you tried what they suggested, any error messages, and anything you were inspired by since you posted the questions.

Photo by Daria Volkova on Unsplash