I agree with what the author is saying. I think test driven development is the way to go in modern programming in order to keep pace with production. I agree that before making any sort of production code you should first make a test for it so that when the code is ready it can immediately be tested for bugs. If a bug is found it can immediately be debugged, fixed, and tested again to see if there are any other issues with that part of the program. Test driven development however, does not guarantee that the code would run perfectly when you follow the rules. You program will not run correctly if if you write bad code or bad test cases. It is important to have a good understanding of what is going on and how the program is supposed to operate before writing any sort of code whether it is production or test code.
I agree with the author that you as a worker have to sometimes say no to certain things. You want to be able to finish a task based on a realistic goal. You do not want to say yes to your manager for a task knowing that it will probably not be finished by the right date. Here it is better to say no so that the managers will be able to work around the date. In software development you would rather spend a little extra time to get the software to work correctly rather than rush into releasing a product that barely works.
I agree with the author. A lot of the times at the work place people say they will do the work but do not seem to show commitment to doing it. When you agree to do something for the job you do it because you are getting paid for it. At the end you as the employee of the company have control over what you can and cannot do. When you have a task at had you should always do it even when you do not seem to have the will power to. One way to show this commitment is to tell you manager or whoever by when you will be able to finish the task by. It works for me because it allows you to manage your time better and be able to focus on the task(s) at hand. This works even if you are depending on someone else to finish their tasks because even if you are relying on them so that you will be able to integrate your efforts you can still do your part of the overall task without him/her. Also if you are stuck on the task you are given tell your team that you have a problem. You are not helping anyone out by not telling anyone and by doing this someone will be able to help you with the issue or pick up the issue for you.
I liked the author’s analogy about how when he first started typing he was not sure what keys he was pressing and once he got enough practice he was able to figure out what keys he was pressing without looking at it. When he pressed the wrong key he was able to recognize it without having to look at the keyboard. I think that same concept is true when working in the field. Once you get a lot of practice with coding in a language or a particular technology then you will be able to notice when you are making mistakes without even thinking twice about it. I also liked how you should be prepared for every scenario put out there. When a customer you are making software for wants something entirely different than what was initially planned then you should be prepared to make changes without having to stress much. I also liked how the author talked about how it is always a good idea to walk away from a problem when you are stressing too much about it. When you walk away you are able to relax and think much more clearly which at the end will help you produce and solve the problem you had to deal with from the start. I would personally take whatever the author said in this chapter and apply it in the workplace since a lot of it is proven and I have tried it and it works when performing any type of task.
After reading chapter one of clean code I have learned that as a programmer the clarity of your code matters and how you go about working in a team matters as well. I would pretty much agree with everything that was said in the book. A lot of the people in the chapter know exactly what they are talking about since they have a lot of experience in the field of computer science. If there is one thing for sure that the work environment is much different at school than it is when you start working in the industry.
Hi my name is Ani. I am currently a junior at Worcester State University. I am currently working on my capstone which is contributing to the OpenMRS project with 5 people. I look forward to this project and hope it will give me real world experience on how it is like to work in real time projects.
Here are some videos I found that would explain MapReduce in detail