Weeks 10 and 11 (Intro to TA Land)

As I briefly noted in my last blog post, I have been undergoing the process of converting from a Developer to a Technical Analyst. In this post, I will summarize how I feel about this new position, primarily, how being a T.A. compares to being a Developer, how the two positions provide insight on each other, and whether I think it is better to start as a Developer and then convert into a TA or vice-versa. I will also do my best to briefly capture all of the things that I have learned during these past two weeks.

So, first, how does being a TA compare to being a Developer? In my opinion, it doesn't. But that is entirely my opinion. Many TAs would probably choose their line of work over that of a Developer's any day of the week. Being a Developer, I enjoyed being able to actually see the contributions that I made to the product. There is nothing more exciting to me than adding new features, improving existing features, and fixing things that aren't working correctly and then being able to go and look at the product and say, "Hey! Look at that! I did that!" As a TA, I primarily dealt with data. To me, data just isn't all that exciting. Another huge factor was the languages with which I worked. As a Developer, I primarily used PHP, javaScript, html, and some SQL. As a TA, I used large portions of SQL and was introduced to Ruby. Object oriented programming is definitely my favorite, thus, PHP was by far my favorite language of the aforementioned five. As a TA, I definitely missed using PHP.

I feel that my last two questions, "how do the two positions provide insight on each other," and "is it better to start as a Developer and then convert to a TA or vice-versa," go hand-in-hand, and therefore must be discussed as one. As a Developer, I feel that I started out rather blindly in regards to how our product actually worked. I basically learned about our product....errr....services bit by bit, learning only the parts that pertained to my particular project. I feel that this is a very sluggish way to learn about the company and its services. As a TA, I had to solve more data-related problems which, in turn, require a working knowledge of our product so that there is background behind that data. After all, if you don't understand what the data means and where it came from, how can you ever attempt to figure out anything? Thus, I learned much more, much faster as a TA in regards to the inner-workings of our product/services.

So, that being said, which is the better place to start, TA or Developer? I would have to say that it is highly valuable for every Developer to begin as a TA. There is no better way to get a glimpse of the system than to be a TA. As a beginner TA, the wide assortment of tasks forces an individual to constantly be tracking down more experienced employees for detailed explanations and guidance. Not only is this healthy for the beginner employee because he/she gains knowledge of a wide span of the company, it is also valuable because it allows him/her to interact and get to know the vast majority of his/her co-workers. I know that I definitely found this to be the case. As a Developer, it is pretty easy to just talk to a select group of other Developers. As a TA, you are forced to interact with a much wider array of individuals.

Lastly, what have I learned these past two weeks? I feel that a list is a must in order to do this effectively:

• How to write a several types of parsers.
• Smidgens of Ruby.
• What a source table is.
• How to write a puller.
• Loads of additional SQL knowledge.
• How to use Core Manager.
• Batch committing
• Anti-joins
• How to handle BLOBs in SQL (I learned the hard way that writing a PHP script to grab the BLOB is NOT a good plan....though I did succeed....)
• Where/how claims and raw claims are stored, including their various very specific formats.
• When there is a question involving SQL, ask Berger, he'll fix it in less than five minutes.
• Nate Smith is a VERY busy man.
• David O'Neill is all-knowing when it comes to Core Manager.
• More about how the company works in general.
• The hardest part about being a TA is not grasping blocks of complex code, rather, it is grasping from A-Z the inner-workings of how our service works.

Week 9 Thoughts and Experiences

Work

Monday:

• Joe returned from vacation and helped Austin and me realize that we were changing the javaScript alert boxes into mootools alerts the hard way. Originally we had written a complex script to go through and physically change all of the function calls. Joe explained that it would be a much easier/cleaner fix to re-define the alert() function to be the Sentry alert function and not even touch all of the references. Essentially, we made one global change instead of hundreds of individual changes.
• Joe also reviewed the changes that I had made to the VPN Setup Tool. Previously I had added a feature to the tool that showed "Not a Customer" as an option in the client-selector on the VPN page. I had done this by adding a "Not a Customer" row to the table from which the client names were being pulled. The alternate method was to add it as an option to the selector without actually adding it to the database. This proved a little more complex than it sounds, as there was no ID to submit with the form, but all-in-all, it wasn't a difficult fix.

Tuesday-Friday:

