Sharking

The title refers to a term I had not given much thought to in years, if not perhaps decades. But first let me mention what prompted the memory.

This weekend my daughter was competing at the State Odyssey of the Mind competition in Binghamton, NY. While waiting for her team to compete, I noticed a member of one of the other teams walking around with a stuffed, cloth sharkfin pinned to the back of a sport jacket.

This reminded me of a t-shirt my mom made for me years back with a similar design.

So, you may be asking yourself, “why?” and perhaps asking “what’s the point of this particular blog post”.  I’ll endeavor to answer both. But first we have to jump back into the time machine and again go back to my days at RPI. The year is 1989 and I’m now helping out with the Student Orientation (SO) staff. We were a bunch of students who would return to RPI over the summer and help the incoming Freshman class get oriented while they visited RPI in prep coming in as students in the fall.

Back then, the ratio at RPI was pretty lopsided, it was 5 men for every one 1 women. This among other things lead to some women using the phrase, “The odds are good, but the goods are odd.” In a strictly mathematical sense this was in a way accurate, if a woman wanted to date, she had 5 men vying for her attention. The reality of course was much different. It meant that if a woman didn’t want to date, she still had 5 men vying for her attention. (Of course it was far more than that since things didn’t divvy up nearly as cleanly.)

This was a tough social environment and combine that with fairly geeky students who often didn’t develop good social skills in high school and you often ended up with a lot of awkward situations and honestly, some pretty bad behavior all around; hence the goods being odd.

And unfortunately, some SO staff weren’t immune from being problematic. We tried to self-police, but there were always the 1-2 men who would be extra friendly to the incoming women and like a shark swimming the waters, look for their easy prey. We called this sharking. We would look out for it among ourselves and try to stop anyone SO advisor we thought was doing it and if they were particular egregious, make sure they weren’t invited back the next year. But the problem definitely existed.

My mom, bless her heart made me a shirt with a shark fin on the back, not because I personally was a shark, or to mock the problem, but more to highlight the problem and help us be more self-aware.

So, this weekend I was reminded of sharking.

So why bring it up? Because, being a member of several communities, including IT savvy communities, caving, and others, I still see this as an ongoing problem; someone in a position of power or influence, preying upon the newcomers; often young women. Now it often can start out with the best of intentions and without the person meaning to. You see someone new, they ask for help. You decide to mentor them. You’re just being helpful, right? But then it becomes the extra friendly touch, the slight innuendo in a comment, the off-color joke or even the outright blatant consent violations.

Watch out for it. Don’t do it and if you catch others doing it, say something. Nip it in the bud. If you’re mentoring, mentor. Provide them with professional guidance and advice. Don’t use it as an opportunity to prey upon their naivete and lack of knowledge or experience. Remember, as a mentor, you are in a position of power and influence and so you should be like Spiderman and only use that power and influence for the greater good and to help them, not to help yourself.

And if you do for some reason find yourself slipping beyond the role of a mentor and your mentee also appears to be comfortable with this (hey, it does happen, we’re all human), then STOP BEING THEIR MENTOR.  Make it clear that you can’t do both. A mentor, by definition and nature, is a position of influence. Don’t mix that with relationships in a professional setting. Just don’t.

As many of you know, I love teaching, it’s a reason I’m a cave rescue instructor and a reason I teach at SQL Saturdays and at other events.  I encourage folks to teach and help mentor others.  But please, be aware of boundaries and keep it professional.

Oh and a final note, I’m not immune to my own follies and mistakes and if you ever catch me crossing a line, by all means call me out on it. I don’t want to be “that guy”.

 

Slacking on the Job: Or using someone else’s brain as your own!

This post by Thomas LaRock came across my feed a few weeks ago. I’ve had it in my queue to write about since then. Basically he talks about cutting back on using Slack communities. For those not familiar with Slack, it’s a tool used to basically chat with other folks. It can be used internally for companies, set for just two people, or for larger groups of people.

