In the first chapter of Software Craftsman, the author talks about how working in the industry was different in the past compared today. He makes remarks that even though people who work in the industry have been there for a long time and have gotten the Senior rank, it does not mean that they have the assumed knowledge that a Senior rank developer should have. Nowadays, companies are wanting professional work and professionally made projects, unlike back when they used to hire cheap coders who thought they knew what they were doing.

I kind of have to agree with the whole senior rank topic when it comes to knowledge. Not everyone is as fresh when they reach senior rank and they would usually depend on the internet and make excuses to go through their day. While it could be anyone, the seniors have an ideal image as they are looked up to as leader so its interesting how today plays out.

In the second chapter of Software Craftsman goes into the topic of being Agile, as did the Clean Coder in the previous book. Talking about the two groups, process-oriented and technical-oriented. Process-oriented focused on what is priority to finish while technical-oriented aims for teams to focus on quality. The author then talks about the Agile manifesto which comes with the 12 principles along with other agile content.

Its interesting that the author started to point out that companies who have been tackling the agile process have been producing crap results in terms of code.I guess only people who know how to agile should use it or as the author calls them professionals. Describing how the work environment between two companies can tell how professional they are with organizing and that comes clear with being agile.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

This sprint has definitely been a busy one. After everyone got the programs downloaded and the server accessed, everyone was waiting for their invitation to the JIRA tracker for AMPath so we can all get ready to work on bugs. Before the bug tracking, we had an open conference online with developers of AMPath where developers were talking about different projects they are working on such as rewrite code to angular 3. It was after the conference that we start focusing on the bug tracking. I was one of the first ones to get an invite to the tracker so  I set up my account and showed off the tracker to my team. We did not know what bug we were going to work on but we were told that everyone will get to pick in the next class.

Eventually, after a coin flip and discussing among other groups, we decided to take the issue in the tracker known as AMRS-287, which was an issue that wasn’t really priority to address but would have been nice to take care off. The issue in detail was to find the “return to draft button” when navigating the forms and then move it to a more convenient place. Originally we thought it was an easy thing to do, but it was a bit more involving than we thought since we ran into some difficulty. First and foremost we had trouble finding the button. This took the longest portion of the sprint. We knew that we had to go to the locations where the forms were located to find the buttons but the links to the forms would not open for the life of us. We did not know what was happening, let alone we tried other servers as well to see if it worked and they did not.

Eventually I contacted Johnathan Dick through the tracker and he said to use the same test server we were using to find the button and edit the code. We tried again the week after, and then Kyle managed to find it after managing to access the forms. This was strange but the forms were accessed this time around. We debated where to put the button, and we decided to put the button near the task bar either above or below the vitals. We did not decide on a final place just yet but we will soon and hopefully take care of that button.

Other than the button issue, we have to address team behavior in regards to lateness so we are going through that as well, and that is to be continued.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Wow! Finally in the last chapters of Clean coder, kind of emotional right? I’m still holding it in without spearing a tear from my eye. In the 13th Clean Coder chapter, the author talks about the value of teamwork and how the concept is incorporated into projects. The gel phase gets talked about where its the phase a team really gets to know each other so they can adapt and work together properly. The author goes on about the challenges of being a project leader, including the the point where every team needs enough time to gel so they can work properly together and get things done and keep it together for as long as the project or projects are in development.

I didn’t know that a typical team is around 12 people, i always wanted to know about how many are working within a project. Let alone i wonder how that many people get to know each other while working in the environment, probably go out to the bar or something. Teamwork is critical since working individually on a project is tedious so this is a great topic to touch base on.

The last and 14th chapter of The Clean Coder talks about teaching people how to code and giving them opportunities to guide the educated by working with them and giving them advice. The author first talks about meeting a student who is going for a masters in computer science and somehow managed to avoid coding, and then goes into saying that school can not teach you into being a craftsman.

While I do know people who aren’t really good at coding and are in the CS program, they at least work in a different field that does not include a lot of programming and just mainly testing and maintenance. Learning on your own is super beneficial and school will not really teach you that, they only teach you what you learn from google in a shorter amount of time really. It’s the adventure you go to on your own that counts.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Chapter 11 in the Clean Coders targets a topic that was one of the factors that went into me deciding whether or not I should be a programmer, and that is dealing under pressure. The author goes into different occupations and how they have to handle pressure or else there will be consequences on their health and others as well. Pressure can include in terms of the programming field, creating what you need before a deadline occurs, doing everything in the right and best way, and also making sure the software works and not bug-fested. Pretty much advice is given to focus and not panic to make situations worse.

Pressure is everywhere, but not really seen as much compared to other scenarios or occupations. I can easily think about how programmers can get stress and struggle form the challenges of being a programmer. Not even sure if it’s worth the salary unless people are ok with the conditions they may experience.

Chapter 12 of the Clean Coders covers the topic of teamwork, where no enormous or ambitious project can be completed individually and requires the work of many developers and different departments. Programmers now-a-days program together in pairs which is effective in a way where coding performance is improved.  The author is telling the story about how he got fired for not taking his job seriously while preparing for a milestone, and then goes on to talk about how working with people is all about the concept of coding.

I know that if I did not ask for help from other people during college, I would have had a hard time coding without insight from my class mates and working with them on programming projects. Teamwork is definitely important and it was expressed well in the later courses for the major where we pair up with other classmates to work on projects.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

After deciding to have the reflections due at the end of each sprint instead of the end of the week, this reflection is going to summarize what happened during the last two sprints. The team began by forking the AMPath code on github and cloning the code to their computers. After getting the code settled and making sure everyone can open up the code in Webstorm, we tried to make sure that everyone was able to connect to the AMPath database through local host 3000. A majority of us had a problem where we got the login page to AMPath to appear, however the bottom right kept saying that the server was offline instead of online so we could not connect to it. That obstacle was later solved thanks to Ryan and other people in the class for searching for workarounds to the problem. The most common fix was a google chrome extension that you could download and it will allow you to connect to the server, however when that extension ran on my laptop it disconnected me from using the web. Later on, we found another fix that Ryan suggested which includes adding code to an xml file in the OpenMRS standalone folder and the connection worked out well with no side effects. We also added the proper OpenMRS directory to the server settings which connected us properly.

Other than connecting to AMPath, some users in our team had trouble starting OpenMRS itself since it took around 30 minutes to open for people, later on that issue was resolved but i do not recall what fixed it for them .We troubleshooted by giving them faster internet through a wireless adapter but that did not work out, they probably reinstalled it. We were also instructed to modify the login page of the AMPath and also get a proper understanding of the code which some of us did, but not all. We are now awaiting access to the tracker so we can help fix bugs and as well look forward to the EPIC goal that we are going to do as a class.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

In the 9th chapter of Clean Coder, the author talk about the concept of time management in programming.  Throughout the chapter he explains how meetings are required but at the same time end up being a waste of time. the fact that $200 an hour is being spent per person in a meeting and how it wastes time getting the project done by the deadline is a bad call. While meetings are optional, it may ruin the reputation of people and one would have to depend of their manager to get kept up to date. The rest pretty much talks about keeping healthy and prepared while attempting to maintain your goals.

What I found interesting in the chapter is that the author mentioned you don’t have to go to a meeting even though it is required to? Does that mean that people do not keep track of who goes or not, or are the meetings are not a serious as I thought they originally were?  I find it interesting how he talks about getting sleep and being aware around you and staying organized, i have a tough time doing that currently in my last semester.

The 10th chapter of Clean coders that us to the topic about estimation where the author describes the concept of estimation as fearful and risky since having an estimate is deemed an unsure, finalized choice. The big difference about estimation that the author pointed out is that businesses see it as commitment and developers see it as guesses. The best bet is to be safe on the estimation side when it comes to finding a completion date.

What remarks me is that how businesses and developers tend to have different interpretations of words such as estimation. It forces developers to become more cautious when telling their clients how the project should pan out. I agree with the part that the estimations are fearful and risky as one can never know the exact solution to how everything will pan out.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Chapter 7 of Clean Coders covers pretty much the scenario of both the developer and the business having different expectations or requirements where communication emphasizes clarity on what both sides want and expect to have. Other than that, the chapter also covers the concept of acceptance testing and how the author properly defines the term acceptance testing as “tests written by collaboration of the stakeholders and the programmers in order to define when a requirement is done”. While defining what done actually means, the author states that acceptance tests get the stakeholders, businesses and the programmer all on the same page since they all will know what the behavior of the program is going to be. Other than that the author talk about how the advantages of acceptance testing being automated is an advantage toward cost.

While personally I have never written tests that were automated before or even wrote programs for a business, i can not relate about having clients and working on their projects for them as well as the communication part. To be fair, I am programming in a team at the moment so I may get some kind of experience with that now but I do not know if we will be doing any automated testing.

