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)