But before we go further, let’s jump in a time machine and go back to the fall of 1985. I was a freshly minted freshman at RPI. I was so freshly minted, one or two of my friends to this day joke about how minty fresh I smelled.

Back then the main computer on campus was Sybil, a dual processor IBM 3081D. Some students had written a program called *CB. Some of you may recall the popularity of CB radios in the 70s and 80s. (If you’re too young for that, click the link back there and read up on it). *CB was a computer based version of it. It had as I recall 10 channels; 0-9, 0 being a ‘public channel’ and the other 9 used for different types of discussions.

I found this early on and started to use it. Of course a problem was, this being a mainframe, all CPU cycles got billed to the student. Of course CPU cycles were cheaper after midnight, so, yes, I did a lot of late nights at a terminal (preparing me for a life in computers).

But, *CB had its limits and it wasn’t long before the powers that be decided to shut it down. But the students weren’t to be denied. Next came *CONNECT. This ran in a different mode so was better tolerated. But that too eventually went away.

At some point *CONNECT was replaced by Clover, which I believe ran on an UNIX system. Clover was soon replaced by Lily. I’m not sure how long Lily has been around, but I know it’s been around for at least 24 years.

From *CB to Lily several features were added or improved upon. The number of discussions on Lily is infinite. Discussions can be private, so only allowed members can see the discussion and who is in it. Discussions can be moderated to control who can and can’t talk. Moderators of discussions can control who is or isn’t in them.

One of the coolest features, and as far as I know the first system to implement this was the concept of a detached user, i.e. you could leave the system, come back and reconnect and review what you had missed. This predated by a number of years AOL introducing a similar feature (and other systems introducing it). Many features found in IRC and SLACK and other systems were first tried out at RPI on Lily or one of its predecessors. (more of a history at that preceeeding link)  (Yes, I’m bragging a bit about my alma mater and the students there.)

Anyway, I write all this because it leads me to Slack. I’ve used Slack. I’m not a fan of Slack. There’s no one specific reason and I’m not saying Slack is bad. That said, one issue I personally find is that everything is so separated that I end up with 3-4 separate Slack Windows and I lose track of what’s going on.

But, I still use Lily. I continue to use Lily every day. I’m a member of 333 discussions, I own 16 and some of those I’m in and I own are private (no I’m not revealing any secrets, sorry!) Why?

Well first I should note, of the 333 discussions, probably 300 of them get little to no traffic. For example the discussion Usenet gets extremely little traffic.  Others, such as Space can be very popular at times (like yesterday around 4:30 PM during the Falcon 9 launch).

So why am I on Lily so much? There’s two reasons. One is the obvious reason: we’re social creatures and I like the interaction. And since I work from home, it’s nice to chat with other folks. And I should note that Lily members are scattered around the country and even the world.

But there’s also another very important reason.  I’m not as smart as some of you may think. My brain is limited to the size of my skull. BUT, I’m not limited to that. I call Lily my extended brain. And it really is. At one point I was having a particularly difficult time with some Javascript (we’ve all been there right?). So I asked one of my Lily friends for help. She’s a full-time web-developer and she was able to help me out. When I’ve had Perl questions, various people have helped me out, including at least one member of the Perl Foundation (I may be mistating his actual role/title). I routinely answer questions about SQL Server.

Other RPI Alumns or associated people have played a major role in writing or being involved with the development of Usenet, DNS, the modern Internet infrastructure. Several work at Google, Microsoft, Amazon or other major companies and can provide a great deal of information I might not have access to otherwise.

I’ve also hired people I’ve met through Lily. It’s been a great resource for job hunting for myself and others.

Even long before we had the wealth of knowledge easily available on today’s Internet, Lily was my extended brain. And it continues to be my extended brain.

I’m not as smart as you think I am. But my friends are, and they’re even smarter than that. And this is one thing that basically makes us humans unique: our language and ability to communicate permits us to be smarter than we really are. We can and do share knowledge. If you really want to be smart and improve your lives and your careers, develop your network. Find your extended brain and exploit it. And remember your role in being an extended brain in others.

So no, I won’t develop a love for Slack. But I won’t give up Lily either. It’s part of who I am.

As a postscript, I will remind folks: if you like what I write, please subscribe so you get the updates when I write more.

And look for me at:

SQL Saturday Philadelphia: April 21st
SQL Saturday Atlanta: May 19th
SQL Saturday Albany: July 28th

You can pick my brain and extend yours there.

 

And so it Happened…

New Faces

Last year I made a decision to try to do at least one SQL Saturday outside my “normal” geographic region; which basically encompasses down to Washington DC and out to Rochester NY and Boston. I’ve spoken at a number of SQL Saturdays in this area. I’ve enjoyed all of them. And generally I’ve drawn a decent audience, with a few exceptions.

But, one of the problems of doing that is you keep seeing the same speakers over and over. And while we’ve got a great crowd of speakers, I wanted to hear from speakers I might not normally hear from. Also, unless you’re constantly creating new content (which you should for a multitude of reasons), after awhile your possible audience has heard everything you have to say.

So last year, I put a bid in for SQL Saturday Chicago and was very pleased to be accepted. I had a great time staying with some friends in the area and also a great time at the Speakers Dinner and After Party as well as at the event itself. I met a number of speakers I had not met before and heard a few speaker that I had not previously heard. And, I had a fresh new audience who seemed to really enjoy my topic on “Tips that have saved my Bacon.”

Colorado Springs

So this year, I had a choice of places to put in bids for. I selected Colorado Springs and was pleasantly surprised to find they’d accepted me.  Since I’ve got a friend in the area, that cut down on costs considerably.  It was a win win.

I had a great time at the Speakers Dinner on Friday night and met more speakers that I had not previous met. A quick shout out to @toddkleinhans and Cyndi Johnson and @DBAKevlar among others. It was great. We talked a bit about using VR to navigate a query, about reprogramming our brains and more.

I was excited for the next day. Sure, it was last session of the day, but I showed up early so I could hang out in the Speakers’ Lounge, see some of the other sessions, and hang with my friends, the MidnightDBAs, Sean and Jenn McCown.

Then it happened

As a speaker you have a lot of fears; the slide deck crashing, your computer applying updates in the middle of your talk (it happens!) and more. But I think the one that perhaps you don’t necessarily dread the most, but you’re most disappointed by, is when…. no one shows up! Catherine Wilhelmsen has a great blog post about this and I have to agree with pretty much everything she says.

All I can say is… “it happens”. I know it’s happened to other speakers, many who I have a great deal of respect for and think are a tier above me in terms of their talks.

Sometimes it’s just luck of the draw. Sometimes, as I suspect played a role here, it’s the end of the day, a number of folks have gone home already and ALL the sessions have lower numbers than ones earlier in the day. It could be the organizers misjudged the topics the audience wanted. It could be my title or description just didn’t entice folks (I suspect this is part of the issue with a different talk I gave, where I got too cutesy with the title. I’ve changed the title and updated the description and I’m scheduled to present it again at another SQL Saturday. So at least the organizers there think it’ll draw folks.)

But overall, yeah, it’s frustrating, but a single talk doesn’t make or break me as a speaker. It happens and we move on.

Conclusion

It was still worth coming out to SQL Saturday Colorado Springs and I don’t regret it. I’m grateful to the organizers that gave me the opportunity.  So thanks.

Oh and one more thing I noticed while going back through notes for this blog entry: SQL Saturday Chicago 2017 was event 600, Colorado Springs 2018 was 700. That’s 100 in a year, almost 2 a week. And I was asked to speak at (including Chicago) 6 of them I believe. That’s a pretty good percentage.

I’m content.

That said come see me next month at SQL Saturday Philadelphia! I’m not sure what time I’m scheduled for yet, but I’ll be speaking on “So you want to Present: Tips and Tricks of the Trade”. And yes, I will talk about when people don’t show up. That’s assuming I have an audience 🙂

 

 

Choices

