Like many things in life, people get stuck doing certain things. We come across different challenges preventing us from moving forward and take steps to where we want to head towards to. In a similar way, you get stuck while programming. If you feel embarrassed about asking this question to someone and decided to anonymously find an answer on the web, let me tell you this is an excellent question! and there’s nothing to be ashamed of.
Whether you write code for a living or enjoy developing random projects during your free time, it is normal to get stuck when programming. Whether you are a new programmer or have 20 years of working in the industry, programmers always get stuck with a problem. Programming is not about the act of typing words and writing code, but solving problems.
Some problems will be more challenging than others. Some will seem simple but they are more complex than what we think. Sometimes you believe you can fix the problem in 5 minutes, but you end up spending 10 hours fixing it. Sometimes you don’t even know how long it could take to figure out something and you end up making it work in a couple of hours. Programming could be the best thing it could have ever happened to you when you figure something out or the worst thing that has existed on the planet if you are stuck for hours or days making something work.
Thoughts about quitting programming often come across to new programmers. The main reason is that everything is hard at the beginning. Whether you make your first HTML table, or style the border of a card using CSS, or get data from the database using an API, etc, things seem simple and straightforward are not making you frustrated as your instructor or more senior coworkers can make things work in a matter of seconds while you can make it work in a matter of hours or even days.
It wouldn’t surprise me either if more experienced programmers have thoughts about quitting as well. Regardless of where you are in your programming journey, give it some time before you make any drastic decision.
Contrary to what most people will say, it is ok to quit programming. There is nothing stopping you from quitting programming. There will be people, especially those who are in the industry who will strongly encourage you to not stop programming. However, this decision is personal and people should understand no matter what they think. Sometimes, it is not the best time to program. Sometimes, you don’t have enough time to dedicate to programming. Sometimes people are better at learning other things, and that is normal.
However, before you make the decision of quitting, I will share my piece of advice. I strongly believe anyone can program and make a living of it. Anyone who is willing to go through the struggles and overcome them can learn how to program. That’s why should not quit programming right away. Getting stuck constantly is one of the many obstacles you will find when programming. Training your body to get used to being in uncomfortable situations is hard and sucks for anyone. Nevertheless, once you pass through those obstacles the feeling of satisfaction is priceless and cannot be described with the joy once you make things work out.
If you are reading this article, that means you have internet. Think about the people who wanted to be programmers at other times. There was no such thing as StackOverflow, or YouTube, or Google, or even worst no internet. Learning how to program had to come from a pure desire to make things work. Programmers had to buy and read through extensive technical books in hopes to get an answer to help them get unstuck.
Thinking about quitting programming in those times seemed more justifiable due to all the struggles programmers faced due to the technology stages they were during their times. The desire to move forward and develop great things lead to many programmers making it more accessible for newer generations to get their feet wet in the world of programming. With more and more available resources to learn how to program and even to solve common programmatic problems, there has never been a better time to get in the world of programming than now.
As previously mentioned, it is ok to get stuck. What matters is what we do to get out of that situation. As you gain more and more experience you start developing the skills to get unstuck quicker. There are some tips in case you need help trying to move forward. Chances are you have tried some of the following tips. In case you haven’t tried any, give them a try!
Recognizing you are stuck might not be that obvious at first. However, realizing you are in a place where there are more unknowns than clarity is more powerful than you think. Failing to recognize it could lead to spending unnecessary time trying to make things work that are not that necessary.
Not because you don’t know how to do something and can’t figure out how to make it work within 5 to 10 minutes that means you are stuck. Confusing the definition of getting stuck and not trying more could hurt your abilities to solve problems in the long term.
As programmers, generally we encounter ourselves in the following scenario: Start working on a task, writing some code that works, come across with a bug, try to get it solved, if you haven’t solved it yet, try harder to get the problem solved, frustration starts to increase, try anything that works, become fully frustrated, destroy the keyboard. For some, this sounds funny as it is not too far from reality. The problem turns harder to solve when we start getting frustrated.
It is crazy to think how the way you feel impacts your ability to solve problems. Senior programmers often recommend coding when you don’t think of anything that is bugging your brain constantly such as paying the bills, worrying about your kids’ health, looking for another job, thinking about the discussion you had with your relative, etc. Your brain is not fully focused on what needs to be focused. Being frustrated leads to the same. By being frustrated, you become more concerned about not making things work rather than finding alternatives to making it work.
One of my bosses once told me: One of the best work happens when we are relaxed. It’s true. It gives freedom to your brain to explore and discover new ways to make things happen. Sometimes, frustration makes us keep the focus on the solution we are trying to implement which got us stuck at first. This leads us to not trying different alternatives because we insist on making work the first piece of code written.
This one seems obvious, but it isn’t. It is not a secret we live in a world with access to information about anything. In the programming world, you can find just about any kind of solutions to common problems programmers come across. Unfortunately, that is not always the case.
Going directly to your favorite search engine and try finding a solution for the problem is what leads you to get stuck. Why? because you don’t have true clarity of what the error is. Oftentimes, we get error logs displayed in the terminal and we don’t even read at the whole log. We only see the part of the log that says “[Error]” or “error” and automatically turn our heads to googling.
Sometimes the bug is as simple as a variable name typo causing the application to crash. Take your time to read and understand the error as this will allow you to better choose what next to do, whether it is to try a different solution, ask someone else for help, or googling.
Haven’t you had a time when you talked to someone about a problem but you needed to provide more context for that person to understand better what is going on for them to help you, but you ended up finishing the conversation before the other person talked as you realized what you needed to do?
One of the best ways to find solutions is by talking out loud the code, line-by-line, to someone else or to a rubber duck. This is more commonly known as the rubber duck debugging technique. This is useful sometimes and will help you come across a solution without you even trying to think of a solution.
Logging pieces of information can only get you so far in understanding the root cause of an error. Many programmers like to clutter the code full of logs making it harder to understand. A quick log can oftentimes provide meaningful information. However, that’s not always the case.
Programmers not debugging their code are making it hard on themselves to understand the problem and tu find a solution. There are cases where programmers don’t know how to debug in a specific programming language. Setting up your local environment must be the first thing you do before starting to write code, which includes setting up debugging tools. This could be time-consuming if you haven’t done it before. However, being able to debug your code is a blessing when you have code with thousands of lines and you are trying to spot the problem.
In case you already have your debugging tools set up, I encourage you to take advantage of them. Sometimes we think we understand how the code works. However, once we start debugging we find behaviors we didn’t anticipate when we initially added our piece of code.
Implementing an ugly solution is a hard choice for those who always look for quality code. The reason being is because there is a pre-existing high expectation of delivering high quality all the time, whether it is a highly reusable function or a more performant solution, or following best practices, your brain focuses the attention on writing quality code.
Sometimes an ugly solution can be the best solution. At the end of the day, programmers make things work and not write reusable and high performant code that fails. If something small fails, the whole project could fail, and users quickly lose trust in the software. A better approach is to make things work first, then optimize or improve off of an existing solution. Overengineering is very common when there shouldn’t be. Keep it simple. Keep it ugly. That’ll do the trick sometimes.
This is one of my favorite techniques to understanding what the problem is. Computers run the code that is written. They don’t guess or decide whether or not to execute a piece of code. They just do it. If the code doesn’t exist or is commented out, it won’t run it.
Commenting out chunks of code is a simple and effective approach to getting you unstuck. Sometimes you don’t know what the code does or cannot figure out an unexpected behavior. By commenting out certain pieces of code, you will start getting helpful cues of where the code breaks. Sometimes we think it is failing at the end of a function when in reality it is breaking at the beginning of a function.
Commenting out code won’t get you unstuck, but having a clear understanding of the problem is better than trying all things possible to make something work without knowing what you wrote in the first place.
It is funny how we have adopted the word “google” to mean to search it online. Programmers should be ok googling as many times as they need to. At the end of the day, it is a tool. It is not about the quality of the tools, but how well you know how to use the tools. Like many things in life, it takes time to master how to use the tools and it is no different when googling.
Sometimes you notice other people googling for the same solution you are stuck for hours and they are successful after you had spent hours and hours googling in hopes to get a solution. With more time and experience, you will be able to improve your research skills and discover search patterns that will allow you to find the information you need to move forward rather than remain stuck.
There is nothing wrong with asking for help or having a second pair of eyes to look at our code. Although oftentimes junior programmers ask questions to more experienced programmers, there is nothing wrong if you have 15 years of experience and you ask someone who has a few years of experience on their back.
It is complex to know it all in the world of programming. There will always be something someone knows that you don’t know. It is surprising sometimes to see where some of the best answers come from, and some of them might be from people you never thought they could.
Many programmers look for other solutions to common problems, read StackOverflow and GitHub forums but never post a question. There might be different reasons why many don’t do it.
Some people are afraid to ask questions publicly and expose themselves to being pointed at as unintelligent. However, sometimes is surprising to see how many people have the same question you have.
Other people don’t do it because of laziness. We become lazy at doing certain simple things without realizing it. For instance, some programmers don’t ask questions in forums because they don’t have an account in that forum, even if they visit the forum over and over. It is quick to create an account. However, the desire for looking for similar questions leads up to not even try posting the question. In other cases, programmers need the answer right away and can’t wait for someone to answer the question in the forum. Posting the question in a forum and working on sometime while you get some answers might most efficient use of your time in some case.
Not everyone does this at first. However, the documentation is made to provide a single source of truth to how a programming language, library, framework, or architecture works. Spending some time reading through the documentation gives you a better understanding of how things work as well as provides you with ideas on how to tackle the same problem using different approaches.
When you have tried several things and researched a lot of information but you can’t still make things work, you become tight and stressed. Taking a break is your best bet at this point. Going for a walk or stepping away from the computer are simple, yet effective ways to declutter your mind and relax for a little bit.
You could opt to walk away but still think about the problem you can’t solve. The main difference here is you are not staring at a screen reading your code or online information that distracts you from thinking clear after a while. Being able to put pieces of information in a zero to low distraction environment helps many with coming up with solutions. Just make sure to take a pen and paper so you write it whenever you come across them.
There have been cases where software has a particular error that never gets solved as it doesn’t impact the user’s experience or doesn’t compromise the business logic. In other cases, it is an error nobody in the team has been able to solve before due to its complexity.
Regardless of what the reasoning behind is, it is ok to not moving forward with attempting to make something work. Initially, you might not feel good about this as per your desire of making things work as a programmer. However, sometimes not insisting to make work things that were not meant to work is the best decision.
The best moments are whenever you are doing something different than trying to fix a programming problem and unexpectedly you come across a solution. Aha! Those are the moments you enjoy the best as a programmer and also find it hard to explain to someone why you wanted to work on complex stuff at first. Therefore, if you are stuck, don’t let it get you down. Find that as an opportunity to challenge yourself and demonstrate you can make anything work!