What’s the overhead for a page checksum? I’ve seen various numbers thrown out, but I thought that Paul Randal had written at one point that it was around 1-2%. I can’t find a reference, but in this post, Paul doesn’t dispute that.
In any case, it’s better to find corruption than save 2% of your CPU. I’d argue the same thing for performance monitoring, which I’ve often seen referenced at 5% of the load. If you don’t have 5% overhead, you have other problems.
You need to measure things.
I’ve been involved in quite a few debates about job hunting and job interviews recently with a number of people that are considering looking for other work. I’ve also seen some intense debates on the subject of how to look for a job, market yourself, present yourself in an interview and more. It’s on area that seems to always strike a chord with many people out there.
This Friday I wanted to step back, and do a little market research of my own. Perhaps also helping some of you at the same time that might be considering changing jobs, or maybe even preparing for an annual review later this year.
Having information is important to not only making a good decision, but also a good negotiation in this area. With that in mind, I wanted to ask this question:
You can disclose your location and market price if you want, but I’m really wondering if you have a good idea of what your job should pay, and how you know that. Have you looked at other jobs or talked to colleagues doing the same work? Is a salary survey available for your area and industry? The market price for our skills may or may not be the same as our salary. Ideally it would be, but we might make more or less for various reasons.
If you have any information to share, I’m sure others would be interested, especially if there are links or data you can share.
Steve Jones
Work is hard. It’s frustrating trying to work within the constraints of your job, your projects, and with the people around you. We all seem to have conflicting needs and desires, and often clash over when, why, and how we should meet our goals. Work is also long, a place and task at which many of us spend a large percentage of our waking hours.
When we feel bound by rules, or limited by restrictions, it can be even more frustrating. I know many people that reconsider their choice of an IT career, not because of the work or even workload, but more because of the way they are treated. It’s especially true for many companies that place heavy restrictions on equipment. I tried to negotiate for two monitors for one job in the interview, but the manager said he’d never get approval from his boss.
My employer, Red Gate Software, takes a different approach, as shown by Simon Cooper in this blog. Need another monitor, just ask. Want a faster, or bigger, drive, just ask. Need a book, just buy it. Really, if you want something reasonable to help you do your job, it’s allowed. I know people in other companies that not only can’t get approval for buying a book for work, they get chastised for even asking.
I know that costs are hard to contain, and there likely will be people that abuse their privileges, but that’s easy to handle: revoke privileges for that person. There’s no need to do that for everyone, despite what most HR departments think. Telecommuting options ought to be the same way. Let employees try it and if they can’t get work done, remove the privilege for that person only.
If more managers behaved reasonably, and allowed their employees more freedom, they might be surprised just how much more work, at a higher level of quality, would get finished.
Steve Jones
It seems that the vast majority of people that I talk to in the technology field have trouble getting training funded. It doesn’t matter if it’s a conference or a class, it seems that companies don’t want to spend money training people. I find that many companies use one of two excuses. Either they say employees should already know how to do their jobs, or they worry that training will empower employees to go find other jobs.
Or in other words: I Like My IT Budget Tight and My Developers Stupid.
That’s the title of an article and it’s a good question for managers that don’t want to pay for training. The article talks about the choice between being “concerned that if people know what they’re doing, they’ll leave. And if they don’t know what they’re doing, they’ll stay”. It’s actually not a bad argument to make with your boss, though I might reword it in a different way.
There are a certain percentage of people that will not be happy at your company. Perhaps the job is not a good cultural fit, the employees might be ambitious and looking for new challenges, or maybe they are always looking for someone to pay them more. There’s nothing you can do about those people, and withholding training isn’t going to keep them around.
There are also a percentage of people that are unmotivated, uninterested in their jobs, maybe marking time, or just wanting to get through each day and go on with the rest of their lives. Training can be wasted on this group as they aren’t likely to use the skills they’ve learned at work. It’s possible they might not even learn any skills, just sitting in class as an excuse to get out of work. You can’t do anything about this group either.
However I think that both of those groups are the minorities at most jobs. I believe most technology people are interested in what they do, like to learn new skills, and more importantly, like to solve problems. They will take advantage of training and look to use their new skills, especially if you challenge them to do so. And most of these people aren’t looking to leave your company. They might stay forever, but the vast majority of people want to keep their jobs and accomplish something.
And if most people don’t want to stay, perhaps you ought to examine your company’s culture. Maybe it’s the problem. Withholding training isn’t the answer, and you can’t expect people to know, or learn, everything they may need on their own. That’s a recipe to ensure your company isn’t as competitive as it could be.
Steve Jones
Voice of the DBA 