“If you choose not to decide You still have made a choice” – Rush Freewill

One of the things that we believe makes us uniquely human is the concept of freewill; that we can rise above our base instincts and make choices based on things other than pure instinct. While there’s some question if that’s unique to humans, let’s stick with it for now.

Overall, we think choice is good. I can choose to eat cake for breakfast, or I can choose to eat a healthy breakfast. I can choose if I want get up early and exercise, or sleep in.

Sometimes we may think it’s hard to decide between two such things as in the examples above, but the truth is, it’s not that hard.

But, what happens when the choices aren’t nearly as simple. What happens when we sit down with a menu with 3 items versus 30 or even 100? We can become paralyzed. With 3 options, our odds of making a “wrong” decision is only 66%. I say “wrong”because it’s often purely subjective and may not necessarily have much impact.  But when we have 100 different things to choose from, the odds of a “wrong” decision goes up to 99%. In other words, we’re faced with the concept that no matter what we do, we’re virtually guaranteed to make a “wrong” decision.

The Jam Experiment

One example of this effect was seen in what is often called the jam experiment. Simply put, when given the choice of 6 varieties of jam, consumers showed a bit less interest, but sales were higher. When the choice of 24 jams were presented, there was more interest, but sales actually dropped, significantly. People were apparently paralyzed by having too many choices.

Locally there’s an outdoor hamburger/hot-dog stand I like to frequent called Jack’s Drive In. People will stand in long lines, in all sorts of weather (especially on opening day, like this year when the line was 20 people deep and with the windchill it was probably about 20F!) One can quibble over the quality of the burgers and fries, but there’s no doubt they do a booming business. And part of the reason is because they have few choices and keep the line moving.  This makes it far faster for people to order and faster to cook.  With only a few choices, patrons don’t spend 5 minutes dithering over a menu.

Hint: If you’re ever in the area, simply tell them you want “Two burgers and a small french”.  Second hint: No matter how hungry you are, don’t as a former co-worker once did, try “6 Burgers and a large french”. You will regret that particular choice.

Choices to Europe

What brought this particular post on was all the choices I’m facing in trying to plan our family vacation. It’s rather simple really, “we want to visit Europe”. But, I also am hoping to speak at SQL Saturday in Manchester, UK. And we want to visit London (where my cousin lives) and Paris. And we can fly out of the NYC area. Or Boston. Or possibly other areas if the price was cheaper enough.  So suddenly what one would hope is a simple thing becomes very complicated. And of course every airline has their own website design, which complicates things.

Of course the simple choice would be not to fly. The second simplest would be not to care about cost.  Of course neither of those work. So, I’m stuck in deciding between 24 types of jam. Wish me luck!

Getting Unlost

There’s a concept I teach people when I teach outdoor skills. If you’re going to be wrong, be confidently wrong. There’s two reasons for this. For one, people are more likely to follow a leader who appears to be confident and knows what they’re doing. This can lead to better group dynamics and a better outcome.

But the second, for example, if you’re lost is, if for whatever reason you choose NOT to stay in one place (which by the way is often the best choice, especially for children) is that if you make a plan and stick to it, you’re far more likely to get unlost. This isn’t just wishful thinking.

Imagine you’re lost and you decide, “I’m going to hike North!”  And you start to hike north, and after 15 minutes you decide, “eh maybe that was the wrong decision. I should hike East!” And you do this for another 15 minutes, and then you decide, “Nah, now that I think about it, South is much better.” 15 minutes later you decide you’re going to the wrong way and West was the right way all along.  An hour later, you’re back where you started. But, if you had decided to stick with North the entire time, an hour later, depending on your pace, terrain and other factors, you could be 2-4 miles further north. “So what?” you might ask. Well, take a look at a map of almost any part of the country.  In most cases you’re less than 10 miles from some sort of road.  If you’ve spent 3 hours hiking, in a single direction, you’ve probably hit a road, or a powerline or some other sign of civilization. (note this is NOT advice to wander in the woods if you get loss or a promise this will work anyplace. There are definitely places in the US this advice is bad advice).  Also obviously, if you hit a gorge or other impassible geologic feature, you may have to change directions. Or you might get another clue (like hearing a chainsaw or engine or something human-caused in a specific direction).

