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!