Test Driven Development is something that Martin thinks that all programmers should be using in the design of their code. Since this method is only something mentioned to me and done for a course and not implemented in my way of writing code it is something that I am skeptical of adapting and trying to use. After hearing what it does, how it works, and practicing it in a previous course it looks like the best way to approach coding. The main struggle I have with it is actually going about implementing it in my coding routine. I have learned to write code create an input and see if you get what you want. If that fails put some print statements in the portions of the code you think it is failing and trace back through it and try to fix it. After some mess it finally gets fixed but for the assignment to work and be run correctly. That is the problem when it is code that we are having to only do for an assignment we are not concerned with how it gets done, as long as it gets done. I think working for the last month of the semester with actual code in the Radiology module of OpenMRS will allow us to implement TDD as we need to create test cases for the code we create. This could allow for TDD to be used and possibly make writing of the code a lot easier.

From the blog CS@worcester – Greg Tzikas by Greg Tzikas and used with permission of the author. All other rights reserved by the author.

Test Driven Development is something that Martin thinks that all programmers should be using in the design of their code. Since this method is only something mentioned to me and done for a course and not implemented in my way of writing code it is something that I am skeptical of adapting and trying to use. After hearing what it does, how it works, and practicing it in a previous course it looks like the best way to approach coding. The main struggle I have with it is actually going about implementing it in my coding routine. I have learned to write code create an input and see if you get what you want. If that fails put some print statements in the portions of the code you think it is failing and trace back through it and try to fix it. After some mess it finally gets fixed but for the assignment to work and be run correctly. That is the problem when it is code that we are having to only do for an assignment we are not concerned with how it gets done, as long as it gets done. I think working for the last month of the semester with actual code in the Radiology module of OpenMRS will allow us to implement TDD as we need to create test cases for the code we create. This could allow for TDD to be used and possibly make writing of the code a lot easier.

From the blog CS@worcester – Greg Tzikas by Greg Tzikas and used with permission of the author. All other rights reserved by the author.

In chapter 4 Martin brought up many great ideas about the environment and attitude you have while coding. Early on in college I would often have music playing and have my phone next to me. I thought that it never distracted me until reading this chapter. I slowly have pulled away from listening to music or having distractions but after reading this chapter I realize that maybe it is not the best idea to have distractions on in the background that put you into a “zone” that allows you to just blow through code and problems. This leads to poor and sloppy work. While it is nice to breeze through something, more likely than not finishing a chunk of code or a problem is not as easy as taking one look and making a change. It takes time to create it and ensure that it is functioning and done in an efficient manner rather than spaghetti code. Often when things are running in the background or you are distracted because of an event that happened or is going to happen the bad code comes into play. This is because your mind isn’t giving full attention to what you are trying to get done. Doing so results in more problems down the road. The books explanation of 3am code and when to walk away reminds me of the casino. When you are there and winning(focused state) you are good you are having a good time and excited. Good code should do the same but once you start losing money and are down(unfocused/distracted) you start to play risky to try to win your money back. This is when you need to learn to step away, go outside and take a walk or just step away from everything and clear your mind. I think this is a huge thing that I myself should learn as I find the best work I do is after a few hours after I wake up. Myself working or thinking too much about something can stress me out and make me frustrated only hunting and thinking about the correct answer. Luckily being in college still with other classmates it is easy to practice and work together with others. Many times something I am just missing that is not obvious to me is obvious to someone else and we can help each other and vice versa. I think that programming with someone else and getting and receiving help is the best way to learn more. There is just so much to know about programming and given where we are in our careers it is very hard to know every little detail so some students know more about certain things and can help. I have heard that this is also true in the industry and I hope to continue having people around to program with to help and be helped by. I think in the end it comes down to practice. The more you practice the better you will become allowing times where you are stuck to recognize similar situations which when you were stuck before. It may not always be the same scenario but knowing similar problems can solve endless hours of stress and problem solving just by practicing.

From the blog CS@worcester – Greg Tzikas by Greg Tzikas and used with permission of the author. All other rights reserved by the author.

In the reading for Chapters 2-3 I read about knowing when and how to say yes and that it is okay to say no. The biggest thing that I took from this reading that I hope to use in my professional career is to not make promises or say yes to something I know will not get done or not be finished on time. It is better to be honest and tell the manager or boss that you won’t be able to do a task. I hope to be more upfront with people as stated in the yes chapter where he mentions what commitment sounds like. There is no uncertainty and there is no hesitation. I believe that after the readings there is a clearer understanding for myself what saying yes and no really means and when to chose to say either of them. It is the simple words yes and no we use everyday but as a professional in your field you need to know it means more than just a work to make someone happy, you gave them a commitment that you are expecting much like you are expecting your co workers to do their part in the project.

From the blog CS@worcester – Greg Tzikas by Greg Tzikas and used with permission of the author. All other rights reserved by the author.