Final Thoughts

So, if you’re going to make a choice, make it confidently. And don’t second-guess yourself until new, solid reasons come along.

So, keep your choices simple and stick to them.

And with that, I choose to stop typing now.

 

Things Left Unsaid

Pop Quiz

You show up at an accident scene and see two patients. One is screaming in pain about a broken arm. The other is propped up against the wall seemingly fine, not saying a word. Which one do you check out first?

Many will answer, “the one screaming in pain about the broken arm, the other person is fine.” The experienced responder will most likely check out the 2nd person. Why? Because they’re NOT saying a word.

Here’s the thing. You know the 1st person has a pulse and an airway. They’re breathing just fine. Perhaps a bit too fine. A broken arm, by itself isn’t going to kill them.  But what about that 2nd person? Are they breathing? You don’t know. Perhaps they’re not saying a word because they’ve stopped breathing.  If you take the time to splint the broken arm and then get to the 2nd person, they may have died. So, check out the 2nd patient first, then determine your course of action.

We’re Safe! Really, we are. Trust us, because we keep repeating it!

I saw this because in problem solving, I often find what’s NOT said is often far more important than what is said.  Several years ago my son received a letter saying he had been nominated for a program that took children to other countries on basically extended field trips. It actually sounded really interesting. We went to the presentation. I sat through it thinking, “this is really cool.” But, two things struck me. First, they kept emphasizing how safe it was. At first pass, and the first time they mentioned it, I wasn’t bothered. I mean as a parent, you want to know your kid is going to be safe if you put them in the hands of strangers for an extended period of time. But, they kept emphasizing it. It got to the point that all three of us (my wife, my son and I) started to wonder, “why the hell are the dwelling on this point?”

The other thing that was bothersome was once we got out of the lecture hall and tried to speak to some of the individuals, we asked them “How did our son get nominated?” “Oh it must have been a teacher at his school.” Which sounded great until we thought about it and thought it strange that no teacher had mentioned this to us or our son.

So, when we got home, we did some digging and found out there had been several incidents of accidents happening to students while overseas with this group. On one hand, nothing struck me as too statistically terrible, but the reports of the handling and the fact that we were only reading about the ones reported made me even more paranoid about how unsafe the program really was. I mean why emphasize safety unless you really feel like you have to?

The other detail we uncovered was most parents had the same experience about “your child has been nominated” without any word of by whom. The most troubling was at least one or two parents who chimed in who said that their child had been killed in an accident or otherwise died after their name had appeared in the newspaper for being on the honor roll. i.e. a fact that a teacher who might be in a position to nominate the said child would be well aware of. As far as we and other parents could determine, the “nomination” process was solely a matter of the group scanning the newspapers for honor roll students and the like.

So, relating this back to IT

As a person who loves troubleshooting, one of the things I’ve learned is NOT to trust what the user initially reports to me. “I haven’t changed a thing and this stopped working!”  That generally means, they changed something. 🙂

