Author Archives: jtassone93

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.

The Clean Coder Chapters 11 & 12

This week i read chapters 11 and 12 in The Clean Coder by Robert C. Martin.

Chapter 11 is about pressure in the workplace. As someone who has not yet had a full time programming job this is not something that i have a ton of experience in so this chapter was extra interesting. I’m sure even assignments due in a small time frame cannot compare to the pressure of programming in a full time career under  a time restraint. The first tip that the author suggests is avoiding pressure altogether whenever possible. This goes back to one of the main points of the entire book, which is not committing to things that you are not one-hundred percent sure of. If there is no way to avoid the pressure, then the best way to go about it is to maintain your discipline throughout the pressure. He discusses how disciplines you abandon in times of pressure are not really your disciplines at all if you do not believe in them enough to maintain using them when it matters most. Maintaining your disciplines, remembering not to panic and communicating with your team are the best ways to get through a high pressure environment in the best way possible.

Chapter 12 is about Collaboration. At the beginning of this chapter the author goes on to describe the average programmer, someone who most likely does not enjoy working with people and much prefers machines. Although as he also said this is not all programmers, i completely agree and most of the time this is me to a tee. Working with other people causes so many complications. However as he also says not working with others can be catastrophic. As much as we would like to just sit by ourselves work on our own code and not have social interaction, that is just not possible and for good reason. He talks about something called collective ownership which is  a very good concept to have in my opinion. This means that as a team you take collective ownership for all the code in your department, not just the code that you have written. This creates a much better quality code, and helps people to work much better. Robert also talks about pair programming and how rewarding of an experience it can be and i could not agree more with this as well. Pair programming is an opportunity to learn so much from someone with more experience or to pass on your experience to someone who is new. Not to mention it can help you get past roadblocks in your code.

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 11 & 12

This week i read chapters 11 and 12 in The Clean Coder by Robert C. Martin.

Chapter 11 is about pressure in the workplace. As someone who has not yet had a full time programming job this is not something that i have a ton of experience in so this chapter was extra interesting. I’m sure even assignments due in a small time frame cannot compare to the pressure of programming in a full time career under  a time restraint. The first tip that the author suggests is avoiding pressure altogether whenever possible. This goes back to one of the main points of the entire book, which is not committing to things that you are not one-hundred percent sure of. If there is no way to avoid the pressure, then the best way to go about it is to maintain your discipline throughout the pressure. He discusses how disciplines you abandon in times of pressure are not really your disciplines at all if you do not believe in them enough to maintain using them when it matters most. Maintaining your disciplines, remembering not to panic and communicating with your team are the best ways to get through a high pressure environment in the best way possible.

Chapter 12 is about Collaboration. At the beginning of this chapter the author goes on to describe the average programmer, someone who most likely does not enjoy working with people and much prefers machines. Although as he also said this is not all programmers, i completely agree and most of the time this is me to a tee. Working with other people causes so many complications. However as he also says not working with others can be catastrophic. As much as we would like to just sit by ourselves work on our own code and not have social interaction, that is just not possible and for good reason. He talks about something called collective ownership which is  a very good concept to have in my opinion. This means that as a team you take collective ownership for all the code in your department, not just the code that you have written. This creates a much better quality code, and helps people to work much better. Robert also talks about pair programming and how rewarding of an experience it can be and i could not agree more with this as well. Pair programming is an opportunity to learn so much from someone with more experience or to pass on your experience to someone who is new. Not to mention it can help you get past roadblocks in your code.

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 2/22

This week our group has just finished another sprint slightly longer than the last. We are still working on the AMPATH section of the open source OpenMRS project. We have started getting slightly more into the code itself and so far it has been a rewarding experience.

This spring was all about getting the cloned ng2-amrs directory to install and build successfully. Although it sounds simple enough there were quite a few bumps along the way preventing us from being able to run the build and log in. However we were able to overcome these obstacles by getting aid from the team as well as the rest of the class when it was necessary. Once that was taken care of the next step task in the sprint was to get the standalone version of the OpenMRS version downloaded and the server up and running. Again this did not come without some degree of difficulty, however it was nothing that we were not able to overcome.

Once that was all done we decided to change the way that we wanted to organize our contributions to the open source repository. So we created a github organization and forked the ampath repository into that organization, and from there we forked the organizations repository and cloned it onto each of our computers. This means that we had to delete the repository that we had just spent a good amount of time getting to run and redo the whole process. The good thing is that the entire thing was a lot easier the second time around and we were all able to redo the installations within around an hours time.

Unfortunately we did not have enough time to complete everything on the sprint backlog such as redoing one of the login modules in order to get a better idea of the code that we are working with. So that was put back into the backlog for the next weeks sprint. Upon completion of the sprint we performed a sprint review and a retrospective. Although there was not a great deal of work to be done this sprint i feel we are getting a better idea of the process as a whole and learning to work as a team. I look forward to the next sprint.

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 5 and 6

This is a review of Chapters 5 and 6 in “The Clean Coder” written by Robert C. Martin.

Chapter 5 is titled Test Driven Development. This is a development process in which you write the unit test first just enough to have it fail then you write just enough code to pass the test. You then go back and write more code then more test until the development process is completed. The author seems to be a large fan of Unit Testing saying that there is really no better way of developing, and anyone who disagrees needs to basically get over it and accept the truth. This was interesting to me because i have learned about unit testing before and from what i understood it isn’t incredibly popular. However i have not currently been in the workforce so i am now 100% sure if this is actually the case. I am actually a fan of TDD, i found it to be very fast paced and at the end you are guaranteed 100percent code coverage of code that you know works, what more could you ask for.

