This week i read chapters fifteen and sixteen from The Software Craftsman by Sandro Mancuso.

Chapter fifteen is titled “Pragmatic Craftsmanship”. This chapter discusses the idea of mastering our practices as a programmer and being more pragmatic. It talks about how making quality code should not be more expensive and it is our job as software developers to make this a reality. This does not mean we have to use TDD every time or practice XP practices constantly, however we have to care about what we are doing and be the difference between great and mediocre. You have to be a developer is passionate about writing code. Not only that but you should be proud of the code that you do write. He goes on to talk about the four rules of simple design which he likes to define as.

1. passes all test
2. minimizes duplication
3. maximizes clarity
4. has fewer elements

Although the order is debated these design elements are very important to writing quality code that you can be proud of.

Chapter sixteen is titled “A Career as A  Software Craftsman”. The chapter opens with him telling the readers how amazing it is to be a software craftsman and then he starts listing where software is not only relevant but essential to life as we know it, hint its everywhere. This chapter essentially ties everything in the book together. It goes back over how important our careers are and what we should do if we do not know where exactly we want them to go just yet. The chapter ends with a paragraph titled “The Mission”. This is a very important paragraph to the book. It is something that every software developer should read and implement in their everyday lives along with every thing else that is in these books. It tells developers to be proud of what they can do and who they are. All in all this was an amazing book, that will definitely help me in my future career. I would highly recommend the Robert C. Martin series to any aspiring or current developer.

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

This week i read chapters thirteen and fourteen of The Software Craftsman by Sandro Mancuso.

Chapter thirteen is titled “Culture of Learning”. This was a very interesting chapter in my opinion as learning is one of the most important skills that a computer scientist or software craftsman can have. Technologies will continue to change and we have to be able to stay current in order to be able to do our jobs well, and that means learning as much as we can as often as we can. In this chapter the author tells us how to cultivate a culture of learning in our work environment even if we are not in a position of power within the company. He suggest things such as starting a book club, having a tech lunch, or even switching projects every once in a while. There are numerous ways to encourage learning in a work environment, the key is to cultivate it into a culture so you can motivate others to want to learn as well. Even if it is something that you can only fit in once a week it will be a very beneficial tool in the long run for both your company and your career.

Chapter fourteen is titled “Driving Technical Changes”. This chapter revolves around bringing new and better technical practices such as TDD to your team. This is not always the easiest thing as people do not usually like to change especially management. However it is necessary if you want  a well working team that produces good code in a reasonable amount of time. The chapter teaches us about a large number of different types of skeptics that we might run into, such as the cynic, the burned, the herd, and so on. It also goes into detail as to how we can attempt to deal with these skeptics and bring in new practices. He then goes into detail about the hardest part of this process in my opinion which is dealing with someone above you who is roadblocking your changes. He goes as far as to say that to just fall into line and not push changes you know will help is irresponsible and incompetent. All in all this chapter will most likely help me in my future career as i am sure to face developers and even managers who are stuck in their ways, and if i care about the projects or the company at all it is my responsibility to attempt to bring better practices so that we may all produce better code 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.

This week I read chapters eleven and twelve of The Software Craftsman by Sandro Mancuso.

Chapter eleven is titled “Interview Anti-patterns”. This chapter continues the interview trend discussing something he refers to as interview anti-patterns. The author talks about all the things that an interviewer should not do when talking about a technical interview. The interesting thing is that every single one of the things that he discusses should not be a part of the technical interview are something i have experienced first hand in technical interviews over the past month. He says that you should not do things such as brainteasers, whiteboard coding, blocking the internet and even using algorithms (unless of course it is a job that requires algorithms in the every day job). Over the past month i have been subject to every one of these types of interviews and i have to say white board coding is my least favorite thing in the entire world.

Chapter twelve is titled “The cost of low morale”. This chapter discusses low morale on development teams and how at times it can destroy a software project. It begins with something called the “agile hangover” this is the idea that after a company has taken in all the agile practices and began to implement them, they are still outputting software in a slow manner. This is due to the fact that they don’t fully adopt the technical part and the coaches do not know how to implement these processes. Basically even though they adopted agile they are still doing the same thing that they were before they adopted it. Software projects need motivated and skilled developers to see them to completion. Motivated developers make more motivated developers, allowing a project to flourish. He talks about something called a nine to five developer, basically someone who only goes to work to get paid and doesn’t care about the company the project or even developing their own skills. These people can kill software projects and are very bad to have on your team. You need software craftsman who actually care to help motivate the other developers to care as well.

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

This week I read chapters nine and ten of The Software Craftsman by Sandro Mancuso.

