After a weekend of pure chaos back home, I have returned to campus. Of course, I had to make an ever-important pit stop at Trader Joes for buffalo chicken dip and rolled tortilla chips. I thought things would settle down a bit since there were no longer any major life events happening, but alas it's almost fall break. I think that might be some sort of code for professors to start piling on work. I am committed this next week to staying on top of my assignments, not saving them for 1 a.m. the day they are due. Instead, I will have them done by 12 a.m. What can I say? I'm ambitious. 

On another note, if you were wondering where I was writing this week’s newsletter from, I am currently sitting in my dorm's laundry room, surrounded by piles of clothes, waiting for a dryer. One would think that there would be the appropriate ratio of washers to dryers to prevent every surface from being covered in piles of clean clothes removed from machines out of pure desperation. I guess that is just an unfortunate misconception the residents of Hunt have fallen victim to. 

Speaking of which, Chapter 7 of The Programmer’s Brain focuses on the many misconceptions, or bugs, people have in their thinking when it comes to programming. One main idea was that knowing one programming language can help when learning another, but it can also create misconceptions when we assume the two languages work the same way. Just like learning any other language, some phrases will be similar from one to another, but some will be completely different. Growing up, I loved to code on the website Scratch. It used cute animations and block coding. I can say with absolute certainty it is nothing like coding in R. As much as I wish I could make my package by linking premade blocks together like a puzzle, I cannot. 

Even within the same language there can sometimes be a learning curve. I took STAT230 last semester and that was my first introduction to R. It was simple enough to wrap my head around as I have not used Python for 2 years, so I did not remember enough to confuse me. I thought going into STAT306 that I would be doing the same things I did in STAT230. Instead, we started using the pipe feature and a whole array of new packages. It took me a bit to break my old habits and form new ones. I will admit though I much prefer using the pipe feature instead of attaching the datasets.

Later in the chapter, there is a discussion about bugs in code versus bugs in thinking. Most people’s immediate reaction when their code does not work is “What is wrong in this code?”. This thinking can impair our ability to realize what is actually going on. My usual strategy when studying is just memorization, which worked in the moment, but looking back I could speak maybe a sentence in Italian with what I remember. Memorization can be useful, but when coding it is suggested to focus on what you think a program will do instead of recreating the exact code you saw to complete a task. It might seem like a faster strategy, but if some aspect is changed, your code might fail.

This reminded me of the concept of stability that we read about earlier in the week. Stability focuses on showing that the data acquired in a study was the result of one specific variable by adjusting other possible confounding variables. By moving our thinking towards “What do I think this will do?” Instead of basic copy and pasting, we can create more stable code and reduce the number of bugs caused by ignoring a unique element in our problem.

In Sam’s newest newsletter, “I Know What This Does… So Why Can’t I Write It?”, she discusses how forgetting is a natural part of the memory process. This leads to the poor practice of waiting until you need to use a function to learn it. This is similar to the thought process of what needs done to accomplish a task. Taking the time to learn and understand functions reduce the risk of completely forgetting how a function works and makes it easier to understand what you think code will produce and how it needs to be adjusted.

Being stuck in our misconceptions can be the downfall of many programmers. We must be willing to adapt and relearn our habits in order to succeed in new environments. Just like any new skill, coding takes time to learn, and previous knowledge is not always reliable. I know as I go forth in this class I will work to better change my thought process when working on a project. Until then, I will continue to fight the war that is a dorm laundry room.

Until Next Week,

Aylee and Binksley