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.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

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

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

For week 3 I focused on finishing the stories from my teams first scrum cycle. The only one I had left was to complete Angular Tour of Heroes Tutorial which I did successfully. After finishing the tutorial I didn’t feel very prepared to build an application using the Angular 2 Framework. I think the tutorial was more for a developer who had some previous experience with web development. After some google searches it seems my best bet would be to learn the fundamentals of JavaScript, HTML, and CSS. To start that process I completed the free versions of “Learn JavaScript” and “Make a Website” on codeacademy.com and I am starting to feel a little more knowledgeable. These courses covered the mentioned topics and basically use a compiler in the browser window to walk a user through lessons. I think the next logical step would be to try and make my own web app using an IDE (probably WebStorm) to apply what I’ve learned. My biggest obstacle with Angular 2 was not knowing the syntax and how different pieces of code worked together.  I have also enrolled in Angular University which is a free resource that explains a lot of the framework’s concepts more in depth. I haven’t looked too much into that yet however. Also for the week my group finished our first Scrum cycle. We definitely need to improve on our daily scrums but overall I think we had a good sprint and reflection discussion. It will be easier to assess the effectiveness of a sprint when our tasks are truly divided and we are working on our actual project. In conclusion the first cycle went well for the team and I now know I have some learning to get done so I can better understand Angular 2.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

For week 2 many of the tasks were aimed at getting set up for the rest of the semester. This week is our first real Sprint following the Scrum cycle. The first sprint planning meeting was a little unconventional because all the stories really needed to be completed by each group member. Therefore there wasn’t really a division of work. The first story I completed was creating a Trello login and figuring out how to use the tool. Basically Trello is used for project management and consists of boards made up of lists filled with cards. This setup is acting as our Sprint Backlog and Task Board. We have 3 lists titled Backlog, Doing, and Done. Under each of these lists are the cards which represent a story that was assigned to the current sprint. The tool has an easy drag and drop feature for moving the stories to the correct columns. Next, the team integrated our Trello board with our Slack channel so we can modify the board and get notifications in Slack. There is a built in app for Trello in Slack so the integration is pretty easy and notifications can be configured to the team’s preferences. Next I created my OpenMRS ID so that I can communicate within the development community for the project. I then posted my introduction to the OpenMRS talk page which is basically a communication forum for the project. Lastly I installed WebStorm on my computer which is a JavaScript IDE built by JetBrains. I made a JetBrains student account which gave me access to all of JetBrains tools for free. I thought this was pretty cool and plan to revisit the site to see what other software they have. As for now I haven’t really started using WebStorm but plan to do some kind of tutorial to ensure I am using the IDE to its potential. Lastly, I realized I did not post my Daily Scrum in my slack channel on Friday so I need to make sure I am doing this in the future. As a team, each individual should be posting their stand-up in the channel Monday, Wednesday, and Friday. As this is our first sprint it will take a few cycles before we all are proficient in the sprint process. Looking into this upcoming week I still have the Angular Tour of Heroes to complete and I’m sure the team will be getting more familiar with the OpenMRS source code as well.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Chapter 3 covers the general topic of when and how to say yes as a professional at work. The stand out message is three simple rules: “You say you’ll do it. You mean it. You actually do it.” Avoiding phrases like “let’s” and “we” are crucial because they almost always hint at non-commitment. It said to make more definitive and personal statements. These include using “I” and giving a specific task which will be completed at a designated time. This chapter also reinforced a theme from chapter 2 in regards to only committing to what you can truly deliver. That is if you depend on another team or individual only make real statements about yourself however work with that other party as best you can to get closer to the target goal. Also another idea mentioned previously was early communication. Specifically mentioned in this chapter is to raise a red flag as early as possible because this gives the best chance at a work-around that still allows you to follow through with an expected task. The strongest point of the chapter is to be clear and definitive when saying yes, similar in how to say no in chapter 2.

After reading chapter 3 I have a few takeaways to reflect on. The first is to be more definitive in my own statements. I am definitely guilty of using the “I’ll do my best” mentality and after reading this chapter I realize that way of thinking won’t cut it in the long run. I also think an important message was to not commit to something that is out of your control. Looking forward I will take more time to think about what I am actually promising will get done and ensure it is fully within my power to do so. I also think the last scenario in the chapter was a good lesson. The employee promises that he will meet a Monday deadline knowing he is fully capable of doing so. It was his confident negotiating of taking a day off after his task was complete that I found worthy of remembering. This shows it’s sometimes okay to put in that extra work for an earlier deadline but not to be afraid to take that time to reset afterwards. Once again I believe applying the Scrum development process could help avoid some of these situations and improve your saying yes skills. By having semi-regular sprints you are saying yes and being held to your word on a more frequent basis. This development framework should help keep everyone honest and committed.

