Posted in tSQL, tSQL Tuesday

TSQL Tuesday #133 Wrapup

Thanks to everyone who participated!  I’m excited to go look up some interesting information, see some new presentations when they come out, test out some PowerShell splatting, and start putting demo and sample code into SQL Notebooks!

Rob FarleyThe Other Side of the Room: Rob has learned mostly non-technical lessons. He encourages people to put themselves in the presenter arena. When he gets useful feedback, he takes note and tries to give presenters he watches the same kind of feedback.

John McCormackPowerShell Splatting – What was wrong with backticks?: John had a lot of backticks in his PowerShell code to make it more readable and “keep” code on the monitor. An attendee asked why John didn’t use splatting. John was intrigued and learned how to create a single variable at the top, consisting of an array or hash table of the parameters used in the code. This makes the code easier to read both for attendees looking at a slide, and others using your code.

Jess Pomfret –  T-SQL Tuesday #133: Jess has learned Git and GitHub from contributing to dbatools (woot!) She now hosts presentation demos/slides there. She also learned how to run Docker containers on her laptop for presentation demos. Thirdly, she learned how to build pester tests to ensure her Docker containers are in the correct state for her demos.

Aaron BertrandWhat Else Have You Learned:   Aaron has learned that not all airlines get you where you need to be when you think you need to be there, and that rehearsing content is valuable for a better idea on the content timing. And, sometimes, there are technical difficulties. The two biggest take-home lessons are to be prepared, and do NOT ad-lib 🙂 Oh, and pay attention to what presenters you’re watching do when the going gets tough, so you can learn those lessons a little less painfully! Thanks, Aaron!

Deborah MelkinWhat Else Have I Learned From Presenting?:
Deb learned how to use SQL Notebooks for presentation by converting each script for her T-SQL 101 session into a Notebook. Now Deb is writing a presentation on a Starter’s Guide to SQL Notebooks, which I can’t wait to see because I too need to figure this stuff out! Deb is another converted user of Git and GitHub, and has learned some GitHub-based swear words along with a few lost files. Thanks for persevering and sharing with us!

Tracy BoggianoWhat Else Have I Learned From Presenting?:  Tracy learned that PowerPoint subtitles will get closed captioning! She also learned a whole bundle about Linux when presenting on a Telgraf/InfluxDB/Grafana stack she was involved with setting up at work.

Mikey BronowskiWhat Else Have You Learned From Presenting?:  Mikey had written a blog post about saving Outlook attachments with PowerShell, but wasn’t allowed to use PowerShell at the time in the office. So, he figured out how to save attachments from multiple emails that fit some criteria, using VBA. In Outlook. Cool!

Deepthi GoguriWhat Else Have I Learned From Presenting?:  Deepthi learned some great technical concepts including memory grant connections, redundant joins between tables and their relationship to foreign key constraints, and some information about the NOEXPAND hint. Hmm, I will be looking that up too!

Kevin ChantLearning New Things By Building Demos:   While building demos, Kevin has learned about SharePoint setup and configuration, how to record and edit a video in Camtasia, and Docker setup. Thanks, Kevin! I might not look up the SharePoint config though – I’ve managed to avoid it up to now so I’d like to keep that record going!

Todd KleinhansWhat Else Have You Learned From Presenting?:  Todd learned that sometimes the most amazing ideas aren’t feasible for one reason or another – mostly one of the three roots of any project: time, resources, quality. He’d like to build a VR version of a technical presentation, which sounds amazing, and I hope the near future gives you more of what you need to continue on this project!

Nate Johnson –  Learn By Presenting: Nate tried some Twitch streaming but didn’t have many views. However, he’s been involved in small group learning sessions and realized that he talks to quickly, he enjoys audience interactions, and the infamous, Never Type in Demos!

Justin Bird –  T-SQL Tuesday #133: Justin learned about the contract that SQLBits has with the speaker. The speaker puts in a lot of time and effort and gets… feedback. So, anyone attending a presentation, anywhere – please fill out feedback forms to help them get better! Great point, Justin!

Elizabeth NobleFilling In the Gaps: I love Elizabeth’s use of “sweet potatoes” as a swear word, which is completely unrelated to this topic. She learned how to create VMs with PowerShell, including domain controllers. But IMO the most important take-home message is that we don’t have to know all the answers, but be willing to learn!

Honorable Mentions:

Mike Walsh –  Presenting: What I’ve Learned: Mike got struck with a case of the 2020 Blursday syndrome, so that’s why this is in the honorable mention (aka a little late) section. He talks about learning about log chains and what doesn’t break them, from the audience. He also recorded a video about presenting and things he’s learned about himself and life through presenting 🙂

Joshua HandlerSurprise!! You learned something you didn’t expect!: Josh had some blog host “unvisible” issues.  Josh was presenting on dbatools and was talking about profiles. Afterword, one of the attendees who was also an MVP, let Josh know that there were many profiles you can use with PowerShell. He also got good feedback about his first time presenting!

Thanks again, and now I challenge all of you out there to think about what presentation you could write, and what ELSE you might learn while writing that presentation (or presenting it!)  Go forth and learn – but stay safe and stay healthy!

Posted in tSQL, tSQL Tuesday

T-SQL Tuesday #133: What (Else) Have You Learned from Presenting?

This month, I’d like those of you who have presented, or written a presentation, to share something technical THAT DID NOT RELATE to the topic of the presentation, that you’ve learned in writing or giving the presentation. This can include a work presentation, for those of you who haven’t spoken at an event! 

Why do I ask?  Well, if any of you have heard Allen White (b|t) speak on any topic, he will start his presentation speaking about how much PASS has contributed to his life and career. He will then talk about how every person has a story to share, and there will be a piece of that story that no one has ever heard before. We ALL have something to learn from each other. He will also tell you that you will learn more than you ever thought just by writing and presenting on ANY topic, as well as answering questions!  So, I’d like folks who have done this to share and encourage – especially the new folks who are on the fence about presenting. Feel free to go more in-depth with some of the technical details of your learning than I did!

I will share a couple of stories about my own experiences. My first presentation at our local PASS user group was a lightning talk about a bizarre performance hit we took from a foreign key with an ON DELETE CASCADE option. It was a rare scenario, so I figured most folks hadn’t run into this.

As I was researching foreign keys in general, I realized… hey!  Did you know there were other options for updating and deleting data tied to foreign key constraints? I don’t know that I’ve paid attention to that for the last… at least 10 years. I’ve never seen any of these options used in code I’ve maintained or identified as problematic.  You can specify default behaviors for both delete and update options – for example, if I update the value that the foreign key constraint points to, I can change all those foreign key values to be NULL. Or to update that foreign key value to the new value. Or… not do anything. There are ramifications for all of the choices, but I could definitely see how they might be useful in certain scenarios.

Also, people were interested enough in the topic to ask about indexing on some of the different fields, and asked me to expand this into a full presentation. I did so and presented at our next local SQL Saturday, including testing with the indexes that were recommended to me.

Learning summary:

  1. tables may show up in the execution plan even if they weren’t in the query AT ALL (look for constraints!)
  2. there are other options for coding foreign keys to handle updates/deletes to the primary key data that could be useful elsewhere
  3. Reinforcement: Indexes with low cardinality don’t always improve performance!

I also wrote a book on refactoring legacy T-SQL. I was talking about functions, and how SQL Server’s STATISTICS IO won’t show IO that a function performs. I remember thinking, “I CANNOT write a book in 2019 that talks about running a trace!”  So, I started using simple Extended Events to show the increased IO for functions that the native SQL Server STATISTICS IO sneakily avoids. I need to start making more use of Extended Events but this was a great .. kick in the pants to get going on those, as well as being able to code a very simple, more modern solution to share with readers on how to more accurately find IO stats of the SQL you’re running/tuning!

I could continue about buying a “lab” laptop, re-learning how to use Oracle Virtualbox, dealing with networking (not one of my strengths), using SQL Server core (sooo fast to install!), and all of those fun things. But, there will be future blog posts on those topics, and it’s time for others to share THEIR stories and experiences!  Thanks for reading!


Posted in tSQL, tSQL Tuesday

Learn from… me!

This image has an empty alt attribute; its file name is T-SQL-Tuesday-Logo-e1518373137845.jpg

Kerry Tyler (b|t) asked us in this month’s t-SQL Tuesday topic to talk about a lesson we’ve learned, in order to help others learn FROM our mistakes without also making them! I’ve wanted to talk about this for a while, as I’ve now seen this behavior from both sides and I know how detrimental it can be to everyone involved.

