|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Take of a photo of something that brings you joy and share it I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
Titles and DevOps Confusion Alex Yates has become quite the DevOps consultant in the last few years. I used to work with Alex at Redgate before he left to start his own consulting firm. I hear nothing but good things about his work, and if you are looking for someone to help guide your database development team, he'd be a good choice. He wrote a piece on the Octopus Deploy blog about the title of DevOps Engineer and why that doesn't quite make sense. He essentially notes that this doesn't really describe what a person does and it might not be a good title. I tend to agree, since DevOps isn't a thing, per se, but rather a set of guiding principles. While this might include building software, or deploying it, there are titles for those things (build engineer or release engineer). It could include Infrastructure-as-code, but that's the domain of sysadmins. There are any number of titles that have come about in this business, and likely more being created all the time. If you have a new job, often you can finagle your way around some pay structures because after all, if you invented the term, the HR department doesn't have a pay scale to limit you. I suspect that's part of the reason someone started calling themselves a DevOps Engineer in the first place and got someone to hire them under that title. I suspect titles used to be more descriptive and important in the past, when we had fewer of them and the work that each of us did was more tightly scoped. Throughout my career, I've started to see more people doing more types of work all the time. Especially in technology where we usually do the work that needs to be done, often crossing over the duties between job titles when something is broken. Getting a system working often takes precedence over any claims of some task being "my work" or "your work." Titles ought to be somewhat consistent, if for no other reason than to easily allow us to compare the work we do in different organizations and allow us to easily promote ourselves to a new employer. If every organization had different titles, we'd waste a lot of time trying to decide if we wanted a position, as would hiring managers trying to decide if we could do the work. Certainly the we find that a DBA or a Developer moving organizations might have some different tasks, but we have a general idea of what work they should be able to complete. I've never been too concerned about my titles, though I have worked to become "senior" at different employers. That's usually a function of proving you can do the work well, across a period of time. Of course, if you get work done effectively and efficiently, the title likely doesn't matter. Someone, likely many someones, will want to hire you. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
