Think Like a Coder
Tags: beginners, javascript, codenewbie, webdev
Published: 2022-08-25 06:31:20

##What's this all about, anyway?!##
A lot of words come to mind when I think about Phase 1 of Flatiron School's Software Engineering bootcamp - 'rewarding', 'exhausting', and 'fast-paced' among them - but none more so than extremely challenging. I had anticipated the heavy demand of the 15-week program, and I was prepared... with my flash cards, pneumonic devices, and very thorough note-taking habits at my disposal.

During my second week, our tech coach, Sam Waters, made a comment that stuck with me.

***'The point of this bootcamp is not for you to memorize all the terms, methods, and syntax - you can Google that,' he said. 'The point is for you to think differently, and understand the logic required to communicate with a computer.' ***

And he was right - my flash cards couldn't help me to conceptualize the flow of logic through a callback function (much less reproduce it). 

This became clear in my early struggle with - of all things - *parameters*, particularly after utilizing a loop or iteration method. Consider the below illustration from the Phase 1 Code Challenge: 




![Code block that includes a fetch followed by a forEach from the Phase 1 Code Challenge](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5toscdckkvhtzytmmrk6.png)

 



Although a simple code block, I struggled to remember which parameters to use in subsequent functions - animalData vs. animal - and to follow the line of reasoning through the end of the code. When I mentioned this to another student after the challenge, his response echoed Sam's: 'Yeah, that just involves getting used to a certain way of thinking.'

As I've advanced through the curriculum and the material has become more complex, attempting to adapt my thinking to better align with the computer's has only become more essential.

###A Strategy###
In response, I developed an approach when confronted with chaotic code or a confusing ask. 

*1)  Take a beat and breathe*

It's easy for me to focus solely on what I don't know immediately, and inevitably miss instructions or easy solutions. My husband calls it 'panic mode.' This step reminds me to focus, read any instructions, and not rush into premature work.

*2)  Fall back on what you know best*

One of the really great things about code is that there are usually innumerable ways to reach a solution. I've learned that it generally serves me well to invest in what I know best, instead of trying to learn unfamiliar or seemingly 'better' methods.

*3) Formulate a plan & begin to execute*

To this end, I focus on two questions: '*What's my end goal*?' and '*What is the general roadmap to get there?*' As the most involved, and least specific, step, I first rely on pseudocoding (an informal description of the process with no specific syntax) to conceptualize a solution. Then, moving from least to most specific, I identify functions, variables, and methods to build in to my roadmap - and start to code!


####To illustrate with an example...####
In the below code, I was asked to build an object containing a large volume of sports players' data and then to return a list of jersey numbers. To start, I identified my end goal: build an array of jersey numbers. Through pseudocoding, I decided that my plan of action would be to establish an empty array, isolate players' jersey numbers via a 'for' loop, and then use the .push( ) method to dump all the numbers into the empty array. With that in mind, I began to narrow down on my exact variables and functions, and started writing code!

![A function from the Object Ball lab that includes a 'for' loop to return jersey numbers](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2ysq87oksqx53h7k2lsd.png)
 

*4) Look up what you don't know*

For any methods, language, or processes I can't fully remember, this step is where I do the work to research them.

In the above example, if I didn't remember the syntax for the .push( ) method or specifics on bracket and dot notations, this is when I would look that up.

*5) Log, log, log*

Check your work! I'm learning to be a bit obsessive about console logging as I go, simply to confirm that each step of my code is working like I want it to. Better to know early on than find out something is broken after 50 more lines of code!

###Moving Forward###
Although I may still struggle with turning my pseudocode into written code, this approach seems to be helping me internalize the mindset shift that is required to be a good developer.

Overall, I'm very excited to see where this takes me in the next four phases at Flatiron School, and in my career beyond that!