I found the readings from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye to be enlightening. I have liked the idea of apprenticeships and the varying stages of skill for a long time, but I have not thought of it as something to consider using in my life before. Considering my CS skills as a craft to be honed is fun and energizing. It reminds me of a game. Starting as an apprentice, learning and improving skills. Making your way to journeyman by fostering connections with others and finally becoming a master and contributing to the industry.

I found the section in chapter 2, “Exposing Your Ignorance,” to be particularly useful for me. I frequently find myself in situations where there are one or more areas of a project that I do not know adequately. It is important to remind myself that most people feel this way at times. This section describes that it is better to be transparent with your knowledge, or lack thereof, than to feign competence. Let colleagues know that you are learning what you need to learn to complete your tasks. This is a bit of a challenge for me. “The need to appear competent is ingrained into people of most industrialized societies.”(Hoover & Oshineye, 2009) Thankfully, this section has reminded me that while I have a lot to learn, it is okay if I am willing to learn.

Another section I read into was chapter 3’s “Sustainable Motivations.” This section is about holding on to motivation through the good and the bad. I empathize with Hoover in “Dave’s low pain threshold.” I too have difficulty with working jobs that I have no passion for. This is what lead me to computer science in the first place. I quite liked this line from Hoover, “While many programmers could probably find higher-paying jobs in the short term, the money that follows from doing what you love will pay off handsomely in the long run.”(Hoover & Oshineye, 2009)

The last area I focused on was chapter 5, “Perpetual Learning.” This chapter’s introduction is about how you must continuously learn new skills or improve old ones to be an accomplished developer. The first section, “Expanding Your Bandwidth,” is about expanding your knowledge through widely available resources. The book recommends following software blogs and “software luminaries.” With the internet, there are countless communities for developers to share knowledge. This section does warn not to constantly use this pattern. Developers should switch between research mode and development mode.

These readings have helped me re-frame the way I view my future career in a more interesting way. I am sure that the rest of the book will contain similarly useful information and I look forward to reading more of it.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

With the semester starting, my blogs are back. CS 448, the software development capstone, requires regular posts. As such, I will be writing posts about my sprints and about readings from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye.

I’m looking forward to this course and I think I’ll get a lot out of it. This will be my first time working on a project that is not purely academic.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

For my final post for CS 443, I have decided to write about the code review process. I found a blog series on code review by Dr. Michaela Greiler, “The Ultimate Code Review Blog Post Series.” For this post, I will focus on the sixth entry, “A Code Review Checklist – Focus on the Important Issues,” which gives a very thorough checklist of issues to look for when reviewing code. The checklist includes many categories of issues: implementation, logic errors and bugs, error handling and logging, usability and accessibility, testing and testability, dependencies, security and data privacy, performance, readability, and experts opinion. Some of the items on the list include: following S.O.L.I.D. principles, proper testing, and is the code understandable and clean. While reading through the list I recognized a lot of topics that were raised in class and other CS classes. After reading through this article, I feel I have a better understanding of what to look for in code reviews. Before, I did not really know what to check for during the code review activity in class.

In the end, I highly recommend to others to give the entire series by Dr. Michaela Greiler a read through. If not, then maybe just a look through this checklist post. I know I have bookmarked this series and will likely come back to it for future reference.

Articles Referenced:
https://www.michaelagreiler.com/code-review-blog-post-series/
https://www.michaelagreiler.com/code-review-checklist/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

After CS-443’s class this week, I decided to further investigate CMMI, Capability Maturity Model Integration, process model. I found testbytes’ article, “What is CMMI? (Capability Maturity Model Integration),” to be illuminating. This article gives an overview of CMMI and why it is used in software development.

At the end of the article is a link to another article by testbytes that caught my attention, “What is TMMI (Test Maturity Model Integration) in Software Testing?” TMMI is essentially CMMI with a focus on testing. While the two are similar, the focus of TMMI makes the implementation of CMMI on software testing smoother. TMMI has the same 5 stages of CMMI with some differences.

Level 1: Initial

• No test processes in place
• Failing to meet deadlines

Level 2: Managed

• Tests are planned and monitored
• Set test designs

Level 3: Defined

• All projects are tested from early stages onward
• Test reviews

Level 4: Measured

• Properly defined test strategies set in place from beginning of development process
• Projects tested at every stage to ensure bugless code

Level 5: Optimization

• Testing practices are structured
• All processes and outcomes are measured

TMMI is an interesting model that optimizes the testing process and while it is similar to CMMI, I’d still recommend a quick read through this of this article to others.

Articles Referenced:

https://www.testbytes.net/blog/what-is-cmmi/https://www.testbytes.net/blog/test-maturity-model-integration/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Time to read up on mutation testing. Jasper Sprengers’ article, “Sensible mutation testing: don’t go on a killing spree,” gives a small overview of mutation testing and then explains how killing all mutants is not always necessary. The article uses an example to show how a simple class requires extensive testing to kill all mutants. The example shows how a small class of around 10 lines and a single method requires 18 test assertions to kill all mutants. This shows that it is important to consider letting some mutants live. It is not always efficient to use the extra time expanding the tests. My takeaway from this article is that mutation testing should be used to find situations where your tests are not thorough enough but not all mutants are worth the time killing. Use mutation testing with discretion.

Article referenced:
https://blog.codecentric.de/en/2016/02/sensible-mutation-testing-dont-go-killing-spree-2/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.