Sharing and teaching

I spent this past Saturday in NYC at another SQL Saturday event. This blog isn’t typically about my day job. But sometimes things overlap.

SQL Saturday is basically a community run, volunteer event where folks who use SQL Server, or are interested in it, get together, present and attend talks and share ideas.

I unfortunately missed the keynote given by Grant Fritchey, but from what I understand, he discussed the importance of networking for DBAs: and he didn’t mean the kind running on TCP/IP handshakes as much as the one running on human handshakes.

This is exactly why I’ve wanted to teach at a SQL Saturday for awhile. I can’t claim my presentation was as well attended as many others and I can’t claim my presentation was as useful as some, but it was well received. (I would be lying if I didn’t say I think handing out cookies didn’t help!)

I’m a firm believer in passing on what I’ve learned. It’s how I learned, others took the time to pass information on to me and I take the time to pass it on to others.

One thing I really like about the SQL Saturday community is how much folks leverage off of each other. Often an idea presented by one presenter is seized upon by another who then expands upon the idea and adds to the body of knowledge.  Then the first presenter will take the updated idea even further.

This is how we learn, by taking ideas, expanding and sharing them back.

Getting the right answer by suggesting the wrong one

I’m a participant on a CMC called Lily It is based out of my alma mater, RPI.  At some point, someone created a rule (which I’ve seen elsewhere so it’s hardly unique) that sometimes the fastest way to get the right answer to a question is to post the wrong answer.

There is truth to that.  I think in part it can be summed up with this XKCD cartoon.  Many of us who are involved in technology seem to have an incessant need to be “right”.  So when we see something wrong, we’re compelled to correct the mistake.

But, to be wrong, it has to be clearly wrong.  To go back to my cave rescue experience, if I recommend a 3:1 haul system and you recommend a 2:1, neither of us is necessarily wrong. We might be optimizing for different factors.  On the other hand, if you recommend we use 11mm rope for the haul line and I whip out some clothesline I’ve had in my car for a few years and suggest it should be good enough, after all it’s only Bill we’re rescuing, I’m clearly going to be wrong and need to be corrected.

These thoughts about being wrong and trying to find the right answer were prompted by a coding problem that has consumed far too much of my time. I finally came up with an answer that worked, but not one that I liked.

Essentially I’m building a Combobox (loading it from a datatable) in vb.net

It has key,value pairs, let’s call them (“Test1”, “A”), (“Test2”, “B”) and so forth.
(note VB.net appears to call these a DisplayMember,ValueMember pair and they can be loaded with a dictionary type, so in my mind it’s what they call the “valuemember” is what I’d consider the lookup key and that illustrate my misunderstanding of the issue.)

However, once I load the record in question, I want the selected value in the dropdown to reflect the value in the record (which of course is stored as “A” or “B” etc.)

There appears to be no way in VB.Net to easily say something like:

cbxResource.SelectedValue = Itemrecord.Value

Then I tried:

cbxResource.SelectedItem = Itemrecord.Item just to see if it would work. It doesn’t.

Googling suggests something like:

cbxResource.SelectedIndex = cbxResource.FindString(Itemrecord.Item)

That does indeed work, if I know the DisplayMember name. But that’s I want to display, not what I store in Itemrecord and as such means I don’t know it.

It strangely seems I can not set the index based on the ValueMember, just the DisplayMember.  To me this is strange since coming from a DB world, it appears the value member would be the key I’d want to look  up to select the Displaymember to be displayed.

I finally settled on a hack.  What if I switched the two?

cbxResources.DisplayMember = “Resource”
cbxResources.ValueMember = “Description”

cbxResources.SelectedIndex = cbxResources.FindStringExact(Itemrecord.Item)

cbxResources.DisplayMember = “Description”
cbxResources.ValueMember = “Resource”

I’m not sure I like this answer. It seems to me it should be far simpler. Or that I’m fundamentally misunderstanding how the control should be setup and used.  But for now it’s the hack that’s going into my code.

So why publish here?  Well either it’s a great work-around and I can save other folks the hours of fruitless searching I experienced, or someone can say, “It’s on the Internet and it’s wrong; I have to correct it!”

I’ll take either answer.

Moral: Sometimes being wrong is the right thing to do.

All set to think

A short post today.

This past weekend I attended another SQL Saturday event. This one in Washington DC.  For anyone interested in SQL Server, I highly recommend these events. Typically the cost is just $10 to attend for the day.

I had put in a bid to present but unfortunately was declined.  That’s fine, there were plenty of other seminars worth my time to attend.

One of them, Common Coding Mistakes and how to Mitigate Them by William Wolf was a good example of that. @SQLWareWolf did a great job of illustrating a number of fairly common mistakes.  That itself was worth the price of admission. But what I really enjoyed was an observation of his, one that I’ve had in the past.  As a DBA, I can often spot stored procs written by a programmer with a non-SQL background.  The tell-tale is that many (certainly not all) programmers who come to SQL from another background often think in terms of rows, not sets.

An example of this would be the case of a programmer opening up a cursor and looping through the cursor to set the date on a number of records.  Of course for any person with a SQL background, we understand that can be a single statement which will execute far faster.

Now, there are certainly times when row by row is the only way to do it, but if you see that in a sproc or script, I’ll bet you 5:1 it was written by a programmer who didn’t know better.

Now, to be fair as a DBA who learned to program when “object oriented” wasn’t a buzz-word, I’ve been doing a lot of VB.net programming lately and I have to admit often I’ll find myself down a hole of twisty paths before I’ll realize I’m writing bad code and if I simply think of the data I’m trying to modify as an object, suddenly things get FAR more clear and easier.  I would not be surprised if 5 years from now the next programmer comes along, looks at my code and thinks, “What was he thinking? He obviously understood objects, but didn’t do everything he should have using objects.”

But in both cases, over time the non-SQL programmer coming to SQL will learn and I hope my OO code is slowly getting better.

No real moral here other than common observations and that hopefully overtime, we all improve.

Survivor Bias

I’ve been so busy lately I haven’t had a chance to write anything.

Of course part of the problem isn’t having ideas to write about, but time to write about them.

I think perhaps I should focus more on writing SOMETHING, even if it’s just a short post, than trying to write the Great American Blog post.

In this case I’m going to actually post a link to a great article on survivorship bias.  This is the sort of article I wish I had written myself.  As I’ve mentioned part of my point here is to get one to think about HOW we think.

The story of the bomber survivors was first related to be by a good friend in college, but without a source. Now at least I have a source for it.

In a similar vein, and the article touches upon it, people will talk about how great the older homes in weather prone areas were built because they’re standing decades after they’re built despite hurricanes or floods or blizzards. These folks completely miss the other 90% of homes from those eras that didn’t survive.

Years ago, my father bought and rehabilitated what we believe to have been the oldest house in town (in fact technically it was older than the town and probably where the town charter was signed.)

There really wasn’t anything about the construction that stood out that made it survive. Just luck at this point.  A single fire at any point in time could have made the second oldest house in town the oldest.

In closing, this article doesn’t represent most of my thoughts over the past 6 months only the ones that survived to the publishing stage.

Git ‘r Done (part 2)

Someone recently forwarded the following article to me: “Get Shit Done: The Worst Startup Culture Ever”.  Before reading it I was a bit ready to disagree. (see my previous post on getting stuff done.)

But after reading this article, I have to agree with the premise of the article; and point out I think there’s two different ways of looking at what “Get Stuff Done” can mean.

At my current assignment, a coworker and I were joking about how some people had some many letters after their name like PMP or CAPM, PMI-SP and the like.

So we joked we needed some letters and we settled on GSD – Get stuff done.  At times on this particular project we seemed to be the only ones accomplishing much or caring about accomplishing much. We had one person who was more concerned with the agenda of the meeting every day (yes, daily meetings to see why the project wasn’t getting done.  With 5-6 people in that room, that’s 25 or more person-hours per week of discussing why things weren’t getting done.)

So in that context, “decide what your goal is, and actually GETTING IT DONE” I think “Get ‘r Done” is an important concept.

On the other hand, I have seen (and fallen prey to myself, both as a manager and as a employee) of the “Get ‘r Done” attitude in the above article.

The project above I was working on never got done.  It wasn’t for lack of effort on the part of myself and several others that it didn’t get done.. It was though for the lack of effort on the part of management that it never got done.  At one point they asked me what could be done to make sure the project could be completed on time. I gave them several examples of areas where they could put some pressure on another group to streamline some procedures.

I was basically told that wasn’t going to happen, and that I had to work harder and “get ‘r done”.  At this phase of the project, I needed 4-5 items from another group and the other group had a policy that each item needed a separate ticket.  Each ticket had to be done sequentially and could only be submitted when the previous ticket was closed out.  Oh, and their policy was 2 weeks per ticket.  Period.

So, by my math, that’s 8-10 weeks. That assumes every ticket goes smoothly, which had not been our experience with this other group.

The project due date was in 6 weeks.

So, I was being told to get things done, in an impossible fashion.  Talk about demotivating.

In general, I’ve been my best as a manager, when I’ve been given the tools to let my team get the job done. It may be buying them dinner one night as morale boost. It may be making sure no extra work gets thrust upon them, or keeping certain other managers from trying to add to their work queue. In one case, it was buying a new NAS so we had enough storage space that we weren’t getting paged every night about diskspace issues. When properly motivated, people can move mountains and better yet, can often do it in a normal work week.

So, if you want to get it done, make sure your team has the tools to do their job, aren’t being distracted, and aren’t being given reasons to have low morale.  They’ll move mountains for you. But ask them to work harder without any of the above, and sooner or later you’ll find yourself without a team, and your boss simply asking you to work harder!

By the way, on that NAS, I think that $5K investment probably helped keep a key employee of mine from jumping ship for greener pastures.  That NAS was probably a better investment than if we had tried to offer him another $5K to keep him happy despite the lack of sleep from all the pages and other issues.

Moral: You want them to “get ‘r done”, give them the tools they need, remove barriers and keep morale up.  They’ll get it done.

Link

As a middle manager in several start-ups I’ve had to deal with being short of resources of all kinds.  But, at the height of the first dot-com bubble, I had a great team.  No, not all of them were equals, but each pulled their weight and each could be relied on to perform well, in their area of expertise.

One guy, was a great troubleshooter.  He’d leave no stone unturned and you could tell if a problem was bothering him since he’d fixate on it until he understood it AND had solved the root cause.  It wasn’t good enough for him to fix the current problem. He wanted to make sure it couldn’t happen again.  However, what he wasn’t good at, was the rote, boring procedures. “Install this package in exactly this way, following these steps.” He’d tend to go off script and sometimes that caused problems.

On the other hand, I had another guy who was about 2 decades older and not from an IT background.  Troubleshooting wasn’t his forte and he honestly didn’t have the skill set to do a great job at it.

However, he excelled at the mundane, routine, rote tasks. Now this may sound like a slight, but far from it. The truth is in most cases in IT, you’re dealing with the routine, rote tasks. In an ideal world, you might ever have emergencies.

Now, this wasn’t to say he couldn’t solve most problems as they came up.  Simply if it was overly complex or rather obscure, it wasn’t his forte.

I learned when I wanted to get stuff done, that assigning the routine stuff to him worked far better than assigning it to the first guy.  And just the reverse.  If I had some weird problem I needed debugged that wasn’t easy to solve, the first guy was the guy to through at the problem.

Each excelled in their own way and the team did best when I remembered how to best utilize their talents.

Smart People

Like many, from time to time, I’ve had the distinction of being “the smartest person in the room”. (Often that’s when I’m the only guy in the room, but that’s just a minor detail.)

