October 4, 2011 at 12:11 pm
A good manager will serve his/her department well by fostering this within their group. By actually giving their developers/DBA's the time and not just suggesting it, but actually setting it aside for them. Realistically, this is easier for larger organizations with greater depth and overlap of talent.
There has been a lot of great suggestions here. Technet or MSDN subscriptions, managing employees, etc...
I want to put my two cents in here on the management part. I work for a mid-cap firm with 4k employees. The problem we have is that even in a department of 15 people, we don't have the depth compared to the number of systems. What you find is that you have to manage both the time allocated to your employees and the type of employees. We have our curious, ingenious types that you have to give space to figure it out and we have our curmudgeons, which have value because they are happy with the daily grunt work. The key is to manage this disparate group without a class feeling that the other is treated better.
That is the trick.
Also, I can't stress enough about getting a general knowledge on as many technologies as possible. You don't have to master it, but the BS detection capability will be invaluable. Remember, unless it is proven otherwise, it is not the <fill in blank> fault. 😛
The first line of code starts with coffee. The last line ends with alcohol.
October 5, 2011 at 10:26 am
Question Guy (10/4/2011)
When you die, the last thing you will say is, "I should have spent more time at the office." I used to spend a lot of time reading DBA books and programming. Then I realized I only used about 2-5% of what I actually read.
I'll agree with you to this point and the general philosophy. The new toys are what keeps me interested in my career but that's a personal thing.
However...
Clustering, partitioning, service broker fall into the area of things I read but probably will never use as a DBA. For me there is no reason to learn it, as I won't use it anytime soon. If I would implement such things, there would be no one but me to support it.
If I used the basics to moderate stuff, at least the system admins could help out when I am unavailable if I walk them through it.
So far so good, if you never want to tackle larger systems. You need to know this stuff before someone who does will let you loose in their systems if they required that level of tuning.
In my opinion, a DBA should know how to do .NET programming instead of learning advanced SQL stuff that you would need a instruction list to follow anyways, as the combination of SQL and .NET skills is very valuable. If you are going to learn advanced stuff, hopefully there is a real purpose for it. Otherwise, you are just making other people's wants your own.
Here we definately disagree. My learning .NET merely dilutes me. In general, you don't need a DBA if the guy coding .NET can toss his DB together. The hardware can handle most systems at that level and they're just going to ORM/Entity Framework it anyway. A couple of million rows is really not enough to hire a high-end DBA/SQL Dev for... most programmers get basic data theory.
We're not in it for the DB2 million row systems anymore. Sure, that's where we cut our teeth, but eventually we learn to run. You've chosen to be more rounded, which is good. There's plenty of companies out there who can use someone with basic to middle level abilities who can fill multiple roles. That kind of development doesn't require a full time SQL Dude. You're right in that it can bring value to certain companies.
You'd also never be allowed anywhere near one of my servers without everything you touched being code reviewed.
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
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply