This post will revolve around chapters 1 and 2.

Chapter 1 talks about the current status of software development. Now a days, as a programmer, writing code is not all you have to do in the work place. Now one must contribute to the company in many ways. The author also goes on to talk about the situation with seniority among developers. Though they may have more experience, the way they may do something could be so outdated, that a new programmer might be a better fit, because he/she is comfortable with the latest technologies and methods.

Chapter 2 talks about agile development. It begins with the author talking about the methodology of agile development. Companies who adopted this type of method, were back to their old ways, because they did not see the results that they had yearned for. The main reason for this as the author states is that the companies were not committing to the whole transformation. They were only committing partially which entailed in the crap code that were produced.

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

Another sprint review in the books and it’s safe to say that our vision for our end goal of completing a module for the OpenMRS project is much more clear.

During this sprint, we have made contact with some of the people leading the project and they were kind enough to give us a list of issues that they would like for us to fix. The issues were located in the AMPATH Jira group and we got to select an issue to fix. Along with selecting an issue, we were also given a test server that we could use to incorporate our new code.

This sprint was not perfect, but we got through it. The first issue that popped up was with the test server not being loaded properly in the browser. As a team, we found a plugin called “allow control allow origin”, which allowed us to successfully connect to the server. After connecting to the server, we had to review the code given to us. Since the issue was given to us near the end of the sprint, we were unable to complete a module for it.

I look forward to the next sprint and I believe that our team is doing very well.

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

This blog post will revolve around chapters 13 and 14.

Chapter 13 talks about teams, projects and how it’s important to work as a team in order to accomplish a goal. The author believes that a “gelled” team is very valuable. According to the author, a gel team consists of each team member knowing the strengths and weaknesses of every member on the team. The gel team goes by a very common expression that goes like “Theres no I in team”. I think that a gel team is very important, because it makes you become aware of everyone’s weaknesses and strengths when tackling on a project. I see this as a good thing, because it will allow the team to collaborate and explain things which will lead into everyone being on the same page.

The final chapter talks about how just because you have a CS Degree, doesn’t make you qualified for the real world. Though an education at a university may teach you the basics and theories in programing, but it will never prepare you to what the real world actual has in store for you. He then talks about how having a mentor is critical to molding one into a good developer. I believe with this, because programming is not a very easy task, If one does not seek help, then he/she is not fulfilling their full potential.

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

This blog post will revolve around chapters 11 and 12

Chapter 11 is all about pressure. Professionals thrive under pressure. If you look at athletes like, Tom Brady, Steph Curry, Lebron James  and others you can see that they thrive in this kind of environment. This is what makes them great. One may say that it’s impossible to avoid pressure, but I beg to differ. One way to avoid pressure is to do your work early, on time, and don’t make commitments that you can’t see through.

Chapter 12 talks about collaboration. When I first started programming, I noticed a lot of people working alone. I always preferred working with others, because it’s efficient and if you get stuck on something, the other person can help you out. You can’t do everything on your own, but with the help of collaboration, you can achieve greatness.

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

It’s finally the end to an extend sprint and in all honestly, i’m disappointed with the progress that I’ve made individually. I told myself that I would get through everything on the task board, but there were many roadblocks for me in this sprint. I had a tough time connecting the OpenMRS standalone to the AMPATH. It took me a really long time to do it, but I eventually diagnosed my problems and got it to work. What I did was add a piece of code in the web.xml file, and installed a chrome plugin called ‘Allow Control Allow-Origin’ and it allowed me to connect to the database.

As of now the majority of the group is on the same page and we are looking forward to improving our performance in the next sprint by holding each other accountable for the work that we commit to do.

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

This blog will revolve around chapters 9 & 10

Chapter 9

This chapter is about time management and how it’s imperative to have this skill. The book talks on the topic of how meetings are a waste of time. I honestly agree with this to a certain extent. Whenever i’m in a meeting at my job, I find that most of the time, the meeting usually goes nowhere and is not very beneficial for everyone. I also find that when meetings occur, there would be a selected few who will hold the group back by asking repetitive questions that could be answered on their own time and not the time of everyone in the room.  In programming, I find that meetings are imperative if they don’t last long. Meetings that don’t last long, can be very beneficial for everyone in the room, by  keeping everyone focus and happy.