This past weekend though, I had the pleasure of being in a room full of people where I was definitely not the smartest guy in the room.  One of my side activities is working with the Educational Committee of the National Cave Rescue Commission. This entails, among other things, having face to face meetings once or twice a year. During this time we work on the curriculum, trying to improve it every year.  This weekend’s meeting had 8 people (including myself) in attendance.  The people there bring an extremely wide degree of skills to the table, ranging from medical experience, SRT experience, grammar experience, experience about ropes and devices, rescue experience and more.

With such a diverse background, there are times when not everyone is in agreement on various teaching points.  But, while there may be spirited debate at times, everyone still keeps the end goal in mind: developing the best possible curriculum for cave rescue.

However, one has to be careful about “the smartest guy in the room.”  There is an old joke about a plane about to crash. It has 3 passengers, a Boy Scout, a priest, and a Nobel Prize winner and 2 parachutes.

The Nobel Prize winner grabs a pack shouts, “My discoveries will save the world, I deserve to live” and jumps out of the plane.

The priest tells the Boy Scout, “Son, please take the last parachute.  I have lived a good life and I am prepared to meet the Lord”.

The Boy Scout turns to the priest, “Don’t worry Father, the smartest guy in the world just grabbed my backpack and jumped out of the plane.”

Being smart doesn’t make one immune from error.  But surrounding oneself with smart people can often lead to better solutions.

You don’t have to be the smartest person in the room, but you should at least try to surround yourself with them.

Change is good

So, for the “fun” of it, I added some dns names to my home network (namely the cablemodem and the router).  Now, it’s not like I really NEEDED to do so. The honest truth is IPv4 network addresses are rather simple to remember. So, I could just type in the IPv4 address of the device I want to reference and do fine.

So why bother?

Well, a former colleague of mine convinced me that it was time to change.  You see, IPv6 is coming.  I won’t bore anyone with the details, but let’s just say that I’m not about to try to remember the IPv6 addresses of any of my devices.  At first, the Luddite in me rebelled at the idea that I could no longer just refer to devices by IP address.  I attempted a few feeble attempts at arguments (hey, it’s easy to remember the IP address of some public DNS servers for example, and that’s one of the few times in an IPv4 network it really helps to have memorized some IP addresses.)

But the truth is, over time, I saw his point.  IPv4 was the old way.  IPv6, for a variety of reasons is the future.  My desire to be able to say I could remember the IPv4 address of my router was simply stubbornness.  The truth is, there really isn’t any real benefit to it.  The fact that I could (and did) reference my network printers by IP address wasn’t really helpful.  In fact, it meant that when I wanted to move it to a different address, I had to go to individual machines and make changes.  Now, I had  a small network, and only changed the printer address once in the past 5 years.  So it wasn’t a huge burden.

But now that I’ve moved to using hostnames, even for stuff I used to use IP addresses for, my limited memory can be used for more useful things.  And when I do reconfigure my network (say add another printer, or expand it in other ways) a simple DNS change and I’m all done.  I don’t have to go from machine to machine to make changes.

So, the moral of the story is, just because IPv4 made something EASY to do, it didn’t make it the right thing to do. IPv6 forced me to reconsider my thinking and in the end change for the better.

Sometimes, being forced to change can make you a better person.

SQL Server User Group

Not much of a post tonight.  I didn’t realize it had been over two months since I last posted.  I’m sure all my faithful readers (all 1 or 2 of them?) have been holding their breath.

Anyway, tonight went to the local SQL Server Users Group meeting.  They had a remote demonstration on query tuning, one of my favorite topics.

In fact performance tuning in general has been a topic I’ve often enjoyed.

First rule: There is always a performance bottleneck.  This is one of the first rules I recall reading.  At first people object, “but the system is fast enough.”  That may be true.  BUT, there is still limiting it from being better.  Of course you might not be able to fix that limit.  But more importantly, it may not matter.

