February 11, 2015 at 8:07 pm
Comments posted to this topic are about the item Starting a New Job
February 12, 2015 at 12:38 am
The suggestions in the forum thread highlighted in the editorial are good (or better) but are suitably targeted at starting the functional task i.e. being a DBA. Of course Gail's suggestion of starting with the backups is excellent advice as one can see by how so many luminaries concurred.
I think Jeff hit the nail on the head (whether he was jesting or not - I will assume that it was serious but with tongue firmly in cheek) by suggesting finding the coffee machine and the bathroom (as those in the USA might refer to it as).
As I work freelance I have had more roles than most people who are contracted as employees because of the differing style of engagement. I think that gives me more opportunities for insight that some who haven't been the noob at a place as often. Other essentials are finding out how and when you can get into the facilities bearing in mind that there may be different protocols for different times of the day or days of the week. Also try and find out locally accepted practices. For example even when you are supposed to do so many hours a day some places allow for some flexibility for, say, a dentist appointment and you are allowed to make time up another day whilst at others you are not. Getting such things wrong can cause unnecessary friction which is easily avoided. Another example is Internet usage as accepted practices vary widely here and again often differ in practice from the written rules. Be wary, be cautious and avoid unnecessary disagreements.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 12, 2015 at 7:43 am
I've been at my current job for 16 years. I had a job earlier in my career for 15 years. Haven't really roamed around all that much.
February 12, 2015 at 9:24 am
Assuming there is only one DBA, and you're now it (perhaps the last one left unexpectedly), then taking an inventory of your IT environment is important, but perhaps not the first thing you'll be doing. First is all the HR stuff; the paperwork, the security clearance, who is who, what is what, where you fit in, and the scope of your responsibility.
Alas, you can't run sp_Blitz on the business or the people you'll be working with. :unsure:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 12, 2015 at 9:45 am
I have had two IT jobs in the last 44 years. This one is a month shy of 30 years, with no end in sight. I have no idea at all how it would be to start a new job. It has been a long time. 🙂
Not all gray hairs are Dinosaurs!
February 12, 2015 at 9:47 am
Really pleased to see that there is some longevity in roles. Clearly not for me but the combination is best for businesses and individuals alike.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 12, 2015 at 10:44 am
Gosh, I'd be surprised if any DBA or database developer did NOT have a folder full of T-SQL scripts they carried from job to job. Common metadata queries, a few "frequent problems" scripts and functions, some sample scripts for tasks I don't do often... I've tended towards smaller shops and more development-oriented roles, which has informed which scripts I find valuable, but we all probably have a "toolbox" folder.
I've averaged around seven years at most jobs, which I imagine is pretty normal.
February 12, 2015 at 11:29 am
Things I learned to do when I’m new on the job from a non-technical perspective:
•Shut up, listen, and try to ascertain the culture. Paying attention to what is considered humorous can give you some insight.
•Be mindful of those that are deeply religious or politically oriented
•Ask tactful questions (avoid starting them with the word “Why”).
•Never offer unsolicited advice unless it is clear you can spare the listener some unnecessary pain.
February 12, 2015 at 2:25 pm
Brian J. Parker (2/12/2015)
Gosh, I'd be surprised if any DBA or database developer did NOT have a folder full of T-SQL scripts they carried from job to job. Common metadata queries, a few "frequent problems" scripts and functions, some sample scripts for tasks I don't do often... I've tended towards smaller shops and more development-oriented roles, which has informed which scripts I find valuable, but we all probably have a "toolbox" folder.I've averaged around seven years at most jobs, which I imagine is pretty normal.
I've seen many people start jobs and not have much formally ready. They know what they want to look at, but don't have a series of queries/scripts that they have ready.
February 12, 2015 at 2:30 pm
Steve Jones - SSC Editor (2/12/2015)
Brian J. Parker (2/12/2015)
Gosh, I'd be surprised if any DBA or database developer did NOT have a folder full of T-SQL scripts they carried from job to job. Common metadata queries, a few "frequent problems" scripts and functions, some sample scripts for tasks I don't do often... I've tended towards smaller shops and more development-oriented roles, which has informed which scripts I find valuable, but we all probably have a "toolbox" folder.I've averaged around seven years at most jobs, which I imagine is pretty normal.
I've seen many people start jobs and not have much formally ready. They know what they want to look at, but don't have a series of queries/scripts that they have ready.
Interesting. I hope your article inspires them to think "I might want this in the future" and start saving a few good scripts to carry around. So maybe they start without them, but, they won't next time!
February 12, 2015 at 2:46 pm
Brian J. Parker (2/12/2015)
Steve Jones - SSC Editor (2/12/2015)
Brian J. Parker (2/12/2015)
Gosh, I'd be surprised if any DBA or database developer did NOT have a folder full of T-SQL scripts they carried from job to job. Common metadata queries, a few "frequent problems" scripts and functions, some sample scripts for tasks I don't do often... I've tended towards smaller shops and more development-oriented roles, which has informed which scripts I find valuable, but we all probably have a "toolbox" folder.I've averaged around seven years at most jobs, which I imagine is pretty normal.
I've seen many people start jobs and not have much formally ready. They know what they want to look at, but don't have a series of queries/scripts that they have ready.
Interesting. I hope your article inspires them to think "I might want this in the future" and start saving a few good scripts to carry around. So maybe they start without them, but, they won't next time!
If only there were a website where folks like us could go to get ready made DBA scripts accompanied by insightful articles describing how to use them ... :rolleyes:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 13, 2015 at 12:36 am
Brian J. Parker (2/12/2015)
Steve Jones - SSC Editor (2/12/2015)
Brian J. Parker (2/12/2015)
Gosh, I'd be surprised if any DBA or database developer did NOT have a folder full of T-SQL scripts they carried from job to job. Common metadata queries, a few "frequent problems" scripts and functions, some sample scripts for tasks I don't do often... I've tended towards smaller shops and more development-oriented roles, which has informed which scripts I find valuable, but we all probably have a "toolbox" folder.I've averaged around seven years at most jobs, which I imagine is pretty normal.
I've seen many people start jobs and not have much formally ready. They know what they want to look at, but don't have a series of queries/scripts that they have ready.
Interesting. I hope your article inspires them to think "I might want this in the future" and start saving a few good scripts to carry around. So maybe they start without them, but, they won't next time!
This all brings up the question of copyright of work. If done on company time then they will claim it, however, it is a generic script then there is the view that no one can claim IPR.
Most companies I have known would frown upon such a practice and sometimes it is not the legal position but reputation that will make or break you.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 13, 2015 at 7:12 am
Gary Varga (2/13/2015)
Brian J. Parker (2/12/2015)
Steve Jones - SSC Editor (2/12/2015)
Brian J. Parker (2/12/2015)
Gosh, I'd be surprised if any DBA or database developer did NOT have a folder full of T-SQL scripts they carried from job to job. Common metadata queries, a few "frequent problems" scripts and functions, some sample scripts for tasks I don't do often... I've tended towards smaller shops and more development-oriented roles, which has informed which scripts I find valuable, but we all probably have a "toolbox" folder.I've averaged around seven years at most jobs, which I imagine is pretty normal.
I've seen many people start jobs and not have much formally ready. They know what they want to look at, but don't have a series of queries/scripts that they have ready.
Interesting. I hope your article inspires them to think "I might want this in the future" and start saving a few good scripts to carry around. So maybe they start without them, but, they won't next time!
This all brings up the question of copyright of work. If done on company time then they will claim it, however, it is a generic script then there is the view that no one can claim IPR.
Most companies I have known would frown upon such a practice and sometimes it is not the legal position but reputation that will make or break you.
The vast majority of T-SQL scripts that a DBA writes on the job are derivative (Google, copy, paste, modify). It's not so much original work as it is shortcuts for performing generic sysadmin tasks. On the other hand, SQL scripts that do something like calculating insurance risk scores; that's different because it's proprietary to the way the company does business.
But if I somehow lost access to every sql script I ever wrote in the past, all I really need for performing day to day tasks for a DBA position could be found on SQLServerCentral. Within a few months I would evolve a new personal collection that's probably more up to date and better than what I may have written five years ago.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 13, 2015 at 8:11 am
This all brings up the question of copyright of work. If done on company time then they will claim it, however, it is a generic script then there is the view that no one can claim IPR.
Most companies I have known would frown upon such a practice and sometimes it is not the legal position but reputation that will make or break you.
An academically interesting question, but in the real world, I've never had a problem. Not that I even ask, honestly. I've never worked on a military base or anything, so it's pretty easy to copy a handful of files to a USB stick or cloud drive. (Especially now that I expect to carry a work laptop home for the rest of my career.) I've also always left on very good terms with my employers. So what you say is worth thinking about, but I imagine most of us don't need to worry.
From an ethical (rather than legal) standpoint, I also usually leave copies of these files behind, and I've never gone on to work for a competitor of a previous employer.
And yes, of course, I could just re-collect a lot of stuff from sites like this one, but it's really nice to have familiarity with all my scripts and where they are, besides the little tweaks to suit my preferences. Perhaps I am fussier than most.
February 13, 2015 at 8:21 am
I'm sure our current employers probably benefit from scripts we may have written in our previous jobs. When a company hires a senior level developer or DBA, those of us with a history of past positions, it should be generally understood that we come with a bag of tricks.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply