Cloud Pace

  • Comments posted to this topic are about the item Cloud Pace

  • I'm reminded of the item about change in my signature line below.  And, at the pace the changes are coming out, it can be a little (or a lot) frighting because of EULA protections that protect the makers of bad changes. 😉

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

  • You know what the excruciatingly missing piece to all this is?

    Documentation. Not the BS that passes for documentation these days, I'm talking "For Dummies" level intro material that tells you, in English, what all these things do, what they're intended for, stripped of all the marketing hype. Even, dare I say it, an "index of indexes" kind of document, that lets you quickly narrow down exactly the kind of services you might need.

    Then once you've done that a nice, straight-forward set of documentation to explain (not just MS-style sound bites) what processes you need, how to implement them, what gotchas to watch out for, etc.

    But of course writing good technical documents is something of a lost art. It's hard, it's tedious, it's expensive, and it "slows down the developers" who are haring off after their next fever dream.

    Which means the rest of us are left foundering, trying to decipher ancient Babylonian texts without a Rosetta stone!

    Growl.

  • Today, the modern IT professional has to be more "cosmopolitan" in regards to knowledge and expertise. It's not like the old days where someone could spend a decade embedded in their cubicle knowing only enough SQL and C# to get by.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • roger.plowman wrote:

    You know what the excruciatingly missing piece to all this is? Documentation. Not the BS that passes for documentation these days, I'm talking "For Dummies" level intro material that tells you, in English, what all these things do, what they're intended for, stripped of all the marketing hype. Even, dare I say it, an "index of indexes" kind of document, that lets you quickly narrow down exactly the kind of services you might need. Then once you've done that a nice, straight-forward set of documentation to explain (not just MS-style sound bites) what processes you need, how to implement them, what gotchas to watch out for, etc. But of course writing good technical documents is something of a lost art. It's hard, it's tedious, it's expensive, and it "slows down the developers" who are haring off after their next fever dream. Which means the rest of us are left foundering, trying to decipher ancient Babylonian texts without a Rosetta stone! Growl.

     

    Some of this is changing, at least for the SQL space. We can edit the docs and submit a PR that MS employees can approve. Not perfect, but it does let some of us provide some knowledge that the devs at MS won't (or can't) provide. I've even started to look at "fixing" some of the demo example code where I can to make it a little more useful.

    I'd like to see this for the Azure (or AWS) docs as well. While some of this is auto generated from code, it often lacks some detail as things change. In a crowdsourced environment, the crowd can do some of the work, and also then remind (and ask ) the devs to review the changes and think about what they didn't include the first time.

  • Eric M Russell wrote:

    Today, the modern IT professional has to be more "cosmopolitan" in regards to knowledge and expertise. It's not like the old days where someone could spend a decade embedded in their cubicle knowing only enough SQL and C# to get by.

    I think this is true for the most part, though I do think things don't change quite as fast as we may think they do, at least for a many jobs. It changes, but we also need to use our expertise. The key is we need to be willing to change as we learn things, or see them done better, or we realize that some code/technique/framework needs to be implemented differently.

  • This was removed by the editor as SPAM

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

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