loading...
Cover image for Moving Past Tutorials: 8 Tips for Problem Solving

Moving Past Tutorials: 8 Tips for Problem Solving

aspittel profile image Ali Spittel ・5 min read

So, now you've outlined your code and written pseudocode. It's time to write the actual code! Here's my advice for writing your own stand-alone code and getting better at problem-solving.

How to use tutorials

I know the title of this series is "Moving Past Tutorials", but if you haven't used the technology that you are supposed to for your project, do a tutorial! Focus on understanding that tutorial conceptually -- read the words instead of just copying and pasting the code snippets! You can always come back to syntax later. And, make sure you know your learning style to find a tutorial that speaks to you.

But, don't get stuck in the cycle of tutorials. Do one that makes sense to you, and then build something. You still have that tutorial and Google to come back to if you forget the details, but you have a much better chance of understanding and remembering the technology if you practice with it after understanding it conceptually.

Break down problems

I want to re-emphasize that you should make the steps in your pseudocode as small as possible -- and the same goes for your features. When you're writing a to-do list, it helps to have small things to do on there so that you have a few quick wins to motivate yourself. The same thing is true when you're writing code. The steps will be easier to manage, and you'll feel more encouraged while working. You want to break your big problem into as small of ones as possible and then solve them individually. You want to make these sub-problems as simple and solvable as possible. Your time should instead be spent on that rather than writing the initial implementation code!

When you solve a jigsaw puzzle, you normally solve the outside first, then solve parts of the picture. You aren't just trying to fit random pieces together and see if it will work. The same is true for code! Build things methodologically instead of just guessing at things -- think through the solution to the whole feature or chunk of the puzzle rather than just writing code without a direction in mind.

Draw on similar problems

The first question to ask yourself when you're solving a problem, is have I seen this problem before? Or have I seen another problem with a similar pattern? If you have, then there may be differences, but you can still start to apply the previous solution and then tweak it. Or, is it a combination of problems you've seen before? Think through that as well!

Use the knowledge you already have, no problem is completely unique. You're basically putting together a similar set of tools to solve anything -- loops, functions, classes, conditionals, math, and variables. Yeah, there are fancier things you can use too in most languages, but basically, you're using similar concepts and tools to solve most programming problems. Don't lose sight of that!

Trust yourself

Trust yourself to try writing the code without help at first -- you have your pseudocode and have gone through that tutorial. Before you start searching for an answer, trust your intuition and write some code. Then debug it methodologically if needed. Or think through why it isn't working as expected. Don't immediately jump back to the tutorial, Google, or a colleague -- try yourself first. It will have the biggest benefit to your learning process.

Google effectively

Googling for help is perfectly valid and will be something you do a lot as a programmer. In fact, getting good at it is really important and something I would practice on. But, it can also be harmful sometimes. I often see new programmers Google the whole problem instead of the small part or bug that they're working through. Googling "reverse string in Python" will get you the answer you're looking for -- but you won't be doing any of the problem solving yourself and you won't gain much from the experience. Instead, if you get an error message while you're trying, Google that! Or, if you forget the syntax of a for loop, look that up.

In fact, I'd go so far to recommend cutting out Google for a week or two and solving some code challenges without it. Maybe make yourself a cheat sheet with the language basics. Really read through your error messages, 9 times out of 10 that will be all you need to figure out what's going on!

Also, don't always Google things or ask someone for help right away. Instead, trust yourself. Try things a few different ways. Read through your code again and make sure it looks right. Step by step debug the error with your debugger or with print statements.

Fail Fast

When you're writing code, you want to fail fast. Instead of spending a month going the wrong direction on a feature or introducing 100 bugs and then debugging them at once, you want to know as soon as possible when your code isn't working. Automated testing helps with this -- if your inputs aren't matching your desired outputs, you'll know. But, also, it's helpful to be constantly running your code as you go. After you add a few lines of code, run your program again. It will be so much easier to debug those few lines of code instead of hundreds.

Make sure to have a few sample inputs that cover edge cases, and make sure that your code works as expected for all of those inputs. Usually, you'll have these in your tests, but even if you're just starting out, you will still want to test your functions or code with different values and make sure it still works as expected!

Take Breaks

Sometimes, it gets frustrating to write code. You're getting bug after bug or you're starting to doubt yourself. First, know that is a normal part of the process and happens a lot to programmers of all levels. If you're getting frustrated, it's usually a good time to take a break. Your frustration probably won't help you debug faster, it will just make you unhappier. So, walk away for a while. Take your dog on a walk, workout, or just do something away from a computer for a while. When you get back, you'll probably be in a better head space!

Practice

