Friday, December 8, 2017

A non-DBA guide on upgrading your AWS RDS

I use AWS RDS at work for my production database. I understand that it is not infinitely scalable nor provides regional replication out of the box in case my datacenter submerges 3 meters under the sea because global warming is real, people. But in overall, the thing is pretty nice for a growing startup with a lot of battles to fight, computing capacity or storage upgrade without downtime is just clicks away.

I originally titled this as "When to upgrade your AWS RDS". But that's kinda stupid. When would you upgrade your database? I don't know, when everything is smooth and I have a bit of free time, I guess. The one and only reason I look into my database is when thing runs slow and one of those Kibana chart spikes up. It is also worth noting that this is not about tuning those parameters in Postgres. That would be in a DBA guide.

Hold your horse if placing indices and optimizing SQL pop up in your mind upon the appearance of "performance", we will get there. But I have learned that in the age of cloud, hardware problems still exist, virtually.

There are 2 hardware configs of RDS that matter when it comes to performance: CPU and Disk Space. But if you don't pay attention to the difference in these 2, you will pay handsomely and not necessarily get what you want. AWS is like budget airlines, anything out of textbook examples has the potential to cause explosive cost.

When I said disk space is one of the two important configs, I lied. Or rather, I oversimplified how RDS works. RDS storage puts a cap on how many operations it can perform in a second, the unit is known as IOPS. On general purpose SSD, the one I chose to start with, RDS provides a baseline performance of 3 IOPS/GB. This means no matter how efficient your indices are nor how fast your query runs, you can only run so many operations on a block of storage. There are Write IOPS and Read IOPS metrics in CloudWatch telling you how much traffic is going in and out of the database. There is also a Queue Depth metric showing how many requests to database are put onto a waiting list. If queue depth fluctuating above zero, and sum of IOPS aligns with the size of your disk space, don't bother optimizing that query.

I wish I could show you a typical charge when a machine is out of IOPS, but it was fixed a while back. Queue depth was dancing around 50 line back then. Use your imagination.

There are 2 ways you can increase the IOPS of an SSD.
  • IOPS increases according to disk space, so giving the RDS machine a lot more space than your storage works. 
  • AWS provides a higher performance class of SSD that come with provisioned IOPS, the IOPS still increases according to disk space, but at a much better ratio, 50:1 instead of 3:1.
Pros of increasing disk space is that it is significantly cheaper than provisioned IOPS. The cost breakdown looks like this
  • A T2.small machine with 100GB gives me 300 IOPS at $55/month. Never use t2 machine for anything with load or performance requirement, but that's another story for another time.
  • The same machine with 100GB and 1000 provisioned IOPS costs $165/month. And this is the minimal provisioned IOPS. Ok, it's three times the cost for three times throughput, so not a bad deal, but hold on.
  • The same machine with 200GB gives 600 IOPS at merely $69/month.
The cons of increasing disk space is that there is no easy way to reduce it afterwards. You could either spin up a new machine and dump your db there, or set up a replica (an option available in RDS) and promote for the switch over. Both sound like minor headache.

My service happens to require 500 IOPS and is not consumer-facing so some downtime wouldn't hurt anyone. So saving $100/month is a good deal to me. Your use case might be different.

The second hardware config is CPU is more straight forward. If your query runs consistently slowly on high and low IOPS, CPU usage forms some spiky chart, and if you are unfortunate enough to be on a T2 machine, your CPU credit keeps depleting overtime, your CPU is the problem.

As with IOPS, there are also 2 ways to get around.
  • Rewrite your queries, especially if you are using an ORM. You don't need to cover all of them. A look into `pg_stat_activity` table during a high load moment should give you a glimpse on what is going on inside the database. Work on either the slowest one, or the one that runs most often. I once managed to reduce the CPU usage by 30% by optimizing for the second category.
  • Upgrade your hardware to a machine that looks like a gym buddy of The Rock. Because why should I spend my time optimizing someone else's code? Solve my problem all the time. Did I say this is much more straight forward?
Now go check your IOPS.

Sunday, September 10, 2017

Can Kafka guarantee message ordering?

If you never heard of Kafka, this is not for you. The short paragraph won't repeat the concept of a messaging system and its components, internal as well as external.

Kafka has been proven to be a versatile tool for different use cases. In some of those, message ordering, that messages are consumed in the same order as they are created, is more important than the speed of either consumption or production. There is a big difference between depositing $100 and then withdrawing from it, and the other way around.

This illustration is here to please the eyes rather than any particular purpose


In Kafka, order can only be guaranteed within a partition. This means that if messages were sent from the producer in a specific order, the broken will write them to a partition and all consumers will read from than in that order. So naturally, single-partition topic is easier to enforce ordering compared to its multiple-partition siblings.

But sometimes, this setting is not desirable. Having a single partition limits the throughput speed to that of a single consumer. And in most of systems, an enforcement on global order of all messages ever created is unnecessary. The order of depositing and withdrawing of my account shouldn't interfere that of my colleagues (non-causal). In these cases, as long as relevant messages are sent to the same partition, message (causal) ordering is still guaranteed. In Kafka, this is achieved using keyed messages. Kafka partitioners would hash keys and ensure a key always go to the same partition given the number of partitions is not changed.

If the naive hash scheme skews the size of your partitions, e.g. a ADHD bitcoin broker with a disproportionately number of activities making his partition twice as large as anything else, Kafka allows custom partitioner.


Kafka numerous settings include `retries` indicates the number of time a message will be retried on encountering intermittent error, and ``, the number of unacknowledged messages the producer will send on a single connection before blocking (pipelining, not like they are sent concurrently). The combination of these two can cause a bit of trouble. It is hard to build a reliable system without zero `retries`. On the other hand, it is possible that the broker fails the first batch of message, succeeds in the second (already in flight), and then retries the first batch and succeeds this time. With positive `retries`, `` should be set to 1. This comes with a penalty on producer throughput and should only be used where order enforcement is a must.


Sadly, there is no ordering guarantee for messages written by different producers, the order of reception is used. If the system design insists on multiple producers, one topic, and strong ordering, the responsibility falls into the producer application code. This means bigger investment and is the reason why this comes last. As both clock and network in a distributed system are not reliable, sequence numbers can replace timestamp in showing order of messages. The Lamport timestamp is one of such simple and compact mechanism. Lamport timestamp however cannot tell whether two messages are concurrent or causally dependent. The more heavy-weight version vectors would gladly take the job with a few extra dimes.


Single partition, and producer are easier to maintain total order. On multiple partitions, get casually dependent messages to the same partition using key and partitioner. Independent sequence ordering is needed with multiple producers. Accept the tradeoff of not having message pipelining if you want retries and order in the same place.

Sunday, August 6, 2017

Stories of the underdogs II

The internet as we know today started in the late 1980s. By mid 1990s, it had already had a revolutionary impact on culture, commerce, and technology. Around that time Vietnam had its first commercial internet connection. The tipping point was 2004 when internet usage grew by 200% and gave 10% of the population access to the highway of information. A young population, and a network of locally connected game centers, the first profound impact of the internet in Vietnam was the gaming industry. There were some competitions and when the dust settled, two dominating players emerged: Singapore-based Garena and homegrown VNG. When Garena came to Vietnam in 2010, the press described the event as the doom of VNG, that the little Vietnamese startup would soon be devoured. And there was foundation to that, Garena was led by a Stanford MBA graduate, with a seed fund of $2M and operated at 5 different countries before entering Vietnam. On the other hand, VNG founder was originally a bank officer by day and ran his game center in an alley at night. The startup got $80k seed fund and was non-existential outside of the country. Seven years later, both are still around and extremely successful being the first two SEA startups worth more than $1B. There is a little twist to that though. VNG is still virtually non-existential outside of Vietnam. It manages to get on the same tier with Garena with only one market, while the later has 8. Within Vietnam, Garena is solely known as a game publisher, VNG has transformed into an Internet Giant whose products touch every Vietnamese internet users.

The story of VNG is inspiring, against all odds, and exactly the kind of folk tales you suppose to hear in the world of startups. Most startups suffer from inexperience, understaffed, under financed, and overloaded. Of course, once in a while, there are exceptions, like Color, a photo-based social network led by veteran Vietnamese American founders with $41M initial funding. But for the majority of startups, those 4 horsemen of entrepreneurship continue to chase them till exit. Yet despite being disadvantaged, startups succeeded and disrupted markets from time to time. Again, except if you were Color, the startup was a flop and sold to Apple at $7M. So what if we have read the startup stories wrong. That is, what if instead of succeeding despite of all the challenges, great startups succeed exactly because of the challenges they face?

To listen at these stories differently, first we need to redefine what is an advantage. The same qualities that make big companies appear to be fearsome are often the source of great weakness. For example,
when it comes to technology startups, being big isn't exactly an advantage. While a bigger developer team in theory can produce software faster, they are also significantly harder to manage, might suffer from low productivity because of communicating and bureaucracy overhead, and more expensive to keep. Instagram was acquired for a billion dollar with a team of 13. Whatsapp has 50 engineers for 900 million users. With the power of software, hardware, and automation, size is more a liability than an advantage.

On another point, it's tartarus for a company to expand its core competencies to other areas. Once its core competencies are formed, much of the company resources is spent on extending the scope of features so the product is applicable to more use cases, refining development process, and organizational structure to sustain all those activities. Innovations are still cultivated, usually in form of specialization of teams. which results in a stream of smaller, continuous improvement over an existing product or service. That also makes disruptive innovation, like creating products or services that did not exist before, harder. Google for example is an extremely successful company, yet despite its size and the number of projects, much of Google revenue surrounds its core competencies as a search engine. Most of the projects whose role is to ensure Google's relevancy in the next decade such as Android, self-driving car, or AI, are from acquisition and not in-house.

While big corporates focus on regional and global scale, Vietnam startups, even the successful ones, think and act local. This in turn results in products solving very specific problems existing only in the country, and virtually unheard of for anyone else. As a game distributor, Garena did and still aces VNG in every perspectives. They are well-tuned towards international partnership, multi-nation online game operation, and game tournament hosting. What left for VNG were games that are much less popular and operate in only one country. And it was meant to be that way. VNG resources were spent on another problem of Vietnam in the late 2000s. Back then, to run a game center, you needed to be some sort of computer/game enthusiast because the hardware constantly ran outdated, latest games kept popping up, and your computer needed to be protected against these children who were too eager to try whatever tricks they found on the internet. But that wouldn't scale when game center became a business and investment. So VNG came up with this business development team that would consult small business owners with new location, hardware and software setups, and on top of that, install a home grown management software that not only protected the computers against threats, updated with latest games, but also enabled a VNG membership country-wide. So all of sudden, credit player accommodated in one center, can be used in another, as long as the other place also installed VNG management software. The software spread like wildfire and so did VNG presence in every corner of the country.

The trend in Vietnamese startup in recent years can be summed up as following:
  • Solve local problems
  • Avoid direct confrontation with bigger players
  • Disproportionately abundant in Entertainment and Lifestyle segment, due to the size of it
  • Much fewer B2B effort even among each other, which sometimes unintentionally leads to fewer strategic partnership enhancing value proposition and creating win-win situation
In other words, many startups here find guerrilla tactic fits them right. But then, if such can be formulated, why aren't we seeing more successful startups from Vietnam? Because guerrilla tactic is hard, to the point of desperation. Niche local problems aren't always obvious, they more often lurk in a corner, hiding in plain sight. Finding them is like shooting arrow to a bullseye you cannot see. Sometime, the bullseye doesn't even exist. And you have to go on like that days after days, with marginal profit, investors and employees show doubt, sometimes very expressively, none of the effort seems worth it. You only turn to guerrilla tactic when nothing else seems to work. Even startups succeed in this tactic, drop it as soon as they can. Right when VNG revenue from game distribution was stable, they started looking for extension in conventional market, like social network, media streaming, and messaging, all of which eventually replace game distribution as VNG's cash cow.

Doing startup is one of the many ways to gain perspectives of the world. A great one. Much of what we consider valuable in our world arise out of these kinds of challenges, because the act of facing overwhelming odds produces greatness and beauty. But just as important, the nature of these challenges might not be what they appear to be, giants have weakness, and underdogs over and over accomplish the unexpected with right preparation.

Sunday, February 26, 2017

Bye Chung Cư Nguyễn Huệ. Bye Saigon.

Bạn phải đọc cái tin này, thì mới biết tôi đang lầm bầm gì. Nên đọc đi, tôi chờ. Lười lười đọc tiêu đề được rồi.

Giải tán mấy quán này, chắc chung cư Nguyễn Huệ chỉ còn cái xác bê tông. Từ lâu người ta không còn ở đây nữa, tại vì, như trong bài, hạ tầng xập xệ quá rồi. Nói cách khác, những hàng quán này giờ là thứ duy nhất giữ sức sống của chung cư. Dẹp quán đi, người dân không (muốn) quay lại ở, chung cư chắc nhường chỗ cho một toà cao ốc văn phòng phù hợp hơn với khuôn mặt thành phố.

