Chapter 13: Teams and Projects

Chapter 13 is one of the shorter chapters in the book. This chapter is all about teamwork. In my own experience, like most I have come to find out that just because you get along with someone does not mean you will work well with them. The author states that teams need a long time to start working together, he states it is on the magnitude of months. He also starts that giving one person more than one teams doesn’t work great but giving one team more than on project works well. I am one of the people that likes to work alone so I need to work on my team skills like communication.

Chapter 14: Mentoring, Apprenticeship, and Craftsmanship

This chapter is one of the most important or rather most relevant chapter to my current professional status. My thoughts on Software design used to be that you learned the skill then got a full-time job doing said skill. But more realistically is the way the author describes the transition into a professional Software Developer where you would train through years of work. I rather like his idea of using crafting trade rankings like master, journeymen, and apprentice. He also states that the profession of Software Development is missing the elders teach the young. Though I have not experienced the profession to this extent yet I hope that this is not the case.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 11: Pressure

Chapter 11 is titled pressure and well it is quite straight forward. Every person deals with stress,  and all professions have a certain degree of pressure thrust upon them and being a professional Developer is no different than those other professions. The key in life is to learn how to be cool and clam under pressure. One great way to deal with presser that is detailed in the book is to properly assign your time as to allow for time to deal with crisis if it comes up. Another thing is to code cleanly (which was the title of the last book he wrote) Yet another way to deal with a problem of disaster proportions is to pair up. This is a useful technique to quickly and efficiently quiet the problem.

Chapter 12: Collaboration

This category is one of the ones that I feel like I need the most amount of help in, Collaboration. I definitely am one of the programmers who would like to work completely alone. I feel as though I could be more efficient by myself. But, This is not a good habit ad most of programming stems from collaboration with others. Some of these are clients and business people who know more about the situation you are coding for than you might. Therefore it is most beneficial to collaborate and communicate with other around you get the best end product that you can. Collaboration could even prevent future disasters that you have previously not even thought about.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 7:

Chapter 7 is titled Acceptance Testing. Well that is kind of strange because one of the chapters in the book for Software Quality Assurance and Testing was all about this and I wrote a blog Post about this very topic. Acceptance Testing is the process of asking the customers about what they really thing the software you are making should do, IE its behavior. This will give you a set of requirements that you can use to create acceptance tests. Then these would be used to set a proper definition of done, like he explained in an earlier chapter. So when the software behaves correctly and passes the tests you are finished. This way of testing helps to clear up any trouble in the beginning and end of a project.  This helps everyone get on the same page. The developer and the customer will understand what the software should do and how it should behave.

Chapter 8:

Chapter 8 was titled Testing Strategies and guess what? You guessed it! This chapter is all about Testing Strategies. This chapter helps to outline some good strategist to use when testing. One of which is to develop tests so QA isn’t necessary. What I mean by this is if you find no bugs then QA can focus on harder problems and everyone helps to make a better product. The author then details the Test Automation Pyramid. Sadly it’s not a transformer. But they do include a nice diagram of the pyramid.

This pyramid looks quite daunting but it really isn’t. The bottom layer is Unit test which are written by  programmers and for programmers. These test should be run constantly as a part of continuous integration. Next is component tests, these tests encapsulate a component. These tests are written by QA and Business with assistance from development. Integration tests test how well the assembly of components work together. System tests are automated tests that are executed against the whole system some tests in this section are throughput and performance tests. Finally Manual Exploratory tests are human made tests to explore the system for unwanted behaviors. In summary all parts of a company should work together and have a good strategy when it comes to testing.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 5:

Chapter 5 is titled Test-driven Development.  The Concept of test driven development might sound odd at first.  I mean writing tests first? To me it was very weird because I normally dive head first into any problem I am challenged with.  For the most part it has worked out but, TTD sounds like a more logical and strategic way to code.  It would be like knowing the questions to a test before taking it.  Planning your study session with the questions is a significantly easier way to study.  Well it sounds better written out, why didn’t I think of it earlier? Anyway, TDD is writing tests that fail then only writing enough code to make those tests pass.  It can help with not breaking the entire thing by knowing what’s failing and what’s not.  So if you write a new piece of code and all the tests fail, Then you know you messed up.