What is this I speak of? Our fraught relationship with third-party software vendors. I know, I know, we all love to hate them. (Even those of us that ARE them – we also have third-party software, we completely get your pain.) In a couple former jobs, it was pretty clear: “Hey, Sales just sold software so we need the software to do this in a time frame that’s way too short, and just asking for pain all the way around.” Developers grumble, QA grumbles, shortcuts get taken, functionality and performance are very far from meeting expectations, and everyone – customers, developers, sales, PMs, account reps…. EVERYONE is pointing fingers at each other.

It’s at this point that everyone loses sight that we ALL have the same goal. It’s easy to do – each party feels like they’ve been strung along (which is probably true). No one is happy with the end result. Flashback to when I was on the phone with a customer, who had rolled out this wonderful new functionality and performance was so bad that literally no one could use one of the screens in the software. This was my first interaction with these customers, as my immediate supervisor had moved on to greener pastures a week earlier. It was Friday night (of course), and I had plans with my family and was a bit frustrated.

I was looking at the SQL (which, btw, was generated by the application and not in a stored procedure.) First of all, any SQL changes would require an application patch. Whoops one. Second of all, wow, was this SQL bad. Cartesian join of large tables, so many returned columns that indexing was really out of the question, and a poor plan. As I was looking at the code, I remember saying, “I don’t think I can fix this in an hour. I don’t think I can fix this in SIX hours.”

So, at this point I learned that teleportation is possible, because there is NO other explanation for how the account manager got to the spot standing next to my desk from his office upstairs in the timeframe of 1 second. He frantically motioned me to hit the mute button (which I did), and then followed with, “We can’t say that to the customer!”

My response: “I’m not going to lie, that’s going to be really obvious really fast that this isn’t anything we can fix RIGHT NOW.”

What we didn’t hear: the customer hit THEIR mute button, turned around and said, “Finally, someone is going to tell us the truth!”

That SQL didn’t get resolved that night. What ended up happening is that enough people on the customer’s end went home, so the remaining people could actually run the query. The next week the SQL was pulled out of the application and I wrote a performance-tuned stored procedure. However, something much more magical happened – we started trusting each other.

My new boss (since the previous one had left the week before) was also new to the company. He stepped in to work with this customer (who had very legitimate reasons to be frustrated.) A few other people who had been involved in these interactions were encouraged to step out and let us handle the problems. I started working very closely with the customer, and my boss started being very transparent with them. They were incredible testers; we started working together as partners when we had a release that we felt was ready, and would get excellent feedback from them. With the significant increase in communication, we could really focus on what was most important for them and they would help us get it right, before they rolled it out to production.

What did I learn from this? Shut up and start listening. Try to understand where folks’ frustration is coming from. BE HONEST. Remind everyone that you are all sharing the same goal: the customer being successful. Really focus on what you can do on your end to reach that goal. Encourage people around you to focus on what they can do to help reach that goal. No matter what your scenario, don’t think of people as customers – think of them as PARTNERS. Treat them as partners. Encourage them to BE partners.

I still have a relationship with a couple people from that customer – they have become friends. Real friends. I know I can reach out to them if I need help – hardware questions, home lab setup questions (one of them is a hardware guru). I am pretty sure they would reach out to me if they had a tSQL question as well. Some of them were going to join me at PASS Summit this year (partially because we know this awesome restaurant in Houston, but also because .. we’re friends.) They have brought a lot of value to my life 🙂 So… please take what you can from my learning, I hope it brings you the good things it’s brought me!

Posted in tSQL, tSQL Tuesday

Life Hacks to Save Our Sanity

This image has an empty alt attribute; its file name is T-SQL-Tuesday-Logo-e1518373137845.jpg

Jess Pomfret (b|t) asked us in this month’s t-SQL Tuesday topic to talk about a life hack we’ve done that’s made things easier for us. This is perfect timing for me; I wanted to share a couple of stored procedures I wrote for the book (Refactoring Legacy T-SQL For Improved Performance). The CodeCascade procs can be found on a GitHub Repo called CodeCascade.

Actually, the idea for this code started back when I listened to Andy Yun (b|t) give a talk about nested views. I was dealing with a 2,000 line stored procedure that would be interesting to rewrite, but it really shouldn’t take me that long, right? I mean, 2,000 lines. Except that it called a function that was also 2,000 lines, which called a few procs, not to mention a few other things the original proc called, and then … well, yeah, you get the point. 20,000 lines of code later, I was like, WHAT did I get myself into?

