NOLOCK in SQL Server ain't your friend

If you are in a team that is obsessed with NOLOCK hints to your SQL queries, because you think it is faster and an all weather reliable friend, this post is for you to help you understand why you should avoid it (almost always) for it is not your friend. 

NOLOCK in SQL Server is often abused as if it is the magical way to speed up read queries. It is unfortunate that teams forget that "there is NO Free Lunch". Every action is trading off one thing for the other and so when you take an action, be aware of what you are trading to give to get something.

The Exceptional Circumstances You Can Use NOLOCK

• When you are querying live DB for some Reporting, where some bad data doesn't alter the overall aggregate numbers that you compute.
• When you are using WITH (NOLOCK) for SELECT query in reporting database where data are already written and committed.
• When you are querying a live production DB to take a peak into it and not use the result as a source of truth, knowing that it might have bad data in it.

Unravelling NOLOCK

• NOLOCK is a Table Hint in T-SQL, that tells the Query Optimizer (which can generally pick the best optimization method without any hints being given to it) on what is the better way to execute the said query, as its author is an expert DB specialist who is fully aware that the data could well be bad and that it is alright.
• NOLOCK is synonymous to READUNCOMMITTED isolation level. Reading uncommitted data implies that you are potentially reading data before it is being committed. 
• In an OLTP database where there are a lot of transactions happening, the database is intelligent to consider INSERT, UPDATE and DELETE statements with higher priority over SELECT query. Write has higher preference over Read. Why bother changing this status quo of inherent intelligence?
• In a highly transactional table NOLOCK hint yields you faster READs having UNCOMMITTED data that could potentially turn out to be bad if it is uncommitted.
• When you are employing WITH(NOLOCK) hint, you are trading rare Dead-Lock occurrence possibility and with Bad Data. 

Conclusion

Always use the NOLOCK hint with great caution and don't be fooled into believing that the results are absolutely true.

Book Review : Hands-on Azure Boards: Configuring and Customizing Process Workflows in Azure DevOps Services

Book Title: Hands-on Azure Boards: Configuring and Customizing Process Workflows in Azure DevOps Services

Author: Chaminda Chandrasekara

Publisher: Apress

My Ratings : 4/5

My Review: 

First off, this book is not your guide to learn the WHYs in Azure Boards. You are expected to have experience in Agile Project/Program management to know the WHYs on the Agile ceremonies or that you got to grab another book for this.

When you have the experience and knowledge on the Agile ceremonies and are looking to adopt Azure Boards for your teams like I had to in my team but don't know where to look at, this book should come to your rescue. It demonstrates it hands-on with screenshots of the GUI and is well organized into relevant topics, that makes you productive with Azure Boards. It served me well and I have recommended it to my team managers and so would to any manager wanting to adopt Azure Board for your project/product management.

Go get your copy and get productive :)

Note: The same is shared in Goodreads as well, where you can follow me for my reviews on books I read.

Book Review : Elasticsearch 7 Quick Start Guide

The author lived up to the expectations of the book title, especially the book serving as "Quick Start Guide" and I am thankful to it. In days of chaotic full-stack development and technology changes, you need a go to book for quick refresher on topics. This book serves that purpose and in fact has gone beyond in the sense that that author also shares some of the best practices based on his experience which are both valid and unfortunately no practices in many implementations.

If your team is using Elasticsearch, I would recommend you have at least a copy of this book as team's go to reference manual.

If you have O'Reilly's Safari Online subscription like I do, you can check it out there.

Check out my review of this book in GoodReads.

Go - Strengths, Weaknesses and Threats

This post is web-developer's point of view on the strengths, weaknesses and threats of employing Go as a programming language having used (and continuing to use) programming languages like Java, C-Sharp, Ruby, Python, Javascript etc.

The Strengths

• Fairly straightforward and simpler to learn and be productive. 
• Less features implies less things to worry about -- no OOP and thus no classes, objects, inheritance, polymorphism and associated complexities.
• Errors as return values instead of thrown exceptions. Now this is a different way to see an error/exception.
• The world is circling back to Statically typed languages and Go is statically typed. 
• Programming concurrency is simplified with Goroutines.
• Arguably consumes lesser resources (Memory, CPU, etc.) than other programming languages. 
• Has the goodness of JVM/Dotnet world's Garbage Collection freeing the programmer of worrying about freeing the critical resources.
• Employs Pointers only in specific use-cases (like Pass-By-Reference to mutate state or get reference to a specific object) where you can't have other way to solving your problem.

The Weaknesses

• If you are from the world of OO-programming, you will find OOP amiss. You have workarounds with methods attached to Struct constructs, as an alternative.
• The fact that Go was written as viable alternative to C programming language can be felt with the absence of abstractions that is available in high-level language. Take `slice` data-structure in Go, which is a wrapper on `array` data-structure for the sake of flexibility in size. The slice data structure, however would NOT provide you with any convenience method to say remove an element from it.
• Go lacks fluent interfaces that languages like Java, Python etc have and so you do frequent context switching between the business problem you are solving and the programming language nitty-gritties. For instance instead of iterating a collection using high level constructs such as `for each`, you resort to your older ways of introducing local variables in for loop construct. And I don't think, you can have fluent interfaces without Go first introducing Generics :(
  