Ở Saigon, các hộ kinh doanh nhỏ là xương sống của nền kinh tế, họ không có chỗ trên khuôn mặt thành phố? Đã lâu ở Saigon không có những công trình như Hồ Con Rùa, không nhầm mục đích quần què gì hết, đẹp thì làm. Ngày xây Hồ Con Rùa, ông kiến trúc sư chắc không nghĩ đến việc bán bánh tráng trộn, hay công viên 30/4 thành chỗ gom giấy báo lót đít. Cũng như chung cư Nguyễn Huệ, những địa danh này trờ thành môi trường để các mô hình kinh doanh phát triển một cách tự nhiên (organic). Đó là dạng công việc cần đến chính phủ, tạo ra môi trường phát triển tự nhiên cho xã hội, và nhường công tác quản lý vi mô (đổ đầy shop vào một cái mall trống) cho khối tư nhân. Khi chính phủ hiệp lực với tư nhân bự, tư nhân nhỏ thành người làm thuê, ở thuê.

Chung cư Tôn Thất Đạm. Cái vẻ chất chất nghệ sĩ bạn nhìn thấy mà không gọi tên được là nhờ tính tự nhiên trong tổng thể. Như một ngôi làng Thuỵ Sĩ.
Trà Lạc Đình, Hồ Con Rùa cũng đi luôn? Cô chú ở đây từ hồi chung cư mới dựng.
Hồ Con Rùa nhìn từ Lạc Đình.

Từ sau ngày 25/3/2015, Saigon hay được so sánh với (quá khứ) Singapore. Bằng vai phải lứa với Singapore thành KPI. Ở Sing, khu Tiong Bahru có hơn chục chung cư cũ, được xây từ thời lập quốc nên chính phủ quyết định phân hàng di sản quốc gia, mọi thay đổi, sửa chữa đều phải xin phép. Giờ thành thánh địa cho tụi hispter ghét mainstream. Booksactually nơi tôi mua được bản Sorrow of War ở ngay đây. Những căn đầu tiên ở Tiong Bahru xây hồi 1920, nhưng phần lớn những gì ta nhìn thấy giờ đây là từ 1960. Saigon đâu thiếu di-sản-quốc-gia-singapore.

Tài sản quốc gia Singapore. Nhân tiện, Marina Bay Sands không phải.

Nghị định số 99/2015 có thể tránh được nếu toà nhà 42 Nguyễn Huệ từ bỏ chức năng chung cư của mình? Tôi không biết, tôi là dân tay ngang, và bạn đừng có mà tin một thằng ất ơ trên Internet. Nhưng trung-tâm-mua-sắm-nhìn-như-chung-cư / mall-that-look-like-apartment-building thành trào lưu mới của Saigon? I can live with that. Heck, after a selfie stick is decided to be called "gậy tự sướng", I can live with anything.

Thursday, December 29, 2016

Don't work after 7PM

I have had crunch times where my day basically consists of only one thing: work, randomly interrupted by periods eyes close, mouth drools, and mind goes blank, all by themselves. And those times can be healthy, like a couple of days before a release give me a boost of motivation. But doing so over any extended period is just bad. Its bad for me and bad for the very business I thought I was helping.

Enough talks about burnout, about there is more to life than just work (because work somehow gets the bad rap), about working on the same set of problem over and over is damn boring, lets talk about an engineer's values.

As an engineer, my values consists of 2 components.
  • My absolute value, defined by skills, methodologies, and mindsets. These values are the stuff I bring to meetup, write about in my blog, and are applicable to whatever I do. They are mine.
  • My relative value, defined by my knowledge of the project I am building, the sector my company is in, and how technical decisions were made. These determines my productivity, and ultimately my worth to the company.
Of all the jobs I have had, I always start like this. I don't know anything about what I am supposed to build, but I have my skills as an engineer (hopefully qualified after a legit interview). As I stay around, I acquire more the domain knowledge and know how things are done. I apply what I have learned from the last job to this and in turn sharpen those skills. Both my absolute and relative values increase.

If I neglect picking up new skills, of course my absolute value stays still. Or rather, it slightly decreases as everyone else is forwarding. But if I stay longer, spend more time writing the code that somehow a repetition from the previous job, (same old CRUD), I become the person to provide backstory of features, explain the tweaks and customization we have in code, and set the pace for newbies. My relative value increases, and as a whole, my worth to the company also does.

Alternatively, because I am more than a lazy-ass, occasionally I learn something. New knowledge is hard and immediate reward is scarce so in the beginning I stumble. But those technical advancements are important never the less, like efficient asynchronous model, container orchestration, or architecting data-intensive system. A lot of the things I read, practice, put into pet projects are just out of curiosity and at some point go to the attic for not being practical. But once in a while, it turns out to be useful, I can contribute back to the product I am building. My absolute value enjoys a slight hump and because I still contribute to the project, my relative value also increases.

