The Software Craftsman Chapters 3 & 4

This week i read chapters 3 and four of The Software Craftsman by Sandro Mancuso.

Chapter 3 is titled “The Software Craftsman”, and goes into much detail explaining what this term means to the author as well as to the rest of the computer science community. He gives a short definition of the term as “Software Craftmanship is about professionalism in software development”. He talks about the debate as to whether software engineering is a craft, trade, engineering, science or art, which i think is an interesting debate. He then goes on to talk about why he thinks it should be considered a craft. This is something i completely agree with and reading this helped me to really grasp how amazing our field can be. Developers who really care about their career should consider themselves craftsman, and always strive to put forward quality work and improve themselves. The author talks about how software craftmanship should be a mindset and something that we devote ourselves to and i could not agree more.

Chapter 4 is titled “The software craftmanship attitude”. So far this is my favorite chapter in this book. The author starts out by asking the question “Who owns your career?” and then discussing that point in detail. It is not the responsibility of the company to further your development as a craftsman, they are not responsible for your career, that is up to you. He then goes on to discuss the many many ways that one can furhter their own skills and keep themselves up to date in this field. These include things like books, blogs and kata something that Robert MArtin was also a strong beleiver in. I enjoyed this chapter because it provided me with a great deal of ways and ideas to further my own skill set, and i look forward to owning my career. This is something that i think many people do not understand. It is not enough to go to work and code then come home and do nothing, you need to further your own skills.

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

Posted in CS-448, CS@Worcester | Comments Off on The Software Craftsman Chapters 3 & 4

Sprint 6 Learning Reflection Blog (4/25/17)

This was officially the last sprint for this semester! It flew by a lot quicker than I thought it would. Even though each sprint was approximately two weeks long, it certainly did not feel like it. It felt especially short because it would take our group about two sprints for each issue so the time seemed very short and at times, we wished the sprint was longer because we wanted to be able to finish an issue within one sprint. Overall, we were only able to resolve one issue. For this entire sprint, we spent a lot of time choosing issues to work on. We would choose one issue that looks promising, contact a member of the AMPATH team for clarification or for assistance on how to fix the issue, and a team member would contact us back and tell us that the bug or feature has already been resolved in another issue. This happened to us 4 times! After the second time, it began to get annoying because we were wasting so much time on issues that were already solved!

If there was anything I learned from this sprint it would be how important it is to properly manage and maintain the issue tracker. AMPATH and companies in general can save a lot of time and headache with better issue management. If each issue was thoroughly examined, there wouldn’t be any unnecessary issues that are asking for fixes to something that another issue is already addressing. There shouldn’t be two issues that are asking for the same fixes; that’s counter-productive!

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.

Posted in @IssueManagement, CS@Worcester, Software Development | Comments Off on Sprint 6 Learning Reflection Blog (4/25/17)

The Software Craftsman Chapter 11 & 12 Blog (4/25/2017)

Chapter 11 was a good follow-up chapter to chapter 10’s interviewing software craftsmen. After reading this chapter, i gained a better understanding of what type of company I would want to work for. The books makes an excellent point by stating that interviewers should test candidates according to the things they value and to what is important to the projects instead of asking close-ended questions that anyone can answer by googling the question. Although I haven’t been through a huge amount of interviews, I can tell that most companies care about the “technical skills” rather than the passion of a developer. I don’t know about you but I rather be a developer that doesn’t know much but is passionate and willing to learn, than a technically-knowledgeable developer who does not care much for improving his skill set.

Also, here’s the summary to the idea and basic solution of low morale. Bored developers become lazy. Lazy developers become unmotivated developers. Unmotivated developers start to not care about their jobs. When developers don’t care for their jobs, the company makes no progress. When the company makes no progress, employees feel as though they are not developing and are not making a difference. When employees feel this way, their morale dangerously drops very low. So, basically if you want to stop this vicious cycle, don’t become one of those developers who becomes “bored”. How do you do that? Invest in yourself, constantly sharpen your skills, and be a software craftsman. That way, you will always be learning new ideas and talents; there’s no way you could get bored from that!

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.