• Not much of mature tooling support in terms of IDE or libraries as things stand today.
• Take for instance I have an exported method in a file that I try to have unit tests for in another file. The VS-Code editor wouldn't recognize this method name all of a sudden (say when you refactor/rename your method) and would give go lint error like `UndeclaredName` in spite of it being there. But if you try running your tests, it will work fine. This kind of false negatives defeats the purpose of linting and not sure why this supposedly basic thing is broken for a good while now. You can refer issue in github. Guess what worked for me? Close and re-open the VS-Code IDE.
• You will experience the pain of missing Generics as in Java or the power of dynamic-languages when trying to design a solution. This leaves you with writing a little verbose code and unwarranted duplication of code-logic.
• Go doesn't support method overloading and the convenience default parameter values. As per Go FAQs, this is a decision taken consciously to simplify things.

The Threats

• Go emphasizes on shorter naming convention than meaningful names even if it were to be longer. It's been a hard efforts for the world to come to terms to having meaningful names as naming convention fighting the bad habits of shorter names. Go language is taking programmers to older bad habits with pride :(
• Modules and Packages are a little confusing and takes a while to wrap your head around it; I had to make mistakes and pause for a while to get it right (hopefully). 
• The package name need not be the same as the enclosing directory, for instance.
• That your import statements points to directories where the packages are contained and not the package themselves is weird to me. 
• If you declare a package `game` under `games` directory in a file `f1.go`, then you cannot declare a package other than `game` in another file `f2.go` under the same enclosing directory. Try creating a package like `othergame` in the file `f2.go` in `games` directory and you'll see compile-time error showing `package othergames; expected game compiler(MismatchedPkgName)`.
  If you were to look the go docs for `MismatchedPkgName`, it will read as `MismatchedPkgName occurs when a file's package name doesn't match the package name already established by other files.` only confusing you in this occasion.
  Brain friendly way for this to stick in your mind is thinking about it as you wouldn't want to distribute your packages in different directories for the sake of modularity.
• So in Go, think of `Module` as an independent project on its own. Your current project is a module, for instance. A module can have many packages, each under its own directory as a convention.

My thoughts on hiring and retention

A question to motivate : 

Which of the below candidate do you prefer? 

1. A candidate who stayed in a company for good deal of years but has left it leaving a gaping hole in the knowledge. 
2. A candidate who made it a point to share his/her knowledge by way of brilliant documentation making him/her irrelevant to the company before leaving.

If your choice is option 1, then I would love to learn your though process around that decision of yours and what is your take on mine that I have put forth in this blog post. If your choice is option 2, I am go glad about your choice and would ask what did you do to ensure that your company as well embraces it in its hiring process.

How I approach the hiring side of things?

 

One of the key things I do working with the Talent Acquisition team is to set the basic value system is set right and that we are all aligned to it, so that we can spot the right candidates that others miss. Having said that, I admit this is not an easy thing to do. One thing that worked for me is to have frequent conversations with stakeholders concerned around the following questions (I often trigger the conversation asking one/some of them):

• Do you look for an individual's stickiness (duration of his stay) to a company in his career?
• What is your metric of measuring stability?
• How do you measure productivity and professionalism of an individual against his/her stickiness to a company?
• How do you measure experience -- number is experience or experience in number?
• What specific positive/negative traits do you look for in a candidate? 

During my conversation (aka interview) with the potential hires, I ensure that not only are the candidates treated as people (instead of resources) but are well respected as a courtesy. This sets the stage for me understand the candidate better and that the candidate as well gets a fair insight in the job, the workplace, the company and me as a person. Two things I really care for in any candidate, irrespective of their experience or role are their teaching-ability and learning-ability. I do my homework to ensure I get a decent hunch on these attributes during my time with the candidate.

How I approach the retention side of things?

Retention is yet another hard-ball game. I would bet any day in making the workplace atmosphere more transparent, safe, productive, and guaranteed learnings from solving problems as a team. With this in mind, I start looking out for opportunities for improvement and go about executing them. This is multi-dimensional requiring help from many stakeholders in solving the problem and unfortunately this is often over-looked; take for instance if an outgoing employee cites any of the following reasons for leaving the company in your personal 1-to-1 conversation, what can you do about it:

• pay-scale disparity (you can't drill down on this one in your conversation)
• concerns of discriminations (you really got to win the trust of the person to hear this one out but often isn't something within your control)
• lack of opportunities to pick up better work (you must tactfully drill down on this one to get a hang of ground-zero reality) when they see some of their peers get to work on niche areas
• lack of learning opportunities (you got to drill down to the specifics) when they end up taking too much of support work or see some of their peers getting special privileges of say, certification reimbursements and they feel so left out.
• work-life balance going for a toss because of recurrent production issues, time-crunched deadlines, unplanned works etc. hurting their weekends and holidays. 

Not all the above problems might be in your direct control to bring about change. Not all the above problems can be tackled directly or immediately. Some of the measures that I have taken to improve the workplace atmosphere are below:

• Encourage the habits of documenting key knowledge in business, technology and practices. 
• Encourage more and more work related conversations to happen. It is important that there are conflicting opinions for the teams to get better in what they do. Unfortunately, conflicting opinions are discouraged in most workplaces.
• Encourage brownbag or lunch-hour sessions within teams, within horizontals and slowly stretching it to the outside world as talks in meetups and conferences.
• Encourage pairing not just within roles but across roles.
• Make it a point to reach out to individual team members to understand their aspirations and look for opportunities to accommodate and nurture it as part of their goals. 
• Encourage team work by breaking silos.
• Discourage gossip against person by encouraging open discussions on work subject.

Measure what matters. Loyalty trumps stability; for in my world, retention is not just about how long one stays in a company, but how safe and productive (s)he is at work. Measure an individual's contribution at work and in developing other team members. I look not for how long one stayed in a company but how one helped the company, and the team grow during their tenure.