Chapter 6 was especially important to me, the chapter was titled practicing. The author goes on to discuss that any professional no matter what his field spends a good amount of time practicing his craft. He talks about how it is not the duty of a company to allow their employees time to practice, it is the job of the individual, a company is there to spice up your resume and it is practice that makes it so you can be paid well. Practice is something that i agree is very important to becoming a good developer and it is also something that i personally do not take as seriously as i should. He then goes on to compare programming to the practice of a martial art and discusses many types of practice such as kata. This is a small programming exercise that you can practice repeatedly so that you can become a better programmer. This will allow you to spend less time thinking about the typing and the syntax and more time thinking about the harder problem at hand. There are a large amount of resources out there for young developers to practice, one of them being Codewars which calls its practice problems kata and structures itself very similarly to the way that Martin suggested that we were to practice.

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

Week 3 Reflection

This is a reflection of the third week of my software development capstone.

This was another short sprint where there was not much for us to accomplish apart from finishing the angular tour of heroes tutorial if we had not already done so. One thing that did make it unique however was we officially ended a sprint and with that came the all the necessary procedures. As a team we began by filling out a reflection on our team mates where we rated them in categories such as attendance and communication, so that we can continue to function as a team as effectively as possible. Since there was not alot for us to accomplish this sprint it was relatively easy to close it out, it did however give us an idea of how exactly that process works as well as an opportunity to carry it out. We began the process by conducting a small sprint review, where we went over what we accomplished and what we committed to but did not actually accomplish. Then we conducted the retrospective. This is the part where we analyze how we worked as a team, what we learned and how we could improve going forward. Overall this was a very rewarding experience, and i learned a great deal from the experience.

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

Chapter 3 & 4 Review

This week we read chapters 3 and four of “The Clean Code” by Robert C. Martin.

The third chapter of this book is titled Saying yes, and in it the author talks about a very important topic known as commitment. Meaning that when you say you ate going to do something you are committing yourself to follow through on that. He then goes on to discuss everything regarding the subject. He talks about things like recognizing lack of commitment, and talks about what commitment sounds like. This entire chapter was very interesting to me but everything he said regarding commitment was very relevant to today’s society. I feel as though commitment is something that is very important especially in this profession and something that is lacking in most individuals including myself. A lack of commitment could cause a large amount of issues in a development environment especially if people are looking to you in order to get things done.

Chapter 4 of the book is titled coding. This was another great chapter in the book. In this chapter the author discussed writing intelligent code and the amount of work that really is. He goes on to discuss his principles and behaviors surrounding code. Issues like being prepared, meaning mentally taking care of yourself and putting yourself in the best place to write good code, as well as things like worry code. This means that you are thinking about something else and the code your writing is in the back of your head. He then talks about something called the flow zone which most people have had some experience with doing things like homework. It is his idea that being in this state while coding is not a good idea even though most developers think so. This is due to the fact that you do not always see the whole picture while in this zone and you are usually not kind to interruptions. The chapter goes on to discuss a large variety of topics like knowing when to walk away, overtime, and rushing. All in all this is a very important chapter in my opinion and a large amount of what he talked about is something that every developer should consider. This field is not easy and requires preparation and taking care of your body and mind.

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

Week 2 Reflection

This blog post is a reflection on the second week of the semester in my Software Development Capstone.

This week was a relatively slow one due to there being a snow day on Tuesday causing our team to miss our first real meeting together as a group. Then the following Thursday i was sick and unable to attend classes. In my absence my team created a trello board to keep track of our progress on the openMRS project as well as a slack channel where we are to hold our daily scrum meetings on the days that we do not see each other in  class.

Our group has also begun learning how to use angular two as well as setting up our program environment, including getting node and npm installed.

I look forward to beginning to look at some of the openMRS repositories in order to better understand what we are working with, as well as learning and implementing angular 2 and contributing to an opensource project.

 

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

Review of “The Clean Coder” Chapter 1 & 2

In addition to my weekly post reviewing what i have learned as well as my progress on the AMPATH project, i will also be writing a weekly blog discussing chapters in “The Clean Coder” by Robert C. Martin.

This week i have read the first two chapters of the book, and i almost found it hard to put down. The author has a good way of connecting with the reader and making him invested in what he is saying.

The first two chapters basically begin with the author attempting to define professionalism in the best war possible. This is a large task and takes a deal of time to fully understand what a professional is and how he operates. There was one point in the first chapter where he discussed writing and releasing code that had cost the company 10,000 dollars and he went on to say that a professional would reimburse the company for that loss where as a non professional would shrug it off and just say that “eh it happens”. This hit me pretty hard, and i completely agree. If you are not invested in the code that you write then why even write it at all? Are you ding it just to get a paycheck at the end of the week? If that is the case then the code that you are writing is most likely not that good at all. He goes on further in the chapter to discuss continuing your education and even compares our profession to that of a surgeon and uses the Hippocratic oath as an example. Again this is something that i found very powerful, as people do not understand the effect bad code can have in certain situations, imagine a bug in a self-driving car. He then states that you should spend at least 20 hours outside of work to be furthering your education and working on personal development. I believe this to be the key to success especially in our industry, things are moving so quickly that if you don’t stay up to date on languages and frameworks you yourself will become outdated and find yourself out of a job.

The second chapter discusses things that i am currently not as familiar with because it involves working in teams on large projects.However it was very interesting and insightful to read. I can completely understand the importance of staying true to your own objectives and maintaining composure in confrontations. However i  think the author may have understated how difficult that that may actually be for some of us.

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