Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "senior dba"
-
Yesterday: Senior dev messages out a screenshot of someone using an extension method I wrote (he didn’t know I wrote it)..
SeniorDev: “OMG…that has to be the stupidest thing I ever saw.”
Me: “Stupid? Why?”
SeniorDev: “Why are they having to check the value from the database to see if it’s DBNull and if it is, return null. The database value is already null. So stupid.”
Me: “DBNull is not null, it has a value. When you call the .ToString, it returns an empty string.”
SeniorDev: ”No it doesn’t, it returns null.”
<oh no he didn’t….the smack down begins>
Me: “Really? Are you sure?”
SeniorDev: “Yes! And if the developer bothered to write any unit tests, he would have known.”
Me: “Unit tests? Why do you assume there aren’t any unit tests? Did you look?”
<at this moment, couple other devs take off their head phones and turn around>
SeniorDev:”Well…uh…I just assumed there aren’t because this is an obvious use case. If there was a test, it would have failed.”
Me: “Well, let’s take a look..”
<open up the test project…navigate to the specific use case>
Me: “Yep, there it is. DBNull.Value.ToString does not return a Null value.”
SeniorDev: “Huh? Must be a new feature of C#. Anyway, if the developers wrote their code correctly, they wouldn’t have to use those extension methods. It’s a mess.”
<trying really hard not drop the F-Bomb or two>
Me: “Couple of years ago the DBAs changed the data access standard so any nullable values would always default to null. So no empty strings, zeros, negative values to indicate a non-value. Downside was now the developers couldn’t assume the value returned the expected data type. What they ended up writing was a lot of code to check the value if it was DBNull. Lots of variations of ‘if …’ , ternary operators, some creative lamda expressions, which led to unexpected behavior in the user interface. Developers blamed the DBAs, DBAs blamed the developers. Remember, Tom and DBA-Sam almost got into a fist fight over it.”
SeniorDev: “Oh…yea…but that’s a management problem, not a programming problem.”
Me: “Probably, but since the developers starting using the extension methods, bug tickets related to mis-matched data has nearly disappeared. When was the last time you saw DBA-Sam complain about the developers?”
SeniorDev: “I guess not for a while, but it’s still no excuse.”
Me: “Excuse? Excuse for what?”
<couple of awkward seconds of silence>
SeniorDev: “Hey, did you guys see the video of the guy punching the kangaroo? It’s hilarious…here, check this out.. ”
Pin shoulders the mat…1 2 3….I win.6 -
Yesterday I spent some time on the meta site for dba.stackexchange.com and found this one guy with 1 rep raging about how his questions aren't getting answered and how is answers are the best etc...
"I have 17 years of experience as a dba, blah, blah, blah, my answers are correct, blah, blah"
He got pretty destroyed by the mods and other users about how shit his answers were and how they weren't factually correct etc...
This just continues to show that no matter how much experience you have you won't always be right.
Same goes for my senior at work, he has 10 years more experience than me (I have 2) and he still asks for my point of view and help without being a dick about it.
I hope we'll all keep being nice people unlike that Stackexchange guy...2 -
This was not exactly the worst work culture because the employees, it was because the upper level of the organization chart on the IT department.
I'm not quite sure how to translate the exact positions of that chart, but lets say that there is a General Manager, a couple of Area Managers (Infrastructure, Development), some Area Supervisors (2 or 3, by each area), and the grunts (that were us). Anyway, anything on the "Manager" was the source of all the toxicity on the department.
First and foremost, there was a lack of training for almost any employee. We were expected to know everything since day-1. Yes, the new employees had a (very) brief explanation about the technologies/languages were used, but they were expected to perform as a senior employee almost since the moment they cross the door. And forget about having some KT (Knowledge Transfer) sessions, they were none existent and if they existed, were only to solve a very immediate issue (now imagine what happened when someone quit*).
The general culture that they have to always say "yes" to the client/customer to almost anything without consulting to the development teams if that what was being asked to do was doable, or even feasible. And forget about doing a proper documentation about that change/development, as "that was needed yesterday and it needs to be done to be implemented tomorrow" (you know what I mean). This contributes to the previous point, as we didn't have enough time to train someone new because we had this absurd deadlines.
And because they cannot/wanted to say "NO", there were days when they came with an amount of new requirements that needed to be done and it didn't matter that we had other things to do. And the worst was that, until a couple of years (more or less), there was almost impossible to gather the correct requirements from the client/user, as they (managers) "had already" that requirement, and as they "know better" what the user wants, it was their vision what was being described on the requirements, not the users'...
And all that caused that, in a common basis, didn't have enough time to do all this stuff (mainly because the User Support) causing that we needed to do overtime, which almost always went unpaid (because a very ambiguous clause of the contract, and that we were "non-union workers"**). And this is my favorite point of this list, because, almost any overtime went unpaid, so basically we were expected to be working for free after the end of the work day (lets say, after the 17:00). Leaving "early" was almost a sin for the managers, as they always expected that we give more time to work that the indicated on the contract, and if not, they could raise a report to HR because the ambiguous clause allowed them to do it (among other childish things that they do).
Finally, the jewel of the crown, is that they never, but never acknowledge that they made a mistake. Never. That was impossible! If something failed on the things/systems/applications that they had assigned*** it was always our fault.
- "A report for the Finance Department is giving wrong information? It's the DBA's fault**** because although he manages that report, he couldn't imagine that I have an undocumented service (that runs before the creation the report) crashed because I modified a hidden and undocumented temporal table and forgot to update that service."
But, well, at least that's on the past. And although those aren't all the things that made that workplace so toxic, for me those were the most prominent ones.
-
* Well, here we I live it's very common to don't say anything about leaving the company until the very last day. Yes, I know that there are people that leave their "2-days notice", but it's not common (IMHO, of course). And yes, there are some of us that give a 1 or 2-weeks notice, but still it's not a common practice.
** I don't know how to translate this... We have a concept called "trusted employee", which is mainly used to describe any administrative employee, and that commonly is expected to give the 110% of what the contract says (unpaid overtimes, extra stuff to do, etc) and sadly it's an accepted condition (for whatever reasons). I chose "non-union workers" because in comparison with an union worker, we have less protections (besides the legal ways) regarding what I've described before. Curiously, there are also "operative workers", that doesn't belong to an union, but they have (sometimes) better protections that the administrative ones.
*** Yes, they were in charge of several systems, because they didn't trust us to handle/maintain them. And I'm sure that they still don't trust in their developers.
**** One of the managers, and the DBA are the only ones that handle some stuff (specially the one that involves "money"). The thing that allows to use the DBA as scapegoat is that such manager have more privileges and permissions than the DBA, as he was the previous DBA2 -
GWT.
Let me explain:
Tl;dr : someone fucked up, I took shit, it was a gwt project. In a sense I don't hate GWT because of the framework itself but because how I was introduced and forced to "work" with it.
Context:
Was working as a paid intern at a small company there were 3 devs 2 interns and one senior employee that only worked from home handling the shit ton of legacy VB6 code he wrote over several year and a boss with no technical knowledge. (Other unimportant people as well)
I was working with their DBA (cool dude) because I was writing statistic and report generating software.
Story:
The other intern was tasked of doing a gwt app that was supposed to use a input file.
Rather than asking the user to upload it with a file picker (I guess they exist in gwt I didn't got to dig in the framework) he was trying to load the file with a http request directed at the same host the app was running on.
It did not work.
Then his contract was other and the app was left in an unfinished state.
The boss then tried to have the app deployed, the remaining dev dodged the bullet invoking some bullshit because he was clearly incapable of doing it.
So it fell on me, couldn't deploy the app because it was not even close to working.
Tried to fix things and make it work.
Turns out he thought it would take me 3h to deploy when I clearly explained that the other guy didn't finish the app.
Boss got mad, threatened to ruin my studies and my future career.
Couldn't because my uni had my back.
Didn't want to see me anymore.
Couldn't break my contract.
Told me to work from home for the end of my internship.
I got 3 weeks early vacation and got paid, fuck him, fuck GWT, fuck his company.
Still got well marked for the internship as my supervisor was the DBA who was happy with my work.
Morality:
Don't let your intern unsupervised, don't let your main dev work from home when you don't know shit, don't piss me off and send me work from home. -
When a senior engineer who was essentially a DBA on his last project is made tech lead on an iOS team. He had no iOS background before this and now he thinks hes a friggin architect.1
-
Having a senior DBA can save hours if not days of struggle and save your back, if you do not know well enough how to do a more complicated query yet, without fucking up something.
Good guidance and experience is worth so much.
... and no I do not have the rights to drop databases.1