In chapter 11 of The Clean Coder, Martin talks about how to deal with pressure and stress when it comes to deadlines. None of this stuff is really new to me, especially being a college student and having to deal with deadlines for projects. He goes over how, if you can, avoid pressure, but, if you can’t, make sure to communicate this properly to the people you work with. Mainly, don’t take your stress out on the people that work with and for you. Also, if you are going to miss a deadline, tell your bosses and team way in advance so that you can plan out how to fix that. He points out that you should always follow your disciplines when you are under pressure because you know that the way you’ve been doing things is the right way to get the work done. This makes sense because this prevents you from having a huge mess that you will, most likely, just have to clean up later and waste more time. The last thing he went over is making sure to work in pairs which is common sense in programming now-a-days. You need at least one other person just to review your work to make sure you aren’t so stressed that you miss major flaws in your design.
This leads into what chapter 12 is about, which is working with people. Again, I personally find most everything that Martin has stated in this chapter to be a “no duh” kind of situation. He goes on to talk about how you should pay attention to the business that you are in so you know what is going on there. He gives an anecdote about a time he was fired for being, to summarize his post, “too into the technology and not into the business.” His story basically turned out that he liked the work for the job, but he didn’t care about job etiquette or manners; this includes basic things like what to wear at the job, who the higher-ups are,showing up on time, etc. To me all of this stuff is a no-brainer. When you get a job you follow the dress code, you know the people, and you show up on time. If you don’t like those rules, then look for a different job that will take you. The other two things Martin talks about in this chapter is “owned” code and pairing. I simply agree with him on both of these points. I don’t think people should have code that is “just theirs” because that creates so many issues due to them not wanting their code to be reviewed. This obviously leads to multiple issues down the line. Also, as I’ve already stated, paired programming is effective, and working in teams makes sure that messes and bugs are caught early before major issues start to happen.