It is genuinely exciting to look at something I’ve written and know that it runs. Writing code that functions well is fantastic. I can make something that will perform the task I set it to. That is a massive confidence booster, even though much of what we’re doing is extremely straightforward. I was worried at the beginning of the semester that I would find myself completely at sea in this class. Being able to complete much of it without too much trouble makes me feel a little more centered in class.

I enjoy writing. I write fiction, mainly for myself, sometimes for other people, but mainly for myself. One of the pleasures of writing for me, and not for others, is the freedom to focus on the big picture. Where is a story going? What is it going to say? What will it do? When it’s done, it’s done, and I don’t have to worry about a typo derailing everything I’ve written. Yes, typos are annoying. Yes, I would prefer that my spelling and grammar appear perfect. But the story still functions if they aren’t. Programming is different, though. I need to pay attention to details at a level I’m not used to. Missing a small detail, and in the process making a program nonfunctional, is at times infuriating.

When we rewrote our pay programs to include functions for Chapter 4, I got hung up by a very small error. In the following line from the program, I failed to nest my parentheses correctly:paycheck = ((float(a) - 40) * (float(b)*1.5)) + (40 * float(b)). The line as you see it here is correct. Without the parentheses in the right places, it causes the whole program to fail, and it took me longer than it should have for me to figure out what was wrong.

The clicky turtle project was similar. In def clicky(x, y) : I forgot to insert the colon. Without the colon, of course, the function is not defined. The function is, of course, key to the program as a whole. If the function is not correctly defined, then it cannot be called later.

It takes time to learn habits. In the context of coding, I need to learn greater attention to detail. I think I’m getting better at it. When a program fails to run correctly, I’ve gotten better at reading the lines referenced in the error messages Trinket throws back. As we’ve covered more topics, I’ve become increasingly confident in my ability to code around any errors I do encounter. In Exercise 1 for Chapter 5, I could not for the life of me figure out how to update the variable as described in the chapter. Instead, I read ahead and built a list. Correctly adding the user input to the list is something I’m still proud of. entered_numbers.append(int(s)) could very well not have worked, but I formatted it correctly and was able to correctly troubleshoot the program as a whole. I’m happy it came off well, and I’m very pleased I was able to circumvent what had been a very frustrating process.

I do not think I’ve done well with the pair programming. Both experiences have been difficult for different reasons, and they make it difficult for me to troubleshoot in the way I’m used to. It’s really, really hard not to be in the driver’s seat at all times. During the second pair programming exercise, when my partner had completed the exercise before class, I wasn’t really sure what I was supposed to be doing and I didn’t feel it was clarified when I asked. It was not clear what the purpose of the exercise was when my partner had already done all of it.

As we move into the second half of the semester, there are a number of things I want to work on. The first is a follow-up to the preceding paragraph. I understand why pair programming can be helpful, and I want to make it successful for me and the individuals I work with. Doing group work has never been my favorite thing, but I hope to enable success in this environment by bringing more patience and a better attitude to the activity. I think I let my nerves about not getting finished within the time get in the way of the work itself and I need to let some of that go. I don’t have any free time on Tuesdays between 8:00 a.m. and 9 p.m., and it is hard, after a long day, to focus on getting more work done. That said, letting the nerves fade and just focusing on finishing the work will make things easier. Honestly, I think I can say with confidence that the being nervous about finding the time to do the work is usually a bigger actually doing the work.

I would also like to focus on the quality of my comments. I comment on my code when an assignment reminds us to (e.g. the Tetris refactor due today), but otherwise I either let the comments go, or make them as brief as possible. It wouldn’t be so bad to clarify more of my code, would it? No, no, it wouldn’t, especially if I have any intention of going back and attempting to read it later. I believe that I hesitate to comment because it feels like the work takes longer. But! As I said above, I have to be certain that I am taking the time to go over the little details. Comments are part of that, and I cannot let them slip by.

In addition to pair programming and comments, I am interested in learning how to use a development environment outside Trinket. I’m really looking forward to having a set of tools to take with me into future work. I don’t know if we’re moving past Turtle or not, but I’m interested in how to do some of the work we’ve done with Turtle using the tools Python provides without the Turtle module. How do those tools work? I don’t know, but I can’t wait to find out.