May 17, 2011 at 11:17 am
I decided to lower my total throughput I allow for work. I've felt better ever since.
amen to that!!
May 17, 2011 at 11:21 am
dma-669038 (5/17/2011)
I decided to lower my total throughput I allow for work. I've felt better ever since.
amen to that!!
Just in case some of you wonder. I alot 10 hours / day door to door to my house.
So if I leave at 5:30 am (yes later and I can't the worst of the gridlock) I'm back by 3:30 pm. That leaves 6 hours / day after 8 hours sleep to do something else... pretty nice harmony imho.
May 17, 2011 at 11:25 am
I take care of what i am assigned and set clear expectations on time, that will not push me over the edge. Sometimes i get done sooner, sometimes it takes a bit more. Production emergencies are rare and different. But if a job normally takes 2 hours am not going to say it takes half the time and bust myself trying to do it, sometimes that is one way to make them extra happy, but i take care of my health/stress level/free time and do it at the normal time it is expected. And learnt the hard way not to do my boss's job for him (in other words unassigned stuff is for him to pick up and assign, not me). And always deliver quality, that is all.
May 17, 2011 at 11:27 am
I'm kind of a catch-22 when it comes to this, because I can get pretty dang paranoid about my production systems. Depends on the system, though. Some I just cowboy up and see what happens.
I work hard developing new designs/techniques. I work long, though, during implementation, going very slowly and making sure each piece goes in as gently as possible.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
May 17, 2011 at 11:46 am
Eric M Russell (5/17/2011)
Would "working harder" within the context of programming would mean taking fewer breaks?
I think that's working longer.
Harder means doing things that are more challenging and more risky, harder to understand/build/explain/accomplish. Not related to time.
May 17, 2011 at 12:32 pm
I think it is a combination of the two types. I don't know about calling it hard and long. When I was young a supervisor taught me to work smarter and not harder. In other words, no need to work long and inefficiently. Find a more efficient way of doing it. If, as a DBA, it means working focused for 8 hrs to turn a manual process into an automated process that saves me many hours in the future - then do it.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 17, 2011 at 7:05 pm
Working long and working hard are not mutually exclusive. Indeed, in the current employment climate they are mutually inclusive. Further, for the past decade job growth has been negative, salaries have been stagnant and inflation has caused an eroding loss of income. Mix that together and everyone is working harder and longer than ever.
But one day the Great Recession will be over, growth will return, the Boomers will disappear which will punch a gaping hole in the work force, the global labor arbitrage game will provide ever-diminishing returns (thanks to a declining dollar and rising wages overseas), and the upcoming generation will have skills leverage. THEN working long and hard will be replaced with working smart. Which is how it should have been all along!
James Stover, McDBA
May 18, 2011 at 10:14 am
Ninja's_RGR'us (5/17/2011)
Why are those the only 2 options?Why can't we have fun getting done what needs to be done and go home after that? No need for long NOR hard.
Because sometimes they're necessary (one or both).
We discovered a code problem yesterday that crashes our website whenever X, Y, and Z circumstances come up at the same time. It's not frequent, but as more people hit our web page, it's coming up more often.
However, the problem requires significant reworking of the inner guts of major pieces of the code. It's going to require hard work to fix, no matter how it's done.
We thus now have two options: Leave it crashing periodically (not good) or do hard work. Possibly hard, long work, to get it done in the desired timeframe.
That's just the way it is sometimes.
It's a tough universe. There are a million factors out there that are death-threats to our fragile bodies. There are another million that are death-threats to our fragile businesses and enterprises (and nations and families and what-have-you). The tough and the smart survive, and sometimes they drag others along with them, but it takes hard work on someone's part every time. Some people do hard work, some people rely on others to do it for them. Either way, the choices are: The hard work gets done, or the business/person/nation/group/species/whatever dies.
Does that sound calloused? It might.
But just try breathing at 25,000 feet positive altitude, or 6 inches below the surface of the sea, and you'll quickly find out how fragile we are. We can die of exposure to a temperature range that doesn't even cover the span of liquid water. It takes very little by way of exposure to extremely common chemicals to kill a person. And it takes hard work to avoid these things. Just ask the engineers, et al, who design, build, and operate modern aircraft (altitude, gas mix, temperature, radiation), or who build houses (exposure, breathable air, pottable water, wind, earthquakes, etc.).
Someone does the hard work in all of those cases. Some people are along for the ride and let the people who do hard work carry their load for them. Some people do the hard work for themselves and let others fall by the roadside. Some carry the load for themselves and multitudes of others. That's just the way the physical universe works.
Just by being alive, you're taking huge risks with every heartbeat and every breath, ever drink of water and every bite of food. Again, some try to avoid risks. But really, the only way to be completely risk-free is to be dead, and even then there are indignities that can be suffered, you just won't care about them any more.
Simple as that.
Advice? Decide whether you care about any of that or not. If you do care about it, figure out what to do and then do it. If you don't, then you don't. But if you don't care whether someone else might be having to cary your share of the load, don't be surprised if they don't care whether your share gets carried or not either. It's always about options.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 18, 2011 at 10:24 am
roger.plowman (5/17/2011)
I think the point about being risk-averse is absolutely true--and gets the cart before the horse.Think about it. Would *you* want somebody who enjoyed high-stakes risk taking being a DBA? Really? (laughing)
Isn't the point of being a DBA keeping the data safe, the servers available, and the performance reasonable? All these things benefit heavily from a conservative, risk-averse approach.
Now if you're talking about espionage or war-fighting, there you can't be quite as risk-averse, because that doesn't get the job done.
But when your job involves *guarding*, well if you were picking the person, which would you choose? Someone who minimizes risk or someone who enjoys it?
How about if the choice comes down to someone who is very conservative and risk averse, to the point of complete decision paralysis when the chips are down?
Scenario: Your servers are about to go down, and you need them up, you have a identified a SPID that's causing the problem, but you don't know what it's doing. Do you (a) go risk-averse and freeze up, making no decision at all, (b) leave the SPID alone and hope the servers stay up regardless, (c) kill the SPID and hope it wasn't anything business critical, but be reasonably sure that it would die in a server crash anyway?
Also, all risk is relative. A trained, experienced DBA, getting second opinions on a site like SSC, can do things to a server without any real risk at all, where a code-monkey doing the same tasks might be taking huge risks. The actual risks are the same, but the probability of negative consequences are much reduced.
However, it takes hard work to become a trained, experienced, professional DBA, to build and maintain professional connections to other DBAs who can help with second opinions on options. Hard work, by the definition given here, involves risks. So, your "risk averse DBA" is actually engaging in the daily risks of education, skill-honing, networking with others, social interactions, proof-of-concept work, et al. He's just a "professional driver on a closed course". The risks are still real, but the mitigating factors are too.
Goes straight to the definition of "hard work" and the definition of "risk". For me, modeling data into at least 3NF isn't hard work. I do it in my sleep (yes, I do literally dream about databases from time to time). For someone else, data modeling and normal forms might be very hard work indeed, and the risk of failure to do it right might be very, very high.
It's all subjective.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 9 posts - 31 through 38 (of 38 total)
You must be logged in to reply to this topic. Login to reply