Chapter nine was titled “Recruitment”. This chapter was mainly aimed at people who would be conducting interviews. Or even people who may be in a position to have an affect on the recruitment process at their company. In that regard the author does a good job of outlining how most companies conduct recruitment is very bad and the reason that they do not find the developers that they are hoping for. He talks about how job descriptions do not help as well,  especially when they say things like five years experience java etc. This is because it really tells you nothing about the developer himself. They suggest doing interviews where you can see how the person thinks and how the person codes in real time. Having a set of questions planned out with static answers is not a good thing because anyone can sit down and memorize a bunch of information. You need to provide the candidate with a problem and watch how they go about solving and coding a solution to that problem, maybe even helping them along the way. This chapter was relevant to me in that it showed me what companies might be looking for in the interview process as well as some of the skills that i may need to develop in order to get better at interviews in the future.

Chapter ten was titled “interviewing Software craftsman”. This chapter was very much a continuation of the previous chapter. The previous chapter did a lot of showing what was wrong with the recruitment process where this chapter provided a great deal of solutions in how to fix that process. This chapter looked at the situation from both the side of the candidate as well as the company that is interviewing. Again this chapter helped me much the same to be more prepared for upcoming interviews, or at least provided me with the right information so that i can attempt to make myself more prepared. There was a great deal of helpful information and the author did an excellent job of outlining what good interview practices are and what companies should really be looking for which will help me become that person.

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

This week I read Chapters 7 and 8 in The Software Craftsman by Sandro Mancuso.

Chapter seven is titled “Technical Practices”. This is almost a continuation of the last few chapters where the author discussed how it was not enough to only adopt agile and the procedures that come along with it. There needs to be a balance with those procedures as well as the technical background to be able to implement those procedures well. Something that most people do not do and end up creating more problems for themselves in technical debt like i had discussed in my previous blog posts. Specifically the chapter talks about XP Extreme Programming and the history behind it. Extreme programming has a lot of big names behind it which in my opinion is enough to give it a second look. If people like Robert Martin are endorsing this so vigorously than there must be something to it. XP shortens the feedback loop and provides practices that make agile all it can be with things like Test Driven Development and pair programming. These practices have proved time and time again that they are more than effective however no one will adopt them. Well not no one but in my experience the vast majority of developers barely know what TDD is never mind how to really practice it. He talks about how the lack of these practices could be hard to sell and that is why things like SCRUM are easily pushed down peoples throats. In my opinion XP is a very useful way of programming.

Chapter eight is titled “The Long Road” and it was an amazing chapter. I know i say this a lot so bear with me but this really opened my eyes about my own future and career path. He talks in the beginning about not knowing where we are going, or in other words where we want our career to go. I am in this boat right now as i want a job but i do not really know down the line where i want my career to end up, what technologies i really want to work with or anything else for that matter. The author provides the reader with a number of solutions if this is the boat that you are in, something that i have taken note of. The rest of the chapter then talks about your job as an investment into your career. People often find themselves in a job and then just doing what they need to get the next promotion or advancement and forgetting about what they truly wanted out of their career. Depending on the different points in your lives that  may differ, whether its more time with family, more time on certain technologies ETC. . However it is important to always keep your career in mind and look at your job as an investment into that career and to always keep learning and make sure that your job fits the idea for your future and allows you to still pursue that, otherwise it might be time for a new job.

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

This week I read chapters 5 and 6 in The Software Craftsman by Sandro Mancuso.

Chapter 5 is titled “Heroes, Goodwill, and Professionalism. This chapter reminded me a great deal of the material in Clean Code by Robert Martin. The main point of the chapter was around learning how and when to say no. The author discusses all the negative effects saying yes can have when you know that you will most likely not be able to finish. As a graduating developer this is something that is really important to learn because it will be better for me to say no i cannot complete x task in that amount of time, however i can do Y, instead of saying yes and not being able to stay true to my word. Saying yes is often the easier path but being able to say no and stand by that is very important in this profession. The author talks about instead of saying yes, you can say no and provide the manager with options of how you can both move forward. This is the most professional option to take and ends up being beneficial for  both the developer and the managers.

Chapter 6 is titled “Working Software”. This chapter was also similar to clean code by Robert Martin, and he is making some of the same points that uncle Bob made. This chapter specifically talks about things like technical debt. He tells a story of how when working on a new feature a developer would rather finish the feature quickly and add a lot of work to the technical debt because he isnt implementing it well the first time instead of actually taking the time to fix his mistakes. This is the issue he discusses, how a large number of developers are more concerned with getting things done quickly then making well written code, and this in turn adds a large amount of technical debt that takes much much more time to tackle then just implementing well the first time around. It is much better to take the time the first time around to write tests and well written code then to have to go back and make changes and refactor a large amount of code because it was rushed through the first time.

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

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.

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.

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.

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.