About

Who am I?

I call myself LWY (or wyLeong) online. I was born and raised in Penang, Malaysia. I found employment and moved to Japan in October 2019.

Professionally, I work as a front-end web developer. At one point of my life, I dabbled in indie game development, but I came to realize that it is okay for my hobby and career to be mutually exclusive.

In my free time, I study Japanese, watch cooking videos, read or watch content related to programming, play games, or draw. I wish I could make a living out of drawing web comics, but that is unfortunately not feasible for me right now.

Books I’ve read

I don’t normally read books, but I realized this is a result of the modern age of social media; I’ve become too reliant, addicted even, on fast-paced endless stream of information thanks to the infinitely-expanding world of the Internet.

Recently, I (re)discovered the hidden gem that are books; A lot of them containing age-old wisdom or entertainment that we overlook as social media such as TikTok and Twitter have defined the way we consume content during our downtime.

I’d like to start keeping track of the books I read, as a reminder to myself of how much content I’m missing out on.

Sorted by unread (recent) to read (oldest):

Refactoring

Reading…

Test-Driven Development By Example - Kent Beck

A good read. It consists of three parts. The first part talks about building up a multi-currency application by starting with tests (hence, the name of the book). It’s a simple but good introduction to Test-Driven Development (TDD).

The second part talks about building a xUnit testing framework that tests itself. It’s a nice glimpse into how test frameworks are written with TDD, but I still wasn’t sure how to apply that knowledge to my job. It was an entertaining read, nevertheless.

The third part talks about patterns for TDD. If you’re new to testing, this is a very good read. Otherwise, it’s a good refresher.

Overall, I think it will take effort to practice proper TDD. Most developers join a new company half-way through a project, so the opportunity to build software from scratch using TDD is pretty unlikely. The next best thing is to apply TDD when writing new features, but in fast-moving companies, again, the pressure of deadlines may cause developers to skimp of the practice.

I’m hoping to read another book that dives deeper into testing, not just TDD.

Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin

The first programming book I’ve ever read to completion in my life (it’s embarrassing to admit at 30+ years old, but better late than never). Learned a bunch of things about writing clean code, which I whole-heartedly agree, and can foresee applying in my job using Typescript. This book has some minor overlap with Martin Fowler’s “Refactoring: Improving the Design of Existing Code” and Kent Beck’s “Test-Driven Development By Example”, which I plan to read next.

Most of the book’s first parts (clean code, meaningful names, comments, etc.) reinforced some of my existing ideas about coding practices, but I also learned a few things along the way. Some notes on some chapters:

Formatting - might no longer be a huge deal since we have really good linters now.
Concurrency - didn’t really resonate with me because front-end web development doesn’t deal with this too much…

Part 2 of the book contains 3 use cases of how an existing code base can be refactored with the Clean Code principles. I skipped the last chapter (Refactoring SerialDate) because it required a lot of back-and-forth referencing the code base and the points being made by the author (it’s tiring considering it’s a book rather than a Github page with convenient formatting to highlight changes on a per-commit basis). I’d like to come back to this when I have the mood…

Part 3 contains a list of internal codes and description. Each point is short and worth reading to cap off what we learned in Part 1 of the book.

I can see why a lot of my colleagues recommended this book. Now that I’ve read (almost all of) it, I highly recommend it to other programmers too.

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency - Tom DeMarco

Perhaps the way the book was written just didn’t sit well with me, but it was hard to digest some of the points in any of the parts beyond Part 1. Part 1 talks about the importance of slack; To sum it up, if we are busy 100% of the time, we might think we’re being productive, but it’s not. To truly be productive, we need “slack” – some unsupervised “free time” in between our core responsibilities. This opens up opportunities to experiment, learn and undertake any ad-hoc responsibilities (which we won’t otherwise have time for if we’re busy 100% of our working time).

Part 2 onwards talks about management-related theory and how most “bad” companies employ the wrong methodologies in the name of productivity. Some points I could take home from this entire book are:

Cut ourselves (or our subordinates) some slack to improve productivity and encourage improvement
Collaboration between managers (instead of pitting them against each other for performance awards)
Embrace risk-taking. Change is constant, so we need to always take (calculated) risks to face upcoming changes in the industry

I’m sure there’s more valuable points to be learned from the book, but it felt more aimed toward managers. As an individual contributer in software development, I can just summarize that “We should encourage more slack in the company”.

True enough, after realizing this, I’ve started to allocate some time during work-hours for “self-focus”, where I muted all Slack messages and just spent time catching up on discussions, reading up on coding-related material, planning agendas for upcoming meetings, and even for reading programming books. I’ve felt more productive and knowledgable after each self-focus session, and in turn, probably provide more value to my team in terms of code quality and productivity.

Golden Rules of Success - Hiroshi Mikitani

Another book I read in preparation before my job interview at Rakuten. This book felt almost the same as “Principles for Success”. It talked about business principles and rituals. I felt that Mikitani assumes and expects everyone to have a strong ambition in “succeeding” in life, and that “success” is specifically in business.

I think there are some people who just want to wind down and relax after a hard day’s work. Not everyone wants to be “successful” like Mikitani, and this is a unhealthy mindset to impose upon others.

Principles for Success - Hiroshi Mikitani

A book I read in preparation for my job interview at Rakuten in December 2021. It’s a book full of personal thoughts and principles of Rakuten’s founder, Hiroshi Mikitani. It was anecdotal, and pretty dry to me. The five points explained in this book were philosophical and common sense. I imagine it would at least inspire a young entrepreneur. I disagree with a lot of things that Mikitani wrote in his book, but only because I did not grow up in the same environment as he did.

Sure, he raised Rakuten into the empire it is today, but at the expense of treating his employees like expendable resource. I’ve read many stories on Glassdoor about how they treat web developers poorly, under the guise of “being able to work for a famous company”. Similarly, I was disappointed that my job interview went poorly with Rakuten. They offered me a job with low pay and unappealing contract terms, while trying to convince me that Rakuten is a great company. The kicker was, they did not review my portfolio (did not ask for my Github page or ask me to do any coding test), but still gave me the feedback “technical skills were decent but has room for improvement”, which gave me the impression that their hiring process was not sincere.

The only one thing I got out of this book was “work hard and never give up”, but it’s really easier said than done.

Kafka on the Shore (English) - Haruki Murakami

This was the first book I finished reading years ago. It was bad. I had no idea what the point of the story was. I didn’t understand why people praised Murakami’s writing so much.