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.