Week Five

Practice makes perfect, right? Well that’s what my dad always told me, anyways.

I think in English but that’s only because I speak English. I would imagine that those who were raised speaking another language think in that language. It’s only natural, right? Do they slowly begin to think in another language once they start learning that language? Well in the virtual world, I was “raised” speaking Java, and for the majority of the last project, I was primarily thinking in Java not Python. Learning to code in different languages is like trying to learn any other verbal language—the functions and composition are the vocabulary and the syntax is sentence structure.

Figuring out how the overall sentence is structured might seem difficult at first but that becomes easy over time. Just like how learning to not include semi-colons after each expression took a few hours to overcome. The difficulty lies in remembering the meaning of each word you encounter, or knowing the name of the method you want to call. The same can also be said for synonyms. There might be one way you are comfortable writing a solution, but there are also better and prettier ways of accomplishing the same thing. I feel like this will become easier as well, but for know my “vocabulary” is still very small.

It will take some practice, a lot more than I probably realize, but hopefully I can start thinking in Python without having to relate everything to something in Java.

Until next week. Rock’n Roll

Week Four

Follow the following tips for the next exam:

1. Become more familiar and grow more confident with Haskell

2. Review mostly in Python and refer to Java equivalents for clarification.

3. Skim/re-read all reading assignments including textbook excerpts

4. Take notes over required readings – summaries and important lists only

5. Compose “cheat-sheet” in the same manner as the one for the first exam.

6. Begin studying a week to two and a half weeks prior. Light studying over the course of a week as opposed to intense “cram” studying two to three nights before-hand. Include practice examples. Maybe find a study partner.

7. Utilize Piazza in order to ask clarifying questions.

8. Actually code the examples on Github and play around with syntax.

I thought that the test on friday was very fair, and paced very well. I finished the last question right as time was called. That being said, I know that I could have done better. With a week crammed with projects and other exams, it was difficult finding time to study for the exam, but that is just an excuse. I should have looked at my calender more closely and made the decision to start studying the previous week. With a class like this, you are being tested over syntax and intricacies of the different coding languages. In other terms, as with most other CS test, it was a skills test. As with any other skill, you get better with practice and for this test, I did not practice nearly enough. I know that if I follow at least half of the suggestions listed above, I will do better on the next exam.

Paired Programming – Unsurprisingly, it went very well. I found that I was more on top of the assignment with a partner to work with. When I code by myself, it is very easy to procrastinate up until the date the assignment is due. Scheduling times that I would have to be focused on the assignment was very beneficial. I would say that by working on the assignment in chunks with a partner spread out over the two weeks helped in easing my stress.

Until next week. Rock 'n Roll

Week Three

From what I gather, my mantra for this class is going to be "test, test, test". Test this, test that. Test things you're not sure work, test things that you know will work. Test new, test old. Test. Test. Test. While this won't be hard to adapt to, it is definitely different than my normal "let's just get it written and hopefully it will work when I run it" mentality. If I want to be a more marketable programmer, I need a high deliverability rate. I don't want to be responsible for a project that falls flat and fails at the slightest hiccup. I especially don't want to be responsible for an error like the one that caused the launch failure for the Ariane 5 rocket. Something as simple as a floating point conversion can lead to sever economic loss. I am learning, however.

Today, while meeting to work on a project for a different class, my partner went straight to coding a solution he thought would work. To his surprise, and to my complete lack of surprise, it started to break down right out of the gate. So, before trying to go through the code line by line in order to determine what went wrong, I instead decided to scrap most of what we had accomplished and wrote a few unit tests to help guide us in reconstructing out solution. After writing the program around these test cases, we were able to achieve the correct answer in less time than it would have taken trying to fix the solution we had started with.

Anyways. Until next week...

Week Two

Wow, what a week. That's what I get for waiting until three days before the project was due to start. I kept pushing it further making excuses to myself citing reasons such as other classes and work I had to do for the various organizations I am in. I can tell that, looking forward, I am going to have to organize a little better, start my projects earlier, and work on them piece by piece by adding comments that will help me analyze previous work.

In previous semesters, classes required me to go through terminal in order to run my tests and eventually turn in the projects, but I still managed to work mostly through a text editor on my home machine. I found myself, through the majority of the project, waist deep in terminal-- writing code using nano, editing my tests, pushing to my git repository, and eventually testing all of my solutions. I guess I better get used to this.

Moving forward, looking at the requirements of the next project, I definitely plan to do things differently. After reading through "XP: Installed", I was amazed by the importance they place on testing, but know I see why. Having thorough and helpful tests not only can show you that your solution is performing correctly, but if designed in certain way, can help point you to possible bugs in your code. It wasn't until after I wrote out a few non-trivial test cases that I soon learned where my program was falling apart. Writing exhaustive test cases is critical, and I hope that I have learned my lesson.

Until next time. Rock 'n Roll