How to deal with a not-so-interesting project at work?
Being hands-on is the best way for you to learn. Practice interesting programming challenges like building your own BitTorrent client, Redis, DNS server, and even SQLite from scratch on CodeCrafters.
Sign up, and become a better engineer.
Dealing with not-so-interesting projects at work
I have spent a considerable amount of time in the industry to have faced this. There were some projects that I did not resonate with at all, and to me, they were quite boring. Here's how I dealt with them
1. If the work that has been assigned was important for the org and had a business impact, I took it and completed it no matter what. Aligning myself with the success of org helped me climb the ladder faster.
2. If the work that has been assigned had no potential business impact or has been wrongly prioritized, then I spoke with the leadership and management and backed my pointers with data.
3. If the work was something I "hated", I spoke with my manager and saw if it could be assigned to someone else. While pitching, I did provide the actual reasons and the leadership did understand it.
Note: the work was not so exciting for me (due to the tech stack), and this certainly does not mean it was mundane.
These are some things that I did, and by no means it is an exhaustive list. Every situation is unique, but these are some pointers that might help you navigate it better.
You can find this post on my LinkedIn and Twitter; do leave a like.
📹 Video I posted this week
This week I posted How PostgreSQL generates all possible query execution plans before choosing the best one.
Databases need to generate all possible query execution plans before they find the best one, but how do they do it?
Spent some time this week going through the internal details around how PostgreSQL generates the query execution plan for a SQL query and what exactly happens behind the scenes.
🧠 Paper I read this week
This week I spent reading Umbra: A Disk-Based System with In-Memory Performance
We know that memory access is faster than disk access, but how can we get in-mem performance in a disk-based database?
This weekend I read an interesting paper titled Umbra. It is a database system that provides in-memory-like performance for the data in the use-working set. It covers nuances about efficient buffer management and implementation of strings and statistics.
You can download this and other papers I recommend from my papershelf.
Joins are not always expensive
Once I was reviewing a code and I found that at multiple places the joins were avoided in favor of multiple selects. Upon asking, I got the response - joins are expensive and we should avoid them 🤦♂️
This is not true at all. Let me debunk the myth and give you a way to understand the costs involved.
Joins are expensive, but only when the data we are joining is huge, or your table lacks the right indexes, or when we are joining a large number of tables (>12). A join query can always be substituted with multiple select statements, but you may end up with an n+1 query problem.
Select statements are great but remember every select statement you fire, needs to go to the database over the network and come back to the client. Each query requires connection establishment, query parsing, query execution, disk access, and data transfer.
Even if the statement looks simple, the overhead of network roundtrip and query execution over multiple retrievals is substantial; and in most transactional cases will be greater than the cost of a join query.
A single join query completes the same task in a single shot. Thus one round trip, one-time query parsing, query optimization, and execution and you get the intended result.
Coming back to the incident, we replaced multiple select with a join and the response time of API was reduced from 1.2 seconds to 152ms. Pretty amazing.
Again, this is contextual to the data we had and the use case we were solving. So, instead of blindly following some tips and advice you hear on the internet, it is better to benchmark it on your own codebase and pick the better one.
Beware when someone says such generalized statements; take them with a pinch of salt. Knowing the nuances makes you a better engineer.
You can find this post on my LinkedIn and Twitter; do leave a like.
📰 Interesting articles I read this week
I read a few engineering blogs almost every single day, and here are the three articles I would recommend you to read.
Thank you so much for reading this edition of the newsletter 🔮 If you found it interesting, you will also love my courses
I keep sharing no fluff stuff across my socials, so, if you resonate do give me a follow on Twitter, LinkedIn, YouTube, and GitHub.