Chapter 13 is about the culture of learning. In this chapter, the author says that junior developers are lead to believe becoming a manager or architect is their natural career progression, but it all depends on what the developer likes, if they truly have a passion for programming they can always progress to a senior developer. The chapter goes on to list some things that can be done to create a culture of learning. Learning from others and sharing experience is important when trying to produce a culture of learning. The part where the author said that not career paths for a software developer are the same stood out to me because there is a lot of truth behind it. It all depends on the person’s wants and aspirations in determining their career path.

Chapter 14 is about driving technical changes. The chapter talks about how driving technical change is a hard thing to do. In order to be successful in doing this, we need to understand how to deal with all the different types of people we will need to interact with. Everyone has their own opinions, it is a matter of getting them to your way of thinking and showing them why your solution is the best solution for the problem. preparing yourself for the other peoples points of view is also critical if you plan on making a change. This way you can counter their arguments when they come up.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Chapter 11 is about interview anti-patterns. it talks about the interviewing practices that tend to lead to the wrong candidates being hired. One of the things that this chapter mentions is to not make yourself look smarter than the person that you are interviewing. You want to seem like you are their equal. Even though you may be smarter than them, you are still able to learn something from them. Conducting phone interviews is not the best way to interview candidates because it is hard to get a read on peoples skills and worth ethics. 

Chapter 12 is about the cost of low morale. When a company is struggling to get products out it is probably because your employees have low morale. Sometimes managers don’t talk to their developers so it can be hard for them to know what the manager wants from them. Also, when a manager doesn’t get on a personal level with their developers it almost feels like they are just your boss and not a friend. It is much easier to work for someone that you like rather than someone who you can just call your boss. Managers keeping developers motivated is important when it comes to producing results. 

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Chapter 9 is about recruitment. The author mentions how it is crucial for any software company to hire the best developers, and how this is hard to find sometimes. It also goes into detail explaining a typical job description and points out all the areas in which it can go wrong. When recruiters are looking for the best developers they should not be going on which ones have been doing it the longest. Sometimes it is hard to tell which candidate is the best developer. Finding developers that are passionate about what they do should be more important to a company than finding the best developer at the time. The developer that is passionate about their career will end up passing the developer that only cares about money sometime in the future. This chapter helps put into perspective the difficulties when going in to job searching. It shows that companies also have it hard when trying to find the best match for a position. 

Chapter 10 is about interviewing software craftsman. An interview is essentially a business negotiation. It is not just about finding a job and making money. More importantly it is about finding the best suiting job for YOU and the company. It is important that during interviews you do not let them do all the talking, you need to take the floor and ask them questions. A good interview can be looked as a informal chat between developers, not a interview in which someone asks question and the other answers. Eventually it can come to an pair programming interview where you need to showcase your skills. It is important that you do not dominate and do not be dominated. You need to showcase your skills while taking input and figuring out the optimal solution. This chapter is very important to be especially because I have started with the interview process in a couple companies. It shows me what I need to do in order to have a good interview and shows me what I should not be doing. 

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Chapter 7 is about Technical practices. This chapter focuses on a variety of technical practices and goes into how useful hey are. It also talks about the right thing versus the thing right. A large section of it is about Extreme programming. Test Driven development, continuous integration, pair programming and refactoring are all important practices a software developer should all be using. Also the author talks about how important it is to fic issues before they come up. This helps cut back on the time it would take to go back and fix the code when you are focusing on a different part of it. I think extreme programming is a useful practice that everyone should be using. It covers all aspects of programming and makes sure that the code is maintainable and usable.

Chapter 8 is about the long road. It discusses that you need to be focusing on what you can do to improve you and your career instead of hoping for a promotion. He also talks about autonomy, purpose and mastery when it comes to living a happy life. One can see how these things are more important than money for some software developers. This chapter is important to me because I am a strong believer that your happiness is more important than money in most situations.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Chapter 5 is about heroes, goodwill and professionalism. One of this chapters focuses is the idea of learning how to say no. The author tells a couple stories about how a manager was always pushing for more rather than working with his developers and how that was a unhealthy work environment. Part of being a software craftsman is being in charge of yourself and your own career, this may mean saying no sometimes. But this does not mean say no all the time, because this can be looked as unprofessional. A good manager will put themselves in your shoes to see if what they are demanding of you is reasonable. 

