Chapter 15:

This chapter is about pragmatic craftsmanship. Pragmatic craftsmanship is dealing with things sensibly, in a way where we base our considerations practically, not theoretically. What it is trying to say is why make cheap and lazy code when its just going to come back and bite you while you can just write the well quality code at first, saving you a lot of money and time, and making sure your program is safe and doesn’t break in the future because of small mistakes. By looking at things realistically, we can see what practice should be used where, so clients should never have to pay more for the quality of their product. I agree with all this, to be a craftsman, you need to master your craft and know when to use what practices, without ever needing to sacrifice quality.

Chapter 16:

This chapter is about software craftsman being driven and passionate to do their work and improve their skills on the daily. It isn’t just a job, it is a hobby, and that is the only way a software craftsman can be. This makes you want to learn new things and give it your all, whether it is a little project or large. You don’t care you the money, just the quality of work your produce. Everyday, trying to strive for better than yesterday. Everyday trying to make the industry even better as whole from when you joined. We are the ones pushing our society forward, and to higher limits. We are the evolution of our society. I agree with this because we are at the most basic as it can get, code. It makes programs to run soft wares, which run pretty much everything, all over the world because of our society’s dependence on technology. We are the only thing helping change the world for better and advancing our technology. This is what makes us software craftsman.

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.

Chapter 13:

This chapter gets into learning, the different techniques developers use around the world to try to create a culture of learning. One company for example, had wanted to keep their developers’ tests up by at least seventy percent, so instead of starting to do their tests, or get into the habit of testing their code, they outsourced all of their tests to people who had no idea what the code was even running for. So as this other company continuously wrote tests for their code that didn’t even respond well sometimes, it was all useless and helped no one. A manager can’t just improve the way people code because they think, that the developers will write better code. You need to leave that up to the developer because no matter what you do or make your developers do, they will not write good code or work well with others, if they are not motivated. You can only depend on yourself to further your skills so you can’t blame your managers, you need to apply yourself. By hiring people who actually love doing their job, you make better code. You can’t motivate everyone, you need to inspire them to better themselves.

Chapter 14:

This chapter talks about driving technical change and how hard it is. One important detail is to know how to deal with different types of people and how their minds work. Instead of trying to tell them that your way is better or “correct” try to stand in their shoes and see why they think their way might be better. If you want to be a good developer with some power to make a difference and drive technical change, you need to be able to communicate very well and establish trust with your developers. You’ll need to be considerate and consider everyone’s side and try to explain your own as well as you can.

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.

Even though we all got much accomplished within our team over the semester, unfortunately we were not able to get one of our pushes to be committed. I felt that we were making good progress on the button together as a team but after we decided to split into 3 miniature teams we slowed our progress. Also, there were points when the button stopped working on our system which was also very inconveniencing. We had times where our systems wouldn’t even start up. But in the end I feel that everyone has learned much more than they had thought they would, by being a team and collaborating together on a project and always staying in contact.

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.

Chapter 11:

This chapter talks about how you should be very selective of what you say when conducting an interview to attract the right professionals to your company. Do not make yourself look smarter or better than the person you are interviewing, rather as an equal who you are looking to recruit. Don’t ask questions with no relevance to the job requirements and don’t try to impress them with your job title. You might even learn something from them. So riddles and brain teasers should never be used to determine someone’s passion towards work or their ability to produce a good product. If you want someone to love what they do, you mustn’t belittle them or make them look like a fool. Internet being a very large part of a developer’s arsenal to better themselves, where ever they feel, shouldn’t be taken away in an interview, nor should candidates be made to write code on pieces of paper. Conducting interviews on the phone should also be the last option, only when you have no other choice because they are very poor ways to assess people, their skills, and work ethics.

Chapter 12:

This chapter gets into low morale and how that affects a company and its projects. With companies who are struggling and having a hard time with good delivery, their problems probably lie within the low morale of all its workers, architects, managers, and clients. This could be a problem from bad communication where the manager doesn’t even like to talk to his or her developers who are having a hard time figuring out what it is that the manager actually wants. With no one to talk to and no direction, people can easily go off to make something that isn’t much of the same as where they started and might not match what the client wants. this all can also lead to low morale when you might not even want to do you work, or know what its used for, which you might not even know beforehand. You need to be motivated to do your job to make yourself proud, but that is lacking at these companies. Sometimes people might not feel empowered to change these situations and they don’t want to be pushy. They also don’t believe that things could be changed and that it is just a hassle to do anything about it. So either no one agrees with the fact that there is a problem present and everyone goes back to doing their work because this is just a job. The only thing that can inspire developers is other good developers to share their knowledge, stories, and passions with.

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.

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.

We split into teams and it turns out that it was a good decision. This way we can tackle more problems than before. We are working on three separate issues. We are close to being able to push for our current issue but not just yet. Working on the button to fit into a better location is our priority because we have already made it so that it stays in place, even if the page is being scrolled. We are planning to put it near the top. It should be finished by the end of the sprint with the requirements the developers wanted.

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.

Chapter 7:

This chapter talks about many technical practices and how useful they are. It also talks about how developers struggle to convince others to adopt certain practices because they are unable to explain the usefulness of them. Even though they might be useful for one reason in an area doesn’t mean they will also be useful in another. Also adopting new practices is always a struggle. It takes time to get adjust and get used to a new way of doing things and reforming habits. We also get into the importance of fixing new problems and bugs that occur as fast as we can to try to reduce the pain that we will have to deal with later. Making sure every time a change is made, that everything still works together is important. It helps save time and makes you much more efficient. Most of all we need to know what section we are trying to improve ourselves in. Because without that, you wouldn’t even know what practice to use. I can relate to this because I didn’t realize that different practices could be better utilized in different situations and I thought I could have just stuck to one until a better one came out.

Chapter 8:

This chapter talks about the steps to make a career and advancing in it, not getting stuck at your job. Hoping for a new promotion instead of asking yourself if what you’re doing is still helping yourself grow and love your job with the want to gain knowledge and not just being an overqualified manager that doesn’t do anything new. These things fall into three sections, autonomy, purpose, and mastery. I can relate to this because I never want to get stuck at a job, especially one I didn’t like. A job where I wasn’t learning anything new or contributing much. I would want to keep moving if needed and find a new place where I would find that I contributed to more.

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.

Chapter 5:

This chapter talks about the fact that a good developer does not consist of a mindless worker that does whatever the client asks of him. It tells us that we are in charge of our projects and only we know what is really good for our clients over what they want. It is our job to say no when needed and figure out what the solution to their problem really is and to advise them the right way instead of just doing whatever they ask. We do what we can to make sure everything they want is in their own best interest. They will never understand how you would go about your work so make choices based on your own well being and make sure to give them options and say no if ever needed.

Chapter 6:

This chapter goes into the details of the quality of code. You can’t make quality code that will last a long time if there is no quality in it. It will not last, and eventually it will be worthless. So don’t skip steps and make sure you take the long and hard road rather than the short one to a quicker fix. Many people fall problem to this because they are working on deadlines and need to finish in time which makes them take short cuts. Good softwares can change and adapt their ways quickly, that is how you know they are quality. Also unit tests are important and should always be used. No excuses. Time is in your hands, you always have it. It is just your choice of what you decide to do with it.

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.

Chapter 3:

We talk about what software craftsman is certainly not; test driven development, clean code, clarifications, or specific technologies. Software Craftsman is a metaphor for software development. It is a long journey of mastery, its core being professionalism. Everyone needs to contentiously change and adapt to the new technologies and soft wares to stay on top of their craft. It is their job as a software craftsman to stay up to date with the new and innovative techniques that replace the old ones. I agree with this because it teaches us not only to respond to change but to also add as much value as we can.

Chapter 4:

In this chapter we learn about our careers, and who is in charge of them. We are in charge of them, only we can strive to be better. We should never blame others for our failures and continue to strive to be better even if something or someone is actually holding us back. We should always be determined and make sure that there is passion in what we’re doing. We should try to track our progress and read books and blogs to help us to stay sharp.

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.

We didn’t do much over this sprint because of spring break. I was working almost everyday and didn’t get to see my team at all. When we came back we were finally able to come together and talk about the response we got for the button problem that we solved and pushed. We were met with a new set of requirements to change what we had fixed to better accommodate everyone. We want to make sure we have everything they want with our fix this time before we push it. We also picked new problems to work on with our team members in smaller groups. I think we are much better as a team now.

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.