SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Beginner, Expert, or Both?


Beginner, Expert, or Both?

Author
Message
simon.crick
simon.crick
SSC Rookie
SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)

Group: General Forum Members
Points: 27 Visits: 101
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?
Bhuvnesh
Bhuvnesh
SSCertifiable
SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)

Group: General Forum Members
Points: 5174 Visits: 4076
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;-)
Dird
Dird
SSC-Addicted
SSC-Addicted (463 reputation)SSC-Addicted (463 reputation)SSC-Addicted (463 reputation)SSC-Addicted (463 reputation)SSC-Addicted (463 reputation)SSC-Addicted (463 reputation)SSC-Addicted (463 reputation)SSC-Addicted (463 reputation)

Group: General Forum Members
Points: 463 Visits: 808
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
Gary Varga
Gary Varga
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16100 Visits: 6531
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!!!
    Steve Jones
    Steve Jones
    SSC Guru
    SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

    Group: Administrators
    Points: 61534 Visits: 19098
    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
    My Blog: www.voiceofthedba.com
    Steve Jones
    Steve Jones
    SSC Guru
    SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

    Group: Administrators
    Points: 61534 Visits: 19098
    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
    My Blog: www.voiceofthedba.com
    Steve Jones
    Steve Jones
    SSC Guru
    SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

    Group: Administrators
    Points: 61534 Visits: 19098
    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
    My Blog: www.voiceofthedba.com
    below86
    below86
    SSC Eights!
    SSC Eights! (905 reputation)SSC Eights! (905 reputation)SSC Eights! (905 reputation)SSC Eights! (905 reputation)SSC Eights! (905 reputation)SSC Eights! (905 reputation)SSC Eights! (905 reputation)SSC Eights! (905 reputation)

    Group: General Forum Members
    Points: 905 Visits: 2421

    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.:-)

    -------------------------------------------------------------
    we travel not to escape life but for life not to escape us
    sqlnaive
    sqlnaive
    SSCarpal Tunnel
    SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)

    Group: General Forum Members
    Points: 4269 Visits: 2774
    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.
    Cadavre
    Cadavre
    Hall of Fame
    Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)

    Group: General Forum Members
    Points: 3874 Visits: 8472
    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.


    Forever 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


    Craig Wilkinson - Software Engineer
    LinkedIn
    Go


    Permissions

    You can't post new topics.
    You can't post topic replies.
    You can't post new polls.
    You can't post replies to polls.
    You can't edit your own topics.
    You can't delete your own topics.
    You can't edit other topics.
    You can't delete other topics.
    You can't edit your own posts.
    You can't edit other posts.
    You can't delete your own posts.
    You can't delete other posts.
    You can't post events.
    You can't edit your own events.
    You can't edit other events.
    You can't delete your own events.
    You can't delete other events.
    You can't send private messages.
    You can't send emails.
    You can read topics.
    You can't vote in polls.
    You can't upload attachments.
    You can download attachments.
    You can't post HTML code.
    You can't edit HTML code.
    You can't post IFCode.
    You can't post JavaScript.
    You can post emoticons.
    You can't post or upload images.

    Select a forum

































































































































































    SQLServerCentral


    Search