I have recently read more of The Clean Coder, and what I find interesting is that the two chapters I read talk about polar opposites when it comes to clean coding in the software world. There are other tips in the chapters that I find interesting, and I’d like to share some of these tips and how they relate to my beta testing experience, if applicable.

Chapter 2 was all about Saying No and how to say it properly. However, what i found interesting and important was that not only does one have to defend their No answer, but there’s a way to find the best possible outcome. The example described in the book shows how an issue over a dysfunctional login page turned into the best possible outcome: a mock-up that doesn’t actually check the username-password combination, but one can still log in. This I find is a more appropriate approach to defending a No answer for the reason that the program that was expected wasn’t ready at the time.

Chapter 3, however, talked about how saying Yes produces the right result. One scenario I found interesting is the scenario in a conversation between a manager and her employee who is responsible for modifications to a rating engine. As the scenario progresses, the book talks about how to improve the situation, by not saying “try” and committing to the task. The situation also carries some “what-ifs” in-between. For example, “What if this happened” and “what if that happened”. The conversation between developer and manager gets really interesting as the read continues.

This book is already interesting as it is. I hope to read more of The Clean Coder soon.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

Recently, I started reading The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin. From what I am reading, there are many things described that I find very relatable and very helpful to me. I hope to use these tips in my last class as well as going forward with my professional career wherever I end up.

The first section I read is the Foreword. One of the many business practices discussed was the Batman-Robin routine, though the way Matt, the writer of this section, describes it makes it seem like at first, Matt was arguing with his team member, Joe. Then he says it’s also possible that Joe was trying to play a joke on the rest of the technical team. I find this practice very confusing. Why would a co-worker joke about a legal team having an issue that prevents a web application or a web site from launching on schedule? It doesn’t make sense to me.

Next, I move on to the Preface, which describes how in 1986, Space Shuttle Challenger exploded over 8 nmi above the ground due to a failed SRB. Anyone who has lived to see the event would know that the reaction and aftermath was enough to put family members of the deceased devastated. It also describes what would have been done to prevent this issue from happening again. Reading this, I had a sense of remorse not just for reading about the disaster, but also the aftermath: the mother of high school teacher Christa McAuliffe devastated and possibly in tears after hearing her daughter had died in flight. Immediately after reading the chapter, I immediately decided to watch a YouTube video of the disaster to get a better understanding of it. I do not remember my emotions after watching the CNN coverage of the disaster, but it was more remorse for the dead than anything else.

After reading the Acknowledgements, About the Author, and On the Cover, to which I did not find interest in the subjects in any of those sections, I finally start reading Chapter 1: Professionalism. In the chapter, it discusses many different rules of conduct for a professional. The “stuff happens “comment in the “Be Careful What You Ask For” section really gave me a good laugh. Reading about Martin’s irresponsibility in the “Taking Responsibility” section proved an interesting read, making me learn that proper testing of software will prevent complaints. This is especially true in the field of video games: as the game itself is considered software, proper testing of the game is very important to avoid many bugs, graphical glitches included. I have beta tested at least one game and still remember back in November when I tested the RollerCoaster Builder feature in a game called RollerCoaster Tycoon World (yes, I grew up with the series and continue to enjoy its progress).

The day was Sunday, November 1, 2015. It was the last day of the first Beta weekend for the game, and the team at Atari and Nvizzio was letting fans that pre-ordered the game, including myself, to test the Coaster Builder feature in the game. It was advertised to be very different from the previous three games, all of which let us build coasters piece by piece, a tedious process. In this game, the development team programmed a system that allowed for a safety rating on coaster designs. This rating was supposed to assist in improving the coasters’ design moreso than the other three ratings, which included Intensity, a rating I was more focused on when playing the game. However, there was a bug that showed its face frequently when I built certain coasters: the tighter a curve on the coaster was, the more likely the coaster was supposed to crash. On that day, on almost every coaster I built, I felt like I was doing something wrong; each coaster kept crashing at random curves, be it turns, slopes, etc., where normally I thought the coasters wouldn’t crash. I knew I wasn’t the only tester that noticed this, because the day after, I saw reports to the developers that other players were experiencing similar issues. To my knowledge, the bugs are being repaired to this day. I hope that all known bugs are caught and fixed before the game’s official release, which is supposed to be sometime this Spring.

Continuing on with the chapter.

My previous discussion about the coaster builder in World goes well with the “QA Should Find Nothing” section. The bugs I caught while playing the game is an example of a violation of the “Do No Harm” rule described earlier in the chapter. Once the developers were aware of the issues, they immediately pushed back their promised release date for the game and apologized for the mess they sent to supporters.

Finishing the chapter, I felt confident with the knowledge I was given. The moment I read the first section of the chapter, I thought to myself, “Now I know I want to take the direction of a professional in my career.” I still have this belief after reading.

I hope to read more of this book and learn more practices as I go.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.