Chapter 4 talks about a wide spectrum of factors to keep in mind when actually coding to maintain the professional character the book strives for. One of the main factors mentioned is distractions while coding. This could be that you didn’t get enough sleep, a personal issue at home, or possibly just writers block. You should take some time away from the desk and see if there’s anything that can be resolved regarding the issue so that your mind will be able to focus on your code. Secondly, the author mentions “the zone” where programmers may feel like they are on a roll and have tunnel vision. He warns that you should never code in this state because you lose sight of big picture concepts and will likely return to the written code to fix mistakes. Overall the theme of this chapter is that you should recognize when you are not doing your best coding. It’s suggested to meet with a pairing partner or maybe just walk away for a few minutes so that only the best code gets written.

After reading chapter 4 I think there is a lot of good advice to keep in mind when coding in the future. This being said I’m not sure everything is as easy as it is told. Life distractions will always be present and I’m not sure trying to solve them at work would look professional among my peers. I do agree however with the idea of stepping away and taking a break if I feel like I’m not writing good code. Having a mentor, as the author mentions towards the end of the chapter, could be a great way to stay on track by meeting regularly with that mentor or even a partner. In regards to the author’s mention of false delivery and defining done the Scrum framework once again would help prevent the shortcomings mentioned in the chapter. Throughout the book so far Scrum has proven to address many of the concerns in each chapter. I am starting to see why this form of agile development has been so widely adopted.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

We’ve only had two classes so nothing too detailed to cover for the week. Basically we had an intro class where we learned the work for this class will involve the OpenMRS project and more specifically the AMPATH sub project. I reviewed the SCRUM fundamentals because that framework is how our class teams will be approaching work flow. Additionally we chose the teams we will be working with and I am on Team Loading… for the duration of the project. Lastly I got familiar with Slack which is basically an effective messenger for development and professional teams. This is where my team and the rest of the class will post important project information and communicate among each other. Looking into next week I expect to start setting up my environment for JavaScript and Angular 2 as these will be required to contribute to the project.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Chapter 1 gives a layout of what a true professional software developer should be and highlights a broad spectrum of attributes one should possess. The first major trait is accountability. More specifically, while bugs are certain to occur it is up to the developer to do everything in their power to see their employer’s problems as their own and take all measures to avoid bugs and errors. When a QA team comes back with a bug, a professional developer should be surprised. The second major trait of a professional developer is testing. It is even suggested to use test driven development (TDD) where tests are basically written before the actual program. There should always be some form of automated testing to ensure software is working correctly prior to QA. Also along with the coding aspect, a professional is always making small changes to the structure of their software to ensure continuous improvement. Lastly, a true professional pursues knowledge and information outside of working hours. It is said to dedicate the 40 normal working hours to your employer and 20 hours for self-growth every week. Within those 20 hours it is also not only important to learn new skills but also practice and sharpen skills already obtained.

After reading chapter 1 I believe there are a lot of takeaways, especially for a student who is seeking good habits before letting bad ones set in. One thing that I am going to look into further is the test driven development approach. I lack the experience and knowledge of appropriate testing and by writing tests first I think it would have nothing but positive effects on my development. I also think the 40/20 hour split is an important habit to start now. Even though as students we are learning many hours already, I still strive to learn outside of the curriculum and this chapter has reconfirmed my actions. I will try to continue if not increase my time spent learning more skills outside classroom studies. Lastly I definitely need to practice more of the skills I have already learned. I often find myself only using something when I need it, forcing me to look simple things up that should be committed to memory. This chapter showed me what I really need to be doing if I want to consider myself a professional by the right definition.
Chapter 2 highlighted a lot of situational awareness of when to say no as a professional software developer. One key point is to search for the best possible outcome when dealing with a supervisor. Additionally, never make false estimates and always stay honest in what you truly believe. Saying or working with the “I’ll try” attitude is recipe for disaster and not the trait of a true professional. Lastly, the chapter is clear that being upfront and consistent with your abilities and timelines is best for everyone involved.

After reading chapter 2 I can definitely see how this advice may come as more of a challenge to a junior developer. They lack the experience to accurately and confidently set time tables for themselves. I think there may be an unavoidable learning curve to the “saying no” mindset however it definitely seems like great advice to follow. Having a systematic approach to development such as using Scrum could also alleviate many of the issues described in this chapter. Working in shorter sprints with continuous contact with the client in the Scrum manner should for the most part prevent a team or developer from being coerced into an impossible task. Also, it is much easier to say no as a team rather as an individual to a supervisor. Great content to think about and to keep in mind when you know you are being pushed to accomplish an impossible task on time.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.