Category Archives: clean coder

The Clean Coder: Chapters 11 & 12

The image from chapter 11 perfectly sums up my feelings about this week.

I’ve really enjoyed reading The Clean Coder I think Uncle Bob has made some very clear and important points. This week was quite short and so there is only so much to write for this post. This books is great for a student hasn’t begun working or an engineer who’s at his first job fresh out of college. However, for anyone who has worked in the “real-world”, we already know the things that are stated in chapters 11 & 12.

One of the more interesting topics that I never really had a name for was Crisis Discipline. This is something in my current field that is incredibly important. I work as an Air Quality Engineer. Part of my job is to execute wet sample extractions for pollutant sources per federally regulated methods. In these methods everything I need to do in order to get proper extraction of whatever pollutant I am looking for is written in stone. However, during the actually sample gathering there are ways you can “speed up” the process or “cut corners” to make the job easier. However, EVERY single time someone decides to do this (No one has in my company), it backfires and them. It usually lands them rerunning an entire testing program that may costs tens-of-thousands of dollars.

The next chapter interestingly talks about collaboration. This is something again, that as working person in a technical field, I have found that a second pair of eyes is ALWAYS better. I spent a lot of my earlier years building and fabricating anything from specialized flanges to electrical control boxes. When you spend time designing something and working on something, no matter how good you are, you will screw up. Period. End of discussion. I remember training a young technician on how to rewire a simple relay system that controls a heater block. When the technician had completed the task they simply put it back on the shelf.. Job done, right? This technician in particular had an issue with me always checking his work and I knew that I would do it forever and a day because we are human and humans are fallible. However, from his point of view, he thought I was always passively aggressively saying he wasn’t smart enough. So I decided to go out and check the heater anyways. I found that two of the wires were backwards, and that was going to cause the relay to stay closed 100% of the time which meant power was going to be continually supplied to the heater. The next morning I got in my normal time which was well before the rest of the technicians and I plugged the heater that he had worked on in. Long story short, when he had made it in to work he saw a BRIGHT cherry red heating element just about ready to melt through the metal casing. When he asked me what had happened I explained to him that is why I always check his work and why I always have other engineers check my work.

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 9 & 10

The Management. Such an interesting topic for a book dedicated to becoming a professional. What Uncle Bob is talking about here is two distinct forms of management; personal management and business management. Interestingly enough, these two topics become intertwined quite often. The first instance in which this appears in the book is when he talks about meetings. When the section starts on meetings Uncle Bob stated something I’ve been saying for years now.

There are two truths about meeting.
1. Meetings are necessary.
2. Meetings are huge time wasters.

My current position requires me to attend an occasional meeting, typically conference call style. The one thing I have found is that these meetings are very important to keep people up to date on whatever the contents of the meeting are and it helps get every one on the same page. However, every meeting I have been apart of was by no means short. I believe the shortest meeting I was ever apart of still lasted 45 minutes and by the end I walked out with no more knowledge then I had gone in with. Having had these experiences, when I saw Uncle Bob’s statement about the two truths of meetings I felt relieved that I wasn’t the only one that felt this way. Uncle Bob went on to talk about the different meetings that are had in a Scrum methodology of software development. Reading his thoughts on how these scrum meetings should go is very interesting. Currently with the Capstone class at WSU we are using Scrum and I can see how some of these meetings could go very long. I believe my team and I have done a good job and avoiding wasted time during these meetings, though.

The rest of chapter 9 covers ways to stay focused. Fortunately for me, most of these methodologies or theories appear to be common sense to me and I didn’t take away that much new information from these paragraphs.

Chapter 10 talks about estimates. Interestingly enough, I’ve had to create a few estimates in my line of work. Granted these were extremely small scale and usually completed in under an hour. The thing I learned from creating those estimates was, it’s incredibly hard to estimate time for when things go wrong.

As I mentioned in a previous blog post I listened to a podcast (You can find it here ) on software estimation a few months back. This chapter from Uncle Bob felt like a refresher on the things talked about in the podcast. What I find most fascinating about this subject, is that in my field an estimate is occasionally taken as “set-in-stone” and “done-deal” type of artifacts. However, that’s what business has turned it into and that was never what estimates were intended to be used for.

I don’t have too much more to say about estimates for software, seeing as I haven’t had to ever create one yet. However, I know when my time comes to finally use this information, I will be referring back to Uncle Bob!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapter 7 & 8

This week in the Clean Coder I read chapters 7 and 8. These chapters covered a lot about testing. Acceptance testing and testing strategies to be specific. One of the more interesting topics that was talked about was estimates. This is an interesting topic to me because a few months back I listened to an interesting podcast on the same exact topic. Now Uncle Bob didn’t go into as much details here as did Steve McConnell on the podcast but he made the most important point:

Professional developers understand that estimates can, and should, be made
based on low precision requirements, and recognize that those estimates are
estimates.

The later-half of that quote is the important part. The statement that estimates are estimates is important. A lot of the time estimates are taken as absolute fact in industry and unfortunately this has become poor practice. Once we remember that estimates are estimates then we start taking uncertainty back into account and everyone is happier for it.

