Welcome!
If you have somehow stumbled across my blog you're probably one or all of these few things:
A fellow Flatiron software engineer student (π π )
new to the coding world (π¨βπ» π©βπ» )
becoming frustrated staring at the same code and errors for hours on end and now browsing the web for some comedic relief until you feel mentally ready to be defeated by JS over & over again.. (the reason I have stumbled upon 95% of the blogs that I have read πββοΈ)
and if you're none of those, I hope this blog post finds you well!
As a 30(some π ) year old career changer leaving the world of psychology to become a software engineer, you can imagine I've encountered many frustrating moments have caused me to question my ability to really succeed as a software engineer. In order to learn the many different languages, and concepts of SE, I have had to retrain the way that my brain approaches and solves problems. (Hello, imposter syndrome!)
I am now nearing the completion of the first phase of the five phase curriculum at Flatiron school and through it all the most useful takeaway (besides the JS knowledge) that I have found is to break the problem down, or break the code down. I found myself feeling completely defeated before even attempting to code a solution to a specific lab multiple times throughout the past 3 months.
So what do I mean by break it down? For me, it involves a lot of talking out loud. The more I speak out loud the exact problem that I am attempting to solve, the more I could understand it in "non-technical" terms. (Bonus: the more you speak in technical programming language, the more natural it comes which will be imperative to your career) I've been told many times "to be a developer, you have to speak like a developer", what better way to master this skill than repeatedly doing so?
Once I am able to comprehend what I am being asked to do, I use "pseudocode" to translate the problem into singular steps using non programming language that does not follow any particular syntax guidelines. Make sure to keep your pseudocode short and to the point. Your pseudocode should be able to describe the functionality of your code in terms that someone without extensive programming background could understand. Once you have written out your pseudocode, you can then use this to write out your code.
For a simple example, let's pretend you're creating an app that will take someones info, age, name, occupation, and decide if they're legally able to vote. You need to write a function that takes age as an argument, and will return voting eligibility.
// Write a function that will check voting age of applicant
function checkVotingAge(age) {
// If applicants age is above 17 years old, return "vote!"
if (age >= 18) {
return "vote!";
}
// If applicants age is below 18 years old, return "no vote!"
else {
return "no vote!";
}
}
// Example usage:
const personAge = 20;
const result = checkVotingAge(personAge);
console.log(result); // Output will be "vote!"
The task of writing code and developing can seem quite daunting and overwhelming. To me, it felt as though I was trying to solve multiple problems at once. By breaking the problem down into smaller steps and utilizing pseudocode, I am able to work the problem out step by step and the task becomes less of a mountain to conquer and more of a molehill.
As a beginner in the software development world, I hope these small bits of advice can also help you in those frustrating moments. Happy coding!
Sources
IMAGE : https://medium.com/codex/10-best-programming-memes-1-cec344afc19a
CONTENT REFERENCE : https://www.geeksforgeeks.org/how-to-write-a-pseudo-code/
Top comments (0)