*Both are extreme scenarios made up to illustrate my point, most of us are somewhere in the middle of the spectrum.

Every night, every weekend I spend completing what I should have done between 9 to 5 fosters my relative value and postpones development of absolute value. At some point, there is a chance my worth as a data archiver wins over my worth as an individual contributor. I get my benefits for being valuable to my company, if not even more. That though makes me as an engineer less appealing to other organizations who derive benefits from my absolute value. A golden handcuff.

I can understand where the idea of focusing on your job 24/7 coming from. Picked a course. Realized I didn't know shit. Sucked it up. Put in a lot of hard work. Submit assignment. Remembered I had 3 other courses that semester. Repeated. This was the vicious circle I went through in college. Basically what worked for college was to spend more time till I am better at it. Which I had plenty.

And for a while, career seems like an extended version of college where the semester is longer. So the same trick should work, right? If I work day and night on my job, I should be better. Except career and college aren't the same. The rules are different, a product is an ultimate goal, whereas an assignment is merely a means to an end, more responsibilities from society and family are waiting, and the problems we face are not only harder, but also demand to be done in less time. What got you here won't get you there*.

The keys to succeed in different phases of my life can be arguably sum up as:
  • High school: just be smart and don't do drugs.
  • College: lot of hard work and occasionally try something totally irrelevant.
  • Career: still hard work but learn to know where your time should be spent (up till this point, but I guess you can slice one's career to a zillion of different stages).

Effective on-the-job training is rare, most desirable skills like machine learning, distributed computing, or business intelligence take years to build up. In this part of the world, sabbatical leave isn't the norm. Many people actually haven't heard about it. So being a top-notch engineer is anything but a personal investment. Who I am in the next 5 years is defined less by the company I am in, and more by what I choose to do after 7.

Thursday, February 18, 2016

[Agile Games] Jenga Builders


The core idea of this game is to have teams build wooden structures with jenga sticks. The game is played by rounds, where each round is supposed to deliver an Agile lesson. In the context of this post, attendees can expect to learn about the darkness principle, quick feedback and communication, and being adaptive to change.

Each round after the first is essentially optional, the host can choose to add/remove rounds depends on available time. The host is also welcomed to pick, or customize her own round to deliver the desired lesson.

Team size

Minimum 4, ideally not more than 6.


20 - 60 minutes depending on team size and number of rounds.


  • A deck of Jenga
  • Photos of pre-designed structures, 3 x no. of team / round
  • A whiteboard to record scores


This game will be run over several rounds, with each round introducing a new concept.


  • Split up the group into team of at least 4, and ideally not more than 6.
  • Choose one person from each team to be the Analyst. The Analyst knows the core of the structure, but not which colors to be used. The Analyst is not allowed to touch Jenga sticks.
  • Choose one person from each team to be the Designer. The Designer knows the required colors for a specific part of the structure. The Design is also not allowed to touch Jenga sticks.
  • Choose one person from each team to be the Tester. The Tester knows the whole structure, but can only answer questions and is not allowed to give instructions or touch Jenga sticks. 
  • The rest of each team will play Developers. Developers are the only ones who can actually use Jenga sticks and build stuff.

  • The Analyst is given a photo of the structure needed to be built. The color of the sticks in this photo does not matter, in practice, team can use whatever colors available.
  • The Designer is given another photo of a part of the structure needed to be built. The color of the sticks in this photo is crucial. The part must be a component of the final structure, with the exact color depicted in the photo.
  • The Analyst and Design have to combine their knowledge of the system and convey that to the Developers, who build stuff.
  • The Tester is given the photo of the final structure and has the right to accept or reject the work of the team.
  • The initial flow is that The Analyst and The Designer will discuss and agree on the structure, convey the idea to The Developers and finally the work is given to The Tester to accept or reject.
  • No one is allowed to show her photo to others.

Round 1:

This round teaches The Darkness Principle.

Each element in the system is ignorant of the behavior of the system as a whole, it responds only to information that is available to it locally. This point is vitally important. If each element 'knew' what was happening to the system as a whole, all of the complexity would have to be present in that element.

After the team has formed and roles assigned, give the below photos to relevant team members. And the game begins!
Analyst #1
Designer #1
Tester #1

After all the teams have completed their structure, ask questions on what happened, what went well, and what went wrong.


What we learn from The Darkness Principle is that nobody on a team has a complete picture of all that's happening in the entire team. Each team member can only have an incomplete mental model of the whole project. That is why they have to plan and decide together.

Round 2:

This round teaches Quick Feedback and Communication.

Give the below photos to relevant team members.

Analyst #2
Designer #2
Tester #2

The trick here is that there are many different possible outcomes from the photos given to The Analyst and The Designer. Only The Tester knows the correct one. But he is at the bottom of the chain. 

After all the teams have completed their structure, ask questions on what happened, what went well, and what went wrong. And if they want to make any change to the work flow.


The work will be carried on in usual manner, then given to The Tester to be rejected. We should note half the amount of work was wasted, and that the position of The Tester isn't optimized for quick feedback loop.

Round 3:

This round teaches Being Adaptive To Change.

Give the below photos to relevant team members.

Analyst #3.1
Designer #3.1
Tester #3.1

The trick here is that the outcome is almost possible to do. (At least for me, I had to put a finger on top of the whole thing to prevent it from falling apart.)

Somewhere half way, when the teams keep failing to build the structure, hand out this second set of photos.

Analyst #3.2
Designer #3.2
Tester #3.2

This time, the structure should be possible. (I managed to make that.)

After all the teams have completed their structure, ask the same retrospective questions.


What we learn from this is that goal and target are not always rigid, and in order to deliver, sometimes, reasonable compromises are needed.

Round 4:

Freestyle. This round is for the team to summary what they have learned in previous round and as a whole, feel good about the learning curve. "Finally, a proper sprint!"

Analyst #4
Designer #4
Tester #4
All structure photos can be found here


The game had its first debut at Silicon Straits 18th Feb 2016. Below are the points I observed from that first try.
  • As suggested by The Darkness Principle, the key to win this game is communication, communication, and communication. A good team did a lot more talking than their lesser counterparts. Members in a good team were more willing to listen to each other and showed less tendency to suppress minority's ideas. The existence of an alpha role was subtle. All are desirable behaviours for brainstorming sections. The good team also utilized the role of Tester better (raise more questions and shorter feedback circle). 
  • Whereas in the bad team, where The Analyst and The Designer had troubles expressing their vision, the team stumbled trying to get the sub-components right, left alone combining them together. With bad vision, the team fought for an alpha role, a process in which team members just went ahead trying to prove them right, spent less time listen to each other, and suppress more "silly" ideas (unfortunately, a few of them were really good). And in general, the bad team were more distant to leadership (members with photos) and treated them as checkpoints, rather than equal collaborators. 
  • The gap of speed between a good team and a bad team can be quite big, up to 100% (my subjective observation). This had a couple of by-effects. The good team had way too much free time. The bad team is demoralised. It was suggested to have not 01 host for the entire game but 01 host for each team, constantly checking with each other and dropping hints to keep teams on pace.
  • Can consider switching roles between rounds, so that people can try different positions, have time to slow down themselves and do internal retrospective.
  • Stronger emphasis on mini retrospective meetings. The debut was run with participants all standing. While this was good for the game play and team dynamics, it thwarted the necessary pause to retrospect what happened, what went well and bad, any improvement to make.
  • At some point, The Testers would try to manage the whole project, because they have the complete view of the structure. But as they aren't allowed to give instructions, team needed to have good strategy to query the correct requirements. So far, none of the teams spent time on improving the art of asking questions.

Sunday, February 7, 2016

2015 - I don't trust my plans any more

In contrast to the unpredictable 2014, 2015 was a year full of plans and projects. I planned my life around the sparks of changes in 2014, hoping that I could keep the momentum and better myself every day gone by. And of course, like every single time I make any sort of plan, life tossed it into all weird, twisted, yet still amazing, directions.

1. I moved to Singapore, and left.

Open door concert, which I have missed dearly

2015 indeed started big. I was relocated to Singapore and tasked to lead an effort to produce a gaming smartphone. A freaking actual smartphone. An odd request. But why not?

The original idea was nothing short of moon shooting: an Android-based phone with hardware customized for gaming and bulky design as eye candy. The learning curve was steep, gave me butterflies in the stomach for months. I digested books from hardware design to manufacturing techniques, became proficient at navigating through the dissatisfying interface of Alibaba, and went from trying to pronounce CyanogenMod correctly to a walking wikipedia of Android forks.

As a city, Singapore is extremely modern, convenient, and safe. Hate to admit but Singapore's tech community was way more active than Vietnam's with events basically every day. There was much to think about those events. On one hand, they were trendy with all the latest hypes, people were talking about trips to Silicon Valley as if they were weekend getaway (sorry, I grew up on a mountain), and all the big shots have offices there. On the other hand, a few were just sales pitches in disguise, some were fuelled by consultant bullshit (especially anything "IoT"), and the rest managed to remain quite abstract and high level. Actual coding could still be found at hackathons though, which were plenty. But the most important thing was that everything was there and very well-established. So much that I didn't feel like there was a need for anything new.

It took 5 months (or 6?) to present two working prototypes with a detailed production plan. Just to be rejected by management. For the same reasons raised since the very beginning: huge upfront investment, nonexistent margin, and unless one is an Ivy League member, consumer would not bother. ¯\_(ツ)_/¯

Without going any further to the misalignment between me and management, that was the background of the decision that, after half a year living in Singapore, it was time for me to go home for more adventures, and bigger social impact.

2. I (still) organized BarCamp Saigon.

Meet the team

First thing I committed to upon returning to Saigon was to pull together BarCamp Saigon 2015. After the nightmare of 2014, I thought I had learned a thing or two. Well, guess who managed to surprise himself :D

All jokes aside, the preparation of BarCamp Saigon 2015 was a lot smoother, the team had one event under their bell, which boosted confidence, and I received superb support from professor Edouard, to whom BarCamp Saigon 2015 also happened to be his first public event as the manager of RMIT's IT program.

And thank to that joint effort of everyone, I was given some room to think about the future of BarCamp. BarCamp Saigon has been around since 2008, and during that, a community has grown around it. From a tech event, every year we are observing a more diverse crowd attracted to the openness and democracy of BarCamp. The challenge the BarCamp team needs to face is to maintain the same factors that have kept BarCamp an one of a kind event in Vietnam, and at the same time, evolve to meet the quality requirement of niche segments, an important factor if we want to set the standard for a community event.

In the foreseeable future, BarCamp will remain to be an umbrella event for all sort of topics as long as someone want to share, and someone willing to listen. We are looking for more focused events, like TechCamp for hard-core tech, and, say, BulbCamp for creative people. But an event like BarCamp is an intensive effort. we need 3 months of preparation for each. The majority of time goes into looking for sponsors, and coordinating sponsors and vendors both before and on event day. And most importantly, we don't have enough people to sustain more than an event per year, and we are subject to terrible terrible voluntarism. What works in the tech circle might not work elsewhere, and we might end up solving problems that don't exist, or generating irrelevant values. It works way better if someone with their industry inside decide if their industry can use an unconference like BarCamp to spread a fresh air, and we contribute our expertise from many events in the past, and build something new from that combination. So folks, if you think BarCamp makes sense for your industry, please spread the word, we will take 2016 together!

3. I started training to be a long-distance runner.

Who could have known this pearl in the heart of a mega city?

Singapore's national sport is windows shopping. But it was there that I was blessed to meet Deny. Deny started off as the CTO of my then company for a very short period of time, but remained to be my mentor ever since.

By introducing me to MacRitchie reservoir, Deny unfolded a hidden part of the mega city. MacRitchie is an ever-green tropical forest growing around a lake which was meant to serve as a stable fresh water supply for colonial Singapore, a hundred years back. There are traits through the woods and around the lake shore. Some of these traits link with other upper North reservoirs, requiring no less than 8 hours to explore. I am weak, I am always content with 4.8km and 11km traits :P

Deny is a long-time runner and had completed a full marathon a few years ago. I believe it was none of his intention to squeeze the living breath out of the poor me, but he often held conversations as we jogged under forest shades, those that always started with work (and I felt compulsory to respond) but soon expanded over various topics of life. Needless to say, the first few trips were brutal. It called for mammoth effort to both keep up with his pace and follow the on going convo. I have to say, desperately grasping some air to feed my brain with oxygen and restraining not to split any stupid nonsense is an experience very close to drowning. I am pretty sure there were occasions all I could do was mumbling senselessly. Sorry Deny!


But those early days were crucial for my foundation, and bred a new hobby that, by now, would very likely to stick with me for a few years. The whole running and exercising thing has taken me to a number of interesting events, including Bali 10K, Fansipan trek, and HCMC 21K just a few weeks ago. But the most significant one is to be able to run around Xuan Huong lake, the heart of my home city, 6 days in a row. A task I couldn't do back in high school (we boys typically needed to short break in the middle). The thought that 26-yo me is doing something a bit better than 18-yo me is really cheerful.

I am the kind of person who finds being alone enjoyable (which needs to be differentiated from being lonely, which sucks really hard). Running alone an hour or two, or programming 4-5 hours straight is neither boring or difficult, but pleasant and productive. The essence of running is to exert oneself to the fullest within one's individual limits and I hope this can serve as a metaphor in my life too. (Though recently Trang has managed to find her way into my lonesome solace, I am really glad about this disturbance. Perhaps more on this next year)

4. I wrote vividly.

I wrote a fucking blog post every month in 2015.

There, I said it, such an achievement. And I wouldn't have been able to accomplish that without shredding nonexistent constraints (and a delusion) I put on myself.

  • That I shouldn't stray away from engineering topics. While it is true that I am strongest at engineering and in the past has met some instances where engineering principles made great sense in life. But the other way also works. One's senerity is reflected in his work and being only one-sided one runs the risk of building his own personal problems right into the product itself. Open up to all sort of topics gave me new sources of inspiration and seed diversity into my career.
  • That my Vietnamese was lame. That is actually true too. 
Tiếng Việt của tôi nghe lộc cộc như ngựa chạy. Hồi còn học văn, tôi nghễnh ngãng, lại không đánh giá đúng tầm quan trọng của ngôn từ. Tôi chỉ nhớ được, là lần đầu tôi phải dừng lại, nói lên điều mình suy nghĩ bằng con chữ, là một bài luận TOELF, đương nhiên là bằng tiếng Anh. Cái này kéo dài trong nhiều năm liền, từ phổ thông đến sau đại học. Chả vẻ vang gì, dở tiếng mẹ đẻ của mình tôi lại còn thấy nhột. Dù vẫn còn khoảng cách về chất lượng mỗi khi dịch bài từ tiếng Anh sang tiếng Việt, và ngược lại, mọi thứ đang trở nên tự nhiên hơn tí tẹo.

I was very unskillful at using Vietnamese. I was an absent-mind kid and has always regretted that I didn't develop an appreciation for literature when I was younger. As far as I can remember, the first time I looked into myself and tried to recreate my stream of thoughts in words, it was an TOEFL essay, obviously in English. And that continued to be my dominant form of communication for many years. But being suck at my mother tongue is not something I am proud of and I don't like the feeling of being less than proficient at something as important as communication. Though there is still a degrade in quality when I translate a post from one language to another, it is coming a tiny bit more naturally now.

  • That one day I could turn writing as a hobby into a means of monetization. Writing as a hobby is great. And if I can live by writing, it is even greater. The core idea of making money from writing is that someone must find my writing enjoyable. And nothing is wrong with that. People enjoy a whole lot of thing, there must be someone enjoying my writing. But the trouble was that once I had that idea in mind, I found myself writing less as a way to express myself, and more as a way to please others, the almighty "audience" (who might not even exist). And that was bad. I kept circling around basic topics, known facts, and nothing controversial, because those were low-handing fruits. I was neither productive, nor proud of my individuality. And having an agent nagging about what I should and should not write (though more like must, if I wanted to be published), was annoying as fuck. So I just dropped.

I only want to write because I am a human being with thoughts and feelings, and because no one can stand me being emo and pouring my thoughts on them so randomly.

5. I found these people.

I still remember I found this group of people a hot, sweaty night of April, in Saigon, during one of the many trips between SGP and SGN I had. Though till now, the exact reason the group formed and clicked and jelled so well is still beyond my understanding, and therefore obviously beyond words. Though I am suspect it is Thanh's good and cheerful nature that makes everyone at ease!

We have already had a lounge as our hub of activity, gone for a few trips together, and given each other names that would embarrass the shit out of anyone in public. Out of sudden, I realize that "Damn, these weird crazy people are my greatest dose of anti depression now". Dũng, in case you fucker are reading this, you are important too, but you're not a new dot in 2015. You are a rat's ass dot since junior high!

If there is anything 2015 has taught me well, it is that planning is necessary and it gives you a long-term vision how your life plays out, but it is also important to listen to yourself and the omens of life. Often when we are too focused on the goal (and plans really help that), we underestimate our natural ability to navigate complex system and improvise, forget the original reason of all these plans, and lose track of the journey.

My plan to make a smartphone was dropped like a sack of potatoes, but I got to go through a learning period of hardware design and manufacturing that wasn't available elsewhere.

My plan to organize BarCamp Saigon 2015 didn't turn into a disaster, though lot of unexpected happened. We still haven't missed a single year of BarCamp.

My plan to take on HCMC 21K run scattered as I failed to follow a rhythm and both over stressed my muscles and gave them too much rest. I crawled back to the finish line with cramped legs, but finish the race I did.

I can go on like this for a while, but it is just rant, you get the idea.

At the end of the day, it doesn't matter what happened or whether a plan went well, but that I don't give up on becoming a more okay person and, this is new, who I go through stuff with.

Hello 2016!!!

2016 started off with great photos!!!