Monthly Archives: March 2017

The Software Craftsman: (Chapters 1 & 2)

A huge point that Chapter 1 of The Software Craftsman discusses is what “seniority” is in a company and how it’s measured incorrectly a lot of the time in the workplace.  The chapter states, “There is a huge difference between having 10 years experience, and having 1 year experience repeated 10 times”.  That quote stuck out to me and made me think how true that is.  Just because you have worked somewhere a long time doesn’t mean that you have more knowledge then the person sitting next to you who worked half the time you have at that company.  The other main point this chapter talked about is something that I actually think about all the time. It talked about how developers should be able to keep up with the modern ways of working.  As a developer you need to keep up with the modern tools and equipment.  If you’re doctor was using medicine from 1990, and not upgrading his practices, you would be concerned.  That is how you should think as a software developer!

Chapter 2 discusses what it means to be agile, and how to solve the problems that come along with that with software craftsmanship.  The chapter stresses how you NEED to have a good balance between process-oriented and technical-oriented disciplines and methodologies.  It also talks about how you need to be able to work with your team as a whole.  I agree with this chapter that although being agile can be beenificial, it can also cause a lot of problems.  This is where you need to take your craftsmanship and apply it to help fix those problems.  Becoming more agile in computer science is a “game changer” as the chapter stated.  I now see how being agile in the workplace is very important and can change a lot.  I wish to take this knowledge and hopefully become more agile.

 

 

 

 

 

 

 

 

 

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Chapter 1 & 2 (3/7/17 – 3/14/17)

Nowadays every is all about being agile. I’m sure that if we were to look at a scale of how technology has grown within the last decades, the rate of growth is exponential. This is what makes agile so important; the ability to adapt and change with the nature of software projects. In order to effectively be agile, you need to master BOTH the methodologies and the craftsmanship. To me, this chapter was relatable because as of lately, I do feel as though I’ve only been doing one out of the two; which is the methodologies. I would say I have the Scrum methodology followed pretty religiously but yet there is barely any progress because I am missing the craftsmanship. I am not doing enough research and coding to help better deliver the software we are working on and after reading Chapter 2 I truly realize what I have been doing wrong all this time. Even the author said it, “improving the process without improving technical excellence is pointless”, and he’s absolutely right.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Software Craftsman (Week 8)

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.

Sprint Review 3

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.

The Clean Coder (Week 7)

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.

Software Craftsman 1 + 2 Week 8

Software Development Nowadays:

Seniority is software development has no correlation to one’s skill set. The number of years one has worked is a poor indication of their ability to write code. “There is a huge difference between having ten years of experience and having one year of experience repeated ten times.” The need to explore different technologies and project is vital in this field. The industry is adapting towards needing more flexible coders.

Agile:

After the author goes over the principles of Agile manifesto, he says the statement “Many Agile projects are now, steadily and iteratively, producing crap code.” Roles became reversed, and everything was a mess working in an agile environment.  It has been a partial transformation in his words–or a transformation of the process but not of the technical practices. Software Craftsmanship is not meant to replace agile but to assist it.

 

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Sprint Review 3/8

This week we have closed out another sprint and we are well on our way to being able to contribute to the open source OpenMRS project.

This sprint having gotten everything working the last couple sprints and beginning to receive work from our contact in the AMPATH project we were able to get more work done than in previous sprints. We joined the AMPATH Jira group where are the issues are listed and organized. This will allow us to take on issues and communicate with the team regarding those issues in the future.

During this sprint we were given a new AMPATH test server that we could use to work on and test our issues. We were all able to connect to this server for the most part. However it took some communication from the team, as well as a plugin that we found on chrome called allow control allow origin, to be able to successfully connect to and use the server.

Near the end of the sprint we were assigned an issue to work on for the AMPATH team. The issue was that when you logged into the ampath server it asked you for a location and you were able to type any nonsense and then it would save successfully as a location. For obvious reasons this should not be happening. Since we did not receive the issue until the end of the sprint we were not able to successfully resolve it before the completion of the sprint, and it has been moved to the  backlog for the next sprint.