So, since we all know how excellent we are *cough* at estimating time to perform tasks, I figured it would have been a good thing to have known about this cascading miasma of code before I dove in head-first. Andy’s presentation had code to show the cascade of a view – all of the views it called, and views they might call. I wanted to adapt this to work for stored procedures and functions as well. (Forewarned is forearmed, after all.)

So, I blithely knocked together some code to tell me exactly what objects (procs, views and functions) that my code called, using SQL Server’s dependency information. I went to run it on that exceptionally offensive proc. And guess what? It blew out after 200 recursions. So, I set the limit to 400 recursions, and… it blew that out as well. OH NOES! Well, I had also set a kind of breadcrumb trail field in this because I was particular about the sorting (I wanted each cascaded item to be under the parent that was calling it.) So, I had each object line check to see if that ID was already in the breadcrumb field, and if it was, add a message that it was part of a loop, and stop trying to recurse through that particular line.

Once that was polished up, I also did the “reverse” – what code CALLS my code, and what code calls THAT code? This is again based on dependencies, and checks for that eternal loop.

These procs have come in handy many times. I encourage you to use them and modify them if you’d like, but it’d be great if you left the intro flowerbox on that attributes the original code to me. If you do make changes that you think others would find helpful, please feel free to let me know and I’d be happy to add your changes and attribute them to you as well!

I hope these can help you as well 🙂

Posted in tSQL, tSQL Tuesday

Dealing with Impostor Syndrome

Jon Shaulis (b|t) asked us in this month’s t-SQL Tuesday topic about impostor syndrome. Do we have it? How have we worked past (or around) it? The first question is easy – I don’t know anyone who hasn’t dealt with impostor syndrome, unless that someone is new enough to whatever job or task they’re doing that they don’t have enough experience to know there’s no way you can ever know everything.

The second question can be more difficult. Also, if you lose self-confidence in one area of your life, it can destroy your self-confidence in all areas of your life without you even realizing it. Being self-aware, which is something we should all strive for, unfortunately makes you more prone to this in my opinion.

So, we all think of ourselves as “normal” because we grew up with us, and we know how we feel, and how our family or peers were or are, and what we look like in the mirror, and how much we curse when we accidentally jam our foot into the doorframe – all of those things are familiar and “normal”. We know what we do know and all of those things that we don’t know. When we see someone who knows more or is better at something than we are, it’s very easy to fall into the trap of thinking that person knows so much more “stuff” than we do.

But there’s something that it’s easy to forget. You know something that no one else in any given room does. You are better at something than each and every person. And the opposite is also true: each and every person in the room can do something better than you, or knows something you do not. Everyone has unique experiences and our brains all do “thought algebra” differently. Wait, whut?

So I can look at a and b, and to me, a + b obviously equals c. To someone else, a + b = m. Neither of us are necessarily wrong, everyone just collates information differently, and not everyone solves things in the same way. Nothing has more than just a single solution (well, except the meaning of life, but since no one has figured that out yet…)

So what does this have to do with impostor syndrome? Everything, actually. It’s very hard to do, and I am just as bad as everyone else with this, but we all need to realize how special and amazing each and every one of us are. (It’s still hard to not say “each and every one of you”, and to include me in the amazing people. See?) Maybe there are skills we still need to learn, and we probably will learn those skills. But as people, we are all unique individuals with the capacity to do amazing things. We also need to surround ourselves with friends who remind of this regularly. Discussing this with people we trust, who we know care about us and not about what they can get from us, will go a very long way to help us stay in the right frame of mind when dealing with impostor syndrome!

Thanks for listening 🙂

Posted in PASS

PASS Summit 2019 Networking Dinner

It’s that time again – time to start thinking about the networking we’ll be doing while we’re at the PASS Summit! I have a list of networking items I’d like to check off, including… well, ask me about it when you see me at Summit!

I’ll be organizing the Networking Dinner again this year. We’ll be meeting at the Tap House Grill, and I don’t think I’m going to split it into different times. Just please show up any time between about 5:30p and 8p! This will give folks attending precons time to go and get rid of your laptop bags (but please stick several business cards in your pocket!)

Here is the Eventbrite link, please go ahead and get a free ticket so we can get an idea of how many of us will be descending on the Tap House. (I feel like we should at least try to let them know about it!)

This really is a wonderful event and folks make long-term network relationships and friendships at this dinner. Please join us, get to know more of us, and start early to make the most of your PASS Summit experience. I’m looking forward to meeting you!

