How I earn my corn
I work for Exony; I'm not entirely sure what my job title is, as such things aren't too important around here (one of many things about Exony I like). I spend my time working on database and data warehouse design and implementation issues around our reporting and analytics product. So, Microsoft SQL Server 2000 and Analysis Services are the primary products I work with, with a current emphasis on T-SQL, MDX and a side-order of XSLT. I get a real kick out of solving difficult conceptual problems with those tools, and coaching my colleagues in doing the same (another of the great things about Exony is the technical skills of the people I work with; it's really satisfying working with bright, motivated people).
We tend to have overlapping skill sets, so I'm not the only person who writes SQL, for example (although I'm pretty sure I'm the only one here who enjoys writing MDX!) but we tend to have individual specialisations or preferences. To my mind, this is a two-edged sword; sometimes, we know just enough to get ourselves in a tangle. For example, it's one thing to be able to write a SQL SELECT statement; it's another thing to realise how to write a SELECT statement in such a way that it performs well and doesn't soak up unnecessary system resources; and it's yet another thing to understand the role of objects like indexes or partitioned views in really making them fly. Consequently, part of my role is to identify and promote best practices for the areas in which I specialise, and to keep a watch out for sub-optimal code in our databases.
My background is in OLAP and Business Intelligence, and the primary attraction for me in joining Exony was being able to bring that experience to the evolution of a SQL-based reporting product into a much more powerful analytical product. I suspect that part of my attractiveness to Exony was that I had designed and implemented multiple OLAP solutions previously (albeit not in the telephony arena) and so could jump-start the incorporation of OLAP technologies in our products. Before that could happen, however, I helped to solve some issues around replication and performance in the previous (non-OLAP) version of the product. Once development began on the analytical product, my time was split between designing the new system, and teaching my colleagues how to work with the new stuff.
Prior to Exony, a significant part of my time was spent teaching developers and analysts how to design, build and manage enterprise-strength data solutions. I really enjoyed the satisfaction of seeing the light go on in my students' eyes when they "got it". Currently, I don't perform such a role externally (and truthfully, I really miss it) but it's a conscious decision on my part not to at this time. Which makes the internal skills transfer element of my role particularly satisfying and important to me. As far as I'm concerned, if I'm the only person who knows how to do something, or am the only one with the skills / experience / confidence to tackle a particular issue, then I've failed a significant part of my responsibilities.
How does one measure "success" in a role like this? Well, quantitively, success for a software development company like Exony is indicated by sales. We need to constantly bear in mind that we don't design software for the sake of it, or as an academic or artistic exercise; we need to sell product and associated services. If using a particular technology like OLAP didn't translate into sales (both incremental sales to existing customers, and sales to new customers which previous versions would not have secured) then the exercise would be a failure. On that basis, I feel we're successful. Qualitatively, I knew I'd cracked it when all the jargon of OLAP was being used by one of my sales colleagues in his sales pitches, AND he was using it correctly! ;-)
This blog has been migrated to new software on a different server (http://www.multidimensional.me.uk)
and comments on this post on *this* blog are now closed. All existing comments have been copied to the equivalent post on the new blog. If you still wish to comment on this post, please use the equivalent post at: http://www.multidimensional.me.uk/
We tend to have overlapping skill sets, so I'm not the only person who writes SQL, for example (although I'm pretty sure I'm the only one here who enjoys writing MDX!) but we tend to have individual specialisations or preferences. To my mind, this is a two-edged sword; sometimes, we know just enough to get ourselves in a tangle. For example, it's one thing to be able to write a SQL SELECT statement; it's another thing to realise how to write a SELECT statement in such a way that it performs well and doesn't soak up unnecessary system resources; and it's yet another thing to understand the role of objects like indexes or partitioned views in really making them fly. Consequently, part of my role is to identify and promote best practices for the areas in which I specialise, and to keep a watch out for sub-optimal code in our databases.
My background is in OLAP and Business Intelligence, and the primary attraction for me in joining Exony was being able to bring that experience to the evolution of a SQL-based reporting product into a much more powerful analytical product. I suspect that part of my attractiveness to Exony was that I had designed and implemented multiple OLAP solutions previously (albeit not in the telephony arena) and so could jump-start the incorporation of OLAP technologies in our products. Before that could happen, however, I helped to solve some issues around replication and performance in the previous (non-OLAP) version of the product. Once development began on the analytical product, my time was split between designing the new system, and teaching my colleagues how to work with the new stuff.
Prior to Exony, a significant part of my time was spent teaching developers and analysts how to design, build and manage enterprise-strength data solutions. I really enjoyed the satisfaction of seeing the light go on in my students' eyes when they "got it". Currently, I don't perform such a role externally (and truthfully, I really miss it) but it's a conscious decision on my part not to at this time. Which makes the internal skills transfer element of my role particularly satisfying and important to me. As far as I'm concerned, if I'm the only person who knows how to do something, or am the only one with the skills / experience / confidence to tackle a particular issue, then I've failed a significant part of my responsibilities.
How does one measure "success" in a role like this? Well, quantitively, success for a software development company like Exony is indicated by sales. We need to constantly bear in mind that we don't design software for the sake of it, or as an academic or artistic exercise; we need to sell product and associated services. If using a particular technology like OLAP didn't translate into sales (both incremental sales to existing customers, and sales to new customers which previous versions would not have secured) then the exercise would be a failure. On that basis, I feel we're successful. Qualitatively, I knew I'd cracked it when all the jargon of OLAP was being used by one of my sales colleagues in his sales pitches, AND he was using it correctly! ;-)
This blog has been migrated to new software on a different server (http://www.multidimensional.me.uk)
and comments on this post on *this* blog are now closed. All existing comments have been copied to the equivalent post on the new blog. If you still wish to comment on this post, please use the equivalent post at: http://www.multidimensional.me.uk/
posted by Koan @ 4:55:00 am
0 Comments:
<< Home