Data/Database Career Options and Growth

  • I am a database professional who would like some feedback regarding some recent career choices I have made. At the beginning of the year, I became open to new opportunities and within the same week, had two job offers. One was a Database Developer role and the other was an ETL Developer. Although the Database Developer position was with a Fortune 10 company, I ultimately decided to opt for the ETL position. If I was to take the Database Developer role, my daily job duties would solely entail coding in T-SQL. I felt this would have restricted my career path moving forward and that the ETL role could lead to a much wider range of options. I feel that I can now plan to branch out into other fields, such as being a Data Engineer, Data Architect, BI Developer, or even back to a Database Developer if I so choose. To future employers, I don't want to be seen as one-dimensional. My goal is to take courses and become certified in various data-related areas (currently, I am only certified in SQL Server - DB Dev). I would appreciate some views on my career plans. I also wouldn't mind some feedback on my current position as an ETL Developer. Is it a well-respected occupation in the tech world? How does it compare to a SQL Developer in terms of level? Thank you all for your input.

  • I can't speak on how ETL developer compares to SQL Developer in terms of level.  They are 2 different roles from my understanding.

    The benefit of branching out is you get to taste a bunch of different sections of SQL Server. The problem with branching out is that the technology is constantly changing.  If you become an expert in ETL then change careers over to a database developer, it is a different skillset.    It is similar to how senior level DBA's pass off the "easy" tasks to the Jr. DBA's.  If you spread yourself thin learning ALL there is to learn about SQL and trying to have a career where you can fit in to any of those positions, you are likely not going to get to the Sr level.

    Knowing how to develop ETL and design a database and write stored procedures and such is good knowledge, but my advice is to focus on the particular "part" of SQL you are interested in and build your career around that.  Being one-dimensional SHOULDN'T be a bad thing as long as you can say you are an expert in your field.  If you relate it over to sports, your quarterback is your quarterback.  You don't see the QB playing as an offensive line.  They have the area they are the expert in (QB) and they hone their skills and work to make themselves a better QB.  Now, you can take that advice TOO far too.  If all you are doing is creating tables and nothing else, you've gone too far.  A database developer does need to handle multiple tasks.  Same thing with an ETL Developer.  There are multiple things you need to do and be good at.

    It kind of reminds me of being a C# developer AND a SQL Server developer.  If I was both and I said I made a WHILE loop, most people would HOPE it was in C# and not in SQL Server.  C# loops are frequently needed.  SQL Server, loops are rarely needed.  But if I am expected to do both, it is possible I got mixed up and put a loop into SQL Server and my performance will tank.

    But, that being said, I know some people who are amazing ETL developers.  I am not one of them.  I am one of the ones that ETL developers hate, but I am also not very good at UI and hate "drag and drop" design interfaces.  I prefer getting my hands dirty playing with SDK's and loading DLL's into my code.  I don't care how the thing looks as long as it does the job I need it to, so my ETL packages are frequently messy but they work.  Do they work well? probably not, but they get the results I need in the timeframe I require, so they are "good enough".

  • One thing I would strongly suggest for your career, don't get hung up on labels or titles. I was working as a database developer, and by that I mean, designing, building, and coding databases. However, my title was DBA. I even did some DBA duties (on call rotation, stuff like that). The title said one thing, the work said another. It didn't really matter that much. Further, different companies are going to call different jobs by the same title, or have different titles for the same job. It's much more about what you do versus what it's called.

    In general, I agree largely with your choice. If a database developer for that company was only ever a T-SQL code monkey, then yeah, I'd skip that too. Just know that other orgs might have a database developer role and you're going to want it based on your stated career goals.

    ETL is something I've done quite a bunch of over the years, but it's always been a sideline. Overall in the community, ETL is a specialty. It is one worth pursuing because it will position you well to work with, or around, data science and other analytics if you want to go into that. However, like any specialty, it can also be a bit of a dead end. It's very much a "your mileage may vary" type of situation.

    I'd say you're thinking about things correctly. The goal to have a career, versus just a job, is to strive to have three years of experience be three distinct years, not one year repeated three times. Same goes for 10 years & 20. Constant learning and path adjustment is the key.

    Best of luck.

    ----------------------------------------------------
    The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
    Theodore Roosevelt

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • A lot of this really does depend on company but I've found ETL Developer naturally lends itself to a broader spectrum of offshoots.  As DB Developer the most natural path forward is DBA or becoming a DB Developer/Admin.  On the other hand by it's nature ETL Development while likely requiring a lot of the same skill set as a DB developer/admin can also very easily include web development with the rise in use of web interfaces, and any other tools you end up needing during integrations.  It also is tied into data warehousing quite often which can lead to a lot of good business experience and data analysis experience.

    But like I said a lot of this can vary greatly by company.  Starting as a DBA at a small company(where the job was really DBA + Development) I ended up with a lot of opportunities to work outside of just databases.  Where as working at a larger company as a data architect my job is more focused on just that but with a lot more tools and requirements specifically related to that.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply