Week 7 Reading Response

Peeblogs:

Despite the quantity of this past week's Peeblogs, I came away with only two "diamonds in the rough." (Keep in mind that this is likely due to my terrible memory, not due to the scarcity of diamonds.)

"You can delegate authority, but not responsibility." For example, when a manager learns from a customer that something does not work correctly, he can then go and assign the project of fixing that problem to one of the employees that work under him. He has "delegated authority." However, despite the face that he has put the employee in charge of the project, he is still responsible to the customer for the project being completed and fixing the customer's problem.

"Every startup has to have several early heroes." Peebles explained how the company would never have stayed afloat if it wasn't for the "early heroes" of the company going above and beyond the call of duty, putting in extra time and effort to jumpstart the company. These same heroes have also been turned to in times of company-crisis....they are the saviors of Sentry Data Systems!

"Code Complete"

Let's just say that Code Complete is no more "complete" than it was last week...

Other:

One vital skill that I believe can be vastly improved at Sentry Data Systems is the art of "ticket writing." I cannot begin to explain the countless hours that I have wasted attempting to problem solve what the description OF a ticket means before I am able to actually start solving the problem described IN the ticket. Four specific areas where ticket writing can improve are the following:

• Laziness: The #1 problem that I have encountered when reading tickets is epic proportions of LAZINESS! It is clear that the majority of so-called "ticket-authors" are in a rush and consider writing tickets to be a completely boring and meaningless task. They refuse to describe WHOLE problems and use vague terminology, clearly maintaining the opinion that it is better to waste their reader's time and, in turn, waste their time by causing him/her to have to ask thousands of questions.
• Location: Please CAREFULLY and DISTINCTLY specify the location within the UI of the problem that is being described.
• Clarity: When writing within a ticket, avoid using vague terminology. Go above and beyond the call of duty to explain the problem and/or method of solution.
• Problem/Functionality Definition: Describe, in detail, the problem AND how its behavior is wrong. Describe the correct functionality of that problematic item so that the ticket's reader can formulate a solution that brings that functionality to fruition.