In the third chapter of Mancuso of The Software Craftsman, he goes over what it is to be a software craftsman and the basic manifesto of it. After reading The Clean Coder, a lot of this chapter just felt repetitive. The just repeated what “Uncle Bob” said in the previous book; make sure code is working, but also easy to maintain and predict, make sure code can cater to the clients/industries changing demands, but make sure the code stays clean and is designed for a long lifespan, make sure to help other developers in need to build a better community for everyone, and understand that software development isn’t only about producing code, but understanding who you are making the code for and why they need it. The one thing that I like about this book more than The Clean Coder is Mancuso acknowledges that some companies will only see software developers as assembly workers and sometimes you can’t change their way of doing things. In this case, Mancuso wisely advise that you start looking for another place to work if that is the case.

In chapter 4 of The Software Craftsman, Mancuso goes on the top of “Who should be the one to advance your career?” Just like “Uncle Bob”, Mancuso points out that it is every software developer’s responsibility for them to continuously teach themselves new technologies in their field and not the companies responsibility to train them. As I might have said before when reading the The Clean Coder, I think that it depends on the company you work. If you work for a company that uses proprietary software or coding language, I believe that the company is responsible for making sure their developers get proper training on what they are using or provide material for them to learn about it. However, this does not discount the fact that developers still need to keep up on new concepts or behavioral techniques that they need to develop on their own. What I did like much better then The Clean Coder was that Mancuso delved into some of the different ways software developers could acquire the knowledge they need to keep up to date on their careers. He also took the time to create a small list of where to start acquiring this knowledge, and how to properly view this different ways (ex. types of books vs blogs vs technical websites). After that it goes into what The Clean Coder already stated; make sure to create pet projects for yourself and find “katas” you can do everyday or free period, paired programming/learning from other developers, contributing to open source projects to practice, and he also repeats the same “make time outside of work to work on these things” and the “25 minutes of work/5 minutes of break” technique that Martin spoke about.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

In chapters 1 of The Software Craftsman by Sandro Mancuso, it talks about how developers need to adopt to the changes that are constantly happening in the software field. It states that developers can no longer be only about coding. Instead they need to know about multiple different disciplines and techniques to be successful in the field now-a-days. This is nothing new to me. Lots of companies will not bother to look at your resume if you do not have at least some knowledge of different languages and frameworks, or even if you only have one degree. Also if a developer has no idea what the Agile process is, then they are going to have a hard time in this industry, so most of that part and the next chapter just seemed repetitive to me.

In chapter 2, Mancuso goes over what the Agile process is and how some companies fall into the trap of only transforming their process into a partial Agile process. Again there was nothing really new to this chapter for me. It’s already been driven in how the Agile process works, and how it’s not just making meetings and Sprints shorter, or how to deliver code and receive feedback faster. The other half is making sure that you produce code that is readable and can be easily changed if needed. If other developers are intimidated by the code that you are producing, whether that means that they don’t know how it works or if it’s badly written, then you need to go back and fix the code you are writing right then and there. If you neglect to do this, it means that that piece of code will most likely cause issues down the line because other professionals can not go back and easily change it if there is a issue that pops-up with the section that you’ve written.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

In chapter 13 of The Clean Coder, Martin goes over why teams should not be formed around projects. Instead a team should be put together with the objective being for that team to gel together and stay as a team for a long time. This makes sure that you have people that understand one another and can easily work with each other on multiple projects that they get. If this doesn’t happen, it may take longer for an makeshift team to get a project done rather than one that is already gelled. Martin also points out that it is also time consuming and expensive for a business to be constantly breaking up teams to work on different projects because of that fact. Again this just makes common sense to me. If you constantly have to predict how your teammates will act and never get into a rhythm, then you will be wasting time and effort on those predictions rather than getting your work done.

The last chapter of the book is directed towards those that are already in the field. Martin talks about how universities can only teach the next generation of programmers so much, and the rest falls to mentors that know what it’s like working in the real world. He talks about how, ideally, companies would know not to give recent graduates high level work that could possibly lose the company money. Instead there would be a hierarchy set-up that would make sure people with 10+ years experience would oversee people with less experience, and those people would train graduates on concepts and designs for a year before they are able to work on code. Even though this is technically in place – with project managers, older team members who over look younger team members, etc.  – there isn’t enough supervision and mentoring. I definitely agree with Martin on this point. While I have been learning a lot at college – about design patterns, different types of testing , etc. – I have not ingrained all of these teachings into how I program. I also know that there are tons of other things that I have yet to come across and learn because computer science is a huge field and I can’t possibly learn everything. Most of the stuff that I have absorbed has been from someone helping me personally with a project, or talking with a teacher or a professional on how to get some bit of code to work. This is why I think it is very important for people that are already in the field to remember to work and communicate with graduates, so that they can become better at what they do and, in turn, help the next set of graduates that come in.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

For our second Sprint in my Software Development Capstone we continued to set up our local computers so that we could work on OpenMRS and the AMPATH software. To do this, we first went to the OpenMRS Download Page and downloaded the OpenMRS Standalone version. Once that was downloaded onto my computer, I simply extracted the zip file and then ran the .jar file that was in the there to start the OpenMRS software (for this I also picked the demo data version that comes with 5,000 sample patients). Some people had issues that this point, but I was lucky that this worked right from the start for me so I didn’t have any modifications to make.

Once I had OpenMRS running, I then cloned the repository containing the Ampath Point of Care System Version 2 that one of my team members forked from AMPATH. To get this up and running I first had to download all the dependencies that they required. I first went and downloaded the newest version of Node.js from their website (for me that was the Windows 64-bit of LTS). Once that was working, I then downloaded the list of gloabals with npm install –global:

