Week 7 Thoughts and Experiences

Work

This past week was one of my more productive weeks thus far this summer. I will do my best to summarize how I spent each day.

Monday:

• Blogged
• With Joe's help, I was able to successfully test and verify changes I made last week. These changes included tweaking the "Manage" buttons on the Sentinel home page to only appear if the user has permissions to use them.
• Sifted through the Sentinel home page, finding all of the links on the UI that still needed to be utilizing the "smart_link" or "smart_url" functions in order to only give access to users with valid permissions.

Tuesday:

• Began by explaining to QA how my FTP Setup Tool changes were, in fact, behaving correctly. (My bad QA guys for not explaining more clearly.)
• Successfully finished tracking down the file/code for all of the millions of links, buttons, and clickable graphs on the Sentinel home page and implemented the permissions.
• Pull Wholesaler Invoices button -- Previously, TA's had to find someone to pull invoices manually if they have invoices >3 months old when they were ready to allocate. I modified the button to also pull in invoices older than 3 months.

Wednesday/Thursday:

• Modified the _build_query_and_params() function that constructs the query string corresponding to the filters used in the 'Item Mapping' tool. Modifications included 1) restructuring, 2) trimming the leading and trailing whitespace from a search string, and 3) making the search by NDC look for ALL mapped drug equivalents. Previously, the search returned only CDMs that had, as their primary mapped NDC, the NDC that was being entered into the NDC search filter. Now, the search returns any CDM that contains, as any of its mapped drugs, the NDC that was being searched for.
• Collaborated with Robert "Bobby" Long on the "Matrix Performance Report."

Friday:

• Took out the "Shared Key" column from the VPN reporter and replaced it with a Client Name column. This required adding to the the query in VpnSetupManager::get_vpn_list() to return client_name from freedom.client. Changed default rows displayed from 100 to 250.

Fun

My younger brother, Luke, who just graduated high school and also will be attending Purdue in the fall, called me on Thursday night around midnight. He explained that his friend was making a trip from Indianapolis to Orlando and that he was offered a free ride. Luke had originally hoped to come visit me this summer, but with the help of the parents had determined that impending college tuition rendered him financially incapable.

