My dear friend Josephine Bush a.k.a HelloSQLKitty hosts this month’s T-SQL Tuesday. Josephine’s call to us is to share our understanding of the multitude of job titles available out there and what they mean to us.
While many job titles exist, each role’s essence is heavily shaped by the operational dynamics of the business and how responsibilities are allocated among individuals. A rough and high-level comprehension of these titles can be outlined as follows:
- Database Administrator (DBA): Responsible for High Availability/Disaster Recovery (HA/DR), Backups/Restores, security measures, including audits, storage management, code promotions, and sometimes even code reviews. Encompasses Continuous Integration/Continuous Deployment (CI/CD) and automation, and may also be referred to as a ‘Database Reliability Engineer’.
- Database Engineer (DBE): Tasked with managing database code, architecture, and data process flow. Engages in Extract, Transform, Load (ETL) processes, pipelines, and assumes responsibility for data integrity and health.
- Database Architect: Often involves a blend of DBA and DBE roles, with a substantial infusion of cloud architecture expertise.
- Data Warehouse Engineer/BI Architect: Primarily concerned with reporting, data warehousing, and data lake management.
- Data Scientist: Typically held by individuals with Ph.D. qualifications or similar expertise, focusing on algorithms and predictive analytics.
Having devoted close to two decades to the role of a DBA, I began experiencing weariness around 2018. The toll of being on-call was manifesting as severe health implications. In most settings, DBAs were perceived as reactive problem solvers—earning high remuneration but receiving little attention or respect unless a crisis demanded their intervention. In essence, proactive contributions were unacknowledged, and one’s worth was not recognized as value-added to the business. This prompted me to explore alternative roles. I authored a book for Apress, wherein I engaged with various community members to delve into their roles and responsibilities. After interviewing 29 professionals, I arrived at three viable options:
- Delve deeper into Business Intelligence (BI) and transition to reporting and BI-related responsibilities. While I had previously occupied a BI role, opportunities in this domain were limited.
- Cultivate skills in Product Management and transition into a PM or DBA management role. However, the steep learning curve and the prospect of becoming extensively people-focused gave rise to uncertainty. Additionally, I was skeptical of the fervor around Agile methodologies, as I noticed elevated attrition rates among PMs.
- Embrace a Data Engineer role that primarily involves coding and architecture. Among these choices, this resonated with me the most from a technical standpoint. While I was familiar with R Programming and comfortable with VB.net, I was uncertain whether these skills would suffice. Fortunately, the current job opening aligned with my skill set, enabling me to become a data engineer. Since transitioning, this role has proven to be one of the most fulfilling data-related experiences.
To conclude, the precise definitions of these titles are of secondary importance. The focus should lie on personal aspirations and whether a job aligns with those objectives. Thank you, Josephine, for hosting.