Be Your Own Expert

  • Comments posted to this topic are about the item Be Your Own Expert

  • Yes - dig in and become your own expert. Show that self-motivation and become something better. Practice some difficult problems. Practice setting up various test cases and solutions to get some practice at it. It is the same principle that elite athletes use - they put in the extra effort and exercise the talents they have been given. If they are weak in an area, they practice harder at it to make it a strength.

    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

  • In regard to the statement:

    "Sure we have companies and management that treat us like disposable, easily replaceable parts, but I don' t think that's the majority of companies."

    If there really is a company that doesn't think of us as disposable, easily replaceable parts, I would certainly like to find it. One thing I can assure everyone of, is that such a company is definitely NOT ANY aerospace company. It is probably not an oil and gas company either.

  • It's pretty much not limited to SQL either.

    In my past experience, any effort made to dig in and solve problems, even obscure ones does get recognised by co-workers and management and has been beneficial from my point of view. Certainly hasn't hurt me and I always like to learn something new.

  • This doesn't just work at a personal level; it also works well as a strategy.

    I've come across quite a few companies who maintain a relatively small IT function for dealing with normal maintenance and routine work. When those companies need to implement something more complex, they bring in the "experts" in the form of a consultancy. The net result is that they never gain a proper understanding of their own systems, and are forced back to buy more consultancy every time something goes wrong.

    The company I currently work for also maintains a relatively small IT function for the size of business. However, we implement all our own systems, and if we need to buy in external resource, it's for the general grunt work. This way, we can manage the systems properly (because we understand where tweaking is needed) and can react quickly if something goes awry (because we understand how the systems link together). Moreover, if we do need to bring in consultants or contractors, we have enough knowledge to spot when they're trying to spin us a line.

    Overall, this approach saves us money in several areas:

    • We only implement what's needed, since forced learning of a system also forces us to learn the process we're trying to implement or streamline.
    • Since the work most likely to get farmed out is fairly basic, the external resources we do buy in are generally cheap
    • If we really have to buy in consultancy, it's targetted, so cost effective.
    • By keeping the interesting work in-house, the employees thrive on both the challenge and responsibility, translating into very low staff turnover.

    Worth a thought?

    Semper in excretia, suus solum profundum variat

  • Hi Steve

    Sure we have companies and management that treat us like disposable, easily replaceable parts, but I don' t think that's the majority of companies.

    Now, I am not writing as a DBA or anything like that, but I have quite a lot of life experience and I am just wondering if because you have had a reasonably high profile, is it possible that your exposure to different companies with varying management cultures is not necessarily typical of individuals that are just more 'average'?

    I do not want to give the impression that I am having a go at you - from what I have gathered over the years, you seem to me to be a terrific guy and a good husband and father who displays an awful lot of wisdom, compassion and common sense. 🙂

    It does seem to me though, your advice about becoming "your own expert" is in general good advice. I have no doubt that there are people out there who really do try to do the right thing, but are not appreciated by their company. However, I would encourage those individuals who have been or are not currently appreciated to keep at it because I think in the long run you will be rewarded although not necessarily by your current employer.

    Anyway, that's what I think

    Kind regards

    Ross

  • Sometimes in the midst of trying to solve a problem it is difficult to learn from the situation. One thing I've done is to take notes during the repair process. Even if you bring in 'experts' to help take notes of the problem symptoms and things done to fix it.

    After the repair has been completed review what happened, why it happened, and the solutions that fixed the problem.

    If you have a test environment see if you can duplicate the problem and the solution as a learning tool.

    Learning from books, forums, etc is great, but learning from real world problems is the best teacher.

  • Ross Petersen (5/18/2010)


    Now, I am not writing as a DBA or anything like that, but I have quite a lot of life experience and I am just wondering if because you have had a reasonably high profile, is it possible that your exposure to different companies with varying management cultures is not necessarily typical of individuals that are just more 'average'?

    Are you speaking in terms of having success at jobs or of sticking with a job? I'm not sure from your comment.

  • Dave Schutz (5/18/2010)


    Sometimes in the midst of trying to solve a problem it is difficult to learn from the situation. One thing I've done is to take notes during the repair process. Even if you bring in 'experts' to help take notes of the problem symptoms and things done to fix it.

    After the repair has been completed review what happened, why it happened, and the solutions that fixed the problem.

    This can be hard, and it's a cultural thing. I worked for one large company that did this regularly. We reviewed issues and found root causes and then presented results, like the MMM conferences for doctors. At another one, they kept saying this was important, but never allowed time to delve in and management wouldn't force presentations, so we constantly had issues and struggled to learn what could fix issues that crossed systems.

  • Dave Schutz (5/18/2010)


    After the repair has been completed review what happened, why it happened, and the solutions that fixed the problem. Learning from books, forums, etc is great, but learning from real world problems is the best teacher.

    I tend to a agree. Becoming an expert, is not just about being very good at solving problems, but also at learning from them, DOCUMENTING them, and learning what to do to prevent them from occuring in the future. Paid experts/consultants tend to just fix specific issues, or put out fires, but don't document anything or tell your shop ways to prevent the thing from happening again in the future. When you think about it, it is not in their best interests to do that anyway. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • I work at a small company and I'm the only DBA (part time) so I get to set the rules for how I troubleshoot. Taking notes is something I've learned from 30 + years in IT and electronics.

    Also as I get older I tend to forget things faster so taking notes is mandatory to not repeating my mistakes.

  • In my world, the system is distributed and complicated. I have been working on a problem for several days now. It should be working, works for others, but doesn't work in this situation. I have a test environment which is a VM, and not an exact replica, I can't help that. All of a sudden the problem goes away. Now, what exactly was it that fixed the problem? It's hard to say, it's not like I flipped a switch and it started working.

    I agree with the concepts and comments in this debate. Just adding that in the real world, it's sweat and work.

    A long time ago I heard an analogy of digging through a mountain. The kick-off party is great, but after a while it gets dark, you are all alone, the party people are gone and you are left to sweat and grind through in the dark. You won't know exactly how far along you are or how close you are to success. Until all of a sudden you pop out the other side of the mountain.

    Now, can I get it to work in production?

  • It's definitely hard to do in the real world. However like Dave mentioned, you take notes, you document things, and you review the issues.

    In terms of your VM issue across machines, that's hard. My guess is that you changed something and things got fixed, but since you changed multiple things, or were working through issues, you're not sure what it was.

    All you can do is try to learn. That doesn't mean you'll have 100% success at figuring things out, but as you ask questions, get help, get consultants, read, etc., hopefully you are learning more about your environment.

  • Right on Steve.

  • Along with extensive testing and taking notes I'd mention that listening and asking the right questions can also help you become an "expert".

    Most of my work at this time is support of existing systems, so I get all sorts of calls with staff and even IT folks calling asking how to get the 'system' to do this or that. Or, it was working yesterday but now it's not or can you build a report that shows this information, etc. etc.

    So I end up asking a lot of questions - patiently. Trying to get users and staff to open up as to what they REALLY want the system to do can be a two edged sword. Sometimes what the user wants is fairly easy to resolve and I'm a hero. Sometimes that user is unreasonable in their request and I and perhaps others have to come up with a "creative solution" to an issue that seems 'easy' to a user, but in fact is quite difficult to resolve. Sometimes there is not a solution and you might have to tell your user that their request is not something that can be done 'in house', or perhaps should not be done. In this event, be prepared to show the requesting party the whys and wherefores for this decision. Now you have entered into the grey area of getting a user to understand the costs involved in their request, or perhaps a security issue that the user was not aware of; or perhaps there is a political or some other business reason why the request has been deemed "unworkable".

    I think all of this is part of being an expert. Expanding your knowledge so you can provide the support your users need is what it all comes down to. Being able to communicate that knowledge in a practical, honest and forth right way is also a part of being an expert.

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

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