Chapter 15 was all about the benefits of writing quality/expensive code vs. average/cheap code. It is a myth that quality code is expensive. According to the book, often managers must choose between producing quality products which take time to produce and average code that does not take much time to produce.  It is the duty of software craftsmen to produce clean quality code that is inexpensive.

Overall, what I learnt from this chapter is that quality code is not expensive. The lack of skills on the part of the developer is what makes quality code expensive. Developers must do their best to produce quality code which is inexpensive.

Chapter 16 was about what it means to be a software craftsman and how to have a successful carrier. The #1 word that summarizes what it means to be a software craftsman is passion. Software craftsmen are passionate developers and they love what they do. Being a software craftsman means that you much constantly learn and improve your craft/skills. You are in a journey to mastery. Mastery of software development is a long hard road. Every carrier decision you make must be in order to move you forward in your goal to mastery. And also, as mentioned in the previous chapters a job is a mutually beneficial relationship. Both the employer and the employee must get the best out of the relationship.

To sum up, I learnt about what is takes to develop quality/inexpensive software and what it means to be a software craftsman from reading these chapters.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Chapter 13 is all about creating a culture of learning at your company. Here are some of the things that the author thinks can be done to improve the morale and create a culture of learning:

1. Start a book club.
2. Have a tech lunch.
3. Have group discussions.
4. Conduct group code reviews.
5. Have hands-on coding sessions.
6. Start internal communities of practice.
7. Encourage pet-project time.
8. Engage with external technical communities.

Creating a culture of learning and motivating developers is important for a company as it directly impacts the code developers write. Ultimately, this depends on the developers; hiring passionate developers and providing them with a good environment would improve the innovation of the company.

Chapter 14 is about how to convince skeptics into adopting new practices or changing the culture. The first step according to the book is to identify the type of skeptics. The following are the types of skeptics the book talks about:

1. The uninformed.
2. The herd.
3. The cynic.
4. The burned.
5. The time crunched.
6. The boss.
7. The irrational.
8. The indifferent.
9. The wronged.
10. The inept.
11. The ivory-tower architect.
12. The insecure.
13. The fanboy.

The chapter goes on and on about how to convince these skeptics to adopt something. Overall, what I got out of this chapter is that I must be good at what I do, I must communicate clearly, and I must establish trust to drive change.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

We picked four issues to work on this sprint. We made some progress into fixing them, but it turned out that the AMPATH team had fixed them. At the end of the sprint we decided what needs to be done to complete the presentation. We plan on meeting somewhere before our presentation and work on our presentation.

The only thing I learnt this sprint is that always ask questions when in doubt. If we had not asked the AMPATH team for guidance on the issue we would never have known the issue was already solved.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

I found this chapter 11 really interesting and useful. Most of the scenarios that the author describes I have experienced.

The author mentions that before talented developers accept a offer they consider the financial offer, autonomy, mastery, purpose, productive partnership, talented and passionate people, and a good working environment. Of all the factors involved, I think working with talented and passionate people is the most important. I know what it feels like to work with unpassionate people. Working with unpassionate developers is not very productive and can be quite irritating. The only reason that I am a Software Engineer is because I LOVE Computer Science and I LOVE the craft of developing software. It is hard to work with other developers on creating software who do NOT share the same LOVE. You would not grow as a developer if you stick with unpassionate developers.

The author then talks about interview anti-patterns. The following are the interview anti-patterns mentioned in the chapter: don’t be a smart-ass interviewer, don’t use brainteasers, don’t ask questions to which you don’t know the answers, don’t try to make the candidate look like a fool, don’t block the internet, don’t code on a piece of paper, don’t use algorithms, and don’t conduct phone interviews. I have experienced all of these anti-patterns on my interviews for a year now. I would love to share some of my experiences, but unfortunately I don’t think it would be wise to do it.

The most important thing to understand from this chapter is that you as a software engineer are not a slave to your employer.

Chapter 11 is all about how important the morale of a team is. Low morale can destroy a company; and unmotivated people do a lousy job. A company must bring the best out an employee.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Chapter 9 was all about how to recruit good developers; it was a very interesting read. The author explains what is wrong with the recruitment process in most companies and how to fix it.

One of the major issues with recruitment today is that companies recruit developers just by their resumes and keywords in them. They value keywords ( whether a developer has worked is some technology for x years) rather than whether the developer is passionate about development.

It is very hard to judge whether a developer is passionate about developmen or not. One of the ways that the author judged passion was whether the developer had a gitHub accout, had contributed to open source projects, have a twitter account, have a blog, or have spoken at conferences.

I totally aggree with the ideas in this chapter. Most companies that I interviewed with were more interested in the keywords in my resume than actually accessing whether I had the knowledge, aptitude and passion for software development. Some others asked me stupid obscure questions related to data structures and algorithms that I don’t have at the top of my head at all times, but could solve them if I was given some time to think.

