Choosing Your Tasks

  • Comments posted to this topic are about the item Choosing Your Tasks

  • Well, being a developer I get just a little self directed time permitted. To be honest though, I actually take a whole lot more - and to be honest I think that is good for my employer and for myself, as it allows some scope to find better ways to do things. Best not discuss that too openly but just to do it - believe me my employers are not unhappy when they find the excellent new ways to make things work or flashy bits of interface I have come up with.

  • DBAs are often «cost-centres» and self-directed time is often neither understood nor appreciated by those above. It can be hard when one has to account for one's time in 15-minute intervals.

    Often one needs to explain what one does in terms of tangible benefits, 'I was working on improving the poor performance of the person search' and the like.

    Often those above do not value 'prevention being better than cure' or preparation of technologies as yet unused in the company. You will not spend time learning about replication until we tell you that we need replication fully working within a month.

    That being said, I incorporate self-directed time into my tasks. For example, I will wait the appropriate task that is sent my way to hone my skills with the WITH-clause and recursion. I could surely do the task faster the way I had been doing it before but I am thinking medium to long term. With the next such task I can solve the problem faster. I have a list of aspects of SQL Server that is on my 'to be practiced'-list.

    It gets harder with something like a cube. One can't just learn all about data-marts, OLAP-types, MDX and DMX in the course of a query that might normally take 2 days to create and test. One would have to build it in one's spare time, populate it with company data, demonstrate it usefully to the right people and then when asked how long it would take to build, repay yourself with the expended time. It's not nice, it's risky but sometimes it's an effective way to introduce whole new features to those that pay.

  • I would expect that as a production DBA that is ultimately responsible for an organization's data, would have large amounts of self directed time ( > 50%) to manage and improve the enviroment as they saw fit. Just my .02

  • At my old job, as a development DBA, I had minimal self-directed time. I was in a dev support role so I had a list of tickets to work on and could choose from those. Unless we were in crisis mode which was most of the time so I had a set prioritization of tickets.

    A month into my new job, as a production DBA, almost all my time is self directed. There was an existing DBA that had backups set up and rolling smoothly and I worked with him at my last job before he left so he knows I don't need a lot of babysitting.

  • When there were three of us working together, I used to have a lot self-directed time. Since I don't suffer from motivation issues, I could spend a lot of time improving performance, building things to help me manage my time better, and improving my skill set. Now that I'm the only one (like Tigger), I don't know what self-directed time means anymore. Maybe it's the time I spend to refill the water hopper in the coffee pot because it takes five minute for the water to heat up and there's only enough left for one more cup.

  • In our environment we are mostly production DBA's, but we are production DBA's on 90% purchased/vendor applications; as such we spend a significant amount of time troubleshooting and rolling out new versions of codes for bug fixes, etc in response to problem tickets from the business users - I do not consider this self-directed.

    Part of our problem may be our staffing - we have 2 FTE's and a (new) full-time contractor managing 120 instances over 110 servers, including 12 two-node and three-node clusters; we support over 1000 databases among us. To me this has always seemed like too much per DBA such that we spend most of our time rushing from problem to problem with the duct tape at the ready.

    I agree with Steve's original premise that a lot of time for an established production DBA should be self-directed, but I also agree with the few previous posters that point out that businesses usually don't recognize the value in that - mine definitely doesn't.

  • I and my coworkers are combo development/production DBAs and probably 50 - 60 percent of our time is self-directed. We, of course, have production timelines that we work within, but we also come up with a quarterly "to do" list that we can work on as time permits.

    Greg

  • I would say I spend about 25% of my time as 'self directed'. I suspect I could have more time but I am the only DBA here administering many SQL Server instances and Oracle instances as well, so as you can imagine I get many requests. Biggest challange: I have had to learn to learn to mentally 'switch gears' between SQl Server and Oracle as I deal with requests dealing with both.

  • That being said, I incorporate self-directed time into my tasks. For example, I will wait the appropriate task that is sent my way to hone my skills with the WITH-clause and recursion. I could surely do the task faster the way I had been doing it before but I am thinking medium to long term. With the next such task I can solve the problem faster. I have a list of aspects of SQL Server that is on my 'to be practiced'-list.

    That is a great point. I've "practiced" on things like subtle date/time manipulation or filegroups and partitions when I know that type of effort is coming up.

    As (T-SQL) developer and DBA, for me it's feast or famine when it comes to self directed time. If we're in the middle of producing a deliverable then self directed time is near 0. When we're between projects and it's only routine maintenance and issues to deal with then that time soars to over half; even 3/4's of working time.

    Ken

  • I'd have to say almost 1/2 of my time is spent as "self-directed". I do have to answer to requests from users for new tables, new applications, etc. That takes up about 35% on my time while the other 15%-20% is spent researching new products & installing upgrades.

  • As a production DBA about 50-60% of my time is self-directed.

  • As a production DBA, I'd say probably about 30-40% of my time is self directed. We have a team of 5 DBA's + our manager managing roughly 400 instances. We should have 8 DBA's by the end of the year and my self directed time should go up from there.

    A lot of my self directed time is geared toward managing multiples instances better (learning to use SSIS to dynamically change connection managers to regularly gather data from all instances), pushing accounts or updates to all instances using the CMS (Central Management Server), managing the CMS data store by loading folders and instance registrations from our main list of supported instances.

    I forget where I had previously read it, and it only fits in certain context, but I loved the statement "A lazy DBA is an efficient DBA", and I think of that every time another function is automated, and that automation is thanks to using that self directed time. 😀

  • Lately I haven't had enough of that time. I enjoy that time because I get to accomplish some of my pet projects (which seem to be piling up right now).

    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

  • I love self directed time - and it varies a bit through the year how much I get. Often self directed time actually gives me more self directed time because you are usually spotting problems before they arise or trying to automate things that you've got a pretty good idea can be automated but for whatever reason no one else has spotted as an easy win.

    I was fortunate in one job managed to on the sly re-design a whole system that dramatically cut down on maintenance. That gave me enough time to use to design another system for another department. I would like to do that again with the orginal system to spatially enable it. Unfortunately I don't think I'm going to be allowed. I can see in three to five years management are going to say why can't we have dynamic mapping of all this information and I'm going to have to say its because the legacy systems didn't have the option when they were first designed. If I could do this side project the answer would be - yes sure 🙂

    Great topic by the way

    cloudydatablog.net

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic. Login to reply