I look forward to working with the code base and learning more about how these open source projects communicate and function as we work on and hopefully solve more issues.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Sprint Review 3/8

This week we have closed out another sprint and we are well on our way to being able to contribute to the open source OpenMRS project.

This sprint having gotten everything working the last couple sprints and beginning to receive work from our contact in the AMPATH project we were able to get more work done than in previous sprints. We joined the AMPATH Jira group where are the issues are listed and organized. This will allow us to take on issues and communicate with the team regarding those issues in the future.

During this sprint we were given a new AMPATH test server that we could use to work on and test our issues. We were all able to connect to this server for the most part. However it took some communication from the team, as well as a plugin that we found on chrome called allow control allow origin, to be able to successfully connect to and use the server.

Near the end of the sprint we were assigned an issue to work on for the AMPATH team. The issue was that when you logged into the ampath server it asked you for a location and you were able to type any nonsense and then it would save successfully as a location. For obvious reasons this should not be happening. Since we did not receive the issue until the end of the sprint we were not able to successfully resolve it before the completion of the sprint, and it has been moved to the  backlog for the next sprint.

I look forward to working with the code base and learning more about how these open source projects communicate and function as we work on and hopefully solve more issues.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 13 & 14

This week i read chapters 13 and 14 in The Clean Coder by Robert C. Martin.

Chapter 13 is titled teams and projects, and like every other chapter in this book it is full of extremely valuable information. Although it is a short chapter it expresses the importance of working on a team and how valuable what he refers to as a “gelled” team actually is. Robert discusses the stupidity of assigning developers to work on more than one team and how important it is to work on one project as a unit and to make up for each others shortfalls. This is probably one of the most important things that we can take from this book because chances are that the majority of our time as software developers will be spent working with other developers on teams. My hope is that i will be able to work on a team that works as well as the ones that he describes in this chapter, a team that knows each others strengths and weaknesses and can make up for those.

Chapter 14 is titled Mentoring, Apprenticeship, and Craftsmanship. This chapter discusses how the majority of CS degrees do not actually prepare us for the real world of development. He discusses how the real world is often much different than what we are taught at university and many students are unprepared. He then goes on to talk about the idea of mentoring and how important that is to truly learning how to be a good developer. This is something that i agree with, nothing can beat one on one mentoring when it comes to learning how to develop good software. The author in this chapter discusses how doctors dont come straight out of college and start being a doctor. They first do a one year internship followed by a three year residency in which they are closely monitored and mentored. This is something that the CS community should definitely do, imagine how much better young developers such as myself could be if we were to get this much attention and help in learning our craft.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 13 & 14

This week i read chapters 13 and 14 in The Clean Coder by Robert C. Martin.

Chapter 13 is titled teams and projects, and like every other chapter in this book it is full of extremely valuable information. Although it is a short chapter it expresses the importance of working on a team and how valuable what he refers to as a “gelled” team actually is. Robert discusses the stupidity of assigning developers to work on more than one team and how important it is to work on one project as a unit and to make up for each others shortfalls. This is probably one of the most important things that we can take from this book because chances are that the majority of our time as software developers will be spent working with other developers on teams. My hope is that i will be able to work on a team that works as well as the ones that he describes in this chapter, a team that knows each others strengths and weaknesses and can make up for those.

Chapter 14 is titled Mentoring, Apprenticeship, and Craftsmanship. This chapter discusses how the majority of CS degrees do not actually prepare us for the real world of development. He discusses how the real world is often much different than what we are taught at university and many students are unprepared. He then goes on to talk about the idea of mentoring and how important that is to truly learning how to be a good developer. This is something that i agree with, nothing can beat one on one mentoring when it comes to learning how to develop good software. The author in this chapter discusses how doctors dont come straight out of college and start being a doctor. They first do a one year internship followed by a three year residency in which they are closely monitored and mentored. This is something that the CS community should definitely do, imagine how much better young developers such as myself could be if we were to get this much attention and help in learning our craft.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.