Re:A letter to myself as a fresh software engineer
by btilly on Wednesday April 01, 2020 @09:59AM
(#22748505)
That isn't NIH. In fact it is often the opposite of NIH. It is a pre-requisite of becoming a true expert in the technologies that you are using.
NIH is writing your own database and using it in production.
But understanding how to write a database makes it easier to understand why your existing database works the way it does, and what its quirks should be.
For example suppose that you have a slow query. You EXPLAIN ANALYZE to get a query plan. Now what? It really helps if you can say, "What would a program to do this look like? How fast would it be?" And then be able to say, "And if I was to write a program to do this, how would I do it? How fast would that be?" And then if the second is faster you can ask, "How can I get the database to do what I think it should do?" (Hint, in most databases with temporary tables and indexes on them, you can force your desired query plan to within a factor of 2.)
That exercise really helps in optimization. But that exercise is only available to people who know how a database actually works.
NIH is writing your own database and using it in production.
But understanding how to write a database makes it easier to understand why your existing database works the way it does, and what its quirks should be.
For example suppose that you have a slow query. You EXPLAIN ANALYZE to get a query plan. Now what? It really helps if you can say, "What would a program to do this look like? How fast would it be?" And then be able to say, "And if I was to write a program to do this, how would I do it? How fast would that be?" And then if the second is faster you can ask, "How can I get the database to do what I think it should do?" (Hint, in most databases with temporary tables and indexes on them, you can force your desired query plan to within a factor of 2.)
That exercise really helps in optimization. But that exercise is only available to people who know how a database actually works.