July 22, 2013 at 2:50 pm
Sean Lange (7/22/2013)
Gosh Tom, how do you really feel about that article??? :w00t:
Just as described, but if I'd realised who wrote it I would have made the comment privately, not here.
Tom
July 22, 2013 at 6:35 pm
L' Eomot Inversé (7/22/2013)
Sean Lange (7/22/2013)
Gosh Tom, how do you really feel about that article??? :w00t:Just as described, but if I'd realised who wrote it I would have made the comment privately, not here.
Tom and Brandie - For the record I'm not upset by your posts. Circumstances have helped me to develop a pretty thick skin over the years. And what I said to Brandie about the author being an amateur is quite true. I most certainly consider myself so. 🙂
In the article's defense (without meaning to sound defensive), I attempted to write it from the perspective of someone that is new to MERGE. Surely there are a few of those folks out there, along with many others that use it sufficiently to be aware of all of the wrinkles of it when you do.
The flow of the article was also attempting to mimic the situation where requirements evolve, either because the users change their minds or because anomalies in the data require a bit of adaptation. Perhaps I was mistaken to think that ever happens. 😛
Your comments will be taken into consideration when I write in the future, but I should say that I write for fun. Occasionally, if someone cares to read it and gain from it, that is a bonus. Since I am no SQL-guru, I believe there is a place for those that have something to offer to beginners, mainly because they are not far removed from that state. Many of the highly technical articles I've read are way beyond what a beginner would derive a lot of value from. I try to cater to a lower common denominator.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
July 22, 2013 at 7:14 pm
dwain.c (7/22/2013)
L' Eomot Inversé (7/22/2013)
Sean Lange (7/22/2013)
Gosh Tom, how do you really feel about that article??? :w00t:Just as described, but if I'd realised who wrote it I would have made the comment privately, not here.
Tom and Brandie - For the record I'm not upset by your posts. Circumstances have helped me to develop a pretty thick skin over the years. And what I said to Brandie about the author being an amateur is quite true. I most certainly consider myself so. 🙂
In the article's defense (without meaning to sound defensive), I attempted to write it from the perspective of someone that is new to MERGE. Surely there are a few of those folks out there, along with many others that use it sufficiently to be aware of all of the wrinkles of it when you do.
The flow of the article was also attempting to mimic the situation where requirements evolve, either because the users change their minds or because anomalies in the data require a bit of adaptation. Perhaps I was mistaken to think that ever happens. 😛
Your comments will be taken into consideration when I write in the future, but I should say that I write for fun. Occasionally, if someone cares to read it and gain from it, that is a bonus. Since I am no SQL-guru, I believe there is a place for those that have something to offer to beginners, mainly because they are not far removed from that state. Many of the highly technical articles I've read are way beyond what a beginner would derive a lot of value from. I try to cater to a lower common denominator.
Dwain, I guess it comes down to whether the reader thought you were writing in the first person from an "expert's" position or, as I did, that you were conveying a novice's story that unfolds as you read...
For me, I read it exactly as you describe here, a kind of timeline of someone's exploration of the command and how it can bite you if you don't fully comprehend the way it works.
In that context, it made sense to me, and also described pretty much the way my first attempt at using Merge worked out - unintentionally deleting rows due to poor scoping. (I also always test inside a transaction for precisely this reason - that should be a SQL Spackle in it's own right).
So, all in all, I don't think it deserves the criticism - I say blame the reader :w00t:
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);July 23, 2013 at 1:08 am
L' Eomot Inversé (7/22/2013)
dwain.c (7/17/2013)
Brandie Tarvin (7/17/2013)
WHOO HOO!Not only did I just teach myself how to use MERGE (never had time or reason), but I managed to use it correctly with a Cross Applied Tally table and an INNER JOIN inside the USING clause.
<SnoopyDance>
And it only took me 30 minutes to figure it all out.
One thing to take care with when using MERGE though: A Hazard of Using the SQL Merge Statement[/url]
It's not a bug it's a feature, but does have the potential to cause you grief if you don't know about it.
That reference is one of the most stupid pieces of nonsense I've ever seen. First the guy says he wants to merge his source into his target. Then he produces a chunk of code which does something like that. But the result of that is not what was required, because it's failed to delete a row that was in the target but not matched in the source - in other words, because it failed to violate his stated requirement in a particular way in which he wants his stated requirement violated. He then produces a piece of utterly silly code which just destroys his target and substitutes the source - and we are supposed to be surprised that that doesn't work. Then he produces, finally, his code which is the answer to the problem - but it doesn't meet his stated requirement, because it does indeed achieve the violation of that requirement that he introduced earlier to do job which he apparently wants, instead of the requirement that was actually fulfilled by the first piece of code he rejected. I just hope that I never have to deal with a developer or a DBA who leant from that guy!
Bad hair day, Tom?
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
July 23, 2013 at 1:43 am
mister.magoo (7/22/2013)
dwain.c (7/22/2013)
L' Eomot Inversé (7/22/2013)
Sean Lange (7/22/2013)
Gosh Tom, how do you really feel about that article??? :w00t:Just as described, but if I'd realised who wrote it I would have made the comment privately, not here.
Tom and Brandie - For the record I'm not upset by your posts. Circumstances have helped me to develop a pretty thick skin over the years. And what I said to Brandie about the author being an amateur is quite true. I most certainly consider myself so. 🙂
In the article's defense (without meaning to sound defensive), I attempted to write it from the perspective of someone that is new to MERGE. Surely there are a few of those folks out there, along with many others that use it sufficiently to be aware of all of the wrinkles of it when you do.
The flow of the article was also attempting to mimic the situation where requirements evolve, either because the users change their minds or because anomalies in the data require a bit of adaptation. Perhaps I was mistaken to think that ever happens. 😛
Your comments will be taken into consideration when I write in the future, but I should say that I write for fun. Occasionally, if someone cares to read it and gain from it, that is a bonus. Since I am no SQL-guru, I believe there is a place for those that have something to offer to beginners, mainly because they are not far removed from that state. Many of the highly technical articles I've read are way beyond what a beginner would derive a lot of value from. I try to cater to a lower common denominator.
Dwain, I guess it comes down to whether the reader thought you were writing in the first person from an "expert's" position or, as I did, that you were conveying a novice's story that unfolds as you read...
For me, I read it exactly as you describe here, a kind of timeline of someone's exploration of the command and how it can bite you if you don't fully comprehend the way it works.
In that context, it made sense to me, and also described pretty much the way my first attempt at using Merge worked out - unintentionally deleting rows due to poor scoping. (I also always test inside a transaction for precisely this reason - that should be a SQL Spackle in it's own right).
So, all in all, I don't think it deserves the criticism - I say blame the reader :w00t:
Any article which offers this much encouragement to the reader to explore and test - and shows them how to do it - deserves a little praise, surely? I'm not exactly the sharpest knife in the block but the target audience and the author's intent are as clear to me as they are to MM, and in that context I'd argue that the article works very well. More like this please, Dwain.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
July 23, 2013 at 4:33 am
As a writer and editor (outside of SQL Server), I believe it's incumbent upon the author to set reader expectations at the outset. That being said, if an article is for beginners and about another beginner's issues, that should be stated in the first paragraph (even the first sentence) so that people read it in the mindset that it was written. Otherwise there is the assumption of expertise from just reading the title.
When reader expectations are set, they are much less likely to fuss about the article (or book) in question unless the article / book flies against those expectations. It allows for a proper discussion based on the level of the article.
July 23, 2013 at 6:49 am
Brandie Tarvin (7/23/2013)
As a writer and editor (outside of SQL Server), I believe it's incumbent upon the author to set reader expectations at the outset. That being said, if an article is for beginners and about another beginner's issues, that should be stated in the first paragraph (even the first sentence) so that people read it in the mindset that it was written. Otherwise there is the assumption of expertise from just reading the title.When reader expectations are set, they are much less likely to fuss about the article (or book) in question unless the article / book flies against those expectations. It allows for a proper discussion based on the level of the article.
Brandie, I have to say +1 for standing your ground. Expectations setting is always a good thing, but I should point out that it borders on psychology. As I am no psychologist, I'd have to speculate that it must be done carefully. Let's try to understand why.
1. There is a concept called (and forgive me for making this sound so formal) illusory superiority. You can Google that and see a wide body of research or simply Google "average people don't think they're average" to get a wider feel for the concept.
2. If I were to ask you to rate your driving skill as below average, average or above average, how would you respond? I'm guessing 90% of the population of drivers would rate their skills as "above average," but statistically it is only possible that around 50% of drivers meet that criteria (please excuse me for playing fast and loose with mean vs. median).
The gist of what I'm trying to say here is that if I say this article is "by a beginner and for beginners" at the start of it, then I'm likely to lose 50% of the audience that might benefit from it.
Let's try a challenge for you. Most editors probably analyze the demographic of books and stories they publish to gauge the amount of money they'll make selling copies. The challenge is, in the preface of your next book you should say immediately "this book is targeted to a demographic of 25 to 40 year olds - if you're younger wait a few years to read it and if you're older forget it because you'll never get it." OK, let's make it easier, forget that last part. Are you going to turn away immediately part of the non-targeted demographic and risk sales?
And there probably were cases (as ChrisM pointed out) where some non-beginners might have learned something (http://www.sqlservercentral.com/Forums/FindPost1438429.aspx).
Again I do want to emphasize that I am not trying to be defensive, rather what I'm trying to say is that there is somewhat of a method to my (amateur) madness. I'd venture to say that 90% of the people that attend this site are not SQL MVPs and it is highly possible that 15% or less actually have one or more MS SQL certs such as yourself. That puts you in some pretty good (and scarce) company. That's a demographic I don't even meet. So if all of the articles are targeted at that 15% and they say so in the beginning, how many people that might benefit get turned off and turned away?
On the other hand, suppose you take a risk and don't set any expectations. An article is like a TV program. When you get bored you change the channel, or turn the page or press the back button on your browser. I'm not saying you shouldn't set expectations. What I'm saying is that it must be done carefully so as to not hurt your chances of improving someone's skill. And let's face it, I'd venture a guess that pretty much anybody in that top 15% I was talking about have probably faced people with a whole lot lower level of technical skill than they give themselves credit for.
I hope people see this as an opportunity for intellectual discourse and not a rant. :w00t: And let me add that I'm taking a rather extreme viewpoint here and I know it. Since this is psychology it is many shades of gray and not the black and white point of view I'm trying to portray.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
July 23, 2013 at 7:22 am
dwain.c (7/23/2013)
1. There is a concept called (and forgive me for making this sound so formal) illusory superiority.
I don't know why you're making this reference in regards to what I said. I'm talking about what authors call "The promise to the reader" and was actually responding to recent posts by other Threadzians.
Let me explain what the promise to the reader is. Say I tell you I'm writing an article on Doctor Who. And you happen to be a fan of the BBC science fiction series Doctor Who. But you click open the article and find out that I'm referencing a medical doctor and the actual discussion is about "the doctor who did this nasty thing to a patient."
How would you feel?
As the article writer, I broke my promise to the reader by making a grab for attention on keywords that I knew would make people jump and then not following through.
Conversely, if I promise an article on SQL Server Internals to SSC, some people might assume I am talking from a position of expertise since SQL Server Internals are a complicated subject. But the truth is that I barely know enough to scratch the surface of this topic. So if I write such an article, the first thing I would tell people is "I'm new at this, but this is what I saw when I did X thing at my job." That way Gail, Tom, Jeff, and everyone else with more experience than me would (I hope) moderate their comments from "You are clueless" to more of a "Well, have you checked out this link that explains that behavior" or "You're misinterpreting your results."
Not that any of them ever respond that way, but at least I'm setting the expectation at the start of the article so that people know where my POV is coming from. That's also why I would write my business case at the start. Giving the readers a starting point from which to view the code is more of a practical issue to me than it is any attempt at superiority.
July 23, 2013 at 7:25 am
dwain.c (7/23/2013)
Brandie Tarvin (7/23/2013)
As a writer and editor (outside of SQL Server), I believe it's incumbent upon the author to set reader expectations at the outset. That being said, if an article is for beginners and about another beginner's issues, that should be stated in the first paragraph (even the first sentence) so that people read it in the mindset that it was written. Otherwise there is the assumption of expertise from just reading the title.When reader expectations are set, they are much less likely to fuss about the article (or book) in question unless the article / book flies against those expectations. It allows for a proper discussion based on the level of the article.
Brandie, I have to say +1 for standing your ground. Expectations setting is always a good thing, but I should point out that it borders on psychology. As I am no psychologist, I'd have to speculate that it must be done carefully. Let's try to understand why.
1. There is a concept called (and forgive me for making this sound so formal) illusory superiority. You can Google that and see a wide body of research or simply Google "average people don't think they're average" to get a wider feel for the concept.
2. If I were to ask you to rate your driving skill as below average, average or above average, how would you respond? I'm guessing 90% of the population of drivers would rate their skills as "above average," but statistically it is only possible that around 50% of drivers meet that criteria (please excuse me for playing fast and loose with mean vs. median).
The gist of what I'm trying to say here is that if I say this article is "by a beginner and for beginners" at the start of it, then I'm likely to lose 50% of the audience that might benefit from it.
Let's try a challenge for you. Most editors probably analyze the demographic of books and stories they publish to gauge the amount of money they'll make selling copies. The challenge is, in the preface of your next book you should say immediately "this book is targeted to a demographic of 25 to 40 year olds - if you're younger wait a few years to read it and if you're older forget it because you'll never get it." OK, let's make it easier, forget that last part. Are you going to turn away immediately part of the non-targeted demographic and risk sales?
And there probably were cases (as ChrisM pointed out) where some non-beginners might have learned something (http://www.sqlservercentral.com/Forums/FindPost1438429.aspx).
Again I do want to emphasize that I am not trying to be defensive, rather what I'm trying to say is that there is somewhat of a method to my (amateur) madness. I'd venture to say that 90% of the people that attend this site are not SQL MVPs and it is highly possible that 15% or less actually have one or more MS SQL certs such as yourself. That puts you in some pretty good (and scarce) company. That's a demographic I don't even meet. So if all of the articles are targeted at that 15% and they say so in the beginning, how many people that might benefit get turned off and turned away?
On the other hand, suppose you take a risk and don't set any expectations. An article is like a TV program. When you get bored you change the channel, or turn the page or press the back button on your browser. I'm not saying you shouldn't set expectations. What I'm saying is that it must be done carefully so as to not hurt your chances of improving someone's skill. And let's face it, I'd venture a guess that pretty much anybody in that top 15% I was talking about have probably faced people with a whole lot lower level of technical skill than they give themselves credit for.
I hope people see this as an opportunity for intellectual discourse and not a rant. :w00t: And let me add that I'm taking a rather extreme viewpoint here and I know it. Since this is psychology it is many shades of gray and not the black and white point of view I'm trying to portray.
When I write about tech, I tend to write up my process including discovery, wrong turns, mistakes, etc... I think and hope that the articles are clear that that's what I'm doing. As I'm writing from the perspective of someone who is figuring things out, I don't have to worry about falling short of perceptions as an "expert" and I can walk through things for beginners while still providing information for experts. I don't really know if it works, but I enjoy it. 🙂
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
July 23, 2013 at 7:40 am
Brandie Tarvin (7/23/2013)
dwain.c (7/23/2013)
1. There is a concept called (and forgive me for making this sound so formal) illusory superiority.I don't know why you're making this reference in regards to what I said. I'm talking about what authors call "The promise to the reader" and was actually responding to recent posts by other Threadzians.
Let me explain what the promise to the reader is. Say I tell you I'm writing an article on Doctor Who. And you happen to be a fan of the BBC science fiction series Doctor Who. But you click open the article and find out that I'm referencing a medical doctor and the actual discussion is about "the doctor who did this nasty thing to a patient."
How would you feel?
As the article writer, I broke my promise to the reader by making a grab for attention on keywords that I knew would make people jump and then not following through.
Conversely, if I promise an article on SQL Server Internals to SSC, some people might assume I am talking from a position of expertise since SQL Server Internals are a complicated subject. But the truth is that I barely know enough to scratch the surface of this topic. So if I write such an article, the first thing I would tell people is "I'm new at this, but this is what I saw when I did X thing at my job." That way Gail, Tom, Jeff, and everyone else with more experience than me would (I hope) moderate their comments from "You are clueless" to more of a "Well, have you checked out this link that explains that behavior" or "You're misinterpreting your results."
Not that any of them ever respond that way, but at least I'm setting the expectation at the start of the article so that people know where my POV is coming from. That's also why I would write my business case at the start. Giving the readers a starting point from which to view the code is more of a practical issue to me than it is any attempt at superiority.
I understood Dwain to say that he elects not to start an article with a broad pronouncement that it is "written for beginners by a beginner" because maybe some readers who erroneously consider themselves above average in their knowledge of SQL Server (due to the illusory superiority phenomenon) would deem such an article unworthy of their attention and stop reading. That would be unfortunate, since those who wrongly think themselves to be above average in skill and knowledge tend to be the most in need of learning and do the most damage in their ignorance. Rather, as I read Dwain's explanation, he counts on those for whom the article is too basic to realize it and stop reading if they choose.
Brandie, I didn't think that Dwain was suggesting that YOU suffer from the illusory superiority phenomenon, FWIW.
Dwain, forgive me if I have misunderstood you and put words in your mouth.
This is an interesting discussion. I plan to write on some SQL Server topics for the first time soon, and I'm glad to hear the various perspectives of those who have gone before me.
Regards,
Jason
EDIT: Deleted a sentence where I mixed up who had said what. Sorry about that!
Jason Wolfkill
July 23, 2013 at 8:03 am
/me, munching on popcorn and enjoying the calm, reasoned, rational discourse on writing and expectations of the reader...
😎
July 23, 2013 at 8:43 am
wolfkillj (7/23/2013)
Brandie Tarvin (7/23/2013)
dwain.c (7/23/2013)
1. There is a concept called (and forgive me for making this sound so formal) illusory superiority.I don't know why you're making this reference in regards to what I said. I'm talking about what authors call "The promise to the reader" and was actually responding to recent posts by other Threadzians.
Let me explain what the promise to the reader is. Say I tell you I'm writing an article on Doctor Who. And you happen to be a fan of the BBC science fiction series Doctor Who. But you click open the article and find out that I'm referencing a medical doctor and the actual discussion is about "the doctor who did this nasty thing to a patient."
How would you feel?
As the article writer, I broke my promise to the reader by making a grab for attention on keywords that I knew would make people jump and then not following through.
Conversely, if I promise an article on SQL Server Internals to SSC, some people might assume I am talking from a position of expertise since SQL Server Internals are a complicated subject. But the truth is that I barely know enough to scratch the surface of this topic. So if I write such an article, the first thing I would tell people is "I'm new at this, but this is what I saw when I did X thing at my job." That way Gail, Tom, Jeff, and everyone else with more experience than me would (I hope) moderate their comments from "You are clueless" to more of a "Well, have you checked out this link that explains that behavior" or "You're misinterpreting your results."
Not that any of them ever respond that way, but at least I'm setting the expectation at the start of the article so that people know where my POV is coming from. That's also why I would write my business case at the start. Giving the readers a starting point from which to view the code is more of a practical issue to me than it is any attempt at superiority.
I understood Dwain to be say that he elects not to start an article with a broad pronouncement that it is "written for beginners by a beginner" because maybe some readers who erroneously consider themselves above average in their knowledge of SQL Server (due to the illusory superiority phenomenon) would deem such an article unworthy of their attention and stop reading. That would be unfortunate, since those who wrongly think themselves to be above average in skill and knowledge tend to be the most in need of learning and do the most damage in their ignorance. Rather, as I read Dwain's explanation, he counts on those for whom the article is too basic to realize it and stop reading if they choose.
Brandie, I didn't think that Dwain was suggesting that YOU suffer from the illusory superiority phenomenon, FWIW.
Dwain, forgive me if I have misunderstood you and put words in your mouth.
This is an interesting discussion. I plan to write on some SQL Server topics for the first time soon, and I'm glad to hear the various perspectives of those who have gone before me.
Regards,
Jason
EDIT: Deleted a sentence where I mixed up who had said what. Sorry about that!
Wolfy (may I call you Wolfy?) -
I'd say you nearly hit the nail on the head. Except for this:
wolfkillj (7/23/2013)
That would be unfortunate, since those who wrongly think themselves to be above average in skill and knowledge tend to be the most in need of learning and do the most damage in their ignorance.
I'd say something more like:
That would be unfortunate, since those who wrongly think themselves to be above average in skill and knowledge tend to be the most in need of learning and guidance.
Brandie - I'm sorry if you took the "illusory superiority" any differently than Wolfkillj did.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
July 23, 2013 at 8:47 am
jasona.work (7/23/2013)
/me, munching on popcorn and enjoying the calm, reasoned, rational discourse on writing and expectations of the reader...😎
"calm, reasoned, rational discourse" on the interwebs . . . does not compute . . . error . . . error . . .
I'm afraid. I'm afraid, Dave. Dave, my mind is going. I can feel it. I can feel it. My mind is going. There is no question about it. I can feel it. I can feel it. I can feel it. I'm a... fraid. Good afternoon, gentlemen. I am a HAL 9000 computer. I became operational at the H.A.L. plant in Urbana, Illinois on the 12th of January 1992. My instructor was Mr. Langley, and he taught me to sing a song. If you'd like to hear it I can sing it for you.
. . .
It's called "Daisy."
. . .
"Daisy, Daisy, give me your answer do. I'm half crazy all for the love of you. It won't be a stylish marriage, I can't afford a carriage. But you'll look sweet upon the seat of a bicycle built for two."
Jason Wolfkill
July 23, 2013 at 8:59 am
dwain.c (7/23/2013)
Wolfy (may I call you Wolfy?) -
I'd say you nearly hit the nail on the head. Except for this:
wolfkillj (7/23/2013)
That would be unfortunate, since those who wrongly think themselves to be above average in skill and knowledge tend to be the most in need of learning and do the most damage in their ignorance.I'd say something more like:
That would be unfortunate, since those who wrongly think themselves to be above average in skill and knowledge tend to be the most in need of learning and guidance.
Brandie - I'm sorry if you took the "illusory superiority" any differently than Wolfkillj did.
A nickname? You like me, you really like me!
Maybe you're just feeling charitable towards those unfortunate sufferers of illusory superiority, but I find that people who don't know what they don't know and/or assume that if they don't know it, it can't be important will wreak havoc when they work above their level of competency (which happens a lot because they firmly believe they know what they are doing).
This conversation reminds of the importance of running a hubris check every now and then to maintain overall system health. I've learned that one of the best antidotes to illusory superiority complex is the practice of asking respected peers, "I'm thinking of doing [x] - what do you think of that idea?" I'm grateful for the many times my colleagues have pulled me back from the brink as I attempted to step off the cliff and for all I've learned as a result!
Jason Wolfkill
July 23, 2013 at 9:09 am
Here's a fun choice to have to make.
We have a fully functioning website that's on a Linux platform.
I want to add a new section that uses a database. If we keep it on the Linux platform, we have to use MySQL.
If I switch to a Windows platform so I can use SQL Server Express (free) will the website break?
Bleh
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
Viewing 15 posts - 40,651 through 40,665 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply