Why would anyone try to "hide their deep knowledge of Postgres"? Like, I could easily see someone having to hide their deep knowledge of MongoDB--lest they be branded forever as "damaged"--but I've been under the impression that PostgreSQL skills are considered a really good thing this past decade or so... were they just really hoping to avoid becoming a database engineer, or were they maybe under threat of becoming an "on call" asset?
> you’ll be pigeonholed into that slot as long as you remain in that team
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.
It also creates problems that normally wouldn't exist. I was "the regex guy" at my last company. Every couple of days someone would be trying to solve a problem that would much more reasonably be handled by a few string.split() or indexOf() calls and some logic in their application's language. Instead they would message me "I need to do blahblahblah, can you give me a regex for that?" Or even worse "I've written this regex but it doesn't work on a few cases, can you help me fix it?" and then share some 600 character long regex monstrosity.
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.
Did the company ever use the "internal market" paradigm? If so, keep track of your time spent on other-peoples-problems and record it in a spreadsheet, and invoice other peoples' managers accordingly :)
...and get shit done. I mean come on, who asks a person in another team to help with a regular expression. There has to be a line somewhere. You can be a go-to person for an obscure technology, some complex framework, but being a go-to person for regular expressions? What's next? Go-to person for iteration?
When I joined it was about 15 employees. When I left it was about 150 (but still under 30 devs) so this wouldn't really be reasonable.
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.
How are you supposed to get work done on a team, if any question asked to another team member is immediately seen as "unproductive"? It's not just about regexes. I'm having trouble debugging a system, who do I ask? Nobody, apparently, because if I do then I might incur a "bill" from my own coworkers!
You wouldn't be logging time spent on stuff that's part of your actual responsibilities and/or for your same team (under the same manager) is fine - the whole "internal market" stuff applies to inter-team work, especially work/asks/tasks that don't go through the chain-of-command (i.e. from IC1 in team A to IC2 in team B without going through either Team A's manager nor Team B's manager).
I think in the some cases like people mentioned above, it's no longer collaboration but more of a consultation. The benefit is only going in one direction: to the consultantee. In that case, you need some way to make the nature of that relationship explicit and valued. Otherwise these consultants begin to feel they're being put in a position of working for someone else without management recognizing that and compensating it as such.
When I joined it was still a pretty early stage startup so that wouldn't have been reasonable. When I left it was pretty solidly in the mid-sized company category, so maybe something like that would have been doable (invoices are pretty rude though). I did enjoy helping cross-team though, it's fun working with people you don't work with on a daily basis, and they were/are my friends.
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.
I know enough people who have gotten pigeonholed as "the database person" to believe that's not an enviable place to be. You end up getting a lot of tedious, fiddly work dumped on you by people who have no idea what they're doing and need you to clean up their messes.
No amount of retention pay would raise my spirits in that situation.
> people who have no idea what they're doing and need you to clean up their messes
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.
Worse than that, you can get set with OKRs set by people with no context and then judged because you didn’t meet them. Then your expertise is discounted.
But if you truly find it boring it’s still going to be difficult to frame it that way. Picking up too much work you don’t want to do can make you resent a job very quickly.
idiotsecant, other people having worse jobs doesn't mean you should be happy with the same (or even better). Should we limit ourselves to be content with doing better than 90%? Where would the Torvalds, Stroustups, and Dijkstras come from then?
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.
Most of the world works at jobs that are repetitive, demeaning, dangerous, and insecure. And all that for the payoff of barely continuing to survive. It's truly a point of privilege to turn up your nose to a top 10% first world salary because shuffling things around in a database is distateful to your sensibilities .
Yeah, it sucks. I have strong opinions about how to improve our ops, and the knowledge/skills to do it, but there is no way I'm going to get stuck as being the ops guys.
Can confirm from experience. It took me years to shake that off and become known as a developer who could database. Its a function of whatever the team lacks. Once upon a time, DBA was a thing - I did manage to stay out of that deep pigeonhole luckily.
From my limited interactions with DBA's.. they rarley did anything outside of the database other than tell the developers their queries were inefficient or deploy new tables/databases/upgrades.
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 ?
No, you experienced the average DBA which is probably someone that started as a Junior SysAdmin, futzed around with databases, liked that they could silo into that and do nothing else.
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.
I’ve definitely done it for exactly this reason, and others mentioned in the thread: a strong desire to not suddenly become the ______ guy.
Additional responsibility with no additional authority absolutely sucks when you get (a) pigeonholed, (b) saddled with every single request ever about _______ in addition to your other work or (c) some unholy combination of both.
Especially when ______ only has enough “buy in” from decision makers to make the decision that you need to keep ______ alive because the business “needs”it but apparently not enough to properly source and acquire the necessary resources it needs compared to other business initiatives.
Because “why do we need to do that? I thought you knew about ______ “
Go figure. I’m quite done volunteering myself like that.
Heartily agreed. Additional responsibility without the authority to match just sets you up for failure. And rarely do you get extra pay for this additional responsibility anyway.
In an interview I don’t want to be intimidating and feigning ignorance can give the candidate opportunity to shine. If they go deep, I can keep up and keep pushing, if they veer into bullshitting I can tell and gracefully conclude without offending anyone.
As a manager, not disclosing depth lets me ask stupid questions more frequently and in more contexts (for the benefit of others, for when I forget something or don’t understand something, as a Socratic teaching method, to help set the culture of asking questions, etc)
Playing dumb is also a good way to avoid responsibility if you hate something, too, if a bit passive aggressive.
Sometimes being seen as deeply knowledgeable will do nothing but create endless unpaid work for you. It is often the case that this work comes from people who don't know and don't want to know whatever it is you're good at.
Surely everyone here can relate with the classic "computer guy" everyone takes advantage of. It turns out this exact same thing can happen in actual technology companies. All you have to do to become "that guy" is have knowledge about some vital technology that people don't actually want to care about. People will happily send anything related to it directly your way, increasing your workload and responsibilities with zero additional compensation.
It seems databases are to many professionals what computers are to laymen. They depend on this technology but they don't fully understand how it works or how to fix problems. They still want to define the database schema and make other key decisions. If there's any problem, they don't want the responsibility, they want to be able to offload it to some "database guy". Who wants to be that guy?
If you're specializing in something else but have knowledge of some other, unrelated thing, the latter is often at least accidentally concealed because it rarely comes up. Further, one might deliberately conceal it, to avoid having work assigned that distracts from the thing one is trying to focus on (for career development, personal preference, whatever reason).
I've been known to pretend not to know a damn thing about WordPress, for instance. Even though I do.
Hehe.. I once was asked to retrieve someones mail account (he lost is password)... sigh. People have all kinds of ideas what you can do if you are a programmer.
I once fixed a bug caused by a faulty printer driver from HP. The driver changed the floating point control word and didn't change it back. Our program crashed while doing a completely innocuous operation, but only if you had printed to an HP printer earlier in the session.
I remember that, because I worked on the MS FoxPro team at the time and report printing was crashing for a lot of users, but not all of them. Took forever to finally pin it down because, as parent comment points out, the culprit could have long left the building by the time the crash happens. Stupid driver sets the FPU to say "math errors like divide-by-zero are software's problem now, not mine" without telling software. IIRC (and this was over 20 years ago), operations had to be wrapped in/with the one line of code that flipped it back.
But here's the thing: it wasn't just HP, it was a lot of print drivers. I suspected that there was some printer driver boilerplate out there, possibly even published by MS, that included this bug.
(And, wow, did I swerve sharply into the off-topic lane for story time. Sorry.)
That's funny, we had a very diverse user base but never saw the problem with any printer but HP. And 20 years ago sounds about right for my time frame too. I think that was about the point where Windows started providing more isolation between drivers and user programs.
Similarly I know a lot about software management because I saw that it affects everything I do, and I needed to be able to push back on bad management. Doesn't mean I want to be a project manager. No, I don't, and please stop asking.
And there are tasks you took on at old jobs because they needed to get done and nobody else would do it, so you got stuck. You did them. Maybe you even did them well. But they aren't on your resume, because you don't want to do it again. And if you mention them as anecdotes, you are careful where and when you bring them up.
Why would some be branded damaged because they have knowledge of a tool? That's ludicrous.
I've used many databases including mongo. They are all tools like any other with pros and cons and having experience with multiple across domains is a boon.
