A week and a half or two weeks ago or so, one of my coworkers, who actually is very skilled at SQL, invited a couple of coworkers and me to go to the monthly meeting of Oregon SQL in downtown Portland between 6 and 9PM, and then informed us this morning that he was unable to go because he had custody of his daughter tonight. So, after quickly eating some food on the PSU campus downtown after carpooling in, I and two coworkers navigated our way around the silly coeds and found our way to the building where the meeting took place, on the 9th floor of a building, and though we were a few minutes late, we arrived in time to chat a bit with our neighbors, grab our nametags, and get a couple of tacos apiece. I made sure to grab the chicken tacos as the pork ones were clearly a no go and one can never be too sure about fish, especially with a foot like I have. At any rate, thus provisioned, we were ready to go, at which point the various representatives from Microsoft were introduced for today’s meeting.
The first session of the evening, which lasted about an hour and a half or so, was mostly done by Sanjay Nagamagalam (I hope I spelled his name right), who had to deal with a pretty fierce crowd that seemed pretty eager to poke at Microsoft on areas like adding too many features for novice users who didn’t know what they were doing, people like myself, in other words, or for their aggressive desire to take telemetry data from users. His ostensible purpose was to describe the Modern SQL Server Management Studio, which he did, but his progress was derailed by continual questions from the audience from people whose status was not as curious but fairly new SQL programmers but seasoned and expert database administrators, often contractors for various small and midsize companies. The goals for modernizing SMSS were fairly straightforward, even slogan-like: learn from the cloud, apply in the in-box program updated monthly, and support both online and more traditional computer-based uses of the software. The speaker also claimed to be looking for deeper engagement with users of SQL, and if that’s what he wanted, that’s what he got.
Aside from this, he had a lot of pretty pictures in the mock-up section to use, which showed a start page that could be customized, easy ways for users to show feedback by sending a smile or a frown, as well as some useful edits to the notifications section. Needless to say, the users in the room wanted more, including notifications of long-running queues, which seemed to be a nearly universal want among the developers in the audience, even if it was not part of the mock-up shown. After this the speaker discussed the strategy of monthly releases, separating the tools for developers from the production servers completely, and the use of telemetry to determine what SQL users were actually using the software for, which inspired a lot of hostility from the audience. Many of the developers commented that they used fairly old versions of the server software and that the companies they worked or contracted for tended to be rather leery about adopting the most up-to-date software, preferring instead to use what was tried and true. It was a room that was pretty heavy with resistance to change, from what I could tell.
After the first session there was a short break, at which point my coworkers figured that the material was way over their head, and not wishing to lose my ride back from Downtown Portland, and agreeing that the material was definitely not remotely at a beginning level, I went with them to the Rogue Brewery on PSU campus, where I had a root beer, my coworkers had some Pumpkin Ales, and we shared some tater tots. While my coworkers drank, and we waited for our ride to arrive, which ended up going to the wrong Rogue Brewery in the hipster district of NW Portland, my coworkers and I discussed various matters of our corporate data architecture, including the feasibility from a technical standpoint of developing a data warehouse and dealing with the anarchical nature of the data we have to work with, and the difficulty in making sure the data is of sufficiently high quality to use for forecasting and analytical purposes. Once the car managed to find us, and smelled the pumpkin ale on the breath of my coworkers, we were off. It was a pleasant enough meeting, and I joined PASS afterward, which is the parent organization for Oregon SQL, including more immediately practical groups like that for Excel users and readers of books on data . It is my hope that not all meetings are tedious and technical, and that there are at least a few concessions made for those of us who are clearly not experts when it comes to SQL.
 See, for example: