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.
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.
Chapter 9 is titled Time Management. This is one of the skills that I for one could use a little more practice and will power in. The author states a few interesting things that I had not previously thought of. One of these ideas is that meetings are necessary but also a huge waste of time. This is interesting to me because I viewed meetings as an important information gathering tool within a business. But I guess from the other view point it can take away a lot from the actual work flow. The author states that a professional should only got to meetings that have a clear benefit. He then details a little about arguments and focus.
Chapter 10 is titled Estimation. The author elaborates on why estimation is the cause of so many problems. He has states similar things in previous chapters. He says that the management team takes estimation as reality and will be expecting the project to be complete. This is one cause of major headaches to everyone. The rest of the chapter talks about some of the estimation procedures that can be used.
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 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.
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 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.
Next we all needed to make an OpenMRS id and introduce ourselves on the official form. This was also quite easy. One of the team members (Danny) did happen to get banned from the board very fast. This was probably due to a random occurrence.
Then we set up Trello integration into Slack. This was just a simple command.
Then we installed the WebStorm IDE by Jet Brains. Lucky enough students get a year of some Jet Brain software for free. So that was quite helpful.
If you are a student looking for professional development software, but want it free click here.
The last of the tasks was to complete the Angular Tour of Heroes. This was the hardest part of the week. It was a quite fluid tutorial, but I got stuck a few times. I had a difficult time with knowing where to put some code portions and some of the spelling mistakes took far too long to figure out. I greatly appreciate the tutorial the Angular team has produced because it gave a great overview of some great things Angular can do. I went through the tutorial a few times to try and get everything down. I don’t know if I completely understand everything. It is always process to learn a new language and I am defiantly on the right path.
If you want to try the tutorial here is a link to it!
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.
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.
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.
This week was mostly set up processes. We choose teams with an interesting voting strategy which seemed to work except that someone had dropped the class and there was an odd number of students in the class. Then we chose a team name by having everyone pick a letter and then finding a some what coherent word with those letters.
We then set up a slack for our group. Slack is a group chat room that allows users to post links and information. I have not specifically used slack but I have used discord. Discord is similar to slack but also has a voice chat option. It is a very good way to keep the entire group updated.
Then we learned what we could about the project we would be working with. OpenMRS is a client server application that allows people with little programming knowledge to build medical records. This system is very useful in developing countries and countries without the necessary funding. AMPATH is one of these record systems that is based in Kenya and helps with all kinds of needs. For the OpenMRS Platform they use Spring MVC and Java EE, and for their ORM they use Hibernate. And front end stuff they use Angular 2.
I am excited to learn more about Angular 2 because at my internship there is a group working in Angular 2 and they are doing new things in the industry.
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.
This is my first post of the Software Development Capstone. We will be working in teams to try and produce something worthy of production. This should be some great experience working in a team and learning some new skills like angular 2.