Posted in CS@Worcester, Software Development | Comments Off on The Software Craftsman Chapter 11 & 12 Blog (4/25/2017)

The Software Craftsman Chapter 9 & 10

Chapter 9:

This chapter talks about big companies and their recruitment process. The process itself is flawed. Many problems such as not knowing the people themselves, but just searching through resumes using keywords. These people getting hired might not even be too good at what the company is looking for. This makes it harder to find more dedicated and passionate people who really care about what they do and their jobs rather than people who are just trying to do the bare minimum and make money. This makes it hard for companies to care about their clients’ cultures and values. That is why they should be used as a last resort. It also retells us how we should never think one developer is better than another, just because they have been in the field for longer. Only passion can drive innovation, it can not be taught. I can agree with this because the smartest people, the ones that are the best at their work are always outliers.

Chapter 10:

This chapter talks about the interview process from both the perspective of the interviewer, and the interviewee. It tells us how we can tell a lot about someone, by the way they give their interview and how they act in it.  It can tell you how they feel about others and even where they place themselves among them. We can learn if they want the job just for the money or if they even care about what they are doing. Because if they answer questions like a robot, like some sort of test, they aren’t really a good candidate. You need to find a person that can hold a good conversation that is trying to figure out if this job is right for them or not. This shows that they are interested in benefiting the company as much as they want to benefit themselves. A good partnership between the company and themselves where they actually enjoying working and not dread coming in everyday.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester | Comments Off on The Software Craftsman Chapter 9 & 10

The Software Craftsman Chapters 1 & 2

I have just begun reading The Software Craftsman by Sandro Mancuso. This seems to be a very interesting book from the first two chapters. The first chapter is titled “Software Development in the Twenty-First Century. This chapter basically just talks a bit about the authors experience as a developer and outlines what the book as a whole will be about. He talks about the modern developer something which i think is very interesting and most people do not really understand. Modern developers are no longer only people who just write code. That is not what they do even though that is all some people want to do. They need to be able to work on a team and understand multiple different business practices. There is much more to software development as a whole then just sitting down and writing code.

The second chapter is titled “Agile”, and it essentially outlines what agile really is as well as how the profession and business’ have reacted to Agile. This chapter helped me to grasp a better understanding of what Agile really is and what it means for a business or a team to be Agile. It talks about how agile is all about feedback loops and the more feedback you get the more opportunity you have to react to that feedback. It says “Agile does not solve any problems; it exposes them” This is very important, agile isn’t something you can adopt and have everything magically fixed. It will however expose all of your problems as they are happening (feedback loops) so that you can fix them for future iterations. The author then goes on to discuss companies who have only half adopted Agile policies and failed as a result. In order to be successful you need to be both competent technically as well as adopting all the procedures of agile. All in all it was a very informative chapter and i am excited to be able to practive agile on a development team in the future.

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

Posted in CS-448, CS@Worcester | Comments Off on The Software Craftsman Chapters 1 & 2

Software Craftsman Chapters 7 and 8

Chapter 7
One of the main reasons to implement an Agile environment I believe is that you are constantly reviewing and re-tooling the process to make it work in an efficient manner. I like how he opens with something similar to this and says something to the effect of not being tied down to a heap of documents and diagrams that were written a century ago. Technologies change fast today so what may have been good yesterday may not be good today, literally. In the author’s words Agile development provides a “quick, short feedback loop”. I understand, but I don’t understand why all companies don’t use extreme programming practices. He says that in one company they noticed a 1/3 reduction in production bugs. That is amazing and saves the company a lot of cash and it’s amazing that companies seem to value it so little as far as the book says anyway. I like his stance on how to convince a manager to use the practices by promoting the value of the methodology instead of the practice of it. That is good advice. Another thing that I was surprised by was the efficiency of automated testing, I mean I know that is a time saver and all that, but I didn’t realize the scale of its goodness. It does make sense though because as he says, “as the system grows so do the number of tests.”. Writing them before hand is a time saver and also gives you something to code to. I am not going to go into the rest of the chapter because it is a repeat of the Clean Coder. Test Driven Development, Refactoring, Pair Programming, Refactoring, Continuous integration, yada, yada, yada. I find that the book has its good points, but it is a lot of Clean Coder and I think that either one or the other should be read, but certainly not both in my opinion.
Chapter 8

