Hello, and welcome, to my very first developer blog post! I'm currently a student at Flatiron School's Software Engineering Bootcamp, and we just finished up the first of five course phases. All things considered, being a beginner coder is equal parts nightmare-horror-story and equal parts...SCRUMTRULESCENT!
I mean, one minute I feel like I'm achieving Kanye-level genius (jeen-yuhs?) when my first 'click' event listener finally works, and the next minute I'm taking my fifth cry-break because the nonsense CSS "rules" I wrote keep breaking the whole webpage (CSS guesses make for CSS messes). Like learning any new skill, it's a rollercoaster of emotion, and I'm definitely along for the ride.
But the most basic thing that really threw sand in my gears right at the beginning, was how do I even get started? All the code-alongs in the world fell short when I was alone and faced with the stark void of an empty VS Code file. But after some helpful insight from my instructors and this blog, I found that the right approach to a code problem can be broken down into 6 (relatively) simple steps:
- Understand your problem
- Break the problem into manageable bits
- Write your process out in human words and leave lots of comments
- Use available tools to sample and test stuff you forgot
- Slowly fill in the comments with actual code
- Simplify and optimize for clarity and dynamic use
Understand your problem
If you think about it, this is really a good rule for life in general, but it also applies pretty well to coding. (In my experience, this almost always boiled down to READ THE README!) In general, you need to know what your problem is asking for, before you start flinging out solutions. Before I started writing, I would pump the brakes and ask myself, "What are the known variables? What things do I need to manipulate or change? What are my desired outputs?" Knowing ALL the specifics of a problem helped me to get closer to finding the solution.
Break the problem into smaller parts
Most coding problems were presented in big, complex, unapproachable formats that were tough to decipher. Breaking down the code into smaller bits helped me to cut through the confusion. Once I divided the problem into smaller, more manageable micro-problems that I actually DID know how to solve, it was that much easier for me to then connect the dots. This also helped me to make my code more dynamic - when I wrote functions that were smaller, and more general in scope, it was easier to implement them as re-usable code throughout the program/application (more on that later).
Write your process out in human words, leave lots of comments
Once I had everything all organized, I would literally write out, in full sentences, exactly what I wanted the code to do, and how I wanted it to do it. These notes weren't necessarily pretty, but were just some human-readable syntax that even non-developers could understand. Putting code into literal words this way helped me to clear the mental cobwebs and make sense out of what I was trying to do. I also found that leaving my outline in place as comments helped me to stay organized while I was putting everything together, AND it ultimately made my code easier for others to read.
Use available tools to sample and test stuff you forgot
If you're unsure if your function will work or if your syntax is correct, you can always test out your code with an online app like Replit, or with the VERY helpful developer tools built into Chrome's Dev Tools. Remove even more of the guess work by tapping in to the multitude of testing tools that are totally free to use. As a beginner, the amount of rules and methods and syntax and little itsy bitsy things you have to remember is absurd. I could not keep track of all of them, and even if I looked them up, I would have trouble remembering exactly how they got implemented. (e.g. Does this method return values or an array of values? Does this method mutate my original data set or make a new one?) Using a REPL to test these little bits of my code was a life-saver, and helped to really layer-in those concepts. I can't even count how many bogus arrays and objects I have made just to check if I was using the right iterator methods. No shame! Tools are there to be used!
Slowly fill in the actual code
Once the problem has been clearly defined and parsed out using the strategies above, I would finally start to write up my code and develop a solution. It's at this point, however, that I personally had to use the most caution and take care to go slowly. It was deceptively easy for me to lose my place while writing up the solution and get frustrated. The good thing is, if the comments and notes from before are organized well, staying on track is a breeze. Just be aware, keeping the end goal in mind is critical during this step - don't lose focus! You're almost there!
Simplify and optimize for clarity and dynamic use
This one is kind of pro-level, but when it's all said-and-done the difference between just okay code and hallelujah-oh-mah-freakin-lawdy code, depends on how dynamic it is, or how re-usable. Ask yourself, can your functions be seamlessly used by other functions as callbacks? Or are they all hyper-specialized, monster-style, mega-functions that only have real use in one particular instance? I know from just my little experience, that the more efficient the solution is, the cleaner and easier the code is to read, and the easier it is to replicate. This one is definitely an on-going, long-term kind of goal to always strive for, but it seems like the sooner you try to implement a more dynamic style into your code, the better time everyone will have.
And that's it! Super simple, right? Well...sort of. Putting these strategies to use now could ultimately help take the tension out of the job interview process down the road (I'm told), and it can definitely help with comprehension while learning new concepts.
Thanks so much for making it this far! If you have any questions or recommendations for edits, feel free to reach out. I welcome any and all feedback.
Keep fightin' the good fight! ʕ•ᴥ•ʔ
Top comments (0)