Revision #1

Even if you find the right tool for your job, do you know how to use the tool correctly? 

This is exactly what this article is going to focus on; you need to know your tools in order for you to know it’s the right tool for this job!

Do you know your tooling?

All too often I see developers using amazing new tools but in many cases not knowing the limits or how to use it correctly. It’s very important to understand how to use a tool and what the implications of using a tool in a certain way has. When I find a new tool or a new library that I want to use, I try to research it and understand it before I recommend it for production use.

To me a tool is not only a software that I run or a hammer that I use, but I also consider a third party library a tool. A tool for me is something that I use to solve a certain problem and smaller parts can build a larger tool.

Problems with not knowing your tools

If you don’t know what your tool does behind the scenes you can get very big problems in the end. If you try to use a hammer to screw something into the wall there might be an easy work around just to hammer the screw into the wall. But what if it was the other way around?

Imagine that you had a screwdriver but a nail that you had to put into a plank; getting that into the plank would be much harder, no?

It’s still possible of course to solve the problem by just using the other end of the screwdriver and hammer the nail slowly into the plank.

So where are we going with this?

If you use a library or software that is new and hype which solves a certain problem but makes it harder for you; maybe you’re doing it wrong! The tooling might be great for solving one of the problems, but the way that you use it just gives you too much of a headache. If you go back and do some research on the tools, you might find that you are using it wrong or that the tool simply is not for the specific use case.

A good example here is LINQ to EF. I’ve seen many developers knowing how to use LINQ but not knowing what happens behind the scenes. This can be very dangerous for the performance of your application.

One other problem that arises with this is that most of us test our applications with very little data in it, but in a real world application after some time there might be a lot more data to process which was not considered at the beginning.

Now to be a bit more concrete, see of the following LINQ to EF query:


This can of course be written like this as well:


Both of these will be executed as soon as you request the result by doing persons.ToList(); for instance.

This all looks very good, it might be exactly what we want to do as well. But what happens if we have 1 billion persons in our database?

The SQL query that is generated from this will perform what is called a row search, which means it does not use any indexing which means it will have to go over 1 billion persons and do a search within each person’s name.

Consider that it generated the following SQL:


Of course we can optimize this by using full text search! But that is not the point, the point is that we might not have considered that Contains() will actually be a slow operation to run. If we knew that this would skip all indexes we might had chosen to use StartsWith() instead.

Another problem with not knowing how LINQ works internally is that all too often I see developers doing ToList() just because they want to use the types in .NET instead of having it translated to SQL. If they had known of EntityFunctions or SqlFunctions they might had chosen to run the query on the database side instead of doing LINQ to Object!

Because if we perform the query below, we will actually fetch the 1 billion rows from the database and have them in memory and then perform the search in the application instead.


Again, if we know our tooling and use the right tool for the right job, we are going to do a much better job.

Do you know your tools?

This article was originally posted by Filip Ekberg on blog.filipekberg.se.