Also, I’d like to find someone who would be interested in taking over the organization of this event. If you think you would be interested, please talk to me at Summit this year. There’s not much to it – talking to a few restaurants, posting a blog and sending out to the Twitters.

See you soon!

Posted in tSQL Tuesday

What I Use(d) Databases For

Isn’t it the joke that the cobbler’s son goes barefoot, or that the doctor’s kids are always sick?  So, does this mean that database people should.. use databases?  Well, of course!  This month’s T-SQL Tuesday is about what we use databases for more in our personal lives. Thanks to Todd for the interesting topic 🙂

I started using them personally for a couple of reasons – for practice, and because, well, I needed to track data.  So, what do we need to track data for? Well, in my case, it was (dum dum dum) …. my first wedding. Who were invited? What were their addresses? Were they invited to the shower? What gifts did they give? (Inevitably my mom needed to know so she knew what level of gift to give their kids when the time came. You know how that goes.)

I also went ahead and printed out my own invitations. Do you KNOW how expensive those things are?  Well, if you’ve ever gotten married, then I suppose you might. You can get embossed, very pretty card stock for a WHOLE lot less than the invitations.  And then, voila – print them out from the database. Okay, I have to make a confession – it was in Access. (I know, go ahead, get it all out. Yuk yuk yuk…)

So, since I started tracking presents, I kept doing that -and woot, printed thank you cards!  And you know, while I had everyone’s address in there, uh… CHRISTMAS CARDS! Because you have to make sure you send Christmas Cards to everyone who sent them last year, but if they haven’t sent them to you in two years, you don’t have to send one. But then they send one at the last minute and you have to send one back at the laster minute, and…  and then I just gave up sending Christmas cards anyway because I always wrote long cards with info and no one ever wrote a *#&$ thing back and just signed them.

I have started living on Kanban boards. I’m trying Trello for personal stuff to see if I can get my life a little bit more in order and under control. This may be impossible, but I need to at least try. Even though that’s not directly me designing and coding the database, it’s… similar.  Other than that, though, I keep my life pretty simple. So, no databases for me outside of work anymore. And you know, that’s okay 🙂


Posted in tSQL Tuesday

Dipping into the Cookie Jar

Chocolate chip – I mean, who are we kidding? My Grammie’s homemade.. I don’t care that she followed the same recipe on the back of the chocolate chip bag as everyone else does, they were amazing. And no one can make them the same….

But that’s not really why we’re here. It’s T-SQL Tuesday and Shane O’Neill has asked that we talk about what excellent things we’ve done that keep us going. Now, most (most…) of us tend to be humble, but I know there’s those wins that keep us bouncing with happiness and excitement when we’re not cursing the dumb….. (sorry, too much of the dumb last week.)  Positive!  Positive!

It’s funny because Shane (t|b) is actually involved in one of my cookie jar experiences. It was, what, Summit 2017?  I was sick. Like, uber Nerd Flu, couldn’t sit through an entire session without disruptively coughing, miserable, only-one-party-a-night, sick. (I know, right?)  Friday night, Lou Gonzalez and I dragged me to the Tap House, because.. well, the Tap House. And there were a few #SQLfamily hanging out. There was a couple of English guys – one attendee and his dad  – playing pool. They were amazing to watch, so I was huddled in my misery watching them.

A man named Matteo came over and asked me if I wanted to play. I figured I could at least try, and we were joined by Shane and a great guy named Kevin (t|b). And in my miserableness, I proceeded to play the best pool I think I’ve ever played.   How is this memorable? Mostly because I got to meet some really cool new friends.  And, sometimes even in low points, something great comes out of it.

Okay, okay, there’s more to my cookie jar. My brother owns a small tech support company, and I wrote a SQL Server backend/Coldfusion web front end (enough with the laughing, peeps…) application to handle his techs, their customers and the work. He ran his business on it until last year. 16 years, people. With extremely low maintenance and not much need for enhancements. His entire, successful business.

In my last job, there was functionality that needed to run 6 times in about a 15-minute time span. Problem was, each run took about 2 and a half hours. That kinda math just doesn’t add up. I took that crazy thing down to about 30 seconds per run. Now, granted, the code has to be a little messed up for you to make that kind of improvement, and that’s a facepalm of an entirely different sort.  I have had a couple of these also in my current job, and it never gets old.

