Constant Learning

  • Comments posted to this topic are about the item Constant Learning

    The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore Roosevelt
    The Scary DBA
    Author of: SQL Server 2022 Query Performance Tuning, 6th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • This was removed by the editor as SPAM

  • Heh... the previous post was SPAM about a "diet plan" that recommended ingesting cotton balls as part of the diet.  I agree that's a bit ridiculous.

    In that same vein, you don't want to "ingest cotton balls" while you're learning BUT, to Grant's excellent point in the final paragraph of his article, you DO have to know what a cotton ball is, what it looks like, reasons why you might want to put one in your mouth and when you should not and, if you do have a reason to put one in your mouth, whether you should swallow it or spit it out when you're done.

    The really smart folks know enough about certain things to be able to say "If you do it that way, here's what can/will happen and here's, perhaps, a better way to do it" or be able to ask the question (thank you Mr. Ozar) "What problem are you trying to solve"? and then be able to recommend that it doesn't actually need to be solved or a better way to solve it or solving for something else that has more value.

    To be sure, you also have to be extremely wary of the  "Too cool for school, shiny new tool" syndrome.  A great example of this is when PowerShell first made a reasonable appearance.  Everybody and their kin was writing code to make a centralized backup tool that would actually fire off backups on servers from a central control instead of having a scheduled backup system on each server.  Many people never considered what would happen if that centralized backup system silently failed or comms with the machine it lived on were severed.

    Another recent example is Python.  The tool is EXCELLENT!  But, you shouldn't do the equivalent of rewriting BCP or BULK INSERT in it like a lot of the folks that I know are doing.  Yeah... it'll help you learn the technology but it should fall into that last paragraph that Grant wrote instead of becoming the "go to method" like some people I know are trying to use it for.

    I saw a presentation last week by one of the companies I do work for of what one group was trying to do in that area.  They've been working on it for months and it's still "not there yet".  I summarized their efforts in my mind as "Exporting simple text data from SQLServer tables, doing an import to another type of database (SQLite), converting a bunch of things to JSON strings (not arrays), doing data validations and "upsert" evaluations, and doing "joins" to other sets of data formed using those samee methods, and doing it all in batches of 1000 (to keep from blowing out memory) one row at a time (RBAR on Steroids).  And they've not even gotten to the "meat" of what the process is supposed to do yet.

    The really bad part is that they tell me "Jeff, you just don't understand...".  I'm thinking that I'm not the one that doesn't understand here but I can't stop them.  If they spent as much time learning the right way to do it in SQL Server as they are about all this new stuff, they'd have been done months ago.

    And so I'll add to what Grant has said in his wonderful article... "Learning doesn't have to be about something new.  It just needs to be about something you don't know" because a better way might be right under your nose.

    Ok... enough of that... everyone go get your Index Maintenance done using "Best Practices" because it's absolutely critical to performance... right? 😀


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

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Constantly learning is one of my guiding principles. I love to learn about new things, methodologies, patterns, and the like. I love to learn of ways I can make my job easier or quicker to do. I'm one of those types of love to learn, for learning's sake.

    However, where I work, I am in the minority. Most people in IT (both operations and development) don't have any desire to learn anything new or current. Some are even very vocal about not learning anything new and staying with whatever technologies they've used for the last 10 or 15 years. A few will even deceive themselves into thinking that old, out of support technologies will be better supported than newer technologies. (Yeah, I've had people say that out of support technologies will get updates, even when I point out to them notifications from Microsoft or other vendors that the old tech will never receive any updates.)

    I wonder why so many people where I work are so adamantly opposed to learning anything current. From my point of view, learning is so essential that to be stagnant is equivalent to letting myself die. This job has shown me that a lot of people need some external motivation, which isn't available where I work. I work for one of the largest state departments in my state. Therefore, we have no competition. Competition is a major inducement to learn anything new or current. Our position in the world is assured of because we don't need to fight to hold our place. Consequently, it's possible to depend upon old technologies, like Excel spreadsheets, to do lots of the work. And trust me, there's a LOT of Excel spreadsheets used to report to funding sources like the Federal government for grant compliance and regulation. We do have a lot of SQL 2008 databases around. They're being replaced, against protests, only because they're so out of date that they's no longer supported and not being supported may potentially result in fines or greater regulation or auditing. However, if it weren't for that we'd never upgrade.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod makes a great point that there are a lot of people in It who cling to the "if it's not broken, don't fix it" mentality and a lot more who just can't seem to get the fact that if you have to put hours every day to keep a system going, it's already pretty broken.

  • Oh, I know all too well how people try to avoid doing new & different stuff. The issue to me is pretty clear though. Learning is a skill, like any other. If you don't practice, it atrophies. Then, when you really MUST learn new stuff, it's even more painful.

    So all those people patting themselves on the back for never upgrading, are just looking at bigger pain when they are finally forced to.

    The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore Roosevelt
    The Scary DBA
    Author of: SQL Server 2022 Query Performance Tuning, 6th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply