DEV Community

Discussion on: The Four Layers of Programming Skills

Collapse
 
kev_mcg profile image
Kevin McGillivray

Great question—it's a big challenge to develop exercises to specifically practice this. But, it is still a process that can be defined by a specific set of skills that can be practiced. The typical process I use and the one I help students learn goes like this (but there are variations so don't take this as the One True Way):

  1. Pick a problem, either an exercise you find online or a specific problem in a project you're working on.
  2. Understand the problem – Make sure you actually know what you're trying to do. This can be half the problem.
  3. Sketch out the logic – Use pseudocode, plain English (or your fluent language of choice) descriptions of what the logical steps might be. This is where you really get practice with programmatic thinking. You're writing down the steps in a way that you think would make sense to a computer if it could understand the pseudocode. This step is helpful especially when you're a beginner because you don't have to think about logic and syntax at the same time (which are two different skills of course). If you have to do both as a beginner, it's way, way too complicated. This way you can focus on one at a time. The important thing to remember is that this is a rough draft (see the next skill layer, creative skills). It most likely won't be perfect, but you have to get an idea down anyway.
  4. Write the code – Translate each line into the actual programming language you're using. If the pseudocode was written in a "computery" way, then each line should translate to one line of code. But, often a line of pseudocode requires a few more sub-steps.
  5. Test each line as you write it – Make mini tests (printing to the console) for each line and make sure it's doing what you think it's doing (this is also building a solid base for eventually learning test driven development).
  6. If you complete this process and you haven't solved the problem, revisit the pseudocode and syntax back and forth, experimenting with different approaches until you get closer to something that works. Don't be afraid to research other people's solutions to similar problems online as well.
  7. Eventually you'll narrow down the problems to details until it works. At this point, there's still one more step: refactoring. Typically you'll end up with a solution that works but is a bit messy. Or there might be a better solution that ends up with the same result but is more organized or efficient. Look at your rough draft and think about performance, flexibility, and readability of the code.

I have more thoughts on this written here: Writing Code From Scratch. Wrote it a while ago and might need updating. Thanks very much for your question, I might write a post about this!