Also, in my current job, I’m finally becoming included. The DBAs were the rogue people who always said no and almost everyone went out of their way to avoid us. Upon our move to Scaled Agile, I fought to get one of my team on each of the scrum teams, so we could catch issues before they happened, and become partners in coding/education with our developers.

I’m being asked to be involved in higher level planning – architecture decisions, process improvements, and also in some other ways. I’ve also become much better at listening. Because of this, I can help in some less obvious ways, with more personally-related issues. Bringing that kind of value to my company, my boss and my co-workers – many of which have become good friends – has some super-good feelz associated with it.

And, I cannot end this without mentioning my first horse. He had a rough babyhood – someone shot him as a youngster (in their favor, he really did look an awful lot like a deer, but…)  They couldn’t remove the bullet from his neck because it was too close to arteries. He didn’t have much interaction with people – when he did, his would had become infected and maggot-infested (sorry for the gross) and his skin had grown around his halter. So they had to hold him down to cut the halter out of his head and clean the wound.

He had a lot of trust issues, and was a powerful boy. I spent a lot of time learning how to bail off of him (not always by my own choice.)  But, he was incredibly athletic, and needed someone to love and believe in him. He was my boy, and got me through a whole lot of rough patches in my life. I also really believe that I saved him too, though – he would have gone from owner to worse owner to the slaughterhouse eventually because he would have been considered “dangerous.”  It took 12 years of work and love and trust before he really calmed down, but I was absolutely his person as much as he was my horse.   Earning his trust and love was an incredible thing, and I will never forget that, or him.

Thanks for listening! I know all of you folks reading this have done amazing things as well, and I’m looking forward to reading about them!

Posted in tSQL Tuesday

My “Why”

We  all have different reasons for getting up every morning.  Going to work can be another story, but a lot of us do it. I’d guess that “most” people go to get a paycheck, so they can come home and live their lives.

So why do I go to work where I do, and why have I left the jobs that I’ve left? Well, let’s take a short stroll down memory lane.

I started my career in a place that was mostly grant-funded, working on Early Childhood Education-related projects. We had a fairly decent tech crew to support the projects, but there wasn’t much focus on intentionally writing the funding for paying the technology staff into the grants. There are support dollars that are a portion of each grant that, when grants are plentiful, were enough to cover the tech staff. Unfortunately, when  grants started to dry up, the support dollars weren’t enough to cover all of the staff.  My boss was someone I respected, and the work was worthwhile and enjoyable, but I preferred to get a jump on a new job instead of risking a RIF scenario.

My second job was for a very small company, and one software package that I worked on helped support babies in the NICU. There was a lot of good feels there. Again, the person who mostly was my boss – not technically, I guess, but with whom I interacted with daily and who directed the course of what I was working on mostly, was someone who I both liked and respected.

Unfortunately, there was a big push to really grow the business, without understanding the limitations that sales were working under. Additionally, folks who weren’t living up to the new (ridiculous) sales quotas were “punished”, which lowered their ability to make new sales even more. And, upper-level management was promising customers functionality in timeframes that were extremely unreasonable given the resources we had available. The environment had become extremely toxic, and watching people I respected get treated poorly was the last straw.

Where I work now has had some fluctuations, both in staffing and organizationally. There were times when I wasn’t sure whether the job was still the right fit. But, I am again answering to someone I have a lot of respect for. I also feel like I am making a (slow, but) positive difference in the company, both in identifying process improvements that should happen, as well as performance improvements needed in the software.

So, I guess what it comes down to is that if:
1. I am working for someone I respect, whose values and direction I agree with, and
2. I feel like I am making a positive difference and my skills/knowledge are respected and appreciated
then I am happy to come in and work hard do my best for my team, my boss, and my company.  This may be simplistic, but it seems to work for me!

Posted in PASS

PASS Summit 2018 Networking Dinner

It’s that time again – PASS Summit!  Woot!  I’ll be organizing the Networking Dinner again this year – thanks again to Steve Jones (b|t) and Andy Warren (b|t) who organized it for several years and helped a lot of us meet a lot of other us’s  🙂

Grab some tickets here!

This event will be held on the Monday of PASS Summit – that would be Monday, November 5th.  We’ll meet at the Yard House restaurant in Seattle, which is a quick walk from the conference center. Pre con attendees and all other early arrivals, please join us!  You will have a chance to sit and talk to other conference attendees.  Dinner is not paid for by us though – that’s on you.

Hope to see you all there!