If people ever start seeing you as “the database guy”, you’ll be pigeonholed into that slot as long as you remain in that team.
Or maybe their manager was just a really big fan of Oracle or something. I don’t know.
Or maybe their manager was just a really big fan of Oracle or something. I don’t know.
That's a good thing: it gives you great leverage to ensure good retention-pay.
-------
During your 1:1s/"connects"/perf-evals, don't frame it as "I hate being the only one here who knows SQL, I'm quitting/gimmie-a-raise", instead frame it as "I'm proud of the great accomplishments that my unique and deep understanding of both database-theory and SQL in-practice have brought to the company; given my significant responsibilities I now have in the team/company I'm sure you'll "recognize" my now quite-significant leading-role...."
(for best effect make the "money-gesture" with your fingers during the last part).
...I wish I had the gall to do that when I was younger.
Being pigeon holed into boring work just because you're "the guy" is crap, no matter how good the salary is. I quit my last job because of this, and would encourage anyone feeling the same to do so.
No amount of retention pay would raise my spirits in that situation.
Not even this. It's worse when you end up with a whole bunch of tedious, yet very basic work dumped on your by people who have no desire to know what they're doing because "the database guy" can just do it instead.
Note that it's not only "databases" where this happens.
90% of the time my answer was simply "Yeah... That's a bad use-case for a regex. You can use this java snippet to accomplish the same thing."
At the start I would actually solve their request with some hairy regex, but it generally did not perform well and when requirements change they'd be unable to edit it and would find me again to change it.
But part of the problem was they did know simple enough regex for what they wanted to accomplish. Having a few simple regex and some application logic around them would have done it. But they'd often think "that sounds messy, squeaky-clean can probably solve this in a single regex." And while I probably could, it would not be good code nor would it be more performant.
I wouldn't even have minded being seen as the "string pattern/parsing guy". But I was specifically regex-guy in their minds.
Also story for another day and another thread, I was also the MongoDB-guy. Similar to the regex stuff though, in 90% of the questions they'd send to me MongoDB was not the correct choice.
Overall it's more nuanced then could ever fit into an HN comment (yes I brought it up with management, and other issues), but there are a number of reasons I quit. I quit a couple months before a company buyout we knew was going to happen and I had equity. I felt like it was probably the right choice then. I recently got some beers with some of my friends who stayed through the buyout and had equal amounts of equity and learned I did make the correct choice.
"Hey can I borrow your chainsaw?"
"Sure, you need the gas powered one or the electric one?"
"Oh I'm not sure, which one would be best for cutting my hair?"
Of course I'm solving real and challenging problems, but the skills that got me here in the first place are dying on the vine.
Also, on top of that, I'm "the cloud/networking/debugging guy" for about 150 engineers. It's annoying. I want to turn off Slack.
I understand my view on the DBA may be limited, but are you serious ? Have I been unlucky and only ran into this weird subcategory ?
The problem is that that is basically where all advancement stopped for them. They learned SQL well enough, they might even know how to do transaction rollbacks, but god help you if you have a real systemic problem that takes detailed knowledge of the whole system to unwind and fix without major data loss.
I'm in the process of trying to convince management to hire a real Postgres expert(both inside and outside the database), because we are currently on a bad, checkbook driven path that is moving tons of our managed RDS Postgres databases to self-managed (and poorly architected) clusters on another cloud. I have neither the time nor the inclination to become a deep Postgres expert.