Chapter 10

This chapter talks about estimation and how it’s important to make valid estimations. It’s tough to give an accurate answer when someone asks you how long something will take, because you really don’t know. In the programming world, there could be a plethora of obstacles that will hinder the progress of the project so it’s best to give options to when something will be done to the answer seeker so that they won’t be disappointed. This chapter also talks about commitment. This is different than an estimation, because a commitment is something you MUST see through.

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

This blog post will consist of chapters 7 and 8.

Chapter 7 talks about how communication and avoiding communication errors between stakeholders and developers is imperative to the success of a project. The author emphasizes that the most effective approach to avoid miscommunication is to write automated acceptance testing.

Personally, I’ve never written tests for a corporation, but I have some experience with writing tests for small projects at my University. The tests that I wrote, were for a project that we had to work individually on, so there was never a time that miscommunication would occur.

Chapter 8 discusses all of the different testing strategies and how the most important goal for a development team is to have the quality assurance team find no bugs when they sift through the vast amounts of code. QA teams are important for a software, because without them, there will be plenty of bugs that weren’t discovered and this will effect the quality of the software dramatically.

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

Week 3 is officially over, and I’m ecstatic to say that my team finished our first sprint. This week I finished the Angular Tour of Heroes Tutorial and we did a team member evaluation for our group. Through this exercise, we noticed things we were doing well, but more importantly things that we didn’t do well. We then discussed about how we can all improve as team, before we tackle our next sprint.

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

This blog post will revolve around chapters 5 and 6 of The Clean Coder book.

Test Driven Development (Chapter 5)

The author provides us of some rules for test driven development.

1.  You are not allowed to write more production code than is sufficient to pass the test.
2. You are not allowed to write more of a unit test than is sufficient to fail.
3. You are not allowed to write any production code until you have written a failing test.

By applying these rules, it aims to minimilazie larger problems later on in production. When I first started doing TDD, it was quite tricky, because I was confused on how to write a test case when there were no code for the methods that we were testing. By doing this, you know that your method will pass any type of test case, and you won’t have to worry about it anymore as opposed to trying to find a needle in a hay stack bug at the end.

Practicing (Chapter 6)

This chapter was pretty self explanatory, because we all know of the saying that “Practice makes perfect”.  The author mentions a programming exercise called Code Kata, which allows programmers to improve their skills with repetition and practice. As simple as this chapter is, it’s very important and you can’t stress the importance of practice enough. As a computer science student, I realize how the programming world is quickly evolving as there always seems to be a new language, or framework to learn. It’s impossible to stay relevant in this field without practicing or studying.

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

This weeks reading will be from The Clean Coder by Robert C. Martin. This blog post will revolve around chapters 3 and 4.

Chapter 3 talks about saying yes and when one should say it. Throughout this chapter, Roy Osherove talks about the three main points of commitment.

1. “You say you’ll do it”
2. “You mean it”
3. “You actually do it”

Osherove also talks about signs of non commitment.

1. “Hope”
2. “Need”
3. “Let’s”
4. “I will…by..”
5. “Hope”

Osherove made a lot of valid points that I agree with. I noticed that sometimes when I tell myself that I “should” get something done, it doesn’t necessarily mean that It will be done. I feel like those non commitment words are just excuses to not completing a task. When a person says “I Will” when committing to something, it exhibits assurance to the other person, because it tells them that they are taking it seriously and will follow through with their commitment.

Chapter 4 talks about coding, but more specifically, it grasps on the topic of when to code, when not to code, and what to avoid while you’re coding. There was a story where code written at 3am is bad, because it’s difficult to focus at night. I don’t know if I agree with the author completely, because I like to stay up late and code sometimes.It all depends on what my activities are during the day. On the topic of when not to code, you should stop when you find yourself not producing quality code that you know you can produce. You should take a breather and relax so you can clear your head before resuming.

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