I'll wrap up by saying that the best thing you can do is practice a lot. Do a code challenge every day, block out some time to work through problems a step more difficult than what you're solving right now, or work on an application that is above your current comfort zone. You'll expand your skill set by trying difficult things. Set reasonable expectations for yourself, and try not to get too discouraged if you have a hard time. But, you'll grow the most by challenging yourself.

The best way to learn is by repetition -- you don't need to create the same application over and over again, but solving a bunch of code challenges or building a few practice applications will serve you well. You also want to space out that learning a little. Instead of solving 20 challenges a day, doing a few a day will be more valuable. Resting in between actually helps you, and having to recall the information after a period is valuable in the learning process.

Conclusion

I hope that these tips help you when you're working through problems. The next few posts in this series will be about debugging, Googling effectively, refactoring, and test-driven development. I hope this post gives you the confidence and toolset required to work through some more challenging problems. So, go pick something out of your comfort zone and start solving it!

Posted on by:

aspittel profile

Ali Spittel

@aspittel

Passionate about education, Python, JavaScript, and code art.

Discussion

pic
Editor guide
 

Great post! It's amazing how many simple, repeatable concepts are used from the beginning of our careers all the way through.

I wanted to add an additional tip about tutorials. Try renaming the variables/functions in the tutorial you're doing. Then you can't copy/paste. You have to understand the connections in order to successfully complete the tutorial. This is even better with tutorials that use the same variable names in different scopes. If you just blindly follow, you may not even notice the context of usage is different!

 

+1 to Laurie's comment. Staying vigilant about doing these things as you gain experience is they key! When I find myself off course on a problem, usually I can track it back to not doing something you've detailed here.

You've done such a wonderful job distilling the core principles in this article, Ali!

 

Don't forget that folk wrote code before Google arrived ;-). We must have managed somehow! For me having a mentor helped, as they could be googled for tips and hints. Also starting on a partially complete project (like contributing to open source?) helped as I could see how the problem was being addressed and didn't need to cope with the whole thing myself.

I like your point about breaks. Many times I have beaten my head against a wall only to solve a problem in seconds the next morning. Not only is this a standard "creativity trick" (letting your subconscious work for you) but a good motivator. Ernest Hemingway apparently always left himself something to finish at night so he'd be motivated to get started again on the morning.

 

Great post! As a beginner, what helped me escape tutorial hell is that I simply set out to create a project and Google (DDG actually haha) stuff when I need it, and after doing a few tutorials initially, official documentation felt pretty understandable

 
 

Thanks Ali!

Great reminders!

For those of us who gets code shy (gun shy?)
of getting back on the path - specially when there's
F.O.F (fear of failure) in back of the mind.

Love to see some of your pseudocode which
has been transformed into python code?

As a side thought here? How about reversing actual
python code into pseudocode? Just wondering if someone has done this?

 

A possible 9th (it's similar to #8, but not quite the same): repeat what you learned in the tutorial without referencing it. You can reference if you need, but then do it again _^ After you've finished the tutorial, you've gotten past most of the hurdle for that material, but only gotten a small amount of its value. If you do it again, there will be much less hurdle and just as much value (b/c the first time, you're struggling with the procedure, so it's hard to see the big picture). Each time you do it, it will get easier (unless it's been a while), and you'll have opportunities to gain insights you weren't previously in a position to see.

If you do a tutorial once, then you should do it at least 2 more times since the cost of those 2 times will be lower than the one you've already spent, and the understanding you'll build will be higher than what you've already gained.

IME, anyway _^

 

Hey Alison, thanks for this wonderful and amazing post. This really helped me understand many things that I could do when coding. Looking forward to reading more reads. Have a wonderful weekend. Stay healthy and Be safe. Cheers.

 

Great advice and a good reminder for those of us who might have a 'custom' (read eh, it works usually) approach to problem analysis / solving (e.g. me)

 

And Documentation......
As well as having a code library of β€œhow to do x” I also have documentation on how to solve problems which is a master list of links and problem solving methodologs

 

Nice!

This is def a need.
Can you give examples we can see?

I believe this makes a good roadmap for Noobs like me!

 

Great article Ali! As one of your former students, I can definitely say you helped me understand how to approach problems and improve my problem-solving skills in a way that was easy to understand and universally helpful! Keep up the great work!

 

I have been stuck here for years. Thank you for the tips. I will work on them now.

 

This is beautiful Ali. I assure I would adhere to every bit of advice stated here. You're a tech angel.πŸ˜„πŸ˜„

 

An incredibly helpful reminder, and useful for my friends who are always asking for resources to getting started!

 
 
 

this post is packed with useful content.

 

Thank you for the series

 

Bookmark google search instead of code snippet.

 

what kind of programmer are you?

 

Thanks for this series. As someone who has been stuck in the tutorial loop, alot of good pointers for finally moving past that.