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 Tuesday, October 8, 2013 6:18 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 5:08 AM
Points: 37, Visits: 29
I fully agree with Mr. Jones. One consequence he left out of the mix is obsolescence. As an instructor at a local community college and a working professional I have encountered many developers and DBAs who have never considered it important to improve their skills. Personally, I find this mentality to be one that is as much arrogant as foolish. There are many positions open for both developers and DBAs that are not being filled because of a lack of skills and initiative.

For someone to ignore the many available training tools is the same as asking to be left behind in the career. There are numerous textbooks available from such publishers as Murach, Apress and Microsoft that keeping up with the technology is easy and you can do it from your own home.
Post #1502572
Posted Tuesday, October 8, 2013 6:50 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 11:15 PM
Points: 36,751, Visits: 31,201
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.


I agree with Simon, as well, but certainly not for the reason you stated, Steve. There is absolutely no reason why "core" or "simple" ever need be exclusive of "fast" and "efficient", which is second only to accuracy and nearly at the same level, BTW (if you don't think so, look at all the "my code is running slow" post on your own forum!). I absolutely agree that a 1% gain in performance can almost never be justified by 10x complexity but that's not the normal case. The normal case is 10x complexity and 60x worse performance. And THAT's the real problem. A lot of people just don't spend the time to learn the core, simple methods which are usually also the very fastest methods.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1502584
Posted Tuesday, October 8, 2013 7:02 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 11:15 PM
Points: 36,751, Visits: 31,201
Gary Varga (10/7/2013)
Of course, the editorial is spot on. So many people do not bother to find out the "why" either like SQL being set based, the ordering of the execution of a SQL statement, etc. Yet I find myself caught in between being honest and being fairly compared with my peers. How can I mark myself honestly out of 10 when I know the last half dozen people may know a lot less but still mark themselves highly? When asked verbally I do try and explain my score...I can only hope that it is received in the intended manner the other side of the table.


That's a HUGE problem with most employers and recruiters. They ask people to rate themselves. How can an honest person who rates themselves as a good honest 6 or 7 compete with someone who actually doesn't know much of anything but rates themselves as a 9 or a 10?

I guess I'm one of the few where a high self rating on a resume actually works against folks I interview. People who are really good don't have to rate themselves. It'll show in how the resume is written and during the interview. It also usually only takes me 2 or 3 simple questions during an interview to figure out if a candidate is worth their salt in SQL Server or not. I have been known to stop an interview after just one super simple question and trust me on this... the question is just absolutely stupid simple.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1502587
Posted Tuesday, October 8, 2013 7:15 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:19 AM
Points: 5,181, Visits: 2,798
Yes. It is totally amazing what some people don't know.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1502595
Posted Tuesday, October 8, 2013 7:34 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 11:15 PM
Points: 36,751, Visits: 31,201
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.


I could certainly be wrong but I didn't take Simon's comment as avoiding the "best" technique. What I took it as is that a lot of people will take to what they know instead of learning what they need. For example, at a previous company, someone decided to parse some rather complicated files use PERL and DTS (is was a while back) to control things. This also required a split path in DTS that would later merge so there was some special code that needed to be written to remerge the paths. Since PERL couldn't actually do it all, they also wrote some Active-X and some VBS to complete the task of just getting a file ready for import. It took 45 minutes for each file and God forbid if they made a change because you needed to be an expert at Perl, DTS, Active-X, VBS, AND T-SQL to make a change. As Simon stated, it was a "a completely unmaintanable mish-mash of technologies and techniques". Enter SQLServer 2005 and the ability to write SQLCLR which only served to add yet another technology to the mish-mash. Some (and I don't use the word often) idiot actually wanted me to implement a CLR to do "Modulus" because he didn't take the time to learn that SQL Server has a modulus operator.

I think that's the kind of mess that I think Simon is talking about.

As so frequently happens, it turned out that some strong yet simple "core" knowledge of T-SQL solved 99% of the problem and a well formed splitter (you can probably guess which one I used) covered the other 1%. What used to take 45 minutes to just get a file ready for import now took only 2 minutes to stage, import, validate, and process 8 files to completion.

And that is what I think Simon is talking about when it comes to "core" and "simple" techologies. I don't believe he's suggesting avoidance of the "best" solution, which might involve some "complex" T-SQL. I think he's suggesting what I added to my signature line a couple of weeks ago. It's a play on words of a horribly overused phrase...