This chapter brought back memories of me and my good ole commodore 64 chopping away at te keys in basic. I only wish I had stuck with it back then, but I am glad that I got back to my roots and got back into it again. I think out of all of the chapters I relate to this one the most, but on a personal level. I like the Yogi Berra quote, “ You’ve got to be careful if you don’t know where you’re going because you might not get there.” I thought I was doing what I loved at my last job until I got hurt that is. Then I was in a whole new situation and I didn’t like it. I am finally at the point that I know what I want to do and am happy with the decision, but it took a while to get here. I have been and am using a lot of his tactics. Expanding technical knowledge, attending user groups, and networking to name a few and they have been fantastic to me. Like he says a career is an investment. I am glad I am a bit older and have gained a lot of wisdom along the way so the process of changing careers has been ok, scary in a way but ok. I am doing what I love and can’t wait to put it into practice.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester | Comments Off on Software Craftsman Chapters 7 and 8

Sprint 7 reflections

Well this past sprint went well. Issue NGPOC-185 was successfully fixed and our pull request was accepted, tested, and put on the live test build which is awesome. I learned a good amount by reviewing the code and trying to figure out the issue, though in the end Dan solved it. I have found it quite the experience so far. After completion of NGPOC-185 we decided to split into 2 teams which was for the better because it seems like a lot of the issues don’t need 6 people working on them, but for a start it worked out well as we were getting our feet wet. We chose issue APTS-159 to work on which they wanted the list in a form to show in order of date, newest to oldest as it was supposedly backwards. After investigating the issue and implementing a solution we found out that issue had already been fixed. Brings back memories of people not closing tickets and wasting time. In this scenario it was a learning experience, but in the real world time is money and this would have cost the company a few bucks. It is kind of nice though to see the process working and having to dig through code to figure out where an issue lies and then figure out how to implement a solution. I love troubleshooting.
We are now on 2 issues, one as our split group of 3 and the other as a whole team. We will probably only get one done possibly because time is running short. The first issue is AA-680 which is “Can’t add child to parent relationship”. The problem we believe lies in the database which we do not have access to so we are waiting on an answer from OpenMRS on this. We have found where the relationship lies in the code, but cannot do anything until we get an answer. The issue is that there is only a parent/child relationship and no child/parent relationship. In other words if a child is seen at the clinic, there is no way to add a parent to the form in the relationship drop down. It seems like in this industry, or at least this project there is more time spent waiting on clarification than anything. I understand there are different time zones and such but it sometimes seems counter productive. I guess though you can have multiple issues signed out and at least there is communication. I feel like I am learning more about how the process works than actually learning Angular, not that I am not learning Angular I just guess I thought it wold be different. That is the beauty of it though I guess.

The next issue we are now working on as a team is APTS-254 and they want a reminder to pop up 6 months after switching to a new ART line. This is another issue we are currently waiting on answers for . We have nailed down the area it is in and it seems like we need to just implement a reminder function possibly, but once again we are waiting on clarification, so it’s the hurry up and wait game I guess. It isn’t anyone’s fault it just gets frustrating because we all want stuff now and that isn’t how the world works. I feel confident that I can look at a project now and understand how things work and figure out the routing and logistics of it and that feels good. I am glad I have been able to have this experience and hop that we can get one more issue pulled up before the end of the semester which is soon.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester | Comments Off on Sprint 7 reflections