• webpack (npm install –global webpack)
• webpack-dev-server (npm install –global webpack-dev-server)
• karma (npm install –global karma-cli)
• protractor (npm install –global protractor)
• typescript (npm install –global typescript)

Once all of that was installed, I finished up the rest of the installation by doing these last three steps:

• npm install webpack-dev-server rimraf webpack -g to install required global dependencies
• npm install to install all dependencies
• npm run server to start the dev server in another tab

At first when I ran “npm install” it seemed to give me a list of issues, but when I ran the server everything seemed to work fine and I was able to get to the login screen.

With that completed, our team then set off to work on re-writing the Authentication Module in the AMPATH software and see if we could get it to work (basically just familiarizing ourselves with the software and Angular 2). Our team first put this up as one whole task that need to be completed, but after going through it, we decided to have a story time to break down this task into smaller ones. At this meeting we also decided on what our meaning of “Done” was. Since this was all done closer to the end of our Sprint (due to an excessive amount of snowstorms), our team was only able to do the very beginning of this project. We all start first on going over the login HTML and CSS. Since it’s been at least 4 years since the last time I wrote anything for HTML or CSS (not including what I did for the tour of heroes tutorial), I just put their code next to mine and copied it so I got a feel and could see what they were doing to create the login screen. The last thing that we got to do before the end of our Sprint this time was look over the authentication.module.ts and its dependencies to get a feel for how it works.

During our Sprint review/retrospective we decided to put the rest of the re-writing of the Authentication Module on our backlog and get to it next Sprint. Overall I think that this Sprint went really well, with the exception of how late we got to our story time, but that was all because of storms cancelling our time together and messing up our schedule. Another thing that I found really useful was one of my teammates saw that Scotch.io had a good chuck of their Routing Angular 2 Apps class free to watch. I ended up watching the first couple of videos and found it very helpful, and I will probably finish watching the rest of them over the weekend.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Most of chapter 7  and 8 were things I had already learned from the previous testing class that I had taken. He goes over that unit tests are different than acceptance test, always try to make automated tests because they are cheaper, and all the different types of testing their are and what each one of them covers in the system.
The main thing that I took away from this chapter was that you, as a developer, should make sure that clear communication is established between your team and the stakeholders that you’re working with. Primarily you don’t ever want to assume that the other party knows what you are talking about, or that you are on the same page.  These assumptions can, and usually will, lead to huge messes down the line that may result in your team having to fix the entire design of an application that you were building because you misunderstood critical information that the client was ambiguous on. So, moral of the chapter, never be afraid to ask question and bring in people that may help to clarify the story that the client gives you.
I did also find the small section on testing GUIs interesting. Martin points out that you should not test the GUI itself, but the under lying structure by designing they system to treat it like an API. This makes perfect sense when you think about it because a GUI will always be changing to whatever the clients preference is.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

In Week 3 of my Software Development Capstone, we finished up our Sprint and focused on doing the Sprint review and retrospective. First we rated each team member on a scale of 1 to 3 – 1 being “Needs Improvement” and 3 being “Excellent” – on how well they preformed certain things during the Sprint; like communication, completion of tasks, etc. Overall our team went easy on one another for the first round since everyone was still getting the hang of doing the daily scrums and what we defined as “commitment.”

After that we did the overall retrospective of what our team could do better on in the future and also put items on the product backlog to address in the next Sprint. Again we didn’t go too far into the retrospective since we didn’t do much work besides go over the Angular 2 tutorial and read some of the Advanced pages about Angular. We did go over small things that we wanted to put on the Sprint Backlog such as making a proper definition of “done” for the team, and also setting up a priority list so we know how long certain tasks will take.

Overall it seemed to make sense to go easy on this first Sprint review/retrospective so that all team members have a baseline for how this will go. Once we have code and actual projects to work on, our team plans to go more in depth about giving reviews for people  and also take a bit longer with our retrospective about what our team could improve on in the future.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

In the third chapter of Clean Coder by Robert Martin, he talks more about making sure that you are clear about what you plan to do. Even though this chapter is titled “Saying Yes”, it’s more about how to make sure you can say yes and what it means to say it. A lot of this chapter is common sense and builds upon chapter 2. Basically that if you’re a professional you want to make sure you stick to the schedule you’ve set up for yourself and your team. Make sure that you stick to the deadlines that you have proposed and don’t agree to any extra work that you know you are not able to do. Also if you say you are going to finish something by a certain date, you are agreeing to be done by then and not “sort of” done. If you run into obstacles that may delay you and, in turn, the project, make sure to let your team or boss know immediately to figure out a plan. (This last part is covered in chapter 4, but feels like it should have been included with the part about commitment.)

In chapter 4, Martin discusses things that may impair your ability to code and how to deal with them. Again this chapter boils down to make sure that you take care of yourself, mentally as well as physically, and don’t ignore the fact that you work in teams or pairs. With most of this chapter, I agree with Martin. I find it hurtful for what I’m working on if I’m worried about something else or if I’m up really late at night. Since most everything you do is within a team, you don’t want to ignore them by being in “The Zone”; I know that I get rude when I tunnel vision into something. The only thing I don’t agree with is music. I sometimes find it helpful to put on music that is relaxing and has no lyrics, but when I really need to concentrate I turn it off. The last main thing that I agree with is helping one another. I have learned so much more from someone showing me how to do something or teaching someone else to do it. Programming is no longer something that is done purely by oneself, so helping and communicating to your team is an important part for one’s career.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.