Chapter 6 is about working software. This chapter talks about working software and the fact that working software is not enough. There is always a threat of something going wrong later on when the software is not maintained properly and developed properly. Don’t skip steps when you are developing software. This may be hard for some people because deadlines are constantly being forced. If something happens that you are not able to reach a deadline, it is better for you to talk to your manger about it so you are making sure you are producing code to your best ability. I can relate to this chapter because i have fallen in the trap of just producing software that works, rather than taking all of the steps I should be in order to solve  the problem at hand. This can lead to a disaster somewhere down the road. 

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Chapter 3 is about software craftsmanship. Software craftsmanship is a long term journey to mastery. It is a mindset where software developers chose to be responsible for their own careers. This means that they have to learn new tools in order to stay competitive. It is not test driven development, clean code, or specific technologies. This chapter also goes over the software craftsman manifesto which is not only working software, but well-crafted software. Not only responding to change but steadily adding value. Not only individuals and interactions but also a community of professionals. Not only customer collaboration, but also a productive partnership. These are all things that the software developer should strive for in order to achieve the title of software craftsman. 

Chapter 4 is about the software craftsmanship attitude. It is important that we continue to learn and develop in our careers. Most of the time this means to not to rely on your employers to provide you with everything you need to succeed as a software craftsman, this may involve some separate studying. The chapter goes into detail explaining technology specific, conceptual, and behavioral and revolutionary categories for software developers. We should be constantly reading up on new things that we don’t know how to do, and making we stay up to date on the latest technologies. I think this chapter is very important to every software developer when it comes to self-growth. I believe this is a way that people should live their life, not just their careers. 

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Chapter 1 is about software development in the twenty first century. In the beginning of the chapter the author talks about how you should let your passion determine what you are going to do for your career. He also mentions that just because you have been programming for a long time, doesn’t mean your development skills are going to reflect that. It is very possible that someone who has been working for half the amount of time that you have been working could be a better developer than you. The author also mentions that now days, employers are looking for employees that can do a variety of things, rather than being an expert on one thing. This chapter makes sense to me because I can relate to this in a way. There is a guy i used to work with who has been there for years, but he is by no means the best at his job, seniority definitely is a not good indicator on skill.

Chapter 2 is all about being agile. Over the years companies have been able to come up with agile development practices, based on their needs and requirements. This helps them stay competitive with other companies. He mentions that software craftsman is not meant to replace agile, it is meant to compliment it. A good way to put it is agile helps companies do the right thing while software craftsmanship helps companies do the thing right. This chapter is important to focus on because it defines the differences between agile and software craftsmanship and shows that they are meant to work with each other and are not meant to replace each other.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Unfortunately we were not able to get a push successfully committed. We all were working on our issues after we got assigned them but none of us actually managed to resolve an issue due to a couple things. The button issue was put at a halt because the button stopped working properly for us, so we were not able to make any more changes in fear of breaking the code. The patient banner color issue was assigned to a different developer because it was of a high priority. Even though we did not get an issue completely done, i still think we all learned a lot from each other over the course of the semester. Put into perspective what it is like to be part of a functional team.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

We now have 3 issues to work on. We still have the button problem where they want us to move it to a different location, a new problem that they want us to change the color of the patient banner depending on whether or not they are deceased, and another new issue to notify the user that the changes have been saved successfully. Our button push was not accepted because it did not meet their requirements. We were told to put it in the optimal position and now they want us to lock it onto the screen so when you scroll the button stays in a fixed position. Hopefully we can continue to get work done and get an issue done before next sprint starts. Our teamwork is still improving, we are learning how to collaborate well even though we are all working on separate issues. As of now I like where we are, hopefully we continue to grow as a team.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

This sprint was a little bit tricky because it was right in the middle of spring break, and people were off doing their own things. We did however fix the button issue using the guidelines that were provided with us. We pushed the changes and are now waiting for them to accept it. As of now, we are planning on breaking off into smaller teams and taking on a few problems. Assigning six people to one issue is not the most efficient way to solve issues because that leaves most people with a lot of downtime. I can see us slowly getting better at working together as a team. The decision to break off into smaller teams to tackle more issues was a game changer for us. Hopefully we can continue to improve as a team further down the road.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.