This makes reviewing your high level approach to the problem much easier. • You don’t have to review the code itself until you are happy with the much easier to read and conceptualize pseudocode.
Pseudocoding it out takes much less investment in your initial solution than writing the code and/or tests for the code. • You are more likely to review your proposed solution before being waist deep in a messy solution. • Being able to say your solution in English will make it easier to bounce ideas off of friends. They don’t want to spend hours reading your code.
it. Comments will be easier to write, and if you get lost or distracted while coding the solution, you have a guide to get you back on track. • You will learn to speak to non-tech people better.
are trying to solve. • You can start with just 1 sentence describing what the routine is supposed to do. • Iterate over your pseudocode, expanding on it, until it feel like code will naturally flow from what you’ve written.
there any conditions that need to be met before this routine runs? • What inputs will you need? • What will the outputs be? • Are there postconditions that the routine guarantees to be true.
good name. If you can’t name it well, you haven’t defined the problem well enough. • How will it be tested? • Is there a library you can use that does a lot of the heavy lifting for you? • How will you handle errors? • What is the Big O?
Having multiple projects on the burner can help with this. • Once you define a problem and write good pseudocode, you can let it simmer and move onto another project or another part of that project. • Stepping away and coming back to the pseudocode will allow you to approach it with fresher eyes. It is difficult to see new ways to do something when you’re in the middle of it.
to knock this problem out of the park, but, being in the middle of coding it, you may realize you missed out on something. • Don’t be afraid to step back; fix your pseudocode; and start again or make adjustments
not EVER commit messy code. Take the time to clean up after yourself. • “Messy code, messy mind” • Check your code to your pseudocode. Does it match up? Did you miss anything?
your solution? • Does it need refactoring? • Write tests to prove the code works as intended. • Test for edge cases. • Note: testing is a very extensive topic, so please stop me if I start ranting.