Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««1234»»»

Beginner, Expert, or Both? Expand / Collapse
Author
Message
Posted Monday, October 07, 2013 5:04 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, October 09, 2013 3:49 AM
Points: 24, Visits: 76
Cadavre (10/7/2013)
simon.crick (10/7/2013)
I will probably get shot down again for saying this, but I believe people should stick to core technology and basic tecnhiques unless there is a very good reason for using exotic technology and advanced techniques.

Why? Because no one person (even those of you who think you are expert experts) can ever know more than a tiny fraction of all the available technology and techniques, and if we all go off on our own paths following our own preferences for exotic technology and advanced techniques, then our systems will end up being a completely unmaintanable mish-mash of technologies and techniques.

I am not dumb. I have consistently achieved very high grades and won awards for outstanding achievement, etc., but the more I learn, the more I realize it is impossible to know everything, and therefore, out of consideration for our colleagues, we really ought to be sticking to core technology and basic techniques wherever possible.

Simon


I disagree completely. You go with the "best" technique (measurable by performance tests) for the job, regardless of complexity. Then make sure that you document how the logic works.


So if it works 1% faster but is 10 times as complex, you still go for the "advanced" technique?

Post #1502081
Posted Monday, October 07, 2013 5:16 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, March 14, 2014 2:19 AM
Points: 2,820, Visits: 3,916
Often, The objective if Interview is bascially "not to select good DBA" but to select a person who can easily fit in the requirement and often the inerview's question are very much limited and predictable.
and this is also a reason why people instead of picking the stuff for learning perspective, they choose to grab perdictable easily catching hen.

Very few people read the article/"join forums" to learn or excel their skills.


-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done
Post #1502084
Posted Monday, October 07, 2013 5:45 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, March 21, 2014 6:12 AM
Points: 191, Visits: 634
I think it's all down to motivation. We have quite a large team (16 DBAs) where you can see juniors (1-2 years experience) who are better than a couple seniors (10+ years experience) which just should not happen. They become complacent in their roles & yet can still probably find a new job quite easily by simply showing the duration of their CVs. This becomes even worse when looking at SQL Server since only 3 people support it (vs 15 people for Oracle). None of the 3 SQL DBAs are at the level of the good, mid-level Oracle DBA here, let alone the top Oracle seniors.


Dird // Junior DBA
11g OCA
10.5 newbie
Post #1502090
Posted Monday, October 07, 2013 5:52 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Yesterday @ 8:20 AM
Points: 4,862, Visits: 2,243
simon.crick (10/7/2013)
Cadavre (10/7/2013)
simon.crick (10/7/2013)
I will probably get shot down again for saying this, but I believe people should stick to core technology and basic tecnhiques unless there is a very good reason for using exotic technology and advanced techniques.

Why? Because no one person (even those of you who think you are expert experts) can ever know more than a tiny fraction of all the available technology and techniques, and if we all go off on our own paths following our own preferences for exotic technology and advanced techniques, then our systems will end up being a completely unmaintanable mish-mash of technologies and techniques.

I am not dumb. I have consistently achieved very high grades and won awards for outstanding achievement, etc., but the more I learn, the more I realize it is impossible to know everything, and therefore, out of consideration for our colleagues, we really ought to be sticking to core technology and basic techniques wherever possible.

Simon


I disagree completely. You go with the "best" technique (measurable by performance tests) for the job, regardless of complexity. Then make sure that you document how the logic works.


So if it works 1% faster but is 10 times as complex, you still go for the "advanced" technique?



Surely, that is over simplifying the argument to validate your point.

It is frequently said on these forums that "it depends" and your statistical scenario would most likely result in a no to the "advanced" technique in most cases, however, there are possibly scenarios where 1% would be considered of enough benefit. Particularly as a tactical solution to overcome system capacity limit issues.

