The first section of these chapters is the question of when to say “yes”. When in a professional work environment and a superior or colleague of yours asked you a question, it could be about anything, if you know saying yes will make them happy it is easy to just say it. We have to realize that this is not always possible, and we may use other words like “maybe” or “sure” to give them hope that for example the project will be done by Friday, even though you know it won’t be. We should try to avoid these ways of providing false hope to avoid an awkward conversation. Instead we should say only things we know for sure, like “yes the project will be done in 3 days” instead of “the project should be done in 3 days” if we are unsure. The main point is to not feel pressured to say yes, if you know something can’t be done then say it and it will avoid creating a larger problem down the road. I know that in the past I have said that I would do something very well knowing I didn’t have time or I just didn’t plan to do it in general, and it always ends up causing a larger problem down the road.
The second section talks about professional coding in the office and the right time to code and wrong time to code. It seems that most of the issues mentioned such as writers block, rushed code, coding tired, worried coding, etc can all be solved for the most part by taking a break. This break could be 20 minutes in the break room or taking a day off to gather your thoughts or solve some issues in your life that may be creeping up on you while coding. I know that when I am working on an assignment, especially a coding assignment, I easily get stuck in the “zone” and I tend to overlook the big picture and will later have to go back and fix that code. Another great topic is to help and to be helped, if a coworker has a problem, take some time out of your day to help them through it. If you are having issues and a coworker offers help, do not be stubborn and take a second opinion.
Software Testing 