In chapter 8 Uncle Bob began talking about testing strategies. The first point he decided to hit was actually a reiteration of something he said in an earlier chapter, “QA Should Find Nothing”. My understanding initially is that as a developer you should make sure QA has NO role. However, this is not the case. The issue here was my view on the role of the QA engineers. I assumed that their job was to catch the bugs I missed. This is wrong. According to Uncle Bob their role should consist of creating automated acceptance tests and characterizing the true  behavior of an application.

The rest of chapter 8 continues to talk about the different types or stages of automated testing. These are things like; unit testing, component testing, integration testing, system testing and exploratory testing. These are all things I’ve talked about in previous blog posts so I won’t spend too much time talking about them. I do however, want to note one thing Uncle Bob mentioned,

Unit tests provide as close to 100% coverage as is practical. Generally this
number should be somewhere in the 90s. And it should be true coverage as
opposed to false tests that execute code without asserting its behavior.

It’s interesting that when he talks about code coverage he makes it a point to say that our tests should assert something about >90% of the code we’ve written.

That’s all for this week. I look forward to the next week’s chapters which talk about Management and go into more depth about Estimations!!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 5 & 6

Ahhhh Uncle Bob, You always enlighten my week in some way!

This week in the clean coders I delved into chapters 5 & 6. These chapters talked about Test Driven Development (TDD) and Practicing respectively. These chapters really didn’t introduce these topics to me as these are things I’ve known about for a while but, they shed some light on a few areas that I haven’t heard of before.

In the topic of TDD Uncle Bob made a statement about TDD I hadn’t truly thought of before – Courage. He basically stated that when you follow proper TDD practices you gain courage to go back and fix code. The reason for that is because, we will know whether or not we actually broke the code or not when trying to “fix” it. I’ve worked on a few projects now that I went the wayside of TDD for two reasons, I didn’t really understand it and it seemed like a waste of time. However, even though these were small projects mainly going to be used by myself, when I come across a bug (That wouldn’t have been there in the first place if I’d TDDed) I am always nervous to touch the function or method again. I find myself between this state of “Well did the bug really hard the ability of the software to work? Should be fine.” or “During normal use this shouldn’t happen, I can leave it be.”. Where as if I had written tests I wouldn’t be fearful at all to rewrite and “fix” old code!

Chapter 6 delved into the topic of practice. Uncle Bob seemed to mostly talk about practice in the terms of physical speed of writing code. Like, writing the same method over and over to gain speed of being able to write methods. I’m not going to lie, this is something I’ve done. I’ve worked hard creating code snippets and practicing using key-binds to be able to get the most out of my workflow. The less time I spend writing “boiler-plate” the more time I actually get to be solving the hard problems (aka the “Fun stuff”).

Practicing your workflow and making sure you can code really quickly and you are good with the tools you are using is an important thing. However, one thing I feel Uncle Bob missed is practicing our language specific knowledge. I know for myself and the projects I’ve worked on, every time I don’t have to refer back to documentation is major time saved. One thing I’m not saying is that we should spend major amounts of time learning the deep dark corners of each language. What I am saying is that you should know how to do semi basic things in the language you are working in, without referring to documentation. I remember working on a PHP project where I was doing a massive amount of string manipulation and find/replace type stuff. The first few pieces of code I wrote, I would google my problem and typically find a similar solution to what I needed on Stack Overflow. I would then go to the PHP documentation and see what it had to say to try and figure out the rest of my problem. I found that I kept coming back to the same 4 or 5 functions so I decided to commit these to memory and really try and understand the full capabilities and “hackish” things you could do with each. The 3 or so hours I took reading the documentation about string manipulation probably saved me a week or two worth of work over the projects duration. I’d say that’s worth it!

All in all another great week from The Clean Coder. I am really enjoying this book and cannot wait to see what Chapters 7 & 8 have in store! Thank you Uncle Bob for this awesome book.

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 4 and 5

The Clean Coder Chapters 4 and 5 are all about coding and TDD (Test Driven Development), respectively. Reading these chapters gave me some insight on how to properly write clean code, and there were several parts of each chapter that intrigued me.

Chapter 4 discusses proper Coding techniques, and adds onto what I learned last year reading Clean Code by the same author. Although the chapter allowed me to evaluate my coding technique, I also found the 3 AM coding story quite hilarious. It doesn’t relate to any stories I would have, but at least it helps me understand better about the importance of a healthy, awake, and alert mind.

Chapter 5 introduces some tips for TDD. TDD has been around for ten years and is still a common practice to this day. The only thing I found interesting, though, was that TDD isn’t exactly useful in every situation. One can still write horrible code even if the tests are written first, especially if the tests are bad themselves.

These reads keep getting interesting as I continue, and I hope the next few chapters make some sense for when I step out into the real world. I hope I can also use these techniques while working on the OpenMRS code.

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

Clean Coder Chapters 2 and 3

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.

Clean Coder

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.