"Just because you CAN do something in SQL, doesn't mean you SHOULDN'T!"


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1502608
Posted Tuesday, October 8, 2013 7:43 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 11:15 PM
Points: 36,751, Visits: 31,201
Gary Varga (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?



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


    Again, I could be wrong, but I believe you may have taken what Simon posted the wrong way. See my post to Cadavre above.


    --Jeff Moden
    "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

    First step towards the paradigm shift of writing Set Based code:
    Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

    (play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

    Helpful Links:
    How to post code problems
    How to post performance problems
    Post #1502613
    Posted Tuesday, October 8, 2013 7:55 AM


    SSC-Dedicated

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

    Group: General Forum Members
    Last Login: Today @ 11:15 PM
    Points: 36,751, Visits: 31,201
    chris_masiero (10/6/2013)
    I really don't know if being an expert is even required for 95% of jobs.


    Correct... but I'm thinking that they expect someone who's applying for a job that involves the use of T-SQL can actually do the job.


    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.


    But I'll bet you could write a joined UPDATE for two simple tables off the top of your head. I've interviewed a whole lot of people that don't even know where to begin.


    --Jeff Moden
    "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

    First step towards the paradigm shift of writing Set Based code:
    Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

    (play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

    Helpful Links:
    How to post code problems
    How to post performance problems
    Post #1502622
    Posted Tuesday, October 8, 2013 8:04 AM
    SSC-Enthusiastic

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

    Group: General Forum Members
    Last Login: Tuesday, July 1, 2014 3:20 AM
    Points: 196, Visits: 650
    Jeff Moden (10/8/2013)
    I have been known to stop an interview after just one super simple question and trust me on this... the question is just absolutely stupid simple.


    What Q & A did they give? :o



    Dird // Junior DBA
    11g OCA
    10.5 newbie
    Post #1502627
    Posted Tuesday, October 8, 2013 8:15 AM
    SSC Veteran

    SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

    Group: General Forum Members
    Last Login: Wednesday, July 16, 2014 11:25 PM
    Points: 240, Visits: 304
    I run into this type of problem everywhere I have worked. Someone states "this is the way to do it" because they saw X% faster performance. As my group's resident "expert" on SQL, I have had to teach multiple "lunch-n-learns" on SQL performance tuning. Before this everyone based their SQL perf on how fast the query was (and sadly some still do). The problem with this was/is the test set of data is maybe 100 rows at best. In production we get at least 10-100 times that. Then they wonder, why isn't my query/view/stored proc running faster.

    I also have to agree with Jeff on the hodge-podge of technologies people use. A few of our customers use a Python-scripted tool which utilizes a .Net 1.1 custom executable (source no longer exists) to import data from a flat file to a SQL 2005/2008 database. The Python experts always say its the .Net or the database. The .Net folks blame Python or usually the database. I've been forced to become, at least slightly proficient, in all of those technologies just so I can prove that its a combination of all 3.

    If I wasn't willing to learn and adapt, our customer's performance issues would never get resolved (its now all I seem to do).
    Post #1502636
    Posted Tuesday, October 8, 2013 8:16 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: Monday, July 21, 2014 6:24 AM
    Points: 3,537, Visits: 2,647
    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.


    ...but I absolutely agree. I have a piece of art hanging on the wall that I commissioned a friend of mine to draw. The words on the piece state "Before you can think outside the box, you must first realize... you're in a box!"

    Considering all of the 8 and 9 out of 10 marks I've seen people give themselves on resumes when they turn out to be a 0 to 2 on the SQL Richter scale, including "DBAs" and "developers" alike, I'd have to say that I agree with the assessment that they just don't know what they don't know or, worse yet, they don't actually care. So what separates those people from many of the good folks we see answering questions on forums like SSC? That, in and of itself, is the answer and a lot of people simply won't take the time because "they're not getting paid for it".

    I also blame technology. I asked one fellow some questions about backups and after answering "Don't Know" to all of the questions his question to me was "I've always used {insert name of some backup software} to do my backups. Why do I need to know anything about native SQL Backups or the BACKUP command?" With others, questions like "What is a Clustered Index" are also answered with "Don't Know" and, when I explain it, I get asked "Why would a DBA or Developer need to know that?". My step kid's are all grown up so I can't confirm it but rumor has it that they're not teaching multiplication tables in school anymore. Guess that explains the worst of it all.

    Anything I could say on the subject after that would be perceived as a rant about complacency, a lack of intellectual curiosity, or, perhaps, a matter of arrogance, so I'll quit while I'm ahead.


    I simply loved this Jeff:
    "Before you can think outside the box, you must first realize... you're in a box!"

    This is going to be with me for long time... I was inside the box for long time. It was the platform like this forum and knowledge of people like you, Steve, Gail etc (and few more) which made me think otherwise. Slowly but steadily I'm on the path to improve myself.
    Post #1502637
    « Prev Topic | Next Topic »

    Add to briefcase «««1234»»

    Permissions Expand / Collapse