I once had a client, that had a problem that took at least two winters to diagnose. Why so long you might ask? Because the problem only happened in the winter. The first year it was complaints of “ever since you networked our computers, they reboot without warning.” Now, I had networked them several months previously and they only started to report the problem come the late fall/early winter. I tried several things, but nothing really fixed the problem. I had an idea of what it was, but they wouldn’t listen.  So, among other things, I ended up rewiring their entire network (sounds like a lot of work, but it was a total of 4-5 computers and I moved from thinwire Ethernet to 10baseT (I did say this was a long time ago, right?)

Eventually I sort of gave up. Until the next winter rolled around and they started to call again. Again, I told them what I thought the problem was. Again, they dismissed it.  I’m not sure what finally convinced them, but they finally took me up on my suggestion and put in a humidifier and had their office carpet treated with anti-static spray.  Yes, despite all their instance that “I was just sitting there typing and it rebooted” what was really happening and they weren’t saying was, “I just walked from one office to the other, across the carpet, in the drier than normal air and as soon as I touched my computer it rebooted.”  It was the static build-up all the time.

So this week’s moral of the story: Look beyond what’s being said and pay attention to what’s NOT being said. It might shock you.

 

SQL Data Partners Podcast

I’ve been keeping mum about this for a few weeks, but I’ve been excited about it. A couple of months ago, Carlos L Chacon from SQL Data Partners reached out to me about the possibility of being interviewed for their podcast. I immediately said yes. I mean, hey, it’s free marketing, right?  More seriously, I said yes because when a member of my #SQLFamily asks for help or to help, my immediate response is to say yes.  And of course it sounded like fun.  And boy was I right!

What had apparently caught Carlos’s attention was my book: IT Disaster Response: Lessons Learned in the Field.  (quick go order a copy now.. that’s what Amazon Prime is for, right?  I’ll wait).

Ok, back? Great. Anyway, the book is sort of a mash-up (to use the common lingo these days) of my interests in IT and cave rescue and plane crashes. I try to combine the skills, lessons learned, and tools from one area and apply them to other areas. I’ve been told it’s a good read. I like to think so, but I’ll let you judge for yourself. Anyway, back to the podcast.

So we recorded the podcast back in January. Carlos and his partner Steve Stedman were on their end and I on mine. And I can tell you, it was a LOT of fun. You can (and should) listen to it here.  I just re-listened to it myself to remind myself of what we covered. What I found remarkable was the fact that as much as I was really trying to tie it back to databases, Carlos and Steve seemed as much interested, if not more in cave rescue itself. I was ok with that.  I personally think we covered a lot of ground in the 30 or so minutes we talked. And it was great because this is exactly the sort of presentation, combined  with my air plane crash one and others I’m looking to build into a full-day onsite consult.

One detail I had forgotten about in the podcast was the #SQLFamily questions at the end. I still think I’d love to fly because it’s cool, but teleportation would be useful too.

So, Carlos and Steve, a huge thank you for asking me to participate and for letting me ramble on about one of my interests.  As I understand it my Ray Kim has a similar podcast with them coming up in the near future also.

So thought for the day is, think how skills you learn elsewhere can be applied to your current responsibilities. It might surprise you and you might do a better job.

 

 

 

Hours for the week

Like I say, I don’t generally post SQL specific stuff because, well there’s so many blogs out there that do. But what the heck.

Had a problem the other day. I needed to return the hours worked per timerange for a specific employee. And if they worked no hours, return 0.  So basically had to deal with gaps.

There’s lots of solutions out there, this is mine:

Alter procedure GetEmployeeHoursByDate @startdate date, @enddate date , @userID varchar(25)
as

— Usage exec GetEmployeeHoursByDate ‘2018-01-07’, ‘2018-01-13’, ‘gmoore’

— Author: Greg D. Moore
— Date: 2018-02-12
— Version: 1.0

— Get the totals for the days in question

 

 

set NOCOUNT on

— First let’s create simple table that just has the range of dates we want

; WITH daterange AS (
SELECT @startdate AS WorkDate
UNION ALL
SELECT DATEADD(dd, 1, WorkDate)
FROM daterange s
WHERE DATEADD(dd, 1, WorkDate) <= @enddate)

 

select dr.workdate as workdate, coalesce(a.dailyhours,0) as DailyHours from
(
— Here we get the hours worked and sum them up for that person.

select ph.WorkDate, sum(ph.Hours) as DailyHours from ProjectHours ph
where ph.UserID=@userid
and ph.workdate>= @startdate and ph.workdate <= @enddate
group by ph.workdate
) as a
right outer join daterange dr on dr.WorkDate=a.WorkDate — now join our table of dates to our hours and put in 0 for dates we don’t have hours for
order by workdate

GO

There’s probably better ways, but this worked for me. What’s your solution?