Chapter 10 was about the software developer interview process. The main thing that I learnt from this chapter was that interviewing is like a business negeotiation. The company has needs and problems to solve and the software professional can help the company solve them. The software professional needs to understand the risks and rewards of that negeotiation before signing any contract. The software professional has a reputation and anything that can damage that reputation must be considered a risk.

The rest of the chapter was about how to properly interview a candidate.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

We successfully made the pull request and merged the NGPOC-184 branch to the AMPATH master branch. The most important thing that I learnt was how to squash commits. Overall, this was the most productive sprint we had so far.

The thing that I think could be done differently the next sprint is how we divide the tasks. We did not know how to divide the NGPOC-184 issue into tasks so that everybody could work on it. What I learnt is that each issue could be divided into the following tasks:

1) Research ( How to solve the issue ?)

2) Solve the issue ( Somebody writes the code and pushes the changes to group                                                     repo. Can be done collaboratively.)

3) Fix npm lint errors ( Somebody fixes the lint errors)

4) Squash commit and make pull request.

5) Inform AMPATH team to do QA tests.

I plan to divide our next issue into the tasks above. This way our issues are solved much faster.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Chapter 7 is about the usefulness of technical practices and how to convince your peers on using some of those technical practices. This chapter talks about many things that I don’t think are very useful at this point of my carrier.

Chapter 8 is about what motivates us and how to build a career. The first section of this chapter starts out with a story of the author ( I think). The author had a dream of working in London and he figured the way achieve that dream is to become a software engineer.  He did not speak English at the time and his skills set was pretty basic. He however did not give; he kept working toward his goal until 10 years later he finally achieved his dream. He became a software engineer working in UK.

The moral of the story I think is that nothing comes for free and mastering a skill of achieving a goal takes time and hard work.

And also a software craftsman must always look for three things when choosing a job: autonomy, mastery, and purpose.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Chapter 5 of the Software Craftsman book was a very good read. It gives some very important advise on what it means to be a software professional ( not software slave ). The thing that I found really interesting was the fact that the author of the book used to work for a company that had him start work at 5:00am in the morning and end at 8:00pm at night. And sometimes he worked so late he had to sleep in his car! All for what? Nothing! Absolutely nothing, but being branded a bad software developer.

Sandro Mancuso ( the author) wanted to be seen as the hero who saved the project, the man who made the impossible happen and a great software developer. Instead, he got the opposite and being blamed for the failure of the software project.

The rest of the chapter gives some good examples of what it means to be a software professional. Being a software professional means telling the truth and being honest on what can and cannot be done. Being a software professional means knowing when to say no to a feature request from clients. Software professionals have ethics, and a code of conduct.

Chapter 6 of the book is about what make good software. The author talks about the many things that the software developer must do in order to develop good code. Most of the ideas that the author talks about is from, I think, the Clean Code book.  So there is nothing really new in this chapter.

Overall, the message that I got out of this week’s reading is that a software developer is a professional. The chapters elaborate on what it means to be a professional. And a software professional is not a slave.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Sprint 4 was, I think, more productive than the previous Sprints. We actually got the NGPOC-184 issue solved. And I am thinking of picking one more issue to work on. So after this semester, hopefully, we as a team would have solved three issues.

The problem I had throughout this and previous sprints is that we are moving at a snail’s pace. The reason for that is we are all new to Angular and some of us are not able to learn Angular fast enough or not able to put in more time. It is very fustrating that we are moving so slowly. One issue in 2 months? Wow!!

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Chapter 3 of the Software Craftsman book answers the question: what is a software craftsman? The book gives many definitions; the two that I like are:

1. Software craftsmanship is a long journey to mastery. It’s a mindset where software developers choose to be responsible for their own careers, constantly learning new tools and techniques and constantly bettering themselves. It is about putting responsibility, professionalism, pragmatism, and pride back into software development.
2. Software Craftsmanship is about professionalism in software development.

The rest of the chapter is about the history of software craftsmanship and the software craftsmanship manifesto. The manifesto is sort of like a guideline of what software craftsmen ought to do.

1. Not only working software, but also well-crafted software.
2. Not only responding to change, but also steadily adding value.
3. Not only individuals and interactions, but also a community of professionals.
4. Not only customer collaboration, but also productive partnerships.

Chapter 4 is about the attitude a software craftsman must have. Our careers are in our hands not in our employer’s hands. It is our duty to improve ourselves. I totally agree with this statement. I personally have access to O’Reily Safari Books and it a really good resource. There are many good video courses and live training courses. I signed up for the Design Patterns Boot Camp course that starts this Wednesday and I also watched Uncle Bob’s SOLID principles videos on his website. When I enter the professional world I plan to attend more live training courses.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.