Second rule: It may not matter.  If your query is already running in subsecond times, it may not be worth spending any time on optimizing it any further.  Or, if your query takes 1 hour to run, but runs at night when nothing else is running, it may not matter.

Third rule: Optimize only what you need to.  A classic example of this I’ve seen is finding reports that run overnight and slow down other processes.  You start to optimize it and then think to ask, “is anyone still using this report?”  You find out the report is no longer being used.  Now you can achieve the holy grail (and perhaps the only exception to rule 1): infinite optimization.  Delete the report and suddenly you have infinitely optimized it.

BTW, these rules don’t apply just to SQL Server.

Optimize your life and enjoy more of your time doing things you enjoy.

Think in Russian

In the classic Cold War thriller, Firefox, Vietnam veteran Mitchell Gant has to steal the top-secret Soviet Union, titular plane.  Among its advanced features is that the systems are controlled by thought.  But only if he thinks in Russian.  This becomes a key plot factor in the climax of the film.

In my last post ; I remarked how many bad solutions I had found to sorting a SQLDataconnection Gridview.  Well I’m happy to say I solved my problem last night. (And as an aside, I will not be posting the solution at this time because while the solution itself is decent, I’m not sure the code is the best.)  Part of my solution was solved by “thinking in Russian”.

As I had mentioned, some of the so-called solutions to this problem that I had found on-line were pretty bad.  In one case the author apparently decided the easiest solution was to decipher the viewstate, extract out the information, sort it and stuff it back into the viewstate.  Now, as I’m writing this, I realize one advantage this has is that it removes a roundtrip from the web server to the database server.  But that’s about it.

I also saw a solution that involved passing the column name back to the code-behind and having that decide which of multiple stored procs to call.  I can’t say I favored this approach since it basically means a lot more maintenance if you ever say want to add a column to your Gridview (which turns out I decided afterwards I may want to do.)

Even worse, I’ve seen people propose things like building the select string on the fly and I can’t even begin to say how bad of an idea that is.

That said, the more I thought about it, the more I realized what the “right” solution was.  Rather than fighting the system, I had to think like the system.

So, after a side trip down to trying to use SqlDataAdapter, I went back to my first approach of using a SqlDataReader.  However, based on one example I saw, I decided to move this to a function of its own.  This, if nothing else resulted in cleaner code (since I was already calling the SQLDataReader in two places (see Rule of Three).  Once I did this, it was a little matter of figuring out how to bind the SqlDataReader to a Datatable and returning that.

Then I could bind the datatable directly to the GridView if I wanted to (which I do on the original Page_Load and Click_Submit OR I  could in the _Sorting event bind it to a local Datatable, sort that and then bind the resulting sorted Datatable to my Gridview.

Worked like a charm.  Well except for one little detail.  And this one I’m still not sure if it is a MSFT bug that lives on for backwards compatibility or I and MANY other developers are doing something wrong, but the GirdView incorrectly will always return “descending” for its sort direction.

So in this case the common (still not convinced it’s the RIGHT or BEST solution) is to stuff a variable in the Viewstate and read that back every time sorting is called and reverse it as needed.

Once I did that, I had working code that could sort my Gridview on the selected column that was clean, easily reproducible and made sense.

I’ve found with my forays into .NET Framework and VB programming that if my initial approach appears overly complicated or just plan wrong, it probably is.  So far in pretty much all cases, I’ve found that if I stop and try to “think in Russian” the solution will appear to me and is generally fairly straightforward and looks right.

Years ago when I studied Latin, I reached the point where I could read Latin natively.  I loved it. But part of the switch is being able to think in the structure of the language.  Not all languages use “SVO” (Subject-Verb-Object) order like English.   Latin, “SOV” (Subject-Object-Verb) order uses.  It takes some getting used to. But once you accept it, things get easier.

So I can’t fly a Mach 6 stealth aircraft, nor do I speak Russian, but I’m starting to think in VB. (Or is that I’m in VB starting to think?)