Category: Learning

Steve Jones does some noodling:

I chose the title slightly to poke at Stack Overflow (SO), but the same take expressed in this tweet could be said about SQL Server Central. It’s not quite the same as anyone can answer questions on SQL Server Central.

The tweet is a (long) hot take from Jerry Nixon, a C# developer and MS evangelist in Denver. Essentially he says that a lot of the SO answers are wrong, especially as the software and languages change. Old answers are upvoted, and remain at the top of the list, even as newer answers might be better. People don’t like the behavior on SO of moderators and people who post, which is something we’ve tried to avoid or limit here at SQL Server Central. We want there to be professional discussions. SO also doesn’t allow much discussion or nuance in the questions or answers.

This isn’t just a SO problem or am SSC one. 

Read the whole thing. This is a huge problem with search engines today and there’s a hacky solution for it. Going back to the original PageRank algorithm that Google used, your rank on the search results list was heavily tied to how many individuals linked back to you. Older pages tend to have more linkbacks because they’ve been around longer, and so there’s a built-in bias toward older content. Google, in particular, has done a lot to work around this problem, but there’s a real issue with timeliness in articles: sometimes, you want the brand new information (like say, product recommendations); other times, you want older or even the original information (such as if you’re researching historical activities). The problem is that there’s no good way to indicate this to the search engines we have, so the hacky solution is for content creators to create sites like “The May 2023 Guide to Blahblahblah” and for search engine users to look for terms like “2023 blahblahblah” so they can avoid all of the outdated 2022 and 2021 blahblahblah discussions.

There’s also a story in here around keeping things up to date. Some people are good about that—they’ll go back and update years-old blog posts based on what’s new and happening. I am not one of those people.

Martin Schoombee shares a learning experience:

When you’re young and inexperienced you may have the determination to succeed (read: youthful exuberance), but the lack of experience (or understanding of the context) may get you in a lot of trouble because you may see something as black or white when in reality it’s a shade of grey.

This story is how my inexperience (almost) got me into a whole heap of trouble, and how it defined the rest of my career.

Read on for Martin’s story. Some advice I received early in my career is, give the auditors exactly what they ask for, no more and no less. Don’t assume they have detailed technical expertise—some do, but many don’t. And don’t assume they have the full story—they have what you’re saying and (typically) a built-in assumption that you’re soft-shoeing them.

Richard Swinbank has an image for us:

I spent some time working at a property portal, where users could look at online listings of homes for sale or rent, then go on to book a viewing appointment with an estate agent. On one occasion we were asked to build a Power BI report showing:

• the number of appointments booked by portal users
• the percentage of appointments where the user had viewed the online listing more than once.

Sounds easy enough, right?

Click through for the image. It makes intuitive sense, but is a good visual depiction of why some data requests are more challenging than others.

Nate McMaster (indirectly) talks dollars and cents:

Early in my software engineering career, a senior engineer at Microsoft told me “the best solution is one that requires no new code.” At the time, I thought this was nonsense. Is not my role as a software engineer to write code? Why would writing less or no code be better? More code means more bug fixes, more features, more services, and more tools. So why is more not always better?

Fast forward to 2023 – now I am the most senior engineer on a team, and I give the same guidance. Prefer solutions that require less or no code.

What led to this shift in perspective? 

Read on for Nate’s answer, which is well-written and makes a lot of sense. It’s also close to a topic I’ve written about in the past.

Jeff Mlakar has some advice:

Over the years, in various positions, I’ve participated in many projects as a developer, lead developer, architect, jack-of-all-trades administrator, etc. I’ve also had the opportunity to lead technical projects as well.

This post focuses on techniques I have employed to successfully manage technical projects. Read on for tips regarding meetings, communication, and building your confidence.

Read on for Jeff’s tips and recommendations.

Eitan Blumin takes us to a seminar:

The SPIN sales strategy is a selling technique that was developed by Neil Rackham in the 1980s. SPIN is an acronym that stands for Situation, Problem, Implication, and Need-payoff. This strategy is based on the idea that asking the right questions can help you understand your customer’s needs and provide the best solution for them.

When I first heard about the SPIN sales strategy, I was attending a lecture that was delivered to us by a sales and marketing specialist during one of our company meetings several years ago. As a DBA, I initially assumed this strategy wouldn’t be relevant to my job. But as I listened to the presenter explain the SPIN model, I began to see its potential for use in my daily work:

It’s an interesting approach and I like the way Eitan ties it back to database administration. Of course, we could tie it to application development or any of a number of other fields. I, meanwhile, use the Colombo method, in which I ask a series of seemingly-dumb questions, but just before I leave, I say “Oh, just one more question,” and hit the person with the question proving I know that person committed the crime and have enough evidence to make an arrest.