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.
On the job, I am a realist. I don’t build castles in the air or create software that assumes certain ideal conditions but which in practice does not bring anything to the table or worse, becomes a hindrance to others. I work towards a better state from what exists, incrementally and organically.
This is almost purely a technical blog. Most of my posts are “How-tos”, where I share solutions to problems I’ve encountered with computer technology, some of which have annoyed me greatly. Most of the problems I write about should be solved once, then documented clearly and shared with the world. I liken this to releasing highly reusable and useful software libraries that other programmers can benefit from.
If you have stumbled across my How-tos and found them helpful, or better, contributed improvements, or left notes of appreciation, I sincerely thank you for your support. It brings a smile to my face when I know that people have found what I’ve written useful and saved themselves a lot of time and unnecessary effort. Heck, some of my posts have saved myself a lot of time when I happen to run into the same problems again.
Haskell: Currently, I am actively learning Haskell (again) and taking a different (and much more active) approach as compared to the past. It has been pretty overwhelming, yet mind blowing and rewarding and the same time. Expect to see more Haskell oriented posts on this blog. I will be looking to implement a non-trivial project using Haskell some time later this year.
Mathematics: I have a slight interest in Mathematics - although progress has been slow (but steady) - still on the beginning undergraduate level. I have been actively working on creating PDFs which contain my solutions to the MIT 18.01 Single Variable Calculus course (Fall 2006) - source code and PDFs are available at this GitHub repo - do note that this is still a work in progress.
Systems, security, operations: Even though I am primarily a software engineer, I probably have much more experience than most engineers in system administration and operations, especially after my stint at Grab’s SysOps team, where I learnt a lot from very experienced teammates on how to run production systems and saw a very different side of things (as compared to a software engineer) in an Internet company. Ever since I moved on from Grab, I am finding in myself a growing interest in systems, security and operations.
Any codebase should come with some documentation, at least documentation that describes what it does and gets it up and running. I cannot count the number of times this has saved my life for projects I’ve not touched for several months or over a year (A big thank you to me in the past!). I also cannot count the number of times that I’ve chanced across projects in commercial companies without even a README that contains one sentence describing what the project does. While I agree that code should preferrably be self-documenting, usually that is not the case and sometimes that is just plain impossible, whether it’s due to complex algorithms or intricate business logic (or both), and this is where I believe that proper documentation and comments step in.
Pushing for automation whenever I find myself doing something repeatedly - because this is an extremely strong sign that a computer can do it for me (and is probably one of the reasons why computers were created in the first place). It is also why I maintain repositories such as provision-ubuntu, myvagrant, bin-src and dotfiles. They save a lot of time and effort for me.
Static typing is generally a good thing. Sure, there are some things like JSON parsing that are much easier to do in a dynamically typed language than in a statically typed language. Programming without a type system allows for rapid prototyping and is in fact my preferred method for short one-off scripts. But, how often have you wrote some code in a dynamically typed language that you think works and passes all the tests, only to have it crash during runtime from a type error (that may be difficult to debug)? Often times, these type errors are a symptom of more serious bugs waiting to be uncovered. Why not use the results of decades of research into and implementation of compilers and type systems to your advantage?
In general, it is not that great an idea to reinvent the wheel. I am glad I haven’t learnt this the hard way, but instead through others and the tools they use (which were reinventions of other stuff). The main issues include 1. thinking you can do a better job than the original software and forsaking battle-tested solutions that others have spent a huge amount of time solving and debugging, only to make the same mistakes they have made 2. computer security issues if you’re rewriting cryptographic libraries (it should be pretty obvious which language I’m referring to by now) 3. underestimating the problem, only to realize later on that some specialized knowledge that can’t be picked up fast is required (eg. mathematical and scientific computing software)
Tests also require maintenance. This, I was told by one of my mentors during my final internship before my first job out of school. Initially, I didn’t buy it but it rang true over time. If you don’t believe it, just write a huge amount of tests and see what happens when you do a major refactor to your code - you’ll probably have to update all the tests, too. Which is why frameworks such as QuickCheck are so attractive to me.
I am strongly for open source software. Having studied a few of them myself, I can attest that I have learnt a lot from reading code written by people who are way better than myself. And for the majority of those that I’ve not read, I have certainly benefited from a richer computing experience, kudos to their authors who kindly released their code and allowed for others to contribute to their development.