October 7, 2013 at 8:30 am
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.
October 7, 2013 at 8:34 am
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.
October 7, 2013 at 8:58 am
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
Don't fear failure, fear regret.
October 7, 2013 at 9:03 am
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.
October 7, 2013 at 9:04 am
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.
October 8, 2013 at 6:18 am
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.
October 8, 2013 at 6:50 am
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
Change is inevitable... Change for the better is not.
October 8, 2013 at 7:02 am
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
Change is inevitable... Change for the better is not.
October 8, 2013 at 7:15 am
Yes. It is totally amazing what some people don't know.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 8, 2013 at 7:34 am
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...
[font="Arial Black"]"Just because you CAN do something in SQL, doesn't mean you SHOULDN'T!" [/font]:-P
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2013 at 7:43 am
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
Change is inevitable... Change for the better is not.
October 8, 2013 at 7:55 am
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
Change is inevitable... Change for the better is not.
October 8, 2013 at 8:04 am
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? 😮
October 8, 2013 at 8:15 am
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).
October 8, 2013 at 8:16 am
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. 🙂
Viewing 15 posts - 16 through 30 (of 39 total)
You must be logged in to reply to this topic. Login to reply