Chapter 6:

Chapter 6 is titled Practicing.  Well everyone knows that you cannot get better at something without practice.  But, sometimes you have to be told that before it gets in your head.  There is a saying that most know, it goes something like “the master has failed more than the apprentice has even thought of trying.”  This supports the argument of practice makes perfect.  Anyway, The author talks about a martial arts technique Kata and what it means in programming.  This is a set of keystrokes that simulate solving a problem.  This problem you already know the answer to.  Then he details some other types of Kata like Wasa and Randori that involve more people.  The entire chapter helps to enforce the idea that professionals all practice.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Short summary Chapter 3:

In the third chapter the author discusses what “yes” means and the different types of yes. He states that there are three different ways to accept or respond to an inquiry. The first is equivalent to a sure. Not really confident that this request or situation will be accomplished. The next form of yes is similar to I will try, where you really want to get it done and you will try to get it done but you know it probably won’t happen. The last form of yes is a very confident yes,  this is knowing with almost a 100% chance this task will get done. The author suggests that we all should change the way we accept commitments to only use language to suggest the 3rd situation. If it is not a 3rd situation then you should change some of the factors to be certain that it is accomplished on time, and to the fullest extent of your ability.

Comments:

I tend to agree with the author on his points in this chapter. I have found myself on more than one occasion saying to myself “I will try to get this done”or “maybe I will get this done” when deep down I know I will probably put it off. This point he say about making yes possible is defiantly a good mindset to get into going into the business world where everyone has a job to do.

Short summary Chapter 4:

In the fourth chapter the author talks about a variety of situations that you will face while coding. First is to be prepared and fully understand how long a project will take you. This helps cut down on late night coding. Another situation he details is when being distracted by some event in your life. He states that you should break for a little bit to try and remedy the situation stressing you. The author details about the Flow Zone, which is a super focused state of mind.

Comments:

In the fourth chapter the author talks about a handful of topics, But a few stood out to me. The first that really stood out is the concept of the flow zone. I for one did not think that this zone was an actual thing until I read about it and thought back to all of the times I have coded. The author says that the flow zone is not the place to be during coding. Also that the flow zone uses a different part of your brain. He states it is like a zombie state where you are not problem solving to your best potential. I disagree to a point. I understand his thought process, that coding under this focused state might give less efficient outcomes. But I feel as though every time I sit down to do work I do not get anything done unless I am in this flow zone.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The fist chapters title is professionalism. In part one the author states that the difference between a professional and a nonprofessional is taking responsibility for your mistakes. Part two is a detailed story of when the author did not take responsibility at first and it came and bit him in the butt later. Part three the author elaborates on taking responsibility and that as a professional you should strive to write perfect code and learn from the bugs. Also state in this section is that software should be like clay always changing and flexible. The next section is Work Ethic and something the author says at the beginning of this section is that it is not your employer’s responsibility to make you marketable. The author ends the chapter by stating that if you are going to be a professional then you should strive to know a large amount of your profession.

The second chapter focuses on the actual aspects of saying no and why you should. He details that if you know a project will not be done on time then you should say no to the manager who is pressuring you. By saying no you are stating that this cannot happen in this amount of time. In the end this situation helps everyone find a compromise and doesn’t lead to some catastrophic or terribly broken prototype getting launch into production. It helps everyone to say no.

One of the things in theses chapters that speak to me the most is when he states that it is not your employers job to make sure you are marketable. I believe that this trap is equality easy to fall into as a student. If you expect your teachers to constantly keep telling you to practice coding or to read your books then you will be failing yourself and your future career. I think that I might have fallen into this trap and now because of it I feel as though my skills are no  up to par. I will have to work hard to resharpen my skills. I have been in the situation of saying no to an aggressive manager before but the author has some interesting reasoning on how saying no helps both parties more than just agreeing and saying yes, even though you know it simply cant be done.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.