December 17, 2015 at 7:11 am
Sean Redmond (12/17/2015)
It is the over-compartmentalisation that does it. I was a year into a job as a DBA and I had gotten a grip on what was to be done. I started reading up on the other features on SQL Server that we weren't using. I bought a book on Analysis Services (for SQL Server 2005!), learnt the concepts of datamarts, dimension- and fact-tables, cubes and basic MDX. I followed the chapters in the book, built a cube several ways, was introduced to data-mining, the algorithms within and DMX. I then went to my team-leader and asked to present this new info to the team and I was given out to. It's not in the company strategy, she said.In short, the company is paying me to do certain things and management decides what these are. Data-warehouses are not one of them. When they want cubes, they will decide, not me. I got docked at my annual review that year for not having enough sense of the company (i.e. for being too selfish).
This is my take on why people learn lots in the first year and little afterwards. They do what they need to do their job and are not encouraged to do more.
You appear to be speaking of this specific job in the past tense. If so, then good for you! Your former employer should just outsource all their DBA operations, if all they expect from a DBA is that they follow marching orders, and executive management makes all the IT architectural decisions in a guarded bunker.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 17, 2015 at 7:18 am
Eric M Russell (12/17/2015)
Sean Redmond (12/17/2015)
It is the over-compartmentalisation that does it. I was a year into a job as a DBA and I had gotten a grip on what was to be done. I started reading up on the other features on SQL Server that we weren't using. I bought a book on Analysis Services (for SQL Server 2005!), learnt the concepts of datamarts, dimension- and fact-tables, cubes and basic MDX. I followed the chapters in the book, built a cube several ways, was introduced to data-mining, the algorithms within and DMX. I then went to my team-leader and asked to present this new info to the team and I was given out to. It's not in the company strategy, she said.In short, the company is paying me to do certain things and management decides what these are. Data-warehouses are not one of them. When they want cubes, they will decide, not me. I got docked at my annual review that year for not having enough sense of the company (i.e. for being too selfish).
This is my take on why people learn lots in the first year and little afterwards. They do what they need to do their job and are not encouraged to do more.
You appear to be speaking of this specific job in the past tense. If so, then good for you! Your former employer should just outsource all their DBA operations, if all they expect from a DBA is that they follow marching orders, and executive management makes all the IT architectural decisions in a guarded bunker.
In all fairness "Our company should implement a datawarehouse using the SQL Server stack" is generally not a decision made randomly by a DBA. Made randomly by a manager maybe 😛 but usually not unless it's a company wide initiative
December 17, 2015 at 7:35 am
Well, to be fair, I'd didn't expect them to put me on a data-warehouse project immediately. What I expected was that she'd be excited about it, let me organise a meeting to show the other DBAs and then possibly make a presentation to the directors with the possibilities that this may bring — new sales opportunities and so forth.
The hope was that once the powers-that-be above me were aware that we had new capabilities and possibilities, that it would materialise into a project within a year or two.
December 17, 2015 at 7:55 am
ZZartin (12/17/2015)
Eric M Russell (12/17/2015)
Sean Redmond (12/17/2015)
It is the over-compartmentalisation that does it. I was a year into a job as a DBA and I had gotten a grip on what was to be done. I started reading up on the other features on SQL Server that we weren't using. I bought a book on Analysis Services (for SQL Server 2005!), learnt the concepts of datamarts, dimension- and fact-tables, cubes and basic MDX. I followed the chapters in the book, built a cube several ways, was introduced to data-mining, the algorithms within and DMX. I then went to my team-leader and asked to present this new info to the team and I was given out to. It's not in the company strategy, she said.In short, the company is paying me to do certain things and management decides what these are. Data-warehouses are not one of them. When they want cubes, they will decide, not me. I got docked at my annual review that year for not having enough sense of the company (i.e. for being too selfish).
This is my take on why people learn lots in the first year and little afterwards. They do what they need to do their job and are not encouraged to do more.
You appear to be speaking of this specific job in the past tense. If so, then good for you! Your former employer should just outsource all their DBA operations, if all they expect from a DBA is that they follow marching orders, and executive management makes all the IT architectural decisions in a guarded bunker.
In all fairness "Our company should implement a datawarehouse using the SQL Server stack" is generally not a decision made randomly by a DBA. Made randomly by a manager maybe 😛 but usually not unless it's a company wide initiative
No architectural decision should be made randomly or unilaterally. What I expect from executive management is to at least listen to suggestions from the DBA, because the DBA is in a unique position to know what new technologies can improve the operational efficiency of the organization. But like I said, if management doesn't see the DBA as a source of input regarding architectural decisions, then they should just go the route of outsourcing. I mean, why pay a full time employee $$$,$$$ to sit in a server room robotically and silently following a set of procedures that are set in stone when they can get the same outcome outsourced for half or 1/3 the cost? I'm sure a DBA in that position would love to just take their severance pay and move on to bigger and better things as well.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 17, 2015 at 8:23 am
roger.plowman (12/17/2015)
I simply can't pile on optional extras I'm not going to need right now (data warehousing and all the specialization that goes with that). My plate is full with OLTP, thank you very much.
Except that you mentioned all the extras you do pile on. Continuous learning and growing doesn't mean only learning SQL Server. It means learning something new.
December 17, 2015 at 8:25 am
Sean Redmond (12/17/2015)
It is the over-compartmentalisation that does it. I was a year into a job as a DBA and I had gotten a grip on what was to be done. I started reading up on the other features on SQL Server that we weren't using. I bought a book on Analysis Services (for SQL Server 2005!), learnt the concepts of datamarts, dimension- and fact-tables, cubes and basic MDX. I followed the chapters in the book, built a cube several ways, was introduced to data-mining, the algorithms within and DMX. I then went to my team-leader and asked to present this new info to the team and I was given out to. It's not in the company strategy, she said.In short, the company is paying me to do certain things and management decides what these are. Data-warehouses are not one of them. When they want cubes, they will decide, not me. I got docked at my annual review that year for not having enough sense of the company (i.e. for being too selfish).
This is my take on why people learn lots in the first year and little afterwards. They do what they need to do their job and are not encouraged to do more.
That's a crappy manager. While this happens, there are plenty of places where it doesn't. I've usually had the opposite experience at many jobs where they do appreciate some of the things I learn and can improve.
Not everything, and they certainly don't adopt every idea or tech I think will help, but they do for a few and no one docks me for trying.
December 17, 2015 at 8:44 am
Sean Redmond (12/17/2015)
It is the over-compartmentalisation that does it. I was a year into a job as a DBA and I had gotten a grip on what was to be done. I started reading up on the other features on SQL Server that we weren't using. I bought a book on Analysis Services (for SQL Server 2005!), learnt the concepts of datamarts, dimension- and fact-tables, cubes and basic MDX. I followed the chapters in the book, built a cube several ways, was introduced to data-mining, the algorithms within and DMX. I then went to my team-leader and asked to present this new info to the team and I was given out to. It's not in the company strategy, she said.In short, the company is paying me to do certain things and management decides what these are. Data-warehouses are not one of them. When they want cubes, they will decide, not me. I got docked at my annual review that year for not having enough sense of the company (i.e. for being too selfish).
This is my take on why people learn lots in the first year and little afterwards. They do what they need to do their job and are not encouraged to do more.
I really think you've got something here which I'm not sure has been mentioned before. Some companies simply punish their employees for being innovative or trying to find new ways of getting the job done. That will kill one's desire to do anything new, if it's not appreciated. Several years ago I had the same thing happen to me. I was working in a manufacturing environment. Upper management wanted to move the company to be more competitive. They took the whole company aside for a day, saw videos encouraging "thinking outside the box". Testimonials as to what people did at other companies in order to move things along, etc. I took it all to heart. Until I actually tried to put it in action. I saw an opportunity to go outside of the box and improve efficiency, just as we'd been encouraged and told to do, so I did it. I nearly lost my job because I didn't do as had always been done. Its a bitter lesson I learned, sometimes upper management says one thing, but local management has other ideas and agendas.
BTW, some years later that company went out of business.
Kindest Regards, Rod Connect with me on LinkedIn.
December 31, 2015 at 10:02 am
Iwas Bornready (12/15/2015)
Sean Redmond (12/14/2015)
make haste slowlyThat's the key item for me. When I don't breathe I make mistakes.
Well, yes, it's generally a mistake to omit breathing unless you're intent on suicide. :hehe:
Tom
December 31, 2015 at 10:51 am
It's certainly true that what you've done with your years of experience is more important than how many years you have.
There's a difference here between being in production and being in development - a production DBA tends to learn new stuff when the company upgrades to a new release of RMDBS software, and rarely with extra disaster recovery or continuous availability development. A development DBA (who should maybe be called a developer) may be lucky and learn new stuff when a new application is implemented.
There's also a difference between being in a company where software and/or hardware is its business, its product, and a company where software/hardware is just a tool. If the company develops database systems, the DBA is going to be learning new things rather often (or the company is going to go bust); if it develops applications or tools that use dtabases, the DBA is going to be required to help determine how the company's products will change or expand to cope with the latest versions of the database(s) on which its products run, so is going to have to keep up to date with those database products.be a capable generalist, not just a databases expert.
So there are certainly jobs where one can stay for a very long time and be learning new stuff all the time, and some people will enjoy jobs like that; even more fun is working for a company where you are allowed, if you wish, to change jobs regularly to remain a capable generalist, not just a specialized expert. (I have to include my standard dig about overspecialization in the software business, it's becominge compulsive behaviour on my part.)
So I agree with what the editorial says and with most of the comments here, but I think there's maybe a bit too much emphasis om not staying in one place for a long time. My own jobs have lasted 6 weeks (1 government job), 3 months(1 government job split over several years), 12 months (1 academic job), 18 months (each of 3 industrial jobs), 36 months (1 industrial job), 86 months (1 industrial job), and 295 months (1 industrial job); the one in hich I learnt at the highest rate, by far, was the one that lasted 295 months - I learnt more per week there than I did per month anywhere else. That tells me that staying with one outfit for a long time can be a good thing for learning. Actually the last few months of that long one was me non-productively bowsing the web and waiting for them to terminate me because (a) my face didn't fit with the new management so they'd deliberately allowed me nothing to do and (b) my terms with them meant they would have to pay me a bomb if they did; they did pay that bomb, despite knowing full well that I had more job offers than I could possibly accept. But I learnt a lot in the first 24 years of that employment).
Tom
January 15, 2016 at 5:49 am
ZZartin (12/17/2015)
Eric M Russell (12/17/2015)
Sean Redmond (12/17/2015)
It is the over-compartmentalisation that does it. I was a year into a job as a DBA and I had gotten a grip on what was to be done. I started reading up on the other features on SQL Server that we weren't using. I bought a book on Analysis Services (for SQL Server 2005!), learnt the concepts of datamarts, dimension- and fact-tables, cubes and basic MDX. I followed the chapters in the book, built a cube several ways, was introduced to data-mining, the algorithms within and DMX. I then went to my team-leader and asked to present this new info to the team and I was given out to. It's not in the company strategy, she said.In short, the company is paying me to do certain things and management decides what these are. Data-warehouses are not one of them. When they want cubes, they will decide, not me. I got docked at my annual review that year for not having enough sense of the company (i.e. for being too selfish).
This is my take on why people learn lots in the first year and little afterwards. They do what they need to do their job and are not encouraged to do more.
You appear to be speaking of this specific job in the past tense. If so, then good for you! Your former employer should just outsource all their DBA operations, if all they expect from a DBA is that they follow marching orders, and executive management makes all the IT architectural decisions in a guarded bunker.
In all fairness "Our company should implement a datawarehouse using the SQL Server stack" is generally not a decision made randomly by a DBA. Made randomly by a manager maybe 😛 but usually not unless it's a company wide initiative
Ish ... Quite often it is entirely correct that the development of a SQL Server stack BI solution comes from the DBA as a solution to the highlighted business issue(s)
What is not, and I've seen this - and it always ends in failure, is where IT decide to implement some cool buzzwords without focussing on solving specific business issues of interest to the key businesss managers. As a general rule, even the faintest pause after the question "Ok, what business question are we answering with this", or if the reply is brochurespeak, means every single penny spent on that project was wasted. So was the time spent on it which could have been spent on doing something useful.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
January 15, 2016 at 6:06 am
TomThomson (12/31/2015)
... If the company develops database systems, the DBA is going to be learning new things rather often ...
Not if my experience with third party products is anything to go by, mind, the many suppliers tend to make do without anyone who can even spell database correctly let alone a competent DBA.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
January 15, 2016 at 8:07 pm
andrew gothard (1/15/2016)
TomThomson (12/31/2015)
... If the company develops database systems, the DBA is going to be learning new things rather often ...Not if my experience with third party products is anything to go by, mind, the many suppliers tend to make do without anyone who can even spell database correctly let alone a competent DBA.
well, I've worked with SQL Server, Oracle, Ingres, Postgres, and IDMS and found that the suppliers of those database systems were pretty competent. I also had a brief acquaintance with DB2 (and threw it back to IBM, telling our accounts people not to pay their invoices) so yes, it appears that at least one company that developsdatabase systems may be .nearly as dim as you suggest, but not quite as dim since they managed to spell "database" correctly. You must have had much worse experiences than me - so please do tell us which DBMSs you encountered whose quality suggested that their developers didn't know enough about databases even to spell the word, so that we are all forwarned and know not to buy database systems from those people.
Tom
Viewing 12 posts - 31 through 41 (of 41 total)
You must be logged in to reply to this topic. Login to reply