Delayed gratification or not?

Question

Delayed gratification or not?

Viewing 4 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 1

phonetictalk - Monday, December 11, 2017 12:09 PM
Delayed gratification doesn't work in scenarios where something is finite (such as time, money, attention, resources).
E.g. if I have a plate of treats at my desk, I'll spread them out over a number of days. Each time I see the treats, I ask myself, "Do I really need it now, or might I want it more later?". So the treats last. I don't lose out because there is no competition for the treats. However, when there's a supply of treats in the shared breakroom, I'll grab them while they're there. If I don't, I might easily miss out. It doesn't matter if I really need the treat now, because I know I want it at some point, and it's here now, so I'll grab it now. The result: I often eat a lot more treats over a lot smaller of a time period when the treats are shared, than when the treats are just mine.
I wonder if the same applies when departments get IT's attention on something. They don't *need* something, but they know if they don't ask for it now, they might not ever get it, so they end up using more IT resources up-front on a project (asking for features they don't end up using, for example) than they would have done if they felt IT wasn't such a scarce resource. Almost a vicious circle. The more IT is seen as scarce, the more people ask for things they don't strictly need, making IT ever more scarce for everyone else.

I avoid that round robin of defeat by making sure that when I ask for something it 1) gives them enough time to plan for it and 2) provide metrics and justification for why I think it's needed long before I need it so that people smarter than me have the time to possibly come up with something better and 3) ask for only what is needed. Once you get into that habit, I've found that the infrastructure folks start doing the same as me and I sometimes get things that I was going to ask for before I ask for them. It's the whole principle and culture behind what people are now calling "DevOps"... it's really known as "Prior Proper Planning" and "Effective Communication". That can actually be boiled down to a single concept called "Team Work" and I find that departments within many companies don't understand the concept that they all work for the same company. 😉

--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)

MMartin1 One Orange Chip Points: 27799 More actions · Answer 2

Jeff Moden - Monday, December 11, 2017 6:25 AM
"Delayed Gratification" and "Patience" have a whole lot to do with each other and I've benefitted from both in many ways, especially on the job.
We recently had a huge problem where a 32 CPU/256GB RAM box running the Enterprise Edition of SQL Server saturated at about 85% average CPU. I was working on determining what the root cause was (there were a ton of symptoms) but, in the mean time, they said they were going to throw hardware at it. I was going to tell them that it wouldn't help and could make matters worse (which it did) but I remember telling them that before (they wanted to be sure they had capacity, is the short story) and that they needed to fix some code. They didn't fix the code. So I did NOT tell them again that hardware wasn't going to fix it this time. I didn't set them up for failure but I did give them the "opportunity to fail" instead of fighting them this time.
There were multiple benefits to doing so...
1. They stopped asking me what the fix was while the hardware was being ordered and shipped. That gave me 3 days to do a really deep dive (it was a very strange problem and turned out to be Entity Framework related connections that had MARS enabled).
2. It gave me the opportunity to prove to them that when I said hardware wasn't the fix for what they perceived to be scalability problems and they did so by their own hand making the point even more convincing.
3. I now have a 48 CPU/384 GB box that can handle just about anything provided that they write the right kind of code.
4. They now know that I'm right about hardware and listen much more intently when I propose fixes to code and have made such fix recommendations an action priority.
5. It also helped them change their minds a bit about changing from on-premise hardware to the cloud, which I don't actually want to do for multiple reasons. The cloud isn't necessarily a bad idea to me... it's just a bad idea for the nature of our business.
As a DBA, one of my jobs is to help other people with their jobs but and as the saying goes... "A man forced against his will is of the same opinion still". I'm frequently involved with new things/proposals and there have been several times where I tell them "If you do it that way, here are the problems that will occur and how to avoid them" and there have been several times where someone is passionate about the changes or new thing they want to make. I've learned that when it gets to a certain point, more time will be spent arguing about it than (provided it will not cause harm to any data or the company) simply giving them the "opportunity to fail". Again, I'm not saying that I set them up for failure. I'll even help them with what they want to do as best as I honestly can because, remembering that "One good experiment is worth a thousand expert opinions", sometimes people need to fail to realize that someone else is right (and, yes... I include myself in that even when I think I'm right).
It's also a hard lesson for some people to learn. They want to change (supposedly improve) something or do something new a different way and it looks like the same thing they tried previously and failed at, maybe a year or two ago. I remind them of how it didn't work before. The occasional (extremely rare lately) response is "Yeah, but this is different". The "opportunity to fail" begins again but, no matter what happens, we're all going to learn from it as a team and to the benefit of the company we all work for. 😉

The thing about failure is that sometimes people dont want to admit their mistakes. So they rationalise why things did not work out the first time and convince themselves with no good reason that this time "it will be different." It comes with style of management as well. If people leave a manipulating boss, I can see the boss thinking that they were "bad" employees to begin with (and let the scapegoating begin).
However I think if people feel they will not be judged for being wrong (since we all make mistakes) they are more likely to be open to learning the lesson at hand.

----------------------------------------------------

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 3

MMartin1 - Tuesday, January 23, 2018 10:52 PM
Jeff Moden - Monday, December 11, 2017 6:25 AM
"Delayed Gratification" and "Patience" have a whole lot to do with each other and I've benefitted from both in many ways, especially on the job.
We recently had a huge problem where a 32 CPU/256GB RAM box running the Enterprise Edition of SQL Server saturated at about 85% average CPU. I was working on determining what the root cause was (there were a ton of symptoms) but, in the mean time, they said they were going to throw hardware at it. I was going to tell them that it wouldn't help and could make matters worse (which it did) but I remember telling them that before (they wanted to be sure they had capacity, is the short story) and that they needed to fix some code. They didn't fix the code. So I did NOT tell them again that hardware wasn't going to fix it this time. I didn't set them up for failure but I did give them the "opportunity to fail" instead of fighting them this time.
There were multiple benefits to doing so...
1. They stopped asking me what the fix was while the hardware was being ordered and shipped. That gave me 3 days to do a really deep dive (it was a very strange problem and turned out to be Entity Framework related connections that had MARS enabled).
2. It gave me the opportunity to prove to them that when I said hardware wasn't the fix for what they perceived to be scalability problems and they did so by their own hand making the point even more convincing.
3. I now have a 48 CPU/384 GB box that can handle just about anything provided that they write the right kind of code.
4. They now know that I'm right about hardware and listen much more intently when I propose fixes to code and have made such fix recommendations an action priority.
5. It also helped them change their minds a bit about changing from on-premise hardware to the cloud, which I don't actually want to do for multiple reasons. The cloud isn't necessarily a bad idea to me... it's just a bad idea for the nature of our business.
As a DBA, one of my jobs is to help other people with their jobs but and as the saying goes... "A man forced against his will is of the same opinion still". I'm frequently involved with new things/proposals and there have been several times where I tell them "If you do it that way, here are the problems that will occur and how to avoid them" and there have been several times where someone is passionate about the changes or new thing they want to make. I've learned that when it gets to a certain point, more time will be spent arguing about it than (provided it will not cause harm to any data or the company) simply giving them the "opportunity to fail". Again, I'm not saying that I set them up for failure. I'll even help them with what they want to do as best as I honestly can because, remembering that "One good experiment is worth a thousand expert opinions", sometimes people need to fail to realize that someone else is right (and, yes... I include myself in that even when I think I'm right).
It's also a hard lesson for some people to learn. They want to change (supposedly improve) something or do something new a different way and it looks like the same thing they tried previously and failed at, maybe a year or two ago. I remind them of how it didn't work before. The occasional (extremely rare lately) response is "Yeah, but this is different". The "opportunity to fail" begins again but, no matter what happens, we're all going to learn from it as a team and to the benefit of the company we all work for. 😉
The thing about failure is that sometimes people dont want to admit their mistakes. So they rationalise why things did not work out the first time and convince themselves with no good reason that this time "it will be different." It comes with style of management as well. If people leave a manipulating boss, I can see the boss thinking that they were "bad" employees to begin with (and let the scapegoating begin).
However I think if people feel they will not be judged for being wrong (since we all make mistakes) they are more likely to be open to learning the lesson at hand.

Correct... especially on the very last sentence. The only way to inspire people to have the extremely desirable attribute of "Absolute Honesty" is to do like Horta on the original Star Trek series did and carve into stone "No Kill I". 😉

--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)

MMartin1 One Orange Chip Points: 27799 More actions · Answer 4

Jeff Moden - Wednesday, January 24, 2018 9:08 AM
MMartin1 - Tuesday, January 23, 2018 10:52 PM
Jeff Moden - Monday, December 11, 2017 6:25 AM
"Delayed Gratification" and "Patience" have a whole lot to do with each other and I've benefitted from both in many ways, especially on the job.
We recently had a huge problem where a 32 CPU/256GB RAM box running the Enterprise Edition of SQL Server saturated at about 85% average CPU. I was working on determining what the root cause was (there were a ton of symptoms) but, in the mean time, they said they were going to throw hardware at it. I was going to tell them that it wouldn't help and could make matters worse (which it did) but I remember telling them that before (they wanted to be sure they had capacity, is the short story) and that they needed to fix some code. They didn't fix the code. So I did NOT tell them again that hardware wasn't going to fix it this time. I didn't set them up for failure but I did give them the "opportunity to fail" instead of fighting them this time.
There were multiple benefits to doing so...
1. They stopped asking me what the fix was while the hardware was being ordered and shipped. That gave me 3 days to do a really deep dive (it was a very strange problem and turned out to be Entity Framework related connections that had MARS enabled).
2. It gave me the opportunity to prove to them that when I said hardware wasn't the fix for what they perceived to be scalability problems and they did so by their own hand making the point even more convincing.
3. I now have a 48 CPU/384 GB box that can handle just about anything provided that they write the right kind of code.
4. They now know that I'm right about hardware and listen much more intently when I propose fixes to code and have made such fix recommendations an action priority.
5. It also helped them change their minds a bit about changing from on-premise hardware to the cloud, which I don't actually want to do for multiple reasons. The cloud isn't necessarily a bad idea to me... it's just a bad idea for the nature of our business.
As a DBA, one of my jobs is to help other people with their jobs but and as the saying goes... "A man forced against his will is of the same opinion still". I'm frequently involved with new things/proposals and there have been several times where I tell them "If you do it that way, here are the problems that will occur and how to avoid them" and there have been several times where someone is passionate about the changes or new thing they want to make. I've learned that when it gets to a certain point, more time will be spent arguing about it than (provided it will not cause harm to any data or the company) simply giving them the "opportunity to fail". Again, I'm not saying that I set them up for failure. I'll even help them with what they want to do as best as I honestly can because, remembering that "One good experiment is worth a thousand expert opinions", sometimes people need to fail to realize that someone else is right (and, yes... I include myself in that even when I think I'm right).
It's also a hard lesson for some people to learn. They want to change (supposedly improve) something or do something new a different way and it looks like the same thing they tried previously and failed at, maybe a year or two ago. I remind them of how it didn't work before. The occasional (extremely rare lately) response is "Yeah, but this is different". The "opportunity to fail" begins again but, no matter what happens, we're all going to learn from it as a team and to the benefit of the company we all work for. 😉
The thing about failure is that sometimes people dont want to admit their mistakes. So they rationalise why things did not work out the first time and convince themselves with no good reason that this time "it will be different." It comes with style of management as well. If people leave a manipulating boss, I can see the boss thinking that they were "bad" employees to begin with (and let the scapegoating begin).
However I think if people feel they will not be judged for being wrong (since we all make mistakes) they are more likely to be open to learning the lesson at hand.
Correct... especially on the very last sentence. The only way to inspire people to have the extremely desirable attribute of "Absolute Honesty" is to do like Horta on the original Star Trek series did and carve into stone "No Kill I". 😉

Brilliant!

----------------------------------------------------