Category: Learning

Andy Levy just wants to get things done:

We need to have these meetings. They’re where consensus is reached on cross-team projects and decisions are made about timelines. They’re where we communicate to people outside our teams what’s happening. And sometimes, they’re critical for transferring knowledge to others. These are all part of the job. For better or worse, they are a nontrivial portion of The Work.

Read on for some of Andy’s tips around scheduling meetings.

Kevin Hill has some high-level advice for high-level people:

As a CIO or CTO, one of your primary responsibilities is to ensure that your organization’s data is managed effectively and efficiently. To do this, you need to have a strong understanding of SQL Server best practices. In this post, we’ll discuss some of the most important best practice areas for SQL Server management.

This is a high-level discussion with items that we will explore more in future posts

All of this is stuff that you’d want to do as a DBA but this is at a higher level to make it easier for an executive to understand the why behind it.

Robert Harris warns against the desire of starting it all over:

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand…It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

JOEL SPOLSKY IN THINGS YOU SHOULD NEVER DO, PART 1

There is a fleeting moment in every software project when it is absolutely perfect. It is the time between clicking “New” and “Save” in your code editor. In that brief interval, limitless potential and beauty. In every moment that follows, compromise and doubt (but working software, too!).

There are a few threads to unravel here.

First, Chesterton’s fence: if you don’t know why a thing is there, you are probably not the right person to decide to remove it. If you understand why the code is there and exactly what it is doing, then you become qualified to decide what, if anything, needs to be changed.

Second, ego: I’m a great developer. The best developer I know. Heck, maybe the best developer in the world. Therefore, if I don’t immediately understand code, it must be because that code is bad. Most of us don’t think explicitly in these terms but we still end up in the conclusion of, “if I don’t immediately understand the code, it is bad.” Or even worse, “If the code does not work exactly the way I would have it work, it is bad.”

Third, unstated/misunderstood business requirements. Code often starts to get nasty because the business requirements changed on the original designers or there was a process of business evolution. If business requirements are still evolving, what makes you think you’re going to write code that won’t be just as ugly? If business requirements are not still evolving and you really understand the code, you have a chance. But that leads me to the next bit.

Fourth, the value of reformation. Refactoring is a common path for code reformation. Having lots of tests increases the safety net we have for reformation, as those tests are likely to catch some of the dumb mistakes we make and hopefully suss out some of the worst things.

Fifth, Javascript is a hole of pain.

Ronen Ariely tackles a challenge:

how to pass parameters to view in SQL Server. I need create views with variable as below.

Create view view_name asSelect * from table where tas_id = V_Taskid

V_taskid is variable which are passing during run time from ADF pipeline

Is it possible to pass variable like above in view[?]

Ronen provides an answer but also notes that this probably isn’t the right question. In many cases, we ask for a specific detail because we think we know what to do but are stuck. In practice, we’re stuck because we’re asking the wrong questions. Most of the time, we don’t even know the right question to ask, making things even more challenging.