Chapter 8 of  Clean Coders covers the aspect of having testing strategies. The big tip that the author notes is that the QA team should find nothing wrong when testing the developer’s software, and when they do find something developers may freak out about it. While the QA’s job is to find bugs, the testing strategies used by developers to make sure QA does not find any can include the test automation pyramid. The author takes time to describe this test pyramid as an effective way to test software. The automation pyramid includes (top to bottom) “M exploratory, System Tests, Integration Tests, Component Tests, and Unit Tests.

Personally I think its a challenge if developers have to be absolutely sure they flushed out all the bugs. If they do, then either QA isn’t trying hard enough to find bugs or they are missing some. While I commend there being requirements for developers to take part in to help make their code bug-free, I can highly doubt they can find and terminate all the bugs by themselves. I have not heard of a company that has a QA team that did not find any bugs at all because the developers were too good at debugging it themselves. Then again with the automation pyramid and other testing strategies, I could be wrong but I’m not ready to accept a world where QA people barely need to do anything and are considered non-useful.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

The 5th chapter of the Clean Coder focuses on the topic of Test Driven Development. The chapter involves the author describing his experience with Test Driven Development and how he realized how much beneficial the method of testing is and not just for reducing the cycle time in programming. When it comes to Test Driven Development, it is an opportunity to test yourself on how well you know your code. The author came up with rules indicating that a programmer should not continue programming unless they understand the testing process of their program, including writing failed test cases on purpose to know how the program will fail.

Test Driven Development is important in the creation of code as constantly testing every method you type or just mere lines of code may be kind of aggressive but it helps you debug what will go wrong and what works. Knowing what its like using Junit for testing my code makes me relate to the authors experience of TDD.

The 6th chapter of the Clean Coder focuses on a topic that I can not express enough myself regarding people who come to ask about programming and how hard it is. Anything is accomplish-able if you just practice! From talking about his first program and also getting a computer to code on, the author describes his journey from improving his coding skills and interest along the way attending conference events and practicing methods such as katas to know how to get used to a computer and practicing shortcuts like its a second nature.

People always ask me when I tell them I was a computer science major is “how is programming is it hard?” or “oh gosh programming is too complicated for me” I always try to come up with a response that involves to at least try and keep practicing. 10,000 hours of practice means you are a master at the skill, but you do not need to be a master in order to decently code.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

In regards to an update for what was during during this week for our project included doing peer evaluations where the professor gave us sheets with a set of criteria that we have to mark for each of our team member’s performance. Criteria included the attendance of the team members since we began our groups as well as how often they seek help and ask for help when they cross an obstacle. After we all decided the performances of our teammates we ended up getting our scores tallied and the results were talked about as a group with our professors revealing the results. It honestly felt like we were on survivor and we were getting judged to see who gets kicked of the island. A lot of people got perfect scores on the team and some had only attendance issues. The average was 2.8/3 which is great for a first evaluation and hope people can improve when it comes to their weakness as well as focus on maintaining their strengths.

Lately we updated our Trello tasks and adjusted our categories in a manner where we have a product backlog category and a sprint backlog which focuses on the tasks we are doing in class. If the tasks in the doing category that are grabbed in the sprint backlog (tasks we work on in class) do not end up being complete, then they get put in the product backlog and we have to finish those tasks in the next sprint.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Completely the opposite from the last chapter which is telling you to say no, this chapter revolves around the concept of saying yes. Reliability is one of the most hardest aspects to find around the world. Unless someone has a very good reason to instead of just saying yes out of the blue with nothing really in it for them. they will actually do what they were asked to do. You know its kind of like getting married with the whole “I do”, are you going to commit to a relationship even though you said you are? Or even when we are at work and people go “I’ll see what I can do”, though to be fair that’s not really a yes.  The chapter covers the difficulty of asking someone to get something done and questions the commitment of the people around you.

In the end of the day, the answer to a question is either yes or no, and I suggest that person thinks for a few moments in their head if they are really going to commit if they answer yes. If they don’t, the consequences are going to be more heavy than saying no in the first place.

The fourth chapter dives into the moments of when you go to code. For instance for the author, he had different scenarios when we went to code because he had an argument, the effects of coding late at night, and times where you are on a flow streak and constantly write code and feel like you are unstoppable. The chapter covers when you do not know what to do and also expressiveness your creative mind while coding.

I admire the author talked about his different experiences with coding, I can relate to coding at night but I actually think better at night but tend to do more silly mistakes. When I wake up again I notice stuff I didn’t notice late at night, i guess everyone works differently when they code.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.