Ask Slashdot: Changing Career From OLTP To OLAP Dev

First time accepted submitter xby2_arch writes "After spending over 12 years writing OLTP applications (Java EE/JDBC/ORMs), I decided to dabble in the OLAP world. I had decent DB skills, considering most of my previous projects had involved data modeling and coding using Stored Procs, etc. Yet I hadn't designed or implemented any dimensional databases. Luckily for me, I had enough relevant domain knowledge to land a developer job in a data warehousing project. The work was enjoyable enough that it motivated me to spend that extra time and effort I needed to cope with the different dynamics of coding in the OLAP realm. In my past life, data volumes weren't the primary concern (instead, transaction volumes were), here, everything was about data. ETL/Integrations present another set of problems you generally skirt in a typical web/app-tier developer role. All in all, it turned out to be a non-trivial, yet worthwhile transition. I am certain that there are plenty of seasoned developers out there who plan to make a similar move (or have made already), who see data as the next chapter in their careers evolving toward becoming Enterprise Architects. I want to hear what's holding them back, or what helped them move forward. What should be considered a prerequisite to make this switch, and what are the risks, etc.?"

Comments

No barrier at all

[Intropy]

Moving from one specialized type of programming to a closely related type of specialized programming is pretty straightforward. Apply for such a position and you wont suffer compared with other candidates. Or, if your current employer needs something new done, do that new thing. You're not talking about a major career change here. Programming is programming. Even moving from something like standalone application GUI programming for windows in C# to back-end web service programming in C++ on Unix isn't that big a deal. If you can program, you'll pick up the new tech/language/idioms as needed and notice the striking similarity in the work you actually end up doing.

Re:Eh?

[vlm]

My guess is its a subtle attempt at a philosophical statement that OLTP and OLAP are such wildly different problem domains that it may as well be like trying to horizontally jump from being a fluffer to being a farmer, despite them starting with the same letter and occasionally being confused, at least on /.

Personally I disagree with that viewpoint. You're still in the realm of high performance computing, blah blah blah. They have different enough needs that maybe they need to be separate groups underneath separate supervisors, or at a big enough firm, maybe separate depts, etc, but I'm not seeing a huge fundamental difference. Consider yourself lucky to be at a firm that separates those roles at all. In the last decimal place the problem solving techniques are going to be different, but I'm sure 99.9999% of it is the same, which is probably how a OLTP guy got a OLAP job without the HR filter of "must have 9245 years experience with this specific version of software" filter which theoretically caused this whole discussion. I'm sure a guy who can figure out OLTP can probably figure out OLAP rather quickly and vice versa.

Admittedly I've spent probably a hundred times more career effort on OLAP tasks than OLTP tasks, but very few firms have the luxury of full time personnel for those jobs, so I've spent most of my time doing other stuff.

If anything, I'd say take some more risks. You fail at a OLTP task and customers and sales and marketing scream and data might be lost or corrupted permanently. You fail at a OLAP task and, eh, the TPS reports are released a little later today, we'll survive... Admittedly OLAP stuff is usually a lot more complicated that OLTP, which means you're used to poor / no documentation, maybe you should be worried about doing more documentation of OLAP stuff.

Maybe another way to describe it, is fail once at OLTP and you get fired, fail repeatedly badly enough at OLAP and the company goes out of business before they figure out to fire you?