About Me

Introduction

Hi there! My name is Pang Yan Han (call me Yan Han).

Professionally, I am a Software Engineer with a keen eye on infrastructure and a mindset towards engineering with operations as a first class concern.

My technical interests

Infrastructure and operations. I came from a software engineering background but had the good fortune to be part of Grab’s original SysOps team from 2015 to 2017, where I learnt a lot from very experienced teammates on how to run production systems and saw a very different side of things in an Internet company. (Thank you guys!)

This is pretty much my bread and butter now, with AWS as the base (which I hope to gain deep expertise in), Terraform for infrastructure orchestration, Ansible for provisioning, Kubernetes for container orchestration and a combination of Bash, Python and Golang for any programs I have to write, with the more serious applications in Golang.

Why create this blog?

To share knowledge that I believe others will find useful. This is my way of contributing back to the world and making it a slightly better place (I hope!).

To hone my writing skills. Some day I wish to write a book and this is a precursor to that. If you are / were a colleague of mine and wondered how I manage to write detailed documentation, this is my secret sauce =)

My beliefs as a Software Engineer

Any codebase should come with some documentation, at least documentation that describes what it does and gets it up and running. This is a lifesaver. I frequently find myself thanking me in the past for writing docs.

Pushing for automation whenever I find myself doing something repeatedly - because this is a strong sign that a computer can do it for me - and with less likelihood of making an error. It is also why I maintain repositories such as provision-ubuntu-ansible, bin-src and dotfiles.

Static typing is mostly a good thing. A large codebase written in a dynamically typed language is harder to maintain and requires a lot more tests to ensure runtime safety. Eventually, you may have to write a crappy type checker (personal experience). Why sacrifice correctness and maintainability by throwing away decades of research into type systems and compilers?

Monitoring and logging are absolutely critical. Otherwise you will be flying blind and not knowing where to start debugging the system when shit hits the fan.

Minimizing operational overhead. Especially when you are working in a small team that lacks deep operational expertise in some areas (eg. running databases in production). Focus on solving problems important to your business and make use of managed services with proven production guarantees when possible.

Rewrites usually do not turn out well. Instead, focus on achieving high test coverage, then do refactoring. Having high test coverage ensures that any changes you make to your code are most likely correct and lets you refactor with confidence. A static type system helps tremendously here.

Tests also require maintenance. A lesson taught by one of my mentors at my final internship, which rang true over time. Going excessive with tests likely means that a lot of tests have to updated during major refactorings.

I am strongly for open source software. Having studied a few of them, I can attest that I have learnt a lot from reading code written by people who are way better than myself. It is not an exaggeration to say that the world will be very different without Linux, vim, Apache, Perl, etc and everything else that came from them.