Are the posted questions getting worse?
-
below86 wrote:Jeff Moden wrote:
Heh... mine has started off with a bit of a "well that sucks" factor. Whole new time-keeping system where they want me to categorize virtually every aspect of what I do as a "hybrid" DBA. They originally wanted me to do things like keep track of the time I spent on index maintenance by project/application/DB. Allow me to introduce you to Cohn's law, if you don't already know what it is (and everyone in the world of IT inherently knows what it is, just not what it's called)...
So true, wish those in HR or upper management could understand this
Funnily enough, the (mis)use of time-tracking tools is one of the reasons I'm starting to get itchy feet. That and insisting we come into to the office when government, corporate and WHO advice is to not...
On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
—Charles Babbage, Passages from the Life of a PhilosopherHow to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
-
Jeff Moden wrote:
Heh... mine has started off with a bit of a "well that sucks" factor. Whole new time-keeping system where they want me to categorize virtually every aspect of what I do as a "hybrid" DBA. They originally wanted me to do things like keep track of the time I spent on index maintenance by project/application/DB. Allow me to introduce you to Cohn's law, if you don't already know what it is (and everyone in the world of IT inherently knows what it is, just not what it's called)...
I think I would welcome this, assuming that they are actually going to do some analysis of the data.
My time goes into one bucket. Recently, I started tracking every single thing I did each day and sending it to my boss. It was really an eye opener for the C level folks. They were kind of in shock that I did so many things for so many groups. It got me more money.
We had a pretty detailed set of time tracking when I was director of IT. We looked at what the folks spent time on, and compared it to the same tasks. As an example, person A took 1 hour to install SQL, person B took 8. Is one really good at it, and the other really bad? Or is one really thorough and the other not so much?
It can also be a tool for you, especially when you may be facing a deadline. When the bosses ask why, you can simply say "see for yourself"
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/ -
I always wondered if those looking at this understood that time spent thinking or architecting a solution many times is more valuable than creating many things quickly and spiraling into rework. One can seem to move a bit slower, but is always working on new stuff. The other can sometimes appear very busy and productive in some eyes.
We designed a productivity measure for warehouse workers. How many lines, how many pieces, how many pounds of product, and the distance between each item factored in. Some if one picked one line, and it was a pallet of the product, they didn’t appear productive compared to someone picking 50 lines of different product in all corners of the warehouse.
When gathering requirements, we spent more time. Coding went faster when we had a clear vision. And rework was rare. Business tends to outline the tip of the iceberg, where we tend to think more in terms of flexible, scalable solutions you can build on to answer the next set of related requirements that will be coming. The more data they get, the more questions they have most of the time.
-
Greg Edwards-268690 wrote:
I always wondered if those looking at this understood that time spent thinking or architecting a solution many times is more valuable than creating many things quickly and spiraling into rework. One can seem to move a bit slower, but is always working on new stuff. The other can sometimes appear very busy and productive in some eyes.
We designed a productivity measure for warehouse workers. How many lines, how many pieces, how many pounds of product, and the distance between each item factored in. Some if one picked one line, and it was a pallet of the product, they didn’t appear productive compared to someone picking 50 lines of different product in all corners of the warehouse.
When gathering requirements, we spent more time. Coding went faster when we had a clear vision. And rework was rare. Business tends to outline the tip of the iceberg, where we tend to think more in terms of flexible, scalable solutions you can build on to answer the next set of related requirements that will be coming. The more data they get, the more questions they have most of the time.
I once worked at a company where we had a department wide meeting every Friday at 3:30. 75 folks all jammed into a conference room. They spent the next 2 hours going around the room, "Billy, you had 20 tickets assigned to you this week, and you closed all of them. Good boy". "Mike, you had 5 tickets assigned to you, and you only closed 3 of them. Bad boy". There was zero recognition that Billy's were all "how do you change the font in Word", and mine were all "re-design the world". I only lasted a short while there.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/ -
I once had a ticket to update a field in the ERP system while working in the data warehouse. Their programmers were swamped, and they thought it was a simple process.
I built the update query, tried to run it, and it failed due to a security issue. I talked to the guy running security, and he said I had access. A simple query - changing the case of the entries into upper case as the production crew had loaded them in mixed in a YN field. I had to figure out how to grant myself access, then run it, and then explain to the security officer what he needed to locked everyone out of.
A less than 5 minute job estimate turned into an all day affair. In your ticket example just a count, or in a context of actual verses estimated time, this would appear what a slacker.
Only a few looking at this ticket understood how little reflection it related to the actual task. Only my manager and the security officer understood the value of by my doing it, a hole had been closed as their were about 40 or 50 other people with SME access that could grant themselves the ability to update anything in production. This was the true measure of value of the task done - the ticket only noted I had done a ‘simple’ task and took way too long.
One thing rarely documented in these ticket systems - time you spend on automating something that business does manually, and how much savings add up over time. You may spend 4 hours once creating something that if they only spend 10 minutes a day on, shows where the true value lies.
As you well know from experience, numbers are pretty meaningless without enough context.
-
ahhhh. numbers....
2 situations - long ago, still on mainframes.
some reports were based on Lines of Code written.. so 2 teams each with their own type of code managed to "improve" their numbers in a smart way.
Team A - most of their code used a library of functions - common to most of what they did - so when they reported their code effort during the period they would include the LOC's for the library for EACH call to a function of that library.
Team B - not as pretty as the above - but to improve their numbers and before they did run the process that calculated LOC's they would run a small utility that would split all lines on the real source to be a word per line.
so a ADD A TO B GIVING C. would suddenly become 7 lines of code for the report (and yes the single dot on a line counts as a LOC).
-
And I suppose a third team added lines that did nothing to make it appear they did much more and wrote very complex code.
Creating something that accurately measures performance of people - done right, it is a good tool to look for improvement. Done wrong - it really creates a bad work environment. If you use it as a tool to look for trends - both good and bad - and start conversations geared towards finding more details looking for improvements or what someone does that maybe others can be taught, it can work very well. Used as a club, you make it worthless.
If I had ever been measured solely on lines of code, I would have quickly moved to another job. Someone leaves, and you inherit their bloated, spaghetti code. And likely would be penalized for making it better.
-
Michael L John wrote:Jeff Moden wrote:
Heh... mine has started off with a bit of a "well that sucks" factor. Whole new time-keeping system where they want me to categorize virtually every aspect of what I do as a "hybrid" DBA. They originally wanted me to do things like keep track of the time I spent on index maintenance by project/application/DB. Allow me to introduce you to Cohn's law, if you don't already know what it is (and everyone in the world of IT inherently knows what it is, just not what it's called)...
I think I would welcome this, assuming that they are actually going to do some analysis of the data.
My time goes into one bucket. Recently, I started tracking every single thing I did each day and sending it to my boss. It was really an eye opener for the C level folks. They were kind of in shock that I did so many things for so many groups. It got me more money.
We had a pretty detailed set of time tracking when I was director of IT. We looked at what the folks spent time on, and compared it to the same tasks. As an example, person A took 1 hour to install SQL, person B took 8. Is one really good at it, and the other really bad? Or is one really thorough and the other not so much?
It can also be a tool for you, especially when you may be facing a deadline. When the bosses ask why, you can simply say "see for yourself"
I agree with everything you said and I welcome the change but they wanted to take it too far. Like I said about the index work, I don't have a whole lot of databases on my "consolidated" instance but there are 60 of them so I'd have to make 60 entries from the git. Many of the databases deal with a 1000 Clients and so we have this wonderful Cartesian product of 60*1000 or 60 THOUSAND time card entries for one day, which would take me a week to fill out even it it was just click on an already available entry and enter the 0.48 SECONDS the 8 hours of index work distributed to 60,000 entries works out to.
People that don't play the game should not be making the rules especially when it comes to time cards for a DBA.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions -
Greg Edwards-268690 wrote:
I once had a ticket to update a field in the ERP system while working in the data warehouse. Their programmers were swamped, and they thought it was a simple process.
I built the update query, tried to run it, and it failed due to a security issue. I talked to the guy running security, and he said I had access. A simple query - changing the case of the entries into upper case as the production crew had loaded them in mixed in a YN field. I had to figure out how to grant myself access, then run it, and then explain to the security officer what he needed to locked everyone out of.
A less than 5 minute job estimate turned into an all day affair. In your ticket example just a count, or in a context of actual verses estimated time, this would appear what a slacker.
Only a few looking at this ticket understood how little reflection it related to the actual task. Only my manager and the security officer understood the value of by my doing it, a hole had been closed as their were about 40 or 50 other people with SME access that could grant themselves the ability to update anything in production. This was the true measure of value of the task done - the ticket only noted I had done a ‘simple’ task and took way too long.
One thing rarely documented in these ticket systems - time you spend on automating something that business does manually, and how much savings add up over time. You may spend 4 hours once creating something that if they only spend 10 minutes a day on, shows where the true value lies.
As you well know from experience, numbers are pretty meaningless without enough context.
Lordy, can I ever identify with that. You've hit the nail square on the head.
There have been many times where the extreme has happened to me and I'm sure that it has happened to every DBA and Developer out there.
We're either presented with a new problem to solve where the description or flow chart has several "Insert Miracle Here" requirements or some old problem consisting of a 1200 line stored procedure written in a totally non-maintainable fashion and told that it needs to be fixed and it's on something that you've never seen before.
In the end, I turn in a proc or two with very few lines of code and they raise an eyebrow and say "It took you 3 days to write this small amount of code"? YES IT DID! Between the constant occurrences of drive-by shootings, doing my normal job of things like "Ok... where's the blocking alerts coming from and why", and researching the requirements/reading through 1200 lines of undocumented code, etc, etc, and writing the code in a maintainable fashion so the next poor slob can fix something in an hour, and making it so the code won't fail test, QA, UAT, etc, etc, YES IT DID!
Heh... and I'm still asked "What is it you do"? That's when I show them my favorite shirt...
Hmmm... maybe I should change the shirt to this one...
Except for the tats, that guy even looks a bit like me 😀
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions -
When I retired, the retired HR guy came to see the group of us. He described what I did to the new HR person.
’He’s the guy you come to with a problem. You describe what you are looking for, and he asks questions. When he leaves, no one was sure there is a solution. Then a few days later, he calls you to come look and see if what he came up with will work. When you look at it, it’s everything you wanted, plus a couple extra things would have been on your wish list but were afraid to mention.’
Kind describes your shirt. Although my users knew they had a problem and needed something. I just had to get them to describe it well enough to help them.
You in turn nailed the simple solution once you did research. Many times we get tasked with something we have to learn first, then solve. And many times in new areas not even related to our core skills.
-
Now THAT was an "HR guy" that understood!
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions -
The most annoying thing I find about the time sheet thing is at my workplace they don't have many projects. Just "maintenance," "admin" (for PTO / meetings / training, anything not directly related to work), and the occasional other major project. Yet not only am I expected to fill it out every week but I'm also expected to submit it before Friday is over and it's a Monday - Sunday timesheet. I always work weekends but I never know until the weekend if I'm working 5 minutes to make sure everything is okay or if I'm working full days because something unexpected came up.
It's the epitomy of the useless timesheet. At one point they even told us they didn't want us to record more than 40 hours a week (which I ignored).
-
I had someone from HR make me remove the shirt pictured above. It was at a company picnic. I guess I offended some people.
When I headed up a group of DBA's, all of our revenue was 100% dependent upon the timesheets. We were essentially contractors, and all of our work was time and material. The system "bugged" me. The managers reviewed the DBA's time each week, and there were kudos to the highest billed hours and frowns on the less than billed ours.
I revamped the system, and did some simple analysis of the entries. I wanted to see if similar tasks were being consistently billed to the clients. As an example, I wanted to see if all tasks to install SQL took about the same amount of time. We were in the process of reorganizing the manner in which we worked, and needed to be able to allocate resources differently.
What I DID find was fraud. The DBA's that consistently had the highest billable hours were making things up. I fired one person almost immediately, and they thought that this was the way you were supposed to do things.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/ -
My neighbor worked from home for awhile. He had to run a program that ran extensive calculations. I looked at his machine, noting it was a a few years old, suffering from slow disk and not much ram. I suggested he make a case to have them get him a CAD work station, easily justified in the increase in productivity.
Nope - he was fine using the calculation time to jump on the rider and mow several acres.
Company dropped the high end product line he produced, and him in the process. He thought he was invaluable, I thought more along the lines of a self inflicted wound. I can imagine he got calls that rolled to voice mail, and when returning the call hours later, said he was running calculations. Then the head office, knowing this only means your computer is working, starts thinking so you couldn’t pick up your phone …..
-
I don't mind time tracking for clients, but I hate it internally. I used to do this for a employer and tried to enter time according to major projects. Then, a couple of months after I started they wanted us to predict where we'd spend time the next two weeks. Since I did what a lot of you do as DBAs, responding to tickets and queries, I started to just use two weeks of the same codes, both for actual time and predicted time.
My boss noticed after 3 or 4 months and asked me. I told her I didn't feel it was a good use of time. Her boss also noticed and knew I was valuable enough to not be worth losing. They just accepted my "time tracking" from then on.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Viewing 15 posts - 65,806 through 65,820 (of 66,000 total)
You must be logged in to reply to this topic. Login to reply