Yet I agree with you in principle that all too often a complex solution is rolled out due to:
  • role justification

  • CV engineering

  • curiosity

  • post-training experimentation

  • etc.


  • I guess this is another example of where professionalism should be applied alongside experience and expertise (and documenting skills ).


    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!
    Post #1502092
    Posted Monday, October 07, 2013 8:28 AM


    SSC-Dedicated

    SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

    Group: Administrators
    Last Login: Today @ 11:22 AM
    Points: 32,769, Visits: 14,931
    Jeff Moden (10/5/2013)
    I believe you meant "competent" rather than "complacent" in the following...

    They're expert beginners, and since they can accomplish the things they're asked to do at their jobs, they think they're complacent.




    Tx, reworded.







    Follow me on Twitter: @way0utwest

    Forum Etiquette: How to post data/code on a forum to get the best help
    Post #1502168
    Posted Monday, October 07, 2013 8:30 AM


    SSC-Dedicated

    SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

    Group: Administrators
    Last Login: Today @ 11:22 AM
    Points: 32,769, Visits: 14,931
    chris_masiero (10/6/2013)
    I really don't know if being an expert is even required for 95% of jobs.

    What would you call the level you reach once you are able to understand how to interpret, and modify expertly written examples from this website.

    I mean, there are a lot of people who say they are an expert at SQL and barely know how to perform a join or just know the basics of INSERT, UPDATE , etc. But take me for example, I've just spent 3 years 'porting' myself over to the paradigm that is SQL development. I use this and other sites a lot and can produce some pretty good stuff, but I would hardly consider myself an expert - just a competent builder tweaking the experts plans to suit my own household requirements.

    I might even fail a 'test' in an interview if they wanted me to write something of the top of my head that involves some of the more exotic SQL.



    Most jobs don't need experts. However our pursuit of "expert skills" or "mastery" is one thing that helps us enjoy careers and give meaning to our work.

    If you know most of the stuff we publish and can duplicate it yourself, you're certainly advanced, perhaps expert.







    Follow me on Twitter: @way0utwest

    Forum Etiquette: How to post data/code on a forum to get the best help
    Post #1502171
    Posted Monday, October 07, 2013 8:34 AM


    SSC-Dedicated

    SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

    Group: Administrators
    Last Login: Today @ 11:22 AM
    Points: 32,769, Visits: 14,931
    simon.crick (10/7/2013)
    Cadavre (10/7/2013)
    simon.crick (10/7/2013)
    I will probably get shot down again for saying this, but I believe people should stick to core technology and basic tecnhiques unless there is a very good reason for using exotic technology and advanced techniques.

    Why? Because no one person (even those of you who think you are expert experts) can ever know more than a tiny fraction of all the available technology and techniques, and if we all go off on our own paths following our own preferences for exotic technology and advanced techniques, then our systems will end up being a completely unmaintanable mish-mash of technologies and techniques.

    I am not dumb. I have consistently achieved very high grades and won awards for outstanding achievement, etc., but the more I learn, the more I realize it is impossible to know everything, and therefore, out of consideration for our colleagues, we really ought to be sticking to core technology and basic techniques wherever possible.

    Simon


    I disagree completely. You go with the "best" technique (measurable by performance tests) for the job, regardless of complexity. Then make sure that you document how the logic works.


    So if it works 1% faster but is 10 times as complex, you still go for the "advanced" technique?



    I'm with Simon here. You stick with what works, what is simplist (KISS principle) and what you can get done quickly. You look for better ways to do things, but you also don't just implement something just because it's faster. Mostly because faster isn't always true. We don't operate on a linear scale, but rather a multi-dimensional one. The stuff that we do might work well for some queries/situations, and not others. It works at some data volumes, but not others.

    You look for better techniques and learn how to use them, but you carefully change what you know works well and is simple only when you have good reasons.

    Simple techniques does not imply shoddy techniques. Basics are not wrong, they are just of less complexity.







    Follow me on Twitter: @way0utwest

    Forum Etiquette: How to post data/code on a forum to get the best help
    Post #1502173
    Posted Monday, October 07, 2013 8:58 AM


    SSC Veteran

    SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

    Group: General Forum Members
    Last Login: Monday, April 14, 2014 9:12 AM
    Points: 214, Visits: 718

    I'm with Simon here. You stick with what works, what is simplist (KISS principle) and what you can get done quickly. You look for better ways to do things, but you also don't just implement something just because it's faster. Mostly because faster isn't always true. We don't operate on a linear scale, but rather a multi-dimensional one. The stuff that we do might work well for some queries/situations, and not others. It works at some data volumes, but not others.

    You look for better techniques and learn how to use them, but you carefully change what you know works well and is simple only when you have good reasons.

    Simple techniques does not imply shoddy techniques. Basics are not wrong, they are just of less complexity.


    I was just thinking about what and how to post a response to this, but Steve you just covered everything I was going to say. I follow the 'KISS principle', I know if I use more complex coding techniques, I'll be the one that 'always' has to maintain it.

    I've been working with SQL for over 10 years, am I an 'expert'? I don't think so, I know there is a lot I don't know. I probably wouldn't rate myself to high on a scale of 1 to 10, maybe a 6. Maybe just being to modest.
    Post #1502187
    Posted Monday, October 07, 2013 9:03 AM


    Hall of Fame

    Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

    Group: General Forum Members
    Last Login: Yesterday @ 6:04 AM
    Points: 3,517, Visits: 2,606
    Steve Jones - SSC Editor (10/7/2013)
    simon.crick (10/7/2013)
    Cadavre (10/7/2013)
    simon.crick (10/7/2013)
    I will probably get shot down again for saying this, but I believe people should stick to core technology and basic tecnhiques unless there is a very good reason for using exotic technology and advanced techniques.

    Why? Because no one person (even those of you who think you are expert experts) can ever know more than a tiny fraction of all the available technology and techniques, and if we all go off on our own paths following our own preferences for exotic technology and advanced techniques, then our systems will end up being a completely unmaintanable mish-mash of technologies and techniques.

    I am not dumb. I have consistently achieved very high grades and won awards for outstanding achievement, etc., but the more I learn, the more I realize it is impossible to know everything, and therefore, out of consideration for our colleagues, we really ought to be sticking to core technology and basic techniques wherever possible.

    Simon


    I disagree completely. You go with the "best" technique (measurable by performance tests) for the job, regardless of complexity. Then make sure that you document how the logic works.


    So if it works 1% faster but is 10 times as complex, you still go for the "advanced" technique?



    I'm with Simon here. You stick with what works, what is simplist (KISS principle) and what you can get done quickly. You look for better ways to do things, but you also don't just implement something just because it's faster. Mostly because faster isn't always true. We don't operate on a linear scale, but rather a multi-dimensional one. The stuff that we do might work well for some queries/situations, and not others. It works at some data volumes, but not others.

    You look for better techniques and learn how to use them, but you carefully change what you know works well and is simple only when you have good reasons.

    Simple techniques does not imply shoddy techniques. Basics are not wrong, they are just of less complexity.


    Steve, It's short but very brilliant stuff from you. And it is correct that basics are not wrong.

    However you must grow your knowledge with time because the company's and team's expectation grows as your experience increases. It's good for a 1-3 yrs experienced SQL developer to have knowledge on general tables, procedures, triggers etc but with 3-5 yrs category he should know about performance tuning and optimization and as the expeirence grows, it should show in you work on bigger scale like designing any small scale or big scale project efficiently keeping scalability in mind. Also you should be well versed with stuff like perfmon and profiler etc. Today a good sql developer is also good to have knowledge on business studio (SSIS/SSRS/SSAS). Anything over 8 yrs experience should ideally be able to take decisions from Project's side over database management.
    Post #1502193
    Posted Monday, October 07, 2013 9:04 AM


    SSCrazy

    SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

    Group: General Forum Members
    Last Login: Today @ 7:06 AM
    Points: 2,404, Visits: 7,311
    simon.crick (10/7/2013)
    So if it works 1% faster but is 10 times as complex, you still go for the "advanced" technique?


    All I can say to that is "it depends". I purposely used the word "best" rather than "fastest" to differentiate between different techniques. The "best" solution doesn't necessarily have to be the most complicated (in point of fact, the less work that the optimizer has to do the better!), it is simply the solution that best fits what we're trying to achieve. My time is valuable, so if it will take a "long" time to implement a change for a "1%" performance improvement, then it's unlikely that I'd prioritise that anywhere near the top of my list of things to do.

    Steve Jones - SSC Editor (10/7/2013)
    I'm with Simon here. You stick with what works, what is simplist (KISS principle) and what you can get done quickly. You look for better ways to do things, but you also don't just implement something just because it's faster. Mostly because faster isn't always true. We don't operate on a linear scale, but rather a multi-dimensional one. The stuff that we do might work well for some queries/situations, and not others. It works at some data volumes, but not others.

    You look for better techniques and learn how to use them, but you carefully change what you know works well and is simple only when you have good reasons.

    Simple techniques does not imply shoddy techniques. Basics are not wrong, they are just of less complexity.


    I didn't say "use complicated methods", nor "use the fastest" (that could be said to have been implied from "best", but I find that IO statistics are more helpful than timings), I simply said "You go with the "best" technique (measurable by performance tests) for the job, regardless of complexity".

    I have to test under a lot of different conditions before I can consider a solution. The clients that my company sells to are all using different hardware, with different data loads, different data distribution, different numbers of users concurrently accessing data etc etc, so I need to know that something that works in one place will work in another and if it doesn't then it doesn't get into production. "Work" doesn't just mean that the code has to be accurate and produce the same results from the same inputs, it means that it does this in a timely fashion. This may require more thought and more testing than some people when developing a solution, but it colours all of my thought processes when designing anything.



    Not a DBA, just trying to learn

    For better, quicker answers on T-SQL questions, click on the following...
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

    For better, quicker answers on SQL Server performance related questions, click on the following...
    http://www.sqlservercentral.com/articles/SQLServerCentral/66909/



    If you litter your database queries with nolock query hints, are you aware of the side effects?
    Try reading a few of these links...

    (*) Missing rows with nolock
    (*) Allocation order scans with nolock
    (*) Consistency issues with nolock
    (*) Transient Corruption Errors in SQL Server error log caused by nolock
    (*) Dirty reads, read errors, reading rows twice and missing rows with nolock


    LinkedIn | Blog coming soon (for sufficiently large values of "soon" )!
    Post #1502196
    « Prev Topic | Next Topic »

    Add to briefcase ««1234»»»

    Permissions Expand / Collapse