• Began working on a ticket which involved adding a "Why Non-340B Purchase" column to the PO/Invoices PO reporter. Each line item on a PO would have a short reason listed and then a tooltip so that when the "short reason" is moused over, its corresponding "long reason" pops up.
• Found a massive 250+ line function responsible for assigning a "Why Non-340B reason" to each line item in a PO and storing it in the DB.
• Decided it best to add to the existing PO Dao's existing query, rather than writing a completely new one.
• Needed to join three new tables to the query in order to get to the corresponding non-340B reasons in the DB. This proved difficult, as I did not realize that it should be done by joining on columns that are nullable.
• Once the tables were properly joined, I struggled with returning these additional columns without throwing off some of the SUMs done in the original query. This proved more difficult than anyone realized upon first glance and actually required the expertise of Danny Berger.
• Of course, once everything was working fine in FF, I tried it in IE6 and found some UI issues due to some unnecessary, pre-existing CSS properties.
• Talked on a conference call with Neel/Joe/Alan about why some line items had no existing "why non-340b reason" in the database. I then talked with JJ who identified 3 possible cases in which this could happen (Troy and Joe helped me with how to handle each of these cases) :
1. Old orders prior to the po_debug tables existence.
2. Rogue orders.
3. Possible edge cases we might be missing.
• Edited the existing unit tests to test the new features.

Of Note:

This past Wednesday, I was notified by John, Joe, and Cyrus that, due to a lack of production, I will be switching from Dev work to TA work. Though there are only two weeks left, I plan on learning as much as I can about the TA world. I am quite a bit saddened to be leaving the Dev role, as I really enjoyed my work there, but I will be striving to make the most of my last two weeks.

Week 8 Thoughts and Experiences

Work

I don't feel like I get as much done as I would like, yet somehow I always keep busy doing work-related things....

Monday:

• Added a "Direction" selector box to the VPN Setup Tool which then prints out corresponding text to the config. text box. Added a SQL column and modified existing unit test to handle this. (only worked a half-day)

Tuesday:

• Out of tickets, so I began searching for something to work on. Started off by adding "Manufacture Discontinued" column to the Drug Mapping Reporter, then talked to Drazba and he told me to let him make the changes, seeing as he is re-doing the whole Item Mapping tool.
• Switched to a ticket entitled "add non-340b reasons to invoice view", but struggled to find examples referred to in the ticket description.
• Paired with Robert on his ticket, mapping out several layers of function calls on the whiteboard.
• Blogged about Week 7.

Wednesday:

• Determined to make up for Tuesday's lack of productivity!
• Talked with QA about some clarifications on a VPN ticket.
• Ironed out some specifications with Andrew Neal about the Invoice searching modifications that I previously made within the "Audit/Search Tool."
• Learned about how caching works for certain parts of the system. I was having inconsistencies caused by switching between pointing my dev environment to the dev database and then to the staging database. Reece helped me setup my own cache so that I don't have to worry about other people corrupting my cache.
• Added an option called "(No Associated Customer)" to the VPN Setup Tool's "Client" selector box. This was necessary, because it is required that a client be selected in order to submit the form. This was wrong, because we have tunnels (QS/1, Emdeon, Indy Office, Deerfield Office) that are obviously not associated with a client.
• Berger helped me modify the get_clients() function in the Locations.php object. We joined the query with the table 'organization_v' in order to keep the duplicated sites from being returned. Previously, when multiple sites were under one hospital, the hospital name and all of the site names appeared in the list. Now, just the hospital name will appear on the list.

Thursday:

• Database and Bugmonster down all day. Talked with Jeremy about some of the recent VPN Setup Tool changes.
• Began working with Austin to write a script to change all javaScript alerts to be much better looking mootools alerts.

Friday:

• Finished writing and testing the changes made by the script. Austin taught me a lot about command line tools and intricacies such as 'screen' sessions.

Week 8 Reading Response

Peeblogs:

The Fishbowl was woefully lacking in appearances from Sir John Peebles. Perhaps next week we will be enlightened.

"Code Complete"

Several insightful quotes:

• "Capers Jones reports that a software system with one million lines of code requires an average of 69 kinds of documentation. The requirements specification of such a system would typically be about 4000-5000 pages long, and the design documentation can easily be two or three times as extensive as the requirements. It's unlikely that an individual would be able to understand the complete design for a project of this size-or even read it. A greater degree of preparation is appropriate." (pp. 19)
• "The more you learn about programming, the more you fill your mental toolbox with analytical tools and the knowledge of when to use them and how to use them correctly." (pp. 20)
• "Just as you can misuse any powerful tool, you can misuse metaphors, but their power makes them a valuable part of your intellectual toolbox. (pp. 20)

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.