However, with this new transportation breakthrough, visiting was again an option. As it turned out, the friend was leaving Indy at noon the next day (that's right, twelve hours later). I hurried and hooked Luke up with a $25 bus ride from Orlando to Pompano, and Luke was in town by Saturday afternoon. Saturday we went to the beach for several hours and played volleyball and frisbee and tossed some baseball and football. We also went out to eat at Whale's Rib, a seafood restaurant just down the road from my apartment. Sunday we went to the church that I have been attending, Boca Raton Community Church, and then I had a YMCA basketball game with some of the Sentry guys. Luke ended up being able to play on our squad as well. Needless to say, our team, virtually a man amongst a league full of boys, dominated again, continuing our undefeated season.

After basketball, we had a tee time at Deer Creek golf course. I upheld my big-bro dominance and handed him an 89-100 loss, 2nd career Eagle and 1st career back-to-back Birdies in tote! Monday I took a half day so that we could make the most of his two-day visit, and we went golfing again, before hanging out with friends. I shot my best career 9-holes, a four-over-par 40. Monday night I drove Luke to the West Palm bus stop, and that was the end of his all-too-short stay in paradise.

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.

Week 6 Thoughts and Experiences

Work

This week was mostly productive, though, as does any week in the life of a developer, it contained several snafus that made projects take longer than they should have. I suppose that I am more prone to this than the more seasoned employees here at Sentry, but I also learn a lot when solving these issues. I will now give a brief summary of this week's work.

On Monday I began by finishing up my first unit test. I had a couple issues left over from Friday that I had questions about, and Joe Heth proved quite helpful in dealing with them. Finishing the unit test FINALLY allowed me to commit the changes that I had made to the Search/Audit Tool. I also did some blogging.

The rest of my week involved three more "commits" and almost a fourth:

• VPN Setup Tool -- I edited this tool to allow Implementation to have read-only access. This involved disabling all of the fields and hiding all of the links for Implementation users.

• FTP Account Tool -- This tool was edited so that Implementation could not modify an existing entry's Account Name, SFTP toggle switch, or affiliated VPN Tunnel. This seems easy, but it proved quite difficult, as I could not just disable each of these fields. Disabling the fields resulted in the values in those fields not being passed when the form was submitted. Joe and TVR helped me find a tricky javaScript solution to this problem.

• Pyxis Feed Editor -- I added a 'Paranoia Alert' radio button and 'Paranoia Alert Comment' text field. This involved adding support for the two new fields to the SourceFeedDAO.php object.

• Sentinel home page widgets -- There are a number of widgets that link to different parts of the system. Thereare several "Manage" buttons that are directly linked to pages andignore any permissions. I am working to allow those buttons to be visible only to users that the buttons will actually work for. (Previously we just sent the frustrated users back to the Datanex home page when they did not have permissions to click the button) This is proving to be a little harder than it should be, as I had to add some functionality to the smartURL function and am having trouble finding users to possess so that I can properly test if my changes are functioning correctly.

Fun

The past couple weeks, I had three visitors! My brother Zach and his wife Megan visited for a week, and then my sister Rachel also visited for a week. Needless to say, our one-bedroom apartment was pushed to its limits, but, thanks to our pullout couch, a newly purchased air-mattress, and accommodating roommates, the visit was a success. We went to several awesome restaurants, including Old Key Lime House, which is supposedly Florida's oldest waterfront restaurant. I got a Mahi-sandwich, which was quite tasty! Zach and I went golfing at Palm Aire Country Club's "The Oaks" golf course where I didn't play particularly well, but shot a 92 and still managed to beat my big bro who was using unfamiliar, borrowed clubs. We did lots of other fun stuff, but I am going to stop here, as I would like to begin Week 7's work.

Week 6 Reading Response

Peeblogs:

This week's Peeblogs will be heavily dominated by several words of financial advice, but first, a quote from The Man himself,

"Don't focus on why you can't do something. Focus on what needs to be done, and find a way to do it."

Financial Principles:

-- Live 2-3 pay-cuts lower than what you make.

-- First priority after graduating college is to construct an emergency fund equivalent to 6 months of your salary.

-- The two most important financial decisions you can make are marrying a frugal woman, and never getting a divorce. (addendum from Troy, "Don't get married.")

-- Bonuses should NEVER be counted on when budgeting.

-- Setup student loans to be paid automatically, as missing a payment kills your credit score.

-- Pay debts in order of descending interest rates.

-- Pay the minimum on loans that have a lower interest rate than the rate of inflation.

-- Sign up for zero tax exemptions. This guarantees a large tax return check and assures that you will not have to pay any money back to the government.

-- When debating between using money to pay off a loan or using it to invest, the following formula applies:

LoanInterestRate - RateOfInflation = WorthwhileMinimumInvestmentReturnRate

"Code Complete"

I began reading "Code Complete," by Steve McConnell. This week I read the preface, chapter one, and most of chapter two. Yeah, pretty lame...I will try to do better this week. The following quote explains why Code Complete is applicable to me, "The recent graduate is often rich in theoretical knowledge but poor in the practical know-how that goes into building production programs. The practical lore of good coding is often passed down slowly in the ritualistic tribal dances of software architects, project leads, analysts, and more-experienced programmers. Even more often, it's the product of the individual programmer's trials and errors. This book is an alternative to the slow workings of the traditional intellectual potlatch....It's a hand up for the student making the transition from an academic environment to a professional one."

Week 5 Reading Response

In order to uphold tradition, I will be beginning this post with this week's all-famous Peeblogs. Unfortunately Mr. Peebles was abroad for the majority of the week, so Peeblogs were few and far between. However, despite the scarcity of these little nuggets of truth, I still managed to garner just a few:

--It is very difficult to implement a system that regulates employee promotions and bonuses accurately. This is primarily caused by what Sir Peebles referred to as "optimizing to the metric." In other words, if you setup a metric that is supposed to measure how much an employee has accomplished, that employee will always pay extra-special attention to that metric, making sure to go "above and beyond the call of duty" in the specific area of that metric. This makes it seem that the employee deserves a raise or a promotion, when, in reality, they have merely "optimized to the metric."

--It is quite common for an employee to be promoted to his "highest level of incompetency." This results from the employee working his way up the career ladder, earning rightful promotions until he eventually gets promoted to such a high position that he is no longer competent to do his job. The employer is then faced with a dilemma. Should the employee continue to underperform in his current role, be demoted back to his highest level of competency, or be let go?

--The corollary to the previous point is that managers must think very long and hard before they promote an employee. Demotions are rarely a feasible option, as it generally leaves the employee dejected, dispirited, and embarrassed. Promoting an employee too far is a good way for a company to lose of its most valuable and successful workers.

Moving on, week 5's assigned reading involved three articles on unit testing, which were helpful, because I ended up spending the majority of Week 5 writing my first unit test. I will touch upon each of the three articles briefly.

Article #1 was entitled "Why are we embarrassed to admit that we don't know how to write tests?" It's author drove home the point that "The secret in testing is in writing testable code!" He gave several practices to avoid in order to write code that can very easily have unit tests written for it. I will now quote his second point, which I felt was his best comment in the entire article, "The developers are where the mistakes are made, and testers are the ones who feel the pain. Do you think that the developers have any incentive to change their behavior if they don't feel the pain of their mistakes?" I feel that Sentry addresses this issue by requesting that the developer also be the one to write a corresponding unit test for his own code.

Article #2 was "The Advantages of Unit Testing Early." Three advantages that stood out to me:

Instantaneous Gratification-

-Writing a unit test as you code or even before you code allows you to test a small component of a larger application that has not yet been completed.

Refactoring Safety Net-

-Having a pre-existing unit test allows a developer to refactor code and then check to make sure that he did not break anything.

Documentation-

-Unit tests can be used as a reference to find out what a particular method or class is supposed to do and how.

Article #3--"How to Write 3v1L, Untestable Code." This last article was a blend of poorly written and hilarious. The author decided to turn his blog into satire, writing from a purely sarcastic standpoint. I couldn't have agreed more with one of the readers who aptly commented that, "While the content of this post was excellent, the disingenuous, sarcastic, say-the-opposite-of-what-I-mean style of it was a complete turn-off. I hope you consider re-posting this information in a positive, "what-to-do" style, so that people don't have to parse through all of your negations just to get some good tips." The principle that hit home for me was that I should not use lengthy/intricate if-branches. I have a nasty habit of doing such at school on projects that are merely tested for functionality, and this was a good reminder to break such a habit. I will let points #2 and #3 speak for themselves as they are quite comical and will allow a small glimpse of the sarcastic style of the article:

"Macros are your Friends - Always use #ifdef PROD and other compile-time switches to make sure the testies can't get at your really important blocks of code and test them. In fact, this code won't even run: until it gets to production!"

"Final Methods - Use final classes and methods all the time. They can't be overridden for testing (-; But don't bother making fields final, or using value objects (without setters) - just let your objects' state be changed by anything and anyone. No sense in guaranteeing state, it'd make things too easy."

As parting words of hope, I would just like to let you know that it is merely Monday, and I have already acquired useful material for next week's Peeblogs!

Week 4 Thoughts and Experiences

Just as with every other week here in SoFlo, this one has flown by. I don't have any new, exciting experiences to add to the list that I started last week, so I will skip that section until (hopefully) next week. I will jump straight to the work that I have done this week here at Sentry.

Wednesday marked a milestone in my time at Sentry thus far. My mentor, answerer of every question that my brain can possibly come up with, and endless pool of knowledge, Joe Heth, began a week-long vacation. Do not get the wrong impression, this was not a milestone because Joe Heth took a vacation, rather, it was the first time that I attempted to walk around on my own two wobbly legs without Joe there to give direction. Liken it to a child taking the training wheels off of his bike for the first time. I spent the remainder of the week on a ticket that originally involved just making the Audit/Search tool's "Details" link point to its corresponding invoice instead of its purchase order. However, as I dug deeper into the cause of the issue, more and more errors became evident in the tool's design, and those whom I consulted instructed more and more changes to be made to the tool. In the end, I was doing pretty much a full revamp of the entire invoice feature of the tool. This primarily involved working with Jay Ohms to tweak the InvoiceManager object that he was in the process of creating. After a lot of communication back and forth, we have succeeded in providing a function in his object that returns all of the necessary elements for my reporter object. I made the following modifications to the Invoice report:

--Originally the user could choose between searching from "All Invoices," "340B Invoices," or "Non-340B Invoices." Separate reporter objects were extending a parent reporter object and being used to display the 340B and non-340B invoices. I combined these two objects into the parent object which they formerly had been extending, eliminating the necessity of the two "child" objects. Both types of invoices are now displayed in the same report with a new column called "Order Type" that distinguishes whether an invoice is "340B" or "Non-340B."

--The speed is optimized due to not using binding for $site_id in the SQL query. It is also optimized as a result of Jay writing a more efficient query that eliminated the need to look in any cardinal tables.

--The "Details" link no longer exists, but its functionality has been replaced by making the invoice number into a clickable link.

--The expandable rows feature has been done away with.

--When searching for invoices by NDC, the drug count number actually displays the number of different drugs in the invoice, rather than always displaying "1" like it did before.

--The report is now default displayed as sorted by date in descending order.

--All rows in the report display invoice numbers. (many did not previously)

--All results displayed in the report now match the search string. (Many times invalid results were previously displayed or not all of the correct results were displayed.)

--Invoices with a common PO# are displayed, rather than just displaying one of them.

That pretty much sums up my week of work. I have been talking with Cyrus, Ben Mahan, and JJ Foote about a few more modifications which I feel would really improve the functionality of the tool for the user, and I will likely be presenting a mock-up of what the UI will look like in the upcoming week. Other than this ticket, I also teamed up with QA to solve an issue in one of the tickets that I had submitted last week, and I began working on another ticket involving the Drug search option in the "Search/Audit" tool.

Week four makes me feel like I didn't get a lot done, just because I didn't close any tickets, but, now that I've written everything down, I feel a little better about my accomplishments.

Week 4 Reading Response

Before touching on this week's "official" reading assignment, I am going to reflect upon a couple less official, yet, no less educational experiences. Some might call them "Choctaws," others might refer to them as rants, still others might call them "Soapbox Specials," however, I choose to label them "Peeblogs." That's right, educational, hysterical life experiences and musings by none other than your very own John Peebles. During this week's near-daily Peeblogs, I learned the following very important principles:

• It is key in life to have the ability to take that which you learn/hear/read and be able to apply it to, and associate it with, the real-life situations that you find yourself in everyday.

• The three most important life skills are:

1. -Writing
2. -Reading
3. -Being able to conduct yourself according to the surroundings that you find yourself in, so as to make a good impression and establish good standing. (i.e. People skills in any situation)

• In order to be great, a man must read no less than one book per week. As a result of this principle, I have begun attempting to teach myself how to speed-read, according to an article on the Internet.

• Companies' incentive plans, when regulated poorly, can actually end up demotivating their employees. Sir Peebles went on to explain how his friend had quit working for a company because they denied him his $20k bonus, which resulted in the company losing one of its best employees to a staunch competitor. He explained that, in the long run, the company was ruining themselves. He followed this story up with what was by far the best analogy that I heard all week: "You end up plugging a grenade up your ass. Sure, it feels great until it goes off, and then you're screwed."

And now on to this week's official reading assignment, "Continuous Integration," by Martin Fowler. Fowler's article was an outright home run, endorsing and explaining the ins and outs of CI and hitting upon the principle from every angle. Here is a brief synopsis of what I took from the article.

In CI, "everybody develops off of a shared stable base and never gets so far away from that base that it takes very long to integrate back with it. This results in in less time spent trying to find bugs." Every developer keeps and maintains a copy of the current integrated source on his machine. Updating this copy is called "checking out." This copy must stay up to date with the mainline, or, current source code. In short, there is a single source repository maintained by a program such as Subversion, which contains all of the source code for the product/system. When a developer wants to edit some of this code, he makes sure that he has an updated copy of that source code on his own machine and then works with that copy while editing and initially testing. Eventually, after extensive testing, that edited code will be integrated back into the mainline using a continuous integration server such as Cruise Control.

The following are a few important practices in CI:

• Maintain a single source repository: A mainline with very few branches, which might be necessary for bug fixes and temporary experiments.

• Automate the build: Everything should be able to be built/linked by issuing one single command.

• Make the build self-testing: A close runner up to the above-mentioned John Peebles quote: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all."

• Keep the build fast: Make the build staged: a "commit build" that should quickly test a large amount of the code and a "secondary build" that runs some of the more time-consuming tests. The following is very important in regards to creating an optimally staged build, "As much as possible you want to ensure that any secondary build failure leads to new tests in the commit build that would have caught the bug, so the bug stays fixed in the commit build. This way the commit tests are strengthened whenever something gets past them. There are cases where there's no way to build a fast-running test that exposes the bug, so you may decide to only test for that condition in the secondary build."

Until week five, that is all I have for you. Come back next week for more Peeblogs if you dare.

Week 3 Thoughts and Experiences

I can HARDLY believe that I have already completed my first three weeks here at Sentry! Working here has been phenomenal thus far, and I see no reason why this shouldn't continue. I really enjoy the "Work hard, play hard" mentality that exists here.

And now, I am going to start a new "blogging tradition" where I make a list of different experiences that I have had here in SoFlo! So far:

-Chipotle (x6) (Barbacoa is my last remaining meat to try)

-Boxing Match (The Heavy Weight Factory)

-YMCA B-ball league (Yesterday we won 70-68 on a buzzer-beating treybomb!)

-Golfing at Deer Creek (Sorry about the tough defeat that you suffered, Kyle...)

-Bowling at Boca Strikes ($1 games/shoes!)

-Fishing on the ocean! (THANKS Keith!)

-Boating/swimming on the ocean off of Key Biscayne Island!

(I am rather certain that I am forgetting several things, but I can add them next week.)

Lastly, I will try to give a speedy glimpse of the things that I worked on this week. I experience my first interaction with QA. The rolodex widget that I added to the VPN Setup Tool this past week apparently didn't display in the correct spot exclusively in IE6...BIG SURPRISE...world's WORST browser! But, as Troy pointed out, many hospitals are still operating with VERY outdated software/hardware, and IE6 is VERY prevalent. Thus, I must be very conscious of this when programming. Other work that I accomplished includes converting four more reports to the reporter framework, adding the date widget to these reports, fixing a link in the PIM log, and the very minor tweak of preventing a search from being conducted on a string of less than 3 characters in the Reverse Mapping CDM search.

See ya, week 3...HELLO week 4!

Week 2 Thoughts and Experiences

Week 2 has been vastly encouraging in comparison to week 1. Though I don't feel that I have suddenly transformed into a coding ninja, my overall fluency in the system has easily tripled that of week 1's. I feel more confident about finding files, reading them, and understanding how they relate to one another.

The majority of my week was spent trying to add rolodex widgets to the VPN and FTP setup tool pages. Robert and I decided to take a pair programming approach, because we were basically assigned identical tasks, Robert handling the FTP Setup Tool, and myself handling the VPN Setup Tool. Apparently everyone dreads any tasks involving the word "rolodex," because every time I would mention that I was working on this, I would get a mischievous smirk or a knowing wince of pain. Luckily Joe Heth decided to make my life easier by making a universal RolodexLinkContact.php file which allowed for a one-to-many relationship between the rolodex and various types of contacts. Had it not been for this, I probably would STILL be working on this project!

A small amount of Thursday and most of Friday were spent on my current task, which is revamping the Replenishment Rollover Report. I had to create a reporter object from scratch in PHP, which I ended up enjoying very much. This was much more of the object-oriented type of work that I am used to doing, so it was much easier to understand. By the end of the day Friday, which came all too soon thanks to TF2, I had my reporter object functioning quite nicely and in need of just a few small tweaks. Overall, this has been my favorite project thus far, largely due to the fact that it has been my most successful and required the least amount of outside help due to the fact that Clearspace had very helpful and extensive documentation.

And now, I must bid adieu to week 2, as week 3 is already upon me!

Week 2 Reading Response

I am happy to report that Week 2's reading load paled in comparison to Week 1's. For the most part, we were assigned two documents: Practical Styles of Pair Programming, by Iwein Fuld, and The Art of Agile Development: Collective Code Ownership, by James Shore.

For the most part, pair programming has been a foreign concept to me, but this past semester in my Compilers class we were instructed to group into two-person teams. So, this is how I was introduced to pair programming. Fuld identifies two roles in pair programming, which are the "driver," who is the one behind the keyboard, and the "navigator," who is the one following and guiding the driver's work. Though the article talked about many of the benefits of pair programming, it seemed that the only benefit that I received was that my partner was smarter than I, and he shouldered a majority of the load, acting as a "driver" with no navigator while I sat and watched. I refer to this as a "benefit," but it in reality, it was no such thing....it was, in fact, a crutch, minimizing my understanding and interest in projects and the class as a whole. Reading this article helped me to identify several of the mistakes that we made in our rather lackluster attempt at pair-programming. The following quote from the article seems to describe my situation perfectly, "The driver knows what he's doing and because the navigator doesn't pick up on what he's saying he turns silent and speeds up. The navigator sees that the driver is doing ok and decides not to slow him down but space out and look out the window a bit." It appears that we were committing several pair programming blunders. A) We were both low on sleep, B) we stopped thinking aloud, C) I didn't always stop the driver when something didn't makes sense, and lastly and most importantly, we never tried switching roles. All of this resulted in what Fuld has labeled "The Disconnected Pair or The Sleeping Navigator."

Now that I have touched upon a pair programming failure, I will briefly report a success. As I mentioned in my other Week 2 blog-post, Robert and I have been working on similar tasks this past week and decided to take this pair programming article to heart. We employed many of the concepts covered in this article, and it definitely resulted in a quicker process which created a higher quality product and allowed me to gain an abundance of knowledge. We successfully fulfilled our roles as driver and navigator.

The article on Collective Code Ownership was also very enlightening, but in a different sort of way. Seeing as I have had absolutely zero past situations in which collective ownership could be employed, this article served more as warning and guidance. I found a great deal of healthy responsibility being placed upon my shoulders. The article explained that it is my duty to always leave code better than I found it. Though not directly stated, I felt that the number one point of the article was that laziness is NOT an option. When coding, I cannot do a half-hearted job, assuming that somebody else will fix my mistakes, as collective code ownership doesn't mean "no-code ownership." In summary, A) I should always be looking to improve other's code, and B) I should take pride in the work that I do, but not be so proud that I try to be the sole owner of that code and get offended when someone else modifies it.

Week 1 Thoughts and Experiences

This is going to be somewhat speedy, as TF2 is raging all around my here in the fishbowl:

Wow! I have been here in Florida for exactly a week, and it has been quite THE experience. Working at Sentry has proven to be quite the blessing, and I know that I am going to continue both enjoying being here and attempting to take a sip out of a firehose of information. Monday was mainly spent moving here into the beloved "Fishbowl" and getting a desk, monitor, laptop, user accounts, and software configured. On Tuesday, I received my fist two tasks, which were both regarding some minor changes on the VPN Setup Tool in ImpMonster. However, though these tasks are quite minor and would take an experienced developer a matter of an hour or less, I have been working on them over the past three days, slowly moving along and learning the necessary new information as I progress. While I have a fairly extensive background in object oriented programming and some in SQL, my web programming knowledge was very minimal. I used HTML and javaScript the very first semester of college, and almost never since then, so my abilities with those two tools is next to none. Also, my project deals primarily with PHP, which I had never even seen, so needless to say, I have been learning quite a lot the past few days. A special thanks to Joe Heth for his patience and expertise on the phone, spending hours and hours running me on a crash course through web programming. Ok, well TF2 beckons, so I am fulfilling my promise to keep this short!

Week 1 Reading Response

As I sit here trying to ignore the barrage of "TF2 Smack Talk E-mails" (I've gotten 7 in the last 11 mins alone), I am attempting to recollect some of the articles, blogs, and documents that I have stumbled through in the past five days. Seeing as it's my first week on the job, I have naturally had to read a plethora of information just to tread water and try to get up to speed with my responsibilities. The document that I will be referring to this week is the infamous "Monster Method," which will henceforth be referred to as "The Method."

Firstly, I enjoyed the section regarding "flow." I found that I could most definitely identify with many of the theories that The Method brought to light. While discipline and clear-tasking are not areas that I particularly struggle with, I do sometimes struggle to find an environment in which I can create/maintain good flow. Here at Sentry, at first I struggled with my environment being somewhat loud and distracting, but I feel that things have settled down in the past couple days. At school, I find myself getting into the zone, or as The Method calls it, flow, late at night after my roommates and most of the other people in my house have gone to sleep. I will be working to improve at dealing with distractions this summer here at Sentry.

Secondly, I liked the guiding principle from The Method that talked about "cross-pollination." I have experienced this already in my first week here, although it has mostly just been me getting pollinated by several expert co-workers, rather than assisting others. Were it not for cross-pollination, I would be lost and even less productive than I currently am.

Lastly, I enjoyed the section entitled "Blocks of Time." I have always felt like little 45-60 minute blocks of time are rather worthless to get anything significant accomplished, and this section confirmed my suspicions. According to The Method, "Studies have shown that it takes a minimum of an hour and half of uninterrupted time to get any kind of meaningful work completed." It suggests planning your day into 1.5 hour blocks and using the time inbetween these blocks to take any breaks. This ensures that flow of work is not impaired.