Useful Stuff I Read This Week

Here are 7 posts I thought were worth sharing this week.

This is an amazing read. Etsy engineer Salem Hilal shares their ES6 to Typescript journey. In this post, he covers the strategy, technical challenges they faced, tooling they built, and how they educated their engineers to write effective Typescript code. Etsy has been built over the last 16 years and they had 17000 JS files. Migrating such a codebase is a multi year effort. You need to have a clear plan and ensure there are no tail migration issues. 

A couple of months back a customer wanted us to migrate their 20+ TB Oracle database to Postgres. They had hundreds of stored procedures written in Oracle. Also, their batch processing jobs were written in stored procedures. They wanted to do the complete migration in a couple of months. We politely told them it is not possible. They went with another vendor that said they could do it in two months. Migrations are very risky. There are so many unknowns involved. For a vendor it is much more difficult because they don’t even understand your functional requirements and code base. For migrations I prefer to be safe than sorry.

This is an essential read for all the senior engineers and software architects. We all overdo abstractions. We create premature abstractions that give more pain than advantage. This is multiplied in Microservices architecture where the cost of getting wrong abstractions is much higher. In this post author covers four common premature abstractions:

  • Responsibilities are abstracted too granularly 
  • Design patterns are used without real benefit 
  • Performance is optimized prematurely 
  • Low coupling is introduced everywhere

Another common reason for premature software abstractions is that developers copy and paste starter code from their existing projects. I believe when you are starting a new project you have an opportunity to do things in a better way. You don’t have to repeat the same mistakes. Copy pasting the complete project structure along with all the dependencies (that you will need one day) deprive you from doing things in a better and simplified manner. 

This post covers why Rust is a good choice for building a kernel. Rust is already being used by big tech companies like Google, Amazon, Microsoft to build userlang applications. This post makes the point that we can use Rust for kernel land as well.

Rust is one of the programming languages that I plan to learn and use next year. I briefly played with it in the last couple of years and I enjoyed using it. Next year I plan to build something real with it to build my expertise in Rust.

There should be only one package management solution for a programming language. Python has more than 10 solutions(distutils, setuptools, pip, pipenv, tox, flit, conda, poetry, virtualenv, requirements.txt,, setup.cfg, pyproject.toml) to the same problem. This confuses software engineers and they are most of the time not sure what is the right way to do it. Author suggested PSF pick one solution that solves most of the use cases and be done with it for 30 years. 

I agree with the author that X years of experience with Y technology should not be a prerequisite to hiring senior engineers. There are few key things that I like to see in senior engineers:

  • Willingness to learn a new technology
  • Breadth of experience. This influences how they do research and find answers to problems
  • Experimentation mindset

I enjoyed reading the history of Berkeley DB. I have known about it for some time but I will be honest I never used it directly. Berkeley DB is an in-memory transactional key value embeddable database. It was the first software that used dual licensing – free for open source, paid for closed source. Users of Berkeley DB include Netscape, Amazon, Google, Toronto Stock Exchange, and Oracle. The first implementation of Berkeley DB was in C. Later they added Java implementation as well. Oracle acquired Sleepycats, the company behind Berkeley DB in 2006. It supports development of both C and Java implementations.

Developer onboarding is not a topic that is often discussed. We all agree that it is painful and slow and learn to live with it. As the author suggested, good documentation and pairing can help an engineer get onboarded quickly but it requires investment from the team. He suggested two possible solutions for smooth onboarding – 1) Containerized local development environments 2) Psuedo-local environments like Github codespaces, AWS workspaces. 

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: