Wednesday, December 30, 2015

What people did not tell you about microservices

The context

Over the last few months, I was commissioned to build an analytics system for logistics. Think of Google Analytics for shipment. The project consists of an engine to collect shipment information, analytics logics to normalize, combine and produce subsets of data through various stages, and a few different interfaces to represent the data to targeted users. That nature suggests a system with discrete components that should be planned and built in plug-and-play manner.

Having each component as a standalone, independent module allows me to choose the proper tool for the task. Java made up the core of the system where we need processing speed, stability, and off-the-shelf client support. Nodejs is used where either web socket or massive asynchronous tasks involves. And Python where we want a quick way to glue things together and iterate on ideas. The communication hub is built around Apache Kafka. Up till this point, all development environment is orchestrated with Docker and Docker Compose. We are planning to bring the Docker containers to production soon, once the monitoring is in place.

The project is considered strategic and therefore a new team has been built around it. The goal is to have this team dedicate to the project, grow with it and form the intellectual core in the long run. The project is run in 2-week sprints with committed deliveries at the end of each sprint. Though more often delivery schedule is always welcomed.

So that's the background, lets look at expensive lessons I have learned along the way.

1. Good onboarding is crucial

For many project, onboarding a new team member is an important activity but often neglected and instead, the newbie is given a stack of obsolete document. If she is lucky, she would be given the source code and have to figure out how to bring up the system.

The main reason for the neglect is because during onboarding period, the team's productivity slows down as key people are pulled away from their tasks to explain (parts of) the system to the newbie. And if your team follow a rigid delivery schedule like my team does, onboarding can be a stressful experience as more balls have to be juggled: maintain committed deliveries, and spend decent time for thorough explanation.

I have learned that with such many balls, go for good onboarding and negotiate delivery schedule if needed. While it is tempting to spend less time on the newbie (who, after all, is supposed to kick ass), there are too many reasons not to:
  • There are just so many works a good onboarding requires. Over the course of few days, one has to go through the project overview, business values, and core competencies. he also needs to set up a development environment and interact with the system one would later help building. During which, he would need to get familiar with all components, what they do, and their scope of responsibility. And before writing any line of code, he must understand project standards, toolings, and enforced and unenforced conventions. It is a major, haunting task.
  • Plus a microservice system is almost always complicated by its nature with all those moving components. A newbie, no matter how good he is, won't be productive till he has a good grab on both the big picture and the little piece of lego he will be working on. As a universal law of knowledge worker, a "just code the thing as spec'd" is a lose-lose situation.
  • Given that, no matter how much night oil you burn, you aren't very likely to meet your deadline anyway, not in a decent way. Goofing around for a demo, or pull together an immature onboarding would only result in expensive technical debt and bad morale, both definitely bite you back at some point, might as well, the very next sprint.
A well-informed newbie would always be productive in no time and make up for the delayed delivery. Always.

2. You can't possibly write enough document.

Now, every time I start a new project, I talk to myself "This is more documentation than I have ever done before. Should be enough for even my mother to understand." and it's never enough.

But that is even more true with a system with much dynamic as a microservies system. Seriously, the number of documentation I write this time is just ridiculous.
  • On highest level, there is architecture and infrastructure documentation. One focuses on the logical components, while the other on the actual machines things run on.
  • Integration across services are captured in flow diagrams, which then come with message format (Kafka, MQ, remember?).
  • Every component then has its own set up guide (besides one whole-system set up guide) and those whose service is used by others have their interactive API doc.
  • Specifically complicated components get their own flow diagram (though the rest should be able to interact with them in black box manner.
But the reality is that not only the documentation alone isn't enough to understand the system (a process which, to be fair, can be overflowed with data and decent time for self exploration should be given), I couldn't keep up with the amount of doc, the amount of work is justifiable for a full-time technical writer.

That situation calls for a change in practice. While major high-level document (like the architecture and infrastructure) should continue to drive the implementation, finer detailed documentations that involve multiple modification each sprint should be derived from the code itself. The goal is to have the code serve as one reliable source of truth and everything else to make sense of it is generated when needed. For example, a business analyst needs a database schema? Generate it from the database schema. A developer needs to know how to use the latest API? Comment block is extracted, combined with a simple interactive form to try out, and you have API doc.

3. Automate your environment setup

Now that you have automated document generation, it is a good time to automate environment setup too, starting from dev and all the way to production. My project is using Docker, but this can be applied to all tools, like Chef, Puppet, or Ansible.

At the beginning of the project, with a handful of services, it is simple enough to announce a change in service Docker with a group chat message, or a poke. You can also easily update the new setup requirements to the service's README file. But by the time the project gets a dozen of services, if a developer has to either keep a eye on chat messages for setup changes, or iterate that many README files, he would commit a suicide.

Be it bash script or python script, or whatever else, automate environment setup as much as you can. A few things you can consider to begin with are:
  • auto update code of all services and restart Docker containers
  • auto remove obsolete Docker images and containers (you get lot of these when building new services)
  • auto update configuration files based on last edited/updated timestamp.
I can't stress how relieving it was for my team to have a smooth, reliable automation. No more waste of half an hour every morning trying to figure out why what worked yesterday before stops today. Seamless automation is worth all effort.

4. Standardize everything

The upside of microservices is that developers have lot of freedom to do their work, as long as service contract is respected. The downside of microservices is that developers have too much freedom in their work.

Aside from the choices of technology, a few things I kept running into

  • Mix used of `CMD` and `ENTRYPOINT` in Docker (hint, they aren't supposed to compete, but complement each other)
  • Inconsistent log formats. The log level fluctuated from standard output to log rotator, from random debug log to nginx-style. The Wild West can only so crazy.
  • Bash scripts with different names, in different directories, but all do the same thing. ``, ``, in a `scripts/` directory, or at root level. And so on.
Independently, these are just a bunch of little harmless variations of some right things to do to keep a software system maintainable. But together, they make the life of whoever whose job involves jumping in and out services miserable (i.e. everyone but developers). Now of course monolithic codebases have such issue too, but it can be ruled out easily even without a quality police because everyone looks at such thorn all the time. I didn't realize how different personal preferences can be (but hey, after all, we are a new team).

Well, eventually the variations pissed me off so much I had the development paused so we could sync up the conventions and made an oath to keep them. For the watch!

5. Collective ownership doesn't work

By the book, Agile management encourages every to share responsibilities for code quality, anyone can make necessary changes anywhere and everyone is expected to fix problems they find.

Whereas the share responsibilities part still rings every bits and bytes and we encourage that with tight feedback circle, rigid definition of done, and tests as safety net, the two later parts go from bad to really bad. In a microservices system that employs various technologies, anyone can still make change anywhere, but it is probably for one's best interest that he doesn't. Lets take a quick look at the technologies I mentioned upfront: nodejs is asynchronous by nature and one must forgo traditional threading model (I got many eyebrows saying that nodejs runs on only one big ass thread, but it does, people!). Python is a dynamically-typed language  and Java is a statically-typed one. Each language calls for a different mindset. Makes change to a codebase one does not understand the philosophy behind and technical debt is probably the best outcome.

And fix problems they find? Typical management's hopeless optimism.

A more practical model is to let a developer takes a complete ownership over his service(s). Others might chip in for help, but within the service's scope, he is the technical lead and in charge of maintain quality standard, code convention, and whatever else he considers important. That might sound too rigid for an Agile team, and it might be true. But screw the Agile label, I need reliability. With no monitor system in place, and a dozen services running, each has its own set of runtime problems, I need each to know one thing inside out, not a bit of everything.

6. Keep an eye on everything that moves

Ok, saying that people didn't tell me about the need of monitoring a microservices system is an overstatement. The topic of monitoring appears one way or another in books and articles I have read about microservices. What wasn't seemed to be stressed enough is the sheer amount of work required to get monitoring up to the level you can be confident about the system without fearing something would fall apart the moment you turn away.

Right on the development environment, having all the log gathered in one place that you can later on `tail -f *.log` is a huge time saver. Depends on the 3rd party libraries that you use, your log might be populate with mumbo jumbo of bullshit. Take effort to filter those out of your log, the investment is paid back every time you inspect an inter-service bug. If possible, slice your log into 3 groups:

  • Activity log (or debug log) to monitor the flow of data between services
  • Error log, so you can find the most critical thing right away when something goes awry
  • Third-party libraries log, in case you want to play safe

Once the system is in production, the focus is less on the flow of data, but more on performance and health checking. You want to have the ability to know how many nodes has a request had to travel through before a user can see anything, how much time did it spend at each node, and set up programming to trigger escalating actions when certain thresholds are passed. For this purpose, we are using ELK stack where Logstash crawls log from distributed servers, feeds ElasticSearch, and put a presentation layer of Kibana on top. Formatting log and organize Kibana report is then an ever going job.

While ELK would tell you about the performance of a system, it shows little about the health, e.g. a service can be serving request at less than 100ms, but its RAM is  whooping 90% up and CPU utilization is always above 70%. That introduces a different set of system monitor tools, like AWS CloudWatch, Navigos, or NewRelic.

From time to time, by doing house keeping work such as migrating service into a bigger machine, scale out a service to a few instances, or deploying new service instances while iteratively shut down old ones to achieve zero down time, you would get really tired of constantly checking whether a service is up, and still at the same IP address or not. Well, that is service discovery like Consul or etcd you are longing for.

My point here is to illustrate two points. First, it is very crucial to keep a close eye on the system as a whole and optimize the flow of data. Second, it is very tempting to apply all the bells and whistles, and surrounded yourselves in dashboards and get distracted from the only thing that matters: the system itself.

7. Whatever you estimate, multiply by 3

There is probably no other project where my estimation has been off by 100% and, unfortunately, nothing intrinsically stops it from going to 150% or even 200%. Most original estimation could only barely cover coding and unit testing. While equal amount of time is required for gluing a service to others (integration test), and environment setup (Docker, monitoring). The experience learned from this is absolutely valuable, but it is costing an arm and a leg.

Sunday, December 27, 2015

Đường Tàu

Nhỏ lớn tôi ở trong cái xóm nhỏ (trước) làm nông, lọt thỏm dưới chân mấy con đồi. Xóm nhỏ chẳng có gì đặc biệt, đến người Đà Lạt không có việc đi vào cũng chẳng biết. Được cái gần ga tàu, ngày nghe tàu hụ hai lần. Nhưng tàu ở Đà Lạt là tàu cảnh, cả ngày chỉ tha được cái mông rỉ sét đến trạm Trại Mát, chưa được 20km đi lẫn về.

Muốn đi tàu cho ra hồn, phải xuống ga Phan Rang Tháp Chàm, ở đó có tàu Thống Nhất chạy dọc Sài Gòn Hà Nội đi ngang. Mà xuống được đến Phan Rang, phải qua đèo Sông Pha (lớn lên tôi biết còn gọi là đèo Ngoạn Mục, nhưng cũng như cái tên hồ Sương Mai, tôi cho quả là dở hơi). Với một đứa nhỏ dặt dẹo đi xe hơi trong thành phố cũng bị say, đèo Sông Pha cũng kinh hãi như cuối năm họp phụ huynh. Vậy nên đi tàu, với tôi, chết luôn hình ảnh những chuyến đi đằng đẵng, những vùng đất xa lạ.

Vậy mà lớn lên tôi đâm nghiền tàu hoả. Không chính xác là nghiền những vùng đất xa lạ kia, mà là cảm giác đi tàu. Tôi có tật gắn cảm giác với ký ức. Bị đau tôi nhớ về hồi nhỏ bị đòn. Củ khoai nóng làm tôi nhớ mấy lần lùi khoai trong vườn, không biết nhóm lửa đốt toàn bằng dầu hoả. Tiếng đá kiện lách cách kéo tôi về những năm đồng phục đi học. Bước lên tàu, mùi dầu diesel gợi lại lẫn lộn bao kỉ niệm: lúc nhỏ phấn khích phát hiện ra đi tàu lửa không bị say (nhấn mạnh là tàu lửa, vì có lần đi câu mực trên tàu thuỷ không được êm xuôi lắm), cảnh bình minh choáng ngợp đoạn đi vào Phú Yên - xứ Nẫu nói chung là một viên ngọc thô đầy cảnh đẹp, rồi lần thất tình bỏ nhà, bỏ việc đi biệt.

Những chuyến đi đó đưa tôi đi khắp miền duyên hải Việt Nam, qua những đồng lúa, chui hầm Hải Vân tối hù, lên tận đê sông Hồng mà khi nhỏ chỉ tồn tại trong những câu chuyện xa quê của bà nội. Tàu đưa tôi qua cả các cung bậc xã hội đất nước này. Trên con tàu mười mấy toa, một người trên đường đến toa ăn, đi được qua từ khu giường mềm điều hoà, đến ghế cứng gió trời. Chặng đường càng dài, phân tầng càng rõ ràng. Tôi nhớ hoài lần đi tàu đêm ngang Ninh Thuận, trời hè nóng như hun, toa tàu đóng cửa sổ mắt cáo, không quạt, không khí quánh mùi dầu máy trộn mồ hôi, non trăm con người ngồi ghế cứng, vặn vẹo tìm chỗ ngã lưng chợp mắt. Với tôi, đi tàu là đi chơi. Với nhiều người khác, đi tàu là lựa chọn duy nhất cho hành trình dài dẵng, vì làm cả năm không dám mơ một tiếng ngồi máy bay.  Không đến mức người trong nhung lụa, người bánh tráng phơi sương, nhưng vẫn là một lần mở mắt.

Lớn lên với một sân ga trống. Trưởng thành hơn sau từng chuyến đi. Đoàn tàu với nhịp điệu xình xịch cho tôi nhiều trải nghiệm đầu tiên. Mà tôi có cảm giác thế này, là cảm xúc lần đầu là mạnh mẽ nhất vì mỗi lần như thế, một người để lại một phần tâm hồn của mình lại trong những mẩu ký ức, vun vặt hoặc sâu đậm. Tâm hồn dần bé lại và khi nó biến mất, anh ấy chỉ còn sống trong những hoài niệm. Điều này không đáng buồn, vì một ngày đôi chân ngừng lại, ta biết được mình đã đi qua những gì. Mỗi người lại có sợi dây của riêng mình, kết nối những ký ức này. Đường tàu dằng dặc, đường tỉnh lộ nắng cháy da là những sợi dây của tôi. Đi tàu, đưa tôi về những miền nhớ xa xôi như chính hành trình, đưa tôi về thăm tôi của ngày cũ.

Monday, November 9, 2015

The story of titles - Chuyện cái tên

src: phd comics
When I got my university orientation, I was fascinated to learn the differences between Computer Science (software) and Computer Engineering (hardware), and awed when the professor explained the various career pathway my choice would lead me to. The more courses I took, the better I understood that a successful software project is the contribution of many professions: developer, business analysts, tester and so on. I felt both overwhelming and excited of all the knowledge a project requires.

But after a while, the novelty of specialisation died out. Many seemed to fall in love with the ego boost from their specialisation and got distracted from what really mattered in a software project, the product. All the buzz around programming rockstar or javascript ninja was very eerie to me. I couldn't help but feel indifferent at all the attempts people made to discriminate Coder, Programmer, Developer and a few others, as if it was some sort of Indian caste system.

The ultimate goal of a job title is to provide a common understanding of the scope of responsibility each holds in a software project. As in a developer shouldn't try to set up production environment in the same ad-hoc way he did on his computer and should rather leave the heavy lifting to a system administrator.

But then, does it mean if I was a backend developer, and the frontend of the project I am working was a total disaster, then it would be none of my business? Does it mean if the project was late and everyone was fire fighting, but my part was elegant, flexible, and maintainable, then "good luck, suckers"?

Software development is a very personal experience to me. Given an idea that I find challenging, and that would be the only thing in my mind every waking hours. And if someone tries to stand between me and the good product I am busting my ass to build, just because that wasn't my role to do such and such, she can talk to the hand, because the face doesn't give a damn.

One-man army is nothing new in this industry. One most likely to find such title associated with either an overachiever or a craftsman. Though the course of action might be identical, there is a subtle between the two. The overachiever spends many years of his life being the best in class, slowly turns into a narcissist who assumes everyone is an idiot and choose to be all on himself. His motto is "trust no one and no one will hurt you". The craftsman devotes a good portion of his life to better himself, yet at the same time, appreciates and respects the skills of others. The overachiever wants to be the best. His success is a product of comparison. The craftsman understands that mastery is not a zero-sum game. His success is a product of self retrospection.

I believe the highest stage of any profession is to become independent. Independent in terms of vision, knowledge, and approach. An apprentice spends many years of his life doing others' chores, but that is not his goal but a means to an end. Eventually, that hard work is to prepare the apprentice the foundation of mastering his craft. When one possesses the means, and, more importantly, determination to be independent, he is free from collective thoughts and can live true to his reasoning mind. Any form of creative collaboration should be a free agreement and everyone is free in his proper function.

In recent years, the community has acknowledged this journey of mastery and welcomed the rise of full-stack developers. But the problem with full-stack developer is that "full" refers to a state of finish, of completeness, done! The feeling that I am done with studying, that there is absolutely nothing else I can learn leaves me quite devastated. Furthermore, a sizeable number of conversations I had with full-stack developers went like this
- So you do everything?
- Yeah pretty much.
- Great, how do you deploy your app across all those clusters all by yourself?
- Oh it's sysadmin work, I am more a developer.
- Oh yeah. Never mind. So do you enjoy the freedom cloud computing is offering?
- Sure I do. I have heard lot of good words about it. At the moment, I am focusing on the client side of system and leaving the dirty work to BaaS.
- Like Parse?
- Yeah like Parse.
- How do you get JavaScript to hook up to Parse?
- Oh web is so yesterday. The world is all about apps now. There is where my heart is.
- So you are a mobile developer?
- Yeah. A full-stack mobile developer it is.
- Oh! So... beer?
- Yes, beer please.
To capture the truest meaning of what I want to be in my life, I couldn't find a better word than the old-school, plain, simple Software Engineer. It blurs the artificial lines drawn upon professions and opens a vast, new canvas of creative thoughts. That is the ultimate joy of my inner boy.



Ngày còn đi hướng nghiệp ở trường, là nơi người ta bảo bạn nghề này nghề kia, tôi say mê với những khác biệt, bự banh chành cũng như bé tí hi của Khoa Học Máy Tính (phần mềm) và Kỹ Thuật Máy Tính (phần cứng). Tôi quên luôn cả khép quai hàm khi thầy giáo kể về một tràng các con đường khác nhau mà lúc nào đó tôi sẽ chọn. Sau học thêm nhiều khóa, tôi càng hiểu rõ rằng một dự án phần mềm là đóng góp của rất nhiều mảng: viết code, phân tích hệ thống, kiểm thử, etc. Tôi vừa háo hứng, vừa choáng ngợp với lượng kiến thức cần có để theo đuổi một dự án.

Về sau đi làm, sự mới mẻ của các chuyên ngành dần nhạt đi. Nhiều người yêu quá cái khác biệt, độc lạ của ngành hẹp mình theo, mà lơ là kết quả quan trọng duy nhất của một dự án: sản phẩm. Dần dà, tôi từ hứng thú đến xa lánh những cái tên programming rockstar, hay javascript ninja. Tôi không hiểu được đủ kiểu phân biệt Coder, Programmer, Developer và vài cái tên khác tôi tìm thấy trên Internet. Như thể một kiểu phân chia đẳng cấp ở xứ Ấn Độ thờ bò.

Cho cùng, những chức danh trong công việc là để người này biết người kia chuyên về mảng gì, trách nhiệm ra sao. Để nhắc bạn lập trình đừng cố dựng server production bậy bựa như trên máy cá nhân, và cứ để sysadmin cài đặt hệ thống cho ra ngô khoai.

Nhưng mà, vậy thì chẳng lẽ nếu tôi là lập trình database, mà giao diện dự án nát bét, thì đó hông liên quan gì đến tôi? Lỡ mà project trễ, ai cũng cong đít lên làm, nhưng góc của tôi thì vừa đẹp vừa chạy nhanh, thì "chúc vui"?

Làm phần mềm, với tôi là một hành động cực kỳ cá nhân, và có lẽ là việc duy nhất tôi đủ giỏi để nuôi mình. Chỉ quăng cho tôi một ý tưởng khó là đủ để tôi đè nó, văn vẹo nó, rồi ôm nó ngủ trọn một ngày. Và lỡ mà có ai đứng ngáng giữa tôi và cái ý tưởng khó gặm đó, thì nói thiệt là tôi không có ý làm lơ bạn, nhưng đầu tôi đơn nhiệm, không để ý được mấy thứ khác.

Trong nghề này, ít nhất một lần bạn đã nghe ai đó kể về một đứa ba đầu sáu tay một mình ôm nguyên dự án rồi, không có gì lạ. Cái "chức" ba đầu sáu tay này thường dính với hoặc một đứa ngựa non háu đá hoặc một tiền bối. Hành động có thể giống nhau, nhưng hai dạng này, đụng vô thấy khác liền. Ngựa choai choai thường là đứa học giỏi nhất trường, nhất lớp, từ từ biến thành đứa vị kỷ, nhìn đâu cũng thấy người ta ngu hơn mình, nên thà tự làm còn nhanh hơn đi nhờ cho rác việc. Khẩu hiệu của bầy ngựa này rất triết đểu,"không tin ai thì không ai hại mình được". Tiền bối thường do sống lâu lên lão làng, dành một phần đời mình chui rèn trên bàn phím, luyện được mắt nhìn phân biệt vàng mười, vàng thau, trọng người cùng chí hướng. Con ngựa nào cũng muốn mình là nhanh nhất, thành công là một cuộc đua. Tiền bối hiểu rằng có đủ đường cho tất cả mọi người, thành công là tự ở tâm.

Tôi có niềm tin rằng trong mọi nghề nghiệp, được độc lập là mức độ hiểu biết cao nhất. Độc lập trong tầm nhìn, kiến thức, và đường đi. Thằng học nghề dành nhiều năm làm những việc tủn mủn không tên, nhưng đó không phải đích đến của việc học nghề, mà là con đường. Lao động cực nhọc là nền tảng chuẩn bị thằng học việc trở thành anh thợ chính. Khi tôi tự do làm việc mình muốn, đầu óc tôi được giải phóng khỏi những suy nghĩ đám đông, những hội đồng ban bệ, tôi được sống trong cái tôi của mình. Tất cả những người làm việc sáng tạo điều được quyền sống với cái tôi sáng tạo của mình.

Mấy năm nay, cộng đồng đang nhận ra xu hướng này và chào đón thêm nhiều các full-stack developers. Vấn đề với full-stack developer là cái chữ full trọn vẹn tròn đầy quá. Cảm giác nếu mà một ngày tôi không còn gì để học thêm nữa, làm tôi lo hơn mừng, tôi biết làm gì với thời gian đây? Thêm nữa, nhiều lần tôi làm quen các bạn full-stack developer thì chuyện đi thế này
- Vậy cái gì bồ cũng làm hả?
- Ừ, full-stack.
- Ngon. Vậy mình bồ tự đưa code lên máy chủ của Amazon luôn?
- Không, việc đó là của sysadmin, tôi chỉ tập trung vào phần nào liên quan đến lập trình thôi.
- À, vậy hả, nhưng mà chắc cũng có dùng cloud đúng không?
- Ừ rõ rồi. Nghe bảo có nhiều tính năng hay lắm. Mà mấy nay đang coi phần giao diện, mấy việc phía sau giao cho BaaS hết.
- Kiểu như Parse?
- Ừ, như Parse.
- Ủa mà JavaScript giờ chọt vô Parse được rồi hả?
- Ôi web xưa rồi, giờ cái thì cũng có apps, đó mới là tương lai!
- Vậy bồ làm mobile hả?
- Ừ, full-stack mobile
- À à, thôi "dzô" đi, nói quài!!!
- DZÔ!!!
Để gói gọn hết mong ước được làm phần mềm đến già, tôi thấy không chữ nào lược giản, rõ nghĩa như Software Engineer. Chức danh đơn giản vậy, làm nhòa đi ranh giới tưởng tượng của từng vị trí, mở rộng thế giới của mình. Tôi lại được thấy phần mềm như khi tôi còn tập viết Visual Basic trên máy của ba.

Sunday, October 18, 2015

Tối Sài Gòn trời nực

Tuần này, ở lại công ty gần như cả 5 ngày. Đến ngày cuối (hôm nay), Phương phải cho mượn cái áo thun cứu nạn.

Không ai sắp đặt, nhưng cái kiểu sống bạt mạng quăng quật, sống như ngày mai không có, chỉ còn hôm nay, vùi đầu vào những deadlines tưởng tượng, sao giống những ngày đầu 2011 đến kỳ. Sao nhớ quá.

Nhớ hồi văn phòng là căn chung cư bên Him Lam, phòng chưa kéo cáp, công việc chạy qua chạy vào đều qua cái USB 3G nóng chiên trứng được. Mà máy Phú chạy Linux không chơi với Mac, phải cắm dây LAN vào máy Bách, dây nhợ loằng ngoằng. Thời đêm nằm lại trên bean bag, sáng dậy bả người như ngủ trên xe đò, ngó qua bên Sơn ở trần, bên kia Tuấn Anh cuộn người như con mèo lười, chép miệng bảo lầy. Và không quên được những ngày đôi mắt mù loà với những ảo tưởng bản thân vô nghĩa, đưa chân đạp lên tình bạn, sống như đứa khốn nạn.

Rồi vì nhớ quài về quá khứ, thót nhận ra là từ ngày mình vào Đại Học đến giờ là 7 năm rồi.

Hồi đó, trong mùa hè cuối cùng, những thằng con trai lún phún râu, sần sùi trứng cá, ngập đầy những câu chuyện thì tương lai, nói như mình biết cả thế giới. Chẳng thằng nào biết mình đang nói cái gì cả.

Hồi đó, tương lai như là một con đường tuyến tính, có người đi nhanh, người đi chậm, nhưng cứ nghĩ ai cũng học, cũng đi làm, rồi cuộc sống tua nhanh đến đoạn nghỉ hưu bế cháu như ông bà nội ngoại ở nhà.

Lớn rồi mới biết, không chỉ tương lai, mà cả hiện tại nữa, là những đống bầy nhầy đủ mọi con đường, lẫn lộn cảm xúc, chẳng thấy lối đi. Đứa nào sống qua được những năm hai mươi mà không nghĩ đến việc tự sát một lần, là ông bà phù hộ dữ lắm. Những đứa không may còn lại, hoặc ông bà không thương, hoặc hông có linh, thì phải sinh tồn, riết hồi đâu là mình, đâu là tiêu chuẩn người đời chẳng còn biết nữa.

Chỉ còn nhớ hồi 18 tuổi, cái suy nghĩ mình là một và duy nhất sống động và mãnh liệt. Không cần đến những lớp nâng bi motivational, tin vào sự độc nhất của mình như lẽ tự nhiên. Những tối dở hơi như hôm nay, nhận ra mình cũng như bao người khác trong cái binh đoàn những người trẻ, ra rả những tình yêu công việc như tiếng gọi cuộc đời, xê dịch như lẽ sống, và bọn nhà báo chỉ rặt tuyên truyền (nhưng một thằng không ai biết là ai, giọng văn rặn cho ra được giọng miền Tây, mang cái tên không chút tiếng Việt, thì tin được, đừng lo). Im lặng thầm ghen tỵ với cuộc đời người khác, nhưng đứa nào mở miệng ghét bỏ công việc, cả năm không có nhu cầu đi đâu cả (ngoài đi ăn, đi ngủ, với đi cầu) thì đứa đó kỳ dị, là đứa phải hủi. Và dù nhà đài ra rả bệnh phong tuy lây nhưng rất khó lây, tụi nó vẫn bị đẩy ra cho ở riêng một cái chòi, cho lành.

Giờ lớn, biết mình chỉ là một phần trong xã hội chằn chịt, chỉ mong làm cái phần của mình được đàng hoàng, về sau ngó lại không phải hạ đầu. Vậy mà để cái job title là "Software Engineer" cũng bị đè ra hỏi, vậy chính xác em làm gì. Còn mấy cái title mông lung bỏ mẹ, như "Chief Representative", "General Manager", "CEO", thì không ai hỏi han gì?! Con người ghét bị quy chụp, bị coi là một món đồ vật với tính chất và khả năng bất biến, nhưng hằng ngày, lại đi chụp mũ khối người khác. Má, sống gì mà khôn. Những câu hỏi "mà CEO là làm gì vậy anh?", nghe thật thà, hiền lành. Thèm được vậy.

Tuesday, September 29, 2015

7 things I am hating in Software Industry

1. I hate it when people ask me to fix their computers.

I believe it is universal for everyone in Software Industry that at some point in their life they have to do a dreaded "favor" for someone they know. The "favor" usually involves, but not necessarily limited to, hours of looking into their systems to see some missing drivers, or worse dlls; a browser window with more toolbars than any scout; or 3 "free" anti-virus programs for triple security. The "favor" is boring, irritating, and a time killer.

Just because I make softwares doesn't mean I am good with software other people made. Software engineering is not the same as IT.  Asking a software engineer to fix your computer is no different from asking a mathematician to explain different types of loan interest.  We may be able to do it, but it's nothing we relish doing.

And, I don't see this getting as much acknowledgement as it should, we don't just know every twists and turns of a computer, instantly know what's wrong from an error message pasted to whatsapp, or can effectively "hack" any system with black screen and green text. Trouble shooting a computer is a long process of trial and failure and we are equipped with just the same tool that you are: search engines. Simply call us before any attempt to understand the situation is kinda disrespect to our time. We also only have as much time a day as you do. At least use google first.

(Though I might agree to fix your Linux. I see that as a learning opportunity)

2. I hate it when software engineer is discarded from business development.

I don't like dictators, and I don't like to be dictated (including times at elementary, grammar and vocabulary are sons of a bitch). Imagine you are in a foreign country, a tour guide, and a bucket list. You can either 
  • Tell your guide you want to go to Hội An. Once you get there, you said the next destination would be Hạ Long Bay up North, and then Mekong Delta down South, by motorbike. Even if that mean dragging yourself across Vietnam, twice. And you has never ridden a motorbike before.
  • Or you tell your guide your bucket list, that you have 3 weeks in Vietnam and a budget of 2 months of salary. And let your tour guide figure out the route that sketches across North and South, in one go.
"But there is a lot of risk with that, we might get ripped off!?". Yes, the same risk when you dictate the trip from point to point. If the guide is set out to rip you off, nothing gonna save you, not the local police, not your stating explicitly you want the motorbike to be the cheapest Honda Wave. (And really, don't go with cheapest Honda Wave).

Now think about the engineers of your young startup. At least one of the engineers, if not all of them, has access to AWS account, GitHub repositories, and remote servers. If we are really to screw you up, god blesses you. But we don't. We choose to be engineers because we enjoy building good softwares, one that generates values to its users.

3. I hate it when someone took a Coursera class and is now an expert in software development.

"It is just a simple if/else statement! Right guys? Right?". 
  • Yes. And if it is that simple, we would have figured it out too. Thanks for pointing out 1+1 = 2.
  • No. And then prepare to listen to the same version of the last talk about code refactoring that you didn't understand (and still not), this time, with a little touch of anger management.
I know that this sounds like an asshole finding excuse for his drama (which I happen to be). But when you tell someone how to do their craft, what is the chance you come out winning?

4. I hate it when the only skill of the recruiter is typing keywords into search engines.

In case you haven't experienced, here is how professional recruiter/headhunter works. You would craft a detailed job description with all the key attributes you are expecting from this senior position. You would also meet the recruiter to explain what is your company culture and how it is critically important for cultural fit. The recruiter would then look in the database of top-notch professionals her company has built over years and fetch you with potential CVs. She would be a bit generous, because she doesn't charge on number of CVs. She takes only 2 months of salary of that professional upon recruitment. Once.

Except that all your talk on cultural fit doesn't mean shit, it was just lip service. And her database looks like a combination of LinkedIn and Facebook (read: she only knows about the candidate as much as anyone else with an Internet connection). And she thought PMP and certificates mean good project management. Or that NoSQL is a form of SQL. And by generous, I mean she wouldn't hesitate to flood you with a hundred of CVs (like Saigon river in raining season).

But it shouldn't matter, because she is doing all the hard work for free and I only pay when the recruitment happens right? No. Time is an asset too, the most important of them all. Unlike money, or property, or candy, no one get more or less time then others. Wasting people time, and bring them frustration during the process, is an act of criminal.

I once wished that there would be a recruiter who understands cultural fit, technical depth and a sensitivity of choosing who, when and how to poach. So that when I have a vacant to fill, and budget for that, I can actually get one. I figure that there are people actually doing that everyday. But they aren't professional recruiters. They are the founders, co-founders, and C-level executives. Hiring is hard. Don't expect it to come cheap.

5. I hate highly tenuous comparisons: (programmer) rockstar, (javascript) ninja, and growth hacker.

The terms sounds like they are designed to attract people with delusions of self-grandeur. This is an attempt to imply coolness and eliteness (frequently among those who are neither).

But I don't use drug and crash hotel every week. I don't practice ninjutsu as well. Engineers ourself don't tend to have issues with being engineers, with the way others view our profession and don't want to enjoy some glamorous fame from other fields, like entertainment.  Engineer as an career has its principles and a focus on the product it builds. Once that goal is abandoned for hip and cool, it becomes fashion. Do you want to rebuild your system next year because the trend changes?

There are better ways to describe an experienced engineer, ones that don't sound like a childish marketing ploy (and growth hacking is basically marketing, coincidence?)

6. I hate bosses who think of their employees like lego pieces.

True, it is terrifying to think that there are irreplaceable people in your team and the business that you have built over the years would fall apart soon after they have gone. It is easy to think of them as cogs in a grander machine, that you can purchase another standardised cog from the market would one breaks. It is really tempting to objectify people. Only if you can.

But engineers are far less standardized, reliable, and productive than a machine. We have feeling, opinion, and our goddamn personal preferences. And that's what makes us human and better than machine. I tear my hair out whenever a boss has a team of unix-based engineers and a windows-based one and he is like "you are all engineers, now kiss". While one group looks at the other like a band of idiots and the other view them as prehistoric monkeys with pitch black terminal. When the Windows system is out, the boss expects the other team to fix (and to windows guys that have to fix unix system, best of luck!). Interchangeable?

And I noticed this snowball effect where boss only employs people whom he can pull strings. This kills the employee's willingness to question the nature of work and proactiveness to contribute to the project. The boss feels desperate, that he is surrounded by idiots. To save the scene, he pulled more strings, harder. This in turn pushes the employees further into the stage of indifference. No way out of the spiral. It is an autobahn to hell. More on this on legitimacy in management.

7. And I hate other engineers who compromise much bullshit in their career.

We all know that engineer who wrote crappy code that hurts brain's cells and fails to do what it supposed to do, who agreed to OT every night since the very beginning of a year-long project (and spend much of the next morning fixing the bugs he produces the night before), and who hated their boss to the bone and yet accepted his bullshit everyday. And they gather and go on social media to chant about software engineers being 21st century slaves (No we aren't). 

Don't be like this
Because not only will America go into your country and kill all your people. They'll come back twenty years later and make a movie about how killing your people made their soldiers feel sad. Oh boo hoo hoo.

This is not a rage quit. I love and respect my work, and I wish to continue working into my 70s. So it is important to point out things that ain't quite right in the industry and work on it, to reduce burnt out and foster a sustainable environment.

Monday, August 31, 2015

Mấy câu hỏi cần coi lại

Vài ngày trước, Vietnamworks đăng bài viết này trên trang blog của công ty. Tôi có ngó qua và nghĩ rằng "lẽ ra có thể làm tốt hơn như vậy". Vài câu hỏi trong bài viết thật ra không hỏi thì tốt hơn. Tôi không muốn tìm những lỗi lặt vặt chỉ để đả kích những người đang muốn giúp cải thiện kinh nghiệm phỏng vấn của các bạn trẻ (cảm ơn Thành Nhân cho câu dịch này). Vậy nên trong bài viết này, chỉ đơn giản phân tích nguy cơ đi kèm với những câu hỏi này, và đưa ra vài lựa chọn khác mà cá nhân tôi cho là tốt hơn.

src: Pinterest

(0) Các câu hỏi được gợi ý cho cuối buổi phỏng vấn. 

Tôi không hiểu lắm về qui ước này, nhưng các cuộc phỏng vấn thường diễn ra một chiều, người phỏng vấn hỏi (hy vọng từ một bảng câu hỏi chứ không lướt dọc CV, bạ đâu hỏi đó) và ứng viên trả lời. Cái này không có công bằng. Buổi phỏng vấn, ngoài để chứng minh năng lực của ứng viên, còn là bài kiểm tra rằng công ty là một nơi xứng đáng để làm việc, để cam kết trong tương lai (và xét theo góc độ đó, trong buổi phỏng vấn, công ty nhận được 100% chú ý của ứng viên để "chào bán" công việc đang đăng tuyển, hiệu quả hơn đủ loại quảng cáo khác, nhưng đó là một chủ đề khác)

Vậy nên một buổi phỏng vấn hiệu quả nên là một chuỗi tương tác hai chiều, trong đó vai trò người hỏi và trả lời luôn thay đổi. Dù trên lý thuyết, tôi có thể ráng mà nhớ hết tất thảy câu hỏi chờ đến cuối buổi phỏng vấn, tôi không nghĩ việc này hiệu quả.
  • Ngữ cảnh rất quan trọng trong một câu hỏi tốt. Hỏi một câu hỏi ngoài ngữ cảnh có thể là một hành động cực kỳ thiếu muối. 
  • Nhiều khả năng tôi quên, đến cuối phỏng vấn không còn nhớ câu nào, vì tôi biết tôi là con người không có trí nhớ. 
  • Cuối cùng tôi không muốn tham gia một công ty mà từ giây phút làm quen đầu tiên, tôi đã phải đóng vai bị động.

Chuyện này từng xảy ra khi tôi phỏng vấn ở công ty internet hàng đầu Việt Nam. Tôi bị hỏi implement 1 cái stack (nghĩ nó như cái ống bịt một đầu, data vào trước, thì ra sau). Nhưng mà tại tôi nhoi, tôi hỏi ngược lại là thế kỷ này rồi đâu còn ai tự viết mấy kiểu dữ liệu cơ bản này nữa. Lúc đó mới phát hiện là, tại công ty này, mọi người có xu hướng tự cung tự cấp, không dùng nguồn bên ngoài. Điều này đi ngược với thói quen dùng code open source, không viết lại những cái có sẵn của tôi. Và tôi mừng là đã không nhắm mắt viết theo yêu cầu của người phỏng vấn. Có thể rút cuộc phỏng vấn xong tôi cũng biết được điều tương tự về văn hoá công ty, nhưng đó là sau khi viết đủ thể loại data structures hầm bà lằng.

(1) Bước tiếp theo của buổi phỏng vấn này là gì?
(2) Tôi rất mong muốn có được việc làm này và cơ hội làm việc với anh/chị. Tôi đã tìm hiểu kỹ về công ty, và qua những gì chúng ta trao đổi, tôi muốn biết khi nào anh/chị sẽ ra quyết định?

(1) (2) Hai câu hỏi này, thật ra là cùng một câu hỏi, nhưng là một câu hỏi tốt.

Không cho ứng viên biết bạn ấy đang ở đâu trong qui trình phỏng vấn của công ty, và không thông báo kết quả cho những ứng viên bị loại, là hai thói quen không chỉ là thiếu chuyên nghiệp, mà là không tôn trọng người khác của mấy bạn làm nhân sự ở Việt Nam. Có ai hồi nhỏ bị lạc trong siêu thị không thấy mẹ đâu, sợ muốn chết không? Tôi bị hoài, tại tôi nghễnh ngãng. Tôi không muốn người khác cũng cảm thấy như bị lạc đường lúc đi tìm việc, mà đặc biệt là công việc đầu tiên. Nên trong mọi interview script mà tôi chuẩn bị, phần cuối cùng luôn dành cho thông báo ứng viên đang ở đâu, chuyện gì xảy ra tiếp theo, còn bao nhiêu vòng phỏng vấn nữa. Và dù tôi phải viết thư từ chối hoài hoài, tôi vẫn làm.

(3) Anh/chị còn điều gì cần biết về tôi trước khi ra quyết định không?

(3) Là một câu hỏi kinh khủng.

Phỏng vấn, dù theo nghĩa truyền thống nhất, là môi trường để ứng viên rao bán kỹ năng và kinh nghiệm của mình. Nếu đến cuối buổi phỏng vấn, mà bạn vẫn chưa lái được câu chuyện đến những thông tin nổi bật nhất của bản thân (ví dụ: tổ chức Barcamp, cuối tuần viết code cho người ta xài free, etc) mà phải cạy vô câu hỏi của người khác, thì bạn tạch rồi.

Câu hỏi cuối cùng mục đích chính là để lại ấn tượng với nhà tuyển dụng, vì nếu hỏi để lấy thêm thông tin, thì nên hỏi từ trước rồi. Mà theo tôi, ấn tượng từ một câu hỏi móc họng như này không hay lắm. Có bao giờ bạn đi shopping, mà nhân viên hỏi "Giờ em phải nói cái gì để chị mua cái áo này?" không? Chắc cũng có, mà nhỏ nhân viên đó giờ bị đuổi rồi. Ai có đọc voz chắc biết câu hỏi huyền thoại em có thích ăn rau dền không?. Đây y xì là một câu hỏi ăn rau dền khác, version đi phỏng vấn!

Alternative: "Tôi có kinh nghiệm nhảy sào qua tường trường cấp 3. Công việc mới có môi trường để tôi phát huy lợi thế này không?" Tôi cho là câu này cho phép bạn khoe khéo chân bạn dài, và tìm hiểu xem công ty có đang kiếm người trang trí cây thông Noel không.

(4) Còn điều gì khiến anh/chị thấy tôi chưa thích hợp với công việc không? 
(5) Chuyên môn của tôi có thích hợp với vị trí mà anh/chị đang tìm kiếm không?

(4) (5) Là 2 câu khác nhau tí xí

So sánh 2 câu thì tôi không thích câu đầu tiên lắm. Hỏi người phỏng vấn về khuyết điểm dễ đưa họ vào bẫy tâm lý "hire for lack of weakness, not for strength". Gọi nôm na là tuyển tại vì ngoan, chứ không phải giỏi. Dù tôi có nhiều ưu điểm như ở dơ, da đen, đầu trọc, tôi cũng biết mình còn nhiều điểm thiếu sót (ví dụ: bị hoang tưởng), nên ai mà tuyển kiểu này thì tôi thất nghiệp.

Nhưng nói chung, khi tôi đi tìm việc, tôi sẽ không hỏi câu nào trong hai câu này cả, nếu được. Đầu óc con người có vài cái luật chơi của riêng nó. Một trong những luật căn bản nhất là luôn muốn có được tính nhất quán trong suy nghĩ. Nghĩa là một khi bạn đã xác định quan điểm của mình về một con người hay sự việc, rất khó để thay đổi quan điểm đó. Mấy cuộc chiến tranh tôn giáo, cả ngàn năm qua, đều từ do mấy cha bảo vệ quan điểm cực đoan mà ra.

Khi phỏng vấn, trừ khi bạn là strong hire, còn thì người phỏng vấn nào cũng qua một giai đoạn phân vân chưa biết xác định bạn là tốt, hay dốt. Cả hai câu hỏi của Vietnamworks đều có cùng mục đích là đẩy nhanh quá trình này. Mà chín ép thì không có thơm. Một khi họ trả lời câu hỏi của bạn, họ đã xác định quan điểm của mình. Và họ muốn suy nghĩ mình nhất quán, dù cho các người phỏng vấn khác không cùng ý kiến. Heck. Họ sẽ bảo vệ ý kiến của họ như điên luôn.

Alternative: "Vị trí này (trang trí cây thông Noel) giúp công ty đạt được mục tiêu như thế nào (tăng moral của các anh trai độc thân)?". Giải thích là câu hỏi này cho thấy ứng viên là người tham vọng, muốn có cái nhìn toàn cảnh về công ty và chiến lược hoạt động thì cũng được. Nhưng mà là nói xạo. Trả lương tôi cao là được rồi, rửa tiền cũng được. Tôi chỉ muốn vỗ vai người phỏng vấn mình, nhắc họ về đóng góp của họ với công ty (tuyển chân dài). Hy vọng để lại ấn tượng sau phỏng vấn.

(6) Ai là người đảm nhiệm vị trí này trước đây?

(6) Là câu hỏi hay.

Trước giờ tôi không nghĩ ra. Tôi không biết các công ty ngoài kia cởi mở như thế nào về những người cũ và chuyện thị phi?

(7) Anh/chị hãy chia sẻ cho tôi về văn hoá công ty?
(8) Công ty anh/chị cần ứng viên có những kỹ năng mềm nào?

(7) (8) Là hai câu hỏi lý thuyết. 

Mà trên lý thuyết, tôi hoàn hảo, và công ty tôi cũng vậy. Ở ngoài đời, tôi xa cái chuẩn ấy dữ lắm. Hỏi người quen tôi coi. Nhưng mà khi có người hỏi tôi câu hỏi giả như kiểu "Anh là con người như thế nào?" thì tôi vẽ tới mây luôn cũng được, bắt đầu từ việc tôi là một người đẹp trai. Tại vì tôi không mô tả chính tôi, tôi mô tả con người mà tôi muốn trở thành! Văn hoá công ty của tôi, vì vậy, đương nhiên là chất nhất quả đất. Và nhân viên của tôi có kỹ năng mềm của một hoa hậu. Vậy nên tôi tiệt không còn dùng câu hỏi lý thuyết nữa.

  • "Bây giờ là 6PM thứ 6, dự án 3 tháng nay còn mấy tiếng nữa thì xong, tôi có hẹn với bạn gái đi ăn tối. Công ty muốn tôi làm gì?". Không gì nói lên văn hoá công ty rõ ràng như một câu hỏi thực tế, giữa lợi ích công ty, tập thể, và cá nhân. Câu trả lời ưa thích của tôi là "Tối nay công ty bao pizza với beer. Tuần sau thứ 6 dev team dùng bữa ở Au Manoir De Khai." (Thứ 5 tuần sau báo Au Manoir hết bàn, mình ra hồ Con Rùa vậy, cũng gần)
  • Kỹ năng mềm hả? Trả lời tốt câu hỏi ở trên là kỹ năng mềm rồi đó!

Thursday, August 13, 2015

Do you take things personally?

"Don't take it personally" echoed in my mind during the hours of darkness. Dear friends and colleagues spoke to me in a whisper in the same way a doctor announces to his poor patient he has got cancer.


People don't get to be called green-eyed monster for being cheerful and generous. My younger self would get furious whenever things didn't play out the way he wanted. The source of mayhem were countless. My subordinates didn't take engineering excellency as serious as I did, they were wimp. My boss asked me to do recruitment on a shoestring budget, he was cheap. There were private group chats I wasn't invited in, people must be talking behind my back. I remember a vivid feeling of isolation. I simply wanted to do a good job and the world was simply against me.

For years, it bugged me how the fuck people do not take thing personally. I quitted a lot of times in my life. I quit doing everything that I don't like or not good at (I found this a feedback cycle). As a result, I developed a very fond attachment to the few things I still do, against all odds, like making products and building team around them. The thing I was building was almost always on my mind. It was the first thing I thought about when I woke up and the last thing before I fell asleep. I cared about that deeply.

And I was also terrified of disappointing people, especially
  • those who chose to believe in me and work with me
  • those who put their money in so that I can chase my dream (though they are mostly sharks)
  • and those who staked their reputation on a project to use the software of a shitty 20-something kid

Some refer to themselves as highly logical. I don't have it. A team is an organizational unit. Felix, Uma, Carlos, and Kevin would be otherwise a collection of random citizens, but years of collaboration place them somewhere between friends and family. Laying off is a cost cutting practice. Telling Felix who is one month into his house mortgage the pay check he received just now would be the last is almost a crime. Go tell me how it is logical and not personal.

I understood that without me, the world would continue without missing a beat. People would continue to work, to invest, and to buy, elsewhere. But that wasn't the case was it? Thing happened the way it did for I was there, in the center of every decisions I made. It was impossible not to admit the predicament that I was in was probably all my fault.


Much like the song "I hate myself for loving you", despite all the bad taste from taking every issue to myself and ending up feeling so sick everyday, I couldn't picture myself doing something from which I am emotionally detached. So instead of learning how to not taking thing personally (the process during which would kill the living hell outta me), I am learning to navigate the minefield and not to get burned (or blowed up, whatever).

I get to be more realistic. Managing expectation is just as important as getting shit done. I stopped sugar coating my perspective and started telling it like it is. It is tempting to fall in love with your idea. When traction starts to pick up, the stage is hyperbole and the momentum is great, what can possibly go wrong, really? You start to oversell dreams to your colleagues, friends, and even to yourself. When those dreams aren't fulfilled, you were pissed. Less because your brain child fell apart and more because your credibility crumbled. You take the loss much harder than what it should have been. And that was bad, the moment one focuses on the fame of a novelty goal and not the journey, one is set to stray off the path. Also being frank about hard problem allow more people to work on it, and helps building the team on a foundation of trust.

I learned the difference between personal and emotional, between transparent and moody, and between responsive and overreacting. I thought I was tough. But I wasn't. I was a wimpy kid. I am getting better.

I realize that I like my situation better than that of those who don't take things personally enough, or not at all. Of course I am sad when thing goes awry. I panic, I throw up, I cry. I hate every of that moment and there is no way I can jump in excitement yelling "That was fun! I want more!". But the only way I can feel bad is that I felt something really good before. If I have to take the bad with the good, I think it is a fair trade. I am glad that my career allows me to do what I love, and love what I do. I am afraid that if I keep falling, at some point I would be numb and work would be just muscle memory. Thanks god, that day has yet to come.

One more thing, I think human mind is subject to autosuggestion. If you start to run and you tell yourself there is no way you can finish the track, what is the odd you can actually finish the track? Everyday, thousands of things can go wrong, and certainly many of them do. I know it sounds like a reckless defence mechanism, the only way I know to keep going is to focus on what I am doing and not what I want to avoid. If you keep thinking about all the bad things that can happen, not only that you can't start anything new, but also the mind will start to play tricks on you, the obsession won't let you go, you will go nuts. Okay, so you take things personally. So what? Nobody cares. It has always been a game in your mind and will always be. So do whatever the fuck you have to anyway.


Wednesday, July 22, 2015

TechChat #2 @ Saigon Silicon Straits

Khang Nguyen là cựu sinh viên của Đại học quốc tế RMIT, từng là Founder và President của RMIT IT Club. Khi ra trường,...

Posted by Silicon Straits Saigon on Thursday, July 16, 2015

Friday, June 19, 2015

On Temptation

Src: Family Guy

Are you really sure you mean "temptation"?

How should you treat your temptation? Kill it with fire and bury its ash at the bottom of Challenger Deep, I propose. Words are powerful. When something is called a temptation, it is not just described, it is infused with emotions, the speaker's emotions. The only difference between a temptation and a calling is the emotions people have for them. In one case, the desire is regarded as unwise, wrong, or immoral, while the other is righteous. This perception frames temptation and limits the scope of discussion.

What is much more interesting is the thought process through which our limbic brain chooses to throw a desire into either temptation or calling basket, and our neocortex brain tries to figure out if it makes sense to pursue the desire, or not. The limbic brain, or the old brain, is at the core of human brain and is responsible for, among many things, emotion, motivation, learning and memory. The neocortex brain, or the new brain, is the outer layer of human brain and is what sets us apart from animal. Neocortex brain is responsible for all the reasoning we are capable of. When the limbic brain and neocortex brain disagree with each other, when reasoning doesn't match emotion, we don't feel "right" and that, possibly, is the most common feeling towards desire.

Limbic brain, as a part of the bigger autonomic nervous system, doesn't take command from its human. So all my attempts in the past to smash some senses into my feeling has been futile. These days, I am trying to make my neocortex listen to its pigheaded colleague more. And that consists of three principles.

Principles, because I am an engineer

We human want shit lot of things. I should know it, because everyday I talk to myself "I want to read that book", "I want to understand all the charts Google Analytics is showing me", "I want to learn a new (programming) language". And I actually ended up doing a lot of that.
  • I studied Spanish, though a rational decision would have been to finish my Mandarin
  • I tried to play guitar, only to find out that I have no sense of beat and rhythms
  • I built a company and watched it falling apart, crushing some of my best friendships in the process
I am sure you too can relate to an awful lot of things you did and wished you had not. If I get to make those decisions again, would I do differently? Errr ya, I didn't get burned for nothing. I learned a bit here and there and I am a bit wiser now. But that shouldn't be the question. Given that I cannot travel between multiverses, I will never be given the same situation twice. Projecting what would I do differently if the same event happens in the future gives a false sense of security and improvement.

The one question that more likely to haunt me is "5 years, 10 years from now, would I regret not doing that?". Notice that I try to imagine what I would think in a relatively long period from now. I have learned that right after the event, there is always a strong sense of regret, like a hangover Monday.

I regret a lot of decisions in my life. But a few good ones gave me unparalleled experience, If I didn't fall into those "temptation", none of that would have a chance to exist, I would have less scars on my soul, I might even be fatter because I wouldn't have to think that much. And my life would be anything but a shell of the current one.

And that is my first principle "How haunting it would be for not doing this?"

Steve Jobs had an excellent speech about connecting the dots. Somewhere along the lines, he stated that we can only connect the dots looking backward and that we have to believe the dots will somehow connect in your future and let our guts take the lead. I think the dots have the power to project future too, if you get out of the way.

Once in a while, I stop and look back at my life, I experience this vision where I observe my younger self from a third-person view (and feel extremely embarrassed, like the time I was 3 and told mom proudly about this girl I liked in kindergarten) (or just now when I realized it is kindergarten, not kindergarden :| ).  I also start to see patterns in my life, things that I want to do more, can do once in a while and would be happy to remove completely. Patterns have followed me for twenty-something years of my life are there for a reason, and probably will continue to do so for another 20 years. After which I will have my midlife crisis and go nuts.

Of course there are cases where people change so suddenly and profoundly that the event voids all prior history data. Growing up, every of us must have experienced this once or twice. But I guess when you remember the event, you also remember about the context, the way people treat you (both good and bad) and the intensive shift of emotions you went through. And that kinda remind you why you are who you are. Though I agree that those emotions are hard to express, because not all of us are Murakami.

Biologically, neocortex governs reasoning and short-term memory, but when it becomes experience and merges with emotions, it falls under the domain of limbic brain. That's why the way historians depict a period you were in doesn't feel right. At least my dad told me so.

And that is my second principle, you didn't pop out and be twenty-something out of no where, listen to your experience.

The final principle is about finding a balance. Because doing just whatever you feel like doesn't always make you a noble achiever, more like it makes you a criminal. I have this urge that whenever I cross the streets of Saigon, I want to kick a passing by biker and see what happens.

I think freedom is overrated, not because Vietnam is in communism. But because as an engineer, everywhere I see, I see constraints. And they seem to be there for good reasons. As a society, we need order so that we can live in harmony. Too much order and everything is boring. But we also need chaos, because come on, can you imagine a world where you have laws for about everything?

The key is to strike for the area in the middle, "the edge of chaos", or "the edge of order". I think they are the same thing, but I prefer the later, starting for order and moving toward chaos is easier to navigate for me. What it means to me is to keep the constraints to the minimum and let my heart tell me the rest.

But what are the constraints? That is a very good question. Unfortunately, like many other good questions, I don't have the answer for that. But I can try to explain. Let's look at my favorite extracurricular activity at school: skipping class and go to game center. For some of my friends, the constraint was not to skip any class at all. From a very few others, it was not to go to class at all. But I guess most of us would avoid these extremes and go for somewhere in the middle, like what I did. My constraint back then was not to let my parents know about my "extracurricular activities". As long as the constraint was preserved, I had complete freedom to go to either class or game center. I ended up graduating from high school just fine.

My plan didn't always work. Every once in a while, my teacher would call home to check my sickness and my father would be like "shit he did it again"  and make up some good excuses and go pick up the biggest stick he could find. It is indeed safer to stick to the safe zone, ie not skipping class, and nothing can go wrong there. If I played it safe, my life would be a bit less lively, the sky in my memory more grayish and grass more yellow, but I would pass by high school peacefully. And as an adult, I could keep the same strategy and I wouldn't be hurt. But the thing is, I don't want to just survive, I want to have my stories, I want to connect to the people in my life. And I can't manage to connect to them while keeping my defense stance, with a stick. There is a risk associated with that, and I was hurt, but as time goes by, I am getting better at choosing what damage I can take, what I can't.

I guess that what my counselor meant by "stepping out of your comfort zone" but back then I couldn't understand why doing things I wasn't comfortable with could make me feel better, it just made me sick. I still don't understand that now, I just made up my own theory.


I am sorry I took you on such a long detour, and in the end doesn't tackle much on temptation itself. That's because I don't want to look at the tip of the iceberg and overlook fundamental problems. Though splitted into 3 principles, I guess at the end of the day, what I wanted to say is that, in most of the cases, you have already got the answer, and all the consults you are seeking for, is to justify that spark of feeling. I think that we, in general, are spending more time to consume information, and less time for retrospection and generating original thoughts. Because it is much easier to look for a 3-min tip on resisting temptation on the Internet, than to take a good look into the mess that has built up in your mind over the years.

Think about it, I am wearing clothes someone else made, writing this post on a computer someone else made. The only thing I can make, are my thoughts. And if even those thoughts aren't original, then I don't know what I am doing with my life.

Src: Deep Dark Fears

Sunday, May 31, 2015

Stories of the underdogs

Disclaimer: What I am writing, I learned a lot from the books "David & Goliath" - Malcolm Gladwell and "I am Zlatan Ibrahimovic".


The fight of the century

Mayweather vs Pacquiao is the ultimate fight of 2015. The winner unified the belts. People expected a classic fight on a classic night, one of the greatest fights of all times. What happened in the ring shocked the whole world, in the way no one could have expected. The century fight was described as one way, boring, and too practical, and the one who was pushed hard during the rounds, Mayweather, ended up winning the fight. The tweet "Mayweather run like a chicken, hug like a bear" got 5k retweets and 8k favorites. And I don't know if that was the original tweet, or one of the first. You get the idea.

src bloodyelbow
There was a fundamental difference between the two players way before the match began. Pacquiao (Pacman) was looking for the next challenge in his life. He was a random kid in The Philippines working his way to the top through faith, hard work and failures. Pac wanted a war. Mayweather was looking for a sport event, media coverage and arguably a jackpot. He was trained for a game.

And the difference between a game and a war is that a game has its set of rules, spoken and unspoken, while a war, due to its vital nature, puts as little constraint on it as possible. If you were an gazelle running away from a cheetah, it would make little sense to choose the path with most obstacles (a hurdler) or limit the distance to 100 or 200m (Olympic standard sprint distances). Though in fact the big cat would very likely to gave up after a certain distance (100-150m) after which the reward isn't worth the effort and risks.

The first word most people associate with boxing is knockout. Rocky and Muhammad Ali are probably right up next. When a knockout happens, even a three-year-old can tell who won. The one standing. Around 64.2% of boxing matches end in knockouts. But that includes both amateur and professional. Among pro boxers at their prime, knockouts are very very rare, thank to their agility and resilience. Hence boxing matches are scored.

How a professional boxing match is scored is surprisingly absurd. The judges rely on their judgement and are technically never wrong, even when they clearly are. The logic is regarded as a matter of deep philosophical reasoning. However, anyone knows the rule of basketball would see that American like to quantify thing (which I assume the main reason behind big mac with diet coke). So in recent years, the judges are leaning to the one who lands the greater number of punches.

Mayweather vs Pacquiao scorecard, most important metrics top. 
Boxing, from "the art of hand combat" is turning itself into "the art of hitting and not being hit".

Mayweather got criticized the most for "hug like a bear, run like a chicken" but both are completely allowed in pro boxing though. Running (technically footwork) and hugging (clinching) are fundamental of virtually all martial arts and widely accepted in professional competition. Clinching is typically used when a fighter is hurt or extremely tired and wants to survive the round. It is no surprise many fighters include clinching in their strategy.

src: bbc
So why the world was left in awe? Pacman was shorter and had far worse reach than Mayweather (169 vs 173cm, and 170 vs 183cm). That was like playing basketball with a guy 13cm taller. Pacman had 5 losses (6 now) and 2 draws in his career. Mayweather won all the fights he has been in. And most obvious, Pacman only got 40/60 split of the purse. In short, Pacman was perceived as the underdog, and Mayweather an alpha. But it was Mayweather who used an underdog strategy in the game. Avoiding being hit and clinching to slow down opponent momentum are the strategies of those who run out of option and want to survive another round. That wasn't what an alpha dog supposed to do. And people sensed that it wasn't "fair", they found themselves speechless.

Rules of the underdogs

Rules in modern sport are the result of a mixture of both spoken and unspoken ones. It is in the mix of unspoken rules people define the so-called sportsmanship. Footballers usually kick the ball out of the field when someone is injured even before the referee stops the match, that is sportsmanship. A traditional game of frisbee is run entirely on sportsmanship (there is a set of rules, but there is no referee). And what Tyson did to Holifield was anti-sportsmanship. An underdog is expected to lose, he has everything against him. Throughout history whenever an underdog engaged in a toe-to-toe game with an alpha, he usually ended up losing. An underdog best hope is to look for an unconventional strategy, one that copes with the spoken rules and exploits the unspoken rules to make up for his disadvantages.

Jose Mourinho, Chelsea FC's manager, called himself The Special One. As a footballer, he was ordinary, lacked the requisite pace and power to become a professional. As a manager, he made his name as a trophy-winner. He has repeatedly successfully brought professional teams at different countries to top of their leagues and won most titles a manager could get in his career.

src: skysports
Mourinho's tactics are often criticized as ruthlessly practical. His players can be negatively defensive, throw out fouls to block opponent momentum, and notoriously "park the bus" in front of the goal post to secure wins. But that works. He led Portugal Porto to UEFA Cup 2003 and Champions League 2004. Then Brit Chelsea to Premier League 2005 and 2006. And Italian Inter Milan Champions League 2010.

But why aren't the rest of the world doing that, because screw beauty of the sport, it is titles and trophies that people remember? Because it is hard. The underdog strategy is not a silver bullet. It is not a simple one-line wisdom that let you win the game other have been playing for years. Most of the sports (and everything else that human do) are acts of skills and finely calibrated execution. What an underdog strategy does is to use effort over ability. And that is shit lot of effort.

Footwork and clinching aren't used as a primary defensive strategy of most fighters because it drains energy faster than any other strategy. It is more effective to turn to some other proactive defensive moves. And getting out of a clinch is a high risk move, your arms are entangled and that leaves you defenseless. That is hard work, and if the professionals just good enough, they won't be convinced to practice and play that hard. Underdogs have to be so desperate, so bad that they have no other choice for this to work out.

Before Mourinho came, the name of Porto never made it out of their country. Chelsea never escaped the shadow of its neighbor opponent, Arsenal. And Inter Milan had not seen the glory in Ronaldo era for long time. What Mourinho did was to put the clubs' superstars to the ground, constantly reminded them that despite of their paycheck, the only first-class citizens among footballers is the trophy winner and they were not. He spent 20m to celebrate Chelsea championship and then whole team back to the drill. And his favorite drill was to replay the video when his players were bad and said "So miserable! Hopeless! Those guys can't be you. They must be your brothers, your inferior selves", and they would nodded. They, the multimillionaire celeb playboys, were ashamed. And they would go to war for Mourinho. (That wasn't from me, that was from the very Zlatan Ibrahimovic).

There was one time, Mourinho strategy didn't work out. That was his 03 years at Real Madrid. Because Mourinho style wasn't on the same league with Real Madrid. The club was building it Galaxy 2.0 with all the biggest names money could buy. 03 out of 05 most expensive transfers were made by this club. C. Ronaldo was there. G. Bale was there. Heck, 03 forwards of Real Madrid could buy another team in La Liga. They just couldn't be put into the mindset of the underdogs. They had never been in their lives and they had no intention to be, even if that was the Special One. Out of 22 possible trophies, Mourinho won 3, not bad, but that wasn't Real Madrid expectation. They wanted domination. For they were the alpha.

Next time, when you are confronting giants, remember the advantages of disadvantages (and the disadvantages of advantages).

Thursday, May 14, 2015

Promo video for RMIT

A week ago, RMIT published this promo video featuring me. The video was shot all the way back to 2013 and I almost forgot about it. It is mid 2015 now and many things have changed. Like I am no longer working at Cogini and I went through 2014 with a lot of significant changes in life.

Anyway, for the sake of recording everything about me on the internet, here is the video. Don't ask me why I was shaking the chair like an idiot or why my hands were as rigid as branches of wood. I don't know.