Chapter 11 covers the topic of pressure at work and how to handle it. The first piece of advice is to try to avoid pressure to minimize the time spent under it. The author reminds us that we are not bound to commitments made by the business on our behalf. We have an obligation to do our best for the business but the ultimate responsibility comes down to the person making the commitments. Next the author mentions to always keep code clean to avoid any mess. Messy code always slows the process down and creates headaches in the future. After the tips on avoiding pressure, the author goes into handling it. The first piece of advice is to stick to your disciplines and maintain your professional behavior. He mentions not to panic and lose sleep because that doesn’t solve anything. Lastly he advises to communicate with your team and co-workers when something is going wrong. Always be clear at every step of the process so there are no surprises. Additionally, get help and pair program with a team member to get on track.
After reading chapter 11, I think there was some good advice to keep in mind in future pressure situations. The most important I felt was to maintain discipline when facing pressure. Too often it’s easy to get out of a situation in a messy way and this usually creates future problems. By sticking to the behavior you know is correct, you will handle the situation in the best way. The section where author talks about where we are not bound to our commitments disagreed with me a little. While I don’t think it’s appropriate to have a business make commitments for my work without my consent I still need to be employed at the end of the day. He mentions being able to walk away with honor however, in reality if you have a family at home it’s not that simple. You also have to think that your next employer will want to contact your most recent employer and ask about you. Not being able to meet the needs of the business is not going to land you a new job quickly. While I think the advice in this chapter is worth noting, it is more of a general way of handling pressure, not very specific to developers. However I do realize that handling pressure will be important as a future professional developer.
Chapter 12 covers the topic of collaborating. The author makes it clear that programming is not an individual activity and requires working as a team. A professional developer should make a point to understand their businesses goals and work between teams and departments to accomplish those goals. He is very clear that programmers must work with people and that pair programming is a great way to do that. It increases efficiency and allows employees to share their knowledge among each other. An important point the author makes is that the team as a whole owns the code and not one individual. In conclusion, this chapter was rather short but highlighted the important of working collaboratively on a frequent basis.
After reading chapter 12 my thoughts of collaboration were confirmed in the sense that it is extremely important as a developer. I think people who can truly see the teams goals as their own always prove to be successful because they see the bigger picture. The author’s story about the first time he got fired seemed a little off topic. It seemed to be more about his punctuality and attitude that got him fired, not his lack of collaboration. As a beginner developer I think collaboration will be necessary for success at my first professional job. It will allow me to work with people with valuable knowledge and be part of complex projects I couldn’t quite do on my own. I highly expect to be collaborating regularly upon entering my first development job.
For Sprint 2 we started to actually get involved with the AMPATH project. The first main task was to actually get the project running. First we forked the project to our GitHub accounts, then we cloned the remote repository to our local repository. If we didn’t already have Node JS installed we needed to download that and install any required packages into the ng2-amrs folder. After that we could run the server with the npm command and have a live AMPATH site running in our browser. Once we had AMPATH running we then needed to download the openMRS standalone and connect AMPATH to it. In order to connect them we needed to update the server settings on AMPATH to the standalone server and add some code to a web XML file. Connecting AMPATH to the standalone allowed us to successfully login to AMPATH with access to a mock database. As simple as these tasks sound it was far from an easy setup. At least in our group it took us all several attempts and some troubleshooting to successfully get AMPATH online. We had server errors, issues getting the standalone to run, and version compatibility problems. Each team member basically had to work through their own list of issues to get connected. Aside from the effort of getting the project up and running I completed a good Angular 2 beginner’s tutorial on thinkster.io. I thought it was a better introduction to Angular 2 and I definitely feel more confident with the framework’s fundamentals. To finish off the sprint I started browsing the AMPATH source code. It is a bit overwhelming but I think the more I review the better I will understand. The biggest learning curve is learning the complexities of Angular 2 syntax and the module style development. At the end of the sprint I thought our team retrospective went pretty well. This was another sprint where all the tasks had to completed by each individual so it’s hard to really judge the team’s effectiveness. Overall we are all completing our individual tasks and helping each other as we move through the sprints. Looking into the next sprint it looks like we will be re-writing a module and working on some known AMPATH issues. This should allow us to make our first true contributions to the project and tracking issues will improve our knowledge of the code base.
Chapter 9 covers the topic of time management. The first thing that is talked about is meetings. They are necessary yet frequently very wasteful of time. The author lays out some guidelines to approach work day meetings. The first suggestion is to not attend every meeting. Only choose the ones that are of value to you or require your attendance. Next is to politely decline meetings which aren’t well structured. Meetings should have an outline of talking topics and talking times clearly defined. Lastly is to not be afraid to excuse yourself from a meeting which has either gone off topic or possibly dragging on. Next the author touches upon some things you can do to help keep focused at work. He mentions adequate sleep, consuming some caffeine (but not too much), and breaking with non-work activities to include exercise. The author goes on to mention a time interval strategy called tomatoes which is a Pomodoro technique. Basically you set a 25 minute timer and during the time you deflect any phone calls, issues, or other distractions. After the 25 minutes is up you deal with side tasks and possibly take a short break. When you’re ready, you start the timer again. Lastly, the author talks about blind alleys and software messes. The main message is to never go too far into something that can’t be abandoned. Furthermore it is always easier to turn back at the current time than to keep moving in the wrong direction.
After reading chapter 9 there are definitely some good tips to keep in mind to improve time management skills. The tomatoes technique seems like it would be an effective way to stay productive during the workday. Each time you start the clock you are dedicating 25 undistracted minutes towards completing a main work task. This is something I will try to put in practice especially on days that seem like they may be slipping away. Another tip I will keep in mind is to avoid priority inversion. I am definitely guilty of changing my priorities based on how I feel about tasks rather than doing them in the order they truly should be done. Recognizing that I do this, I will try to be more aware of how I rank my daily tasks and make sure they are correctly prioritized. I thought the section on “focus-manna” was not entirely necessary. Every working adult knows that sleep, exercise, and coffee are going to help performance on just about anything. I also wasn’t in complete agreement about leaving a meeting. If you have committed to attend a meeting I think it would be rude to leave before it is over and it may rub off the wrong way on co-workers. I would finish the meeting I was in but be more mindful of what meetings I attended in the future. Overall this has probably been my least liked chapter so far. I think that chapter assumed too many ideals and I didn’t agree with everything that was mentioned. Still, it is important to remember that the author is one of the most respected software professionals there are so his advice should always be digested and considered.
Chapter 10 covers the topic of estimating completion dates. It is made clear that a commitment and estimation are very different from each other. A commitment is something that must be accomplished and has a hard date associated with it. An estimation is not a promise but a likelihood or ballpark figure. As the author mentions it is best to outline a probability distribution for the likelihood of different time frames. One technique he mentions is PERT which uses a trivariate analysis. Basically a developer will make an optimistic, nominal, and pessimistic estimate and rate the likelihood of each. This gives management a planning guideline they can work with and better communicates deadlines. The author also mentions a popular estimation technique which has many forms called “wideband delphi.” The main idea of this strategy is to make group estimates of tasks and projects. This gives more accurate estimates as well as ensures the entire team is in agreement. Lastly the author refers to the Law of Large Numbers in the sense that projects should be broken down into smaller tasks and each of those tasks should be given an individual estimate. The total of the all these tasks added up should be more accurate due to the better attention of detail the project may require. In conclusion, the author suggests being cautious with commitments because they must be mandatorily met. A well thought estimate is usually the best course of action for a professional developer.
After reading chapter 10 I will be more careful of things I fully commit myself to. I definitely think that team estimating would be the most effective and accurate strategy. As a new developer it would be tough to give confident estimates so a group setting would surely help guide accuracy. If a team is implementing the Scrum framework then they are already following most of the guidelines in this chapter. While I think the trivariate analysis is also a good strategy to gauge likelihood, actually calculating a probability distribution seems like overkill. I may be wrong but I don’t think most work environments will require such calculations for every task and project. In summary, Scrum continues to be a framework which encompasses many of the guidelines and suggestions covered in this book
Chapter 7 covers the topic of acceptance testing. This kind of testing is usually a collaborative effort between the stakeholders and the developers to define the definition of a requirement being done. By using acceptance tests, you can help avoid what the author refers to as the “premature precision trap.” Basically either the stakeholder or developer or even both is too specific which causes irrelevant requirements. By properly conducting acceptance tests a project becomes clear, precise, and it promotes communication. As a professional developer there are several key responsibilities in the acceptance test process. First, it’s the developer’s job to remove any ambiguity from what the stakeholder is asking for. Second the developer should always express an error bar when determining time tables with a stakeholder to prevent estimation anxiety. Lastly, the developer’s role is to connect the acceptance tests to the system to make it pass. Not to create the acceptance tests. The author clearly separates acceptance tests from unit tests. An acceptance test doesn’t care about underlying code but more that a system is behaving like it should from the businesses point of view. Furthermore acceptance tests should run several times a day in a continuous integration system and they should always pass. These tests should also always be automated as manual testing is much too costly. In summary, acceptance tests are mandatory for a professional and increase efficiency between stakeholder and developer.
After reading chapter 7 there’s some important points to remember. However, seeing as I’m not working with stakeholders in a working environment yet there’s not too much from this chapter I can directly apply to my programming right now. I thought one important point was to always estimate with a margin of error. By giving an exact completion date you don’t leave room for setbacks that are bound to happen. Also I will have to remember that it is not the developer’s role to write these acceptance tests. If I come across a test that doesn’t make sense instead of trying to re-write or discard the test, it’s best practice to negotiate with the author for a better test. Moving forward I will keep acceptance tests in mind however it will be some time before I can directly apply the lessons from this chapter.
Chapter 8 covers the topic of testing strategies. The goal of any testing strategy should be that QA finds nothing when they examine a program. In order to come as close to this as possible the developers and QA members need to work closely and follow a hierarchy of tests. By following the Test Automation Pyramid the author lays out, development teams can achieve this goal. The bottom layer consists of unit tests. These test the low level specifications and underlying code. Next are the component tests. These are “happy path” tests written by QA and business with help from the developers. Businesses should be able to interpret and understand these tests. Next are the integration tests. These test the communication of component groups and make sure they communicate properly. Next are the systems tests. These execute against the entire integrated system and make sure the full assembly of components is connected. Lastly the top of the pyramid consists of manual exploratory tests. This involves human testing to seek out odd behavior and ensure normal behavior of the system. This kind of testing is unscripted. By following a hierarchy of tests like this, professional development teams are following best practice of Test Driven Development.
After reading chapter 8 I understand the concept of the testing hierarchy but some specific examples at each level would have been nice. The concepts in this chapter will be better applied when I am on an actual development team. It will be interesting to see if my team uses a similar testing strategy. I think the author places a lot of faith in development teams that they will have the communication and discipline to follow this pyramid forcefully. In a smaller company it may not be so easy to break down these testing levels into such clear guidelines. I do think it’s important to remember the manual exploratory testing. While the computer can tell you everything is working properly you never know for sure until you’ve actually tested and observed the system as a user. In summary, I will keep testing strategies in mind as a professional developer and am eager to see what strategies are truly being implemented in the field.
Chapter 5 covers the topic of Test Driven Development (TDD). This method of coding involves writing unit tests prior to any production code. The author summarizes TDD in 3 laws which must be followed: 1) You can’t write production code until you write a failing unit test. 2) You can’t write more of a unit test than is sufficient to fail. 3) You can’t write more production code than is sufficient to pass the failing unit test. The chapter goes on to highlight many of the benefits of TDD. First, it creates certainty when any code is changed. If sufficient tests have been put in place then you can be certain any changes haven’t broken other pieces of code if those tests still pass. This will also reduce the fear among programmers making changes to older code because they have the reassurance of their tests. The author also points out that the TDD approach significantly reduces bugs and defects in the production code because every function, class, detail, etc. needs to have a passing test. He also makes a point that this provides good low-level documentation to the appropriate audience of how the code really works. Lastly, TDD forces developers to practice good software design because each function needs to be in an independent and testable state. In conclusion the author basically says TDD is necessary for any programming professional and is considered best practice.
After reading chapter 5 I believe there are some good takeaways for a beginning software developer like myself. Many times for school assignments unit testing wasn’t really required so I think it’s important to realize what will be required as a professional. TDD seems like a very smart approach for development in the sense of reducing bugs and increasing confidence to modify older code. This would most certainly save time, money, and other resources. I thought it was important that the author noted it’s still possible to write bad tests which would hinder the effectiveness of TDD. As someone who hasn’t written a lot of tests I think I would definitely need some practice before I could make worthy contributions in a TDD cycle. Having said that I think I will start going back to older programming projects and work on my test writing skills. After some practice I will hopefully be on the level of understanding I need to be able to write unit tests before the actual production code. Moving forward I’ll adjust my approach to coding to reflect the three laws of TDD as best as I can.
Chapter 6 covers the topic of practicing coding. The idea is that any professional practices so that they can keep their skills sharp. The author gives some of the best ways he has seen developers practice which he also calls coding dojos. The first coding dojo is called a kata and it basically involves a developer solving a programming problem but in a choreographed manner to strive for perfection and commit the solution subconsciously. The second dojo is called a wasa and involves two people performing a kata together. Basically one person writes a test and the other writes passing code. This method also helps enforce TDD discussed in chapter 5. The last dojo is called randori and usually involves a group of people. Basically code is projected on the wall and every group member walks up and either writes a unit test or code to that passes a unit test. All these methods help commit problem solving techniques to memory so that they ca be called upon with ease at another time. The last part of the chapter mentions that practicing is up to the individual and not the responsibility of employers. Due to this fact, developers should practice skills outside of their expertise to broaden their knowledge and keep their resume fresh. In summary, a professional practices their programming ability and seeks to diversify their skills on their own time.
After reading chapter 6, I think it gave me some helpful reminders. While in school it seems like I’m always learning a language or tool to complete one assignment. I don’t typically go back to expand on a subject or practice what I’ve learned. This would be a really good habit to adopt so that I am retaining my past learning as well as adding to it. I felt that the author’s mention of practicing reinforced the idea from another chapter that a professional dedicates 20 hours of their own time each week to growing as a developer. After reading this chapter those 20 hours should surely include practicing their development skills. While I am still learning a lot I am going to try and dedicate some time each week and practice or even just re-learn a problem, skill, etc. to become more of the professional described in this book.