Why I blog

A couple weeks ago, I was honorably mentioned in ITViec's blog post 9 Vietnamese tech bloggers you should know. The post later made its way to Tech In Asia a few days later. It is a huge success, a splendid kudo, not only to me, but to the local tech bloggers community who has always been an underdog in Vietnam's rising tech startup scene. And I thought to myself, this is great, I want to help ITViec spreading the message. I decided to "renovate" the original post on my blog. Though who am I to tell you that you should blog, I just gonna tell you why I blog!

It's cool

Dead simple. In the same way owning a super car is cool, or learning a new language is cool, I grew up believing that owning an active blog is cool. When I was a kid, the blog culture, Yahoo360 in particular, was on its hype. Everyone seemed to talk about it. But I was a random country boy, I didn't feel like I had anything to put there (more on this later). That was how I created 2-3 blogs and just helplessly watched them die.

A few years later, when I was in college, the blogging culture struck me again, this time, to the bone. Every cool people I came to know, be it tech celebrities, professors, or classmates, had a freaking blog. At this point, the way I saw it, a personal blog to awesomeness was the same as Rolls-Royce to prosperity. I didn't really mind whether it is a causal relationship or correlation, the idea simply stuck in my mind.

I was forced

Despite of all the good will about owning a blog, I didn't start my blog until the school made me to. You see, when I was on my last semester internship, it was mandatory to keep an active weekly journal report. The school used Blackboard and its UI was horrible. It was so bad that I didn't feel like writing at all. To be honest, writing on a text editor is really difficult to begin with, the cursor keeps blinking like it was forcing me or something. To cope with the requirement, I figured that I could just write a blog post and put the link to the journal entry on Blackboard. I passed, and my blog lived on.

What I learned from this is that I didn't have to start big. It was easier to start with something small and requires minimal effort, especially the by-product of something I have already been doing, like a report, a documentation for my pet project or a collection of Facebook statuses. Gradually, if one finds blogging interesting, s/he will naturally spend more time on it, get more viewers, and the momentum builds up, like a snow ball.

I desperately want to be better at communication

I spent most of my childhood learning the standard K-12 program of Vietnam. And one of the things this program wasn't good at is to teach children expressing their own feelings, emotions and ideas. The concept of writing down my idea was alienate to me till I was 16, when I knew about the TOEFL test. Before that point, all what I learned from literature classes was to copy and paste whatever the teachers lectured. The downside of starting actual writing relatively late was that my skills sucked. The words out of my mind didn't sound right, I didn't have the vocabulary to communicate idiomatically, and my attempts at coming up with metaphors were pretty lame. To make up for that, I have been trying to practice writing as often as I could, started with TOEFL writing test topics, then SAT. Picking up random topics for my blog is just a very natural thing to move on. And not until a year ago did I start writing in Vietnamese. I know it sounds weird as I am a native Vietnamese speaker, but it just happens that way.

What I learned from this is that everyday hard word beats talent. Though I am still no where close to the level of the ones I admire, I believe I am better than me 5 years ago. And that gives me the reason to keep writing.

Now without any further delay, let me introduce a few other Vietnamese tech bloggers that I think you should know

phunehehe.net
Don't let the funny name of the blog fool you. I have known Phu ever since we were fresh men at RMIT and if all those years taught me anything then it is that he is a genuinely talented DevOps and a reliable friend. Let him show you a thing or two on software development, system administration and open source.

buunguyen.net
Buu was a lecturer at RMIT and taught me 2 or 3 courses. He was horrifying brilliant. If there is any lecturer making me chill to the bone when reviewing my assignment, it is him. Buu also happens to be an RMIT alumnus, so he was one of the few people I looked up to define my career path back then.

blog.nerdyweekly.com
Understanding Nhan's interests in system administration and development, I couldn't help but think of Nhan as a clone of Phu. Just by reading his blog, one would find all the qualities people associate with youth: energized, dynamics and creative.

truongtx.me
Trường broke my prejudice that  Aptech and NIIT and the like are pretty much vocational schools, producing second-class developers. Look at the way he takes learning new technologies, investing time to be proficient with essential tools and sharing knowledge, I can tell he is going places.

hieple.net
Hiep is currently an organizer of Agile Vietnam. He has been taking bold steps in sharing knowledge and building a healthy community in Vietnam. And all these works are reflected on his blog. Heck, we need to clone more Hiep.

PS: In writing this, I ran across this list of tech bloggers in Vietnam, both native Vietnamese and expats, way back to 2008 (the year of the first Barcamp Saigon) http://fresco20.com/tech-bloggers-in-vietnam/. If you do the search, many blogs have stopped, and some are no longer in tech. This reflects that blogging is a life style and it changes on different period of life.

PS 2: This nice piece of writing top hacker news this week, it wasn't about why the author blog but more on the benefits of blogging/writing. I couldn't have done a better job myself, so here it is http://mlafeldt.github.io/blog/write-every-day/

==================================================

Vài tuần trước, tôi rất may mắn được điểm danh trong một bài blog của ITViec về những tech-bloggers Việt tiêu biểu. Bài viết này nhận được phản hồi rất tốt từ cộng đồng và được đăng lên Tech In Asia vài ngày sau đó. Tuy tầm ảnh hưởng còn rất hạn chế (Facebook like không nhiều bằng thiếu nữ lột đồ chơi ice bucket challenge) nhưng rất đáng khích lệ với cộng đồng tech bloggers, vốn luôn lép vế trong bức tranh công nghệ Việt Nam.  Để giúp thông điệp của ITViec tiếp tục được lan toả, tôi định bụng sẽ thêm mắm thêm muối vào bài viết gốc trên trang blog của mình. Nhưng tôi là ai mà bảo bạn phải viết chứ, tôi chỉ kể lại câu chuyện của mình thôi!

Viết blog ngầu

Thế thôi. Cũng như việc mua siêu xe ở cái nước siêu nghèo rất là ghê gớm, hay học thêm ngôn ngữ là thú vị, tôi lớn lên với suy nghĩ có một trang blog của riêng mình thiệt là ngầu. Đó là thời gian văn hoá tạo blog (không phải viết), đặc biệt là Yahoo360, nổi lên như một hiện tượng quốc dân. Nhưng mà hồi đó còn nhỏ, còn khờ, tôi chẳng biết có blog thì phải viết cái gì cho nó. Vậy nên 2-3 cái blog sinh ra rồi chết ngắt.

Vài năm sau, khi vào đại học, tình cũ không rủ cũng tới, văn hoá blog lại ve vãn tôi. Mọi con người hay ho mà tôi gặp, tech celebrities, giảng viên hay bạn học, đều có một trang blog ra ngô ra khoai. Tôi chết luôn cái ý tưởng có blog của riêng mình thật là ngầu, như cách Rolls-Royce cộp mác giàu sang thịnh vượng. (Tôi không biết những con người hay ho ấy họ đã thú vị sẵn rồi và blog chỉ là công cụ diễn đạt của họ, hay việc viết blog làm con người động não những vấn đề khó nhằn và do đó thú vị hơn, đừng hỏi tôi)

Tôi bị ép

Dù hơi bị hoang tưởng về việc có cái blog của mình, tôi lần nữa chần chừ đến khi dí dao vô cổ. Hồi đó học kỳ cuối cùng tôi đi thực tập, mỗi tuần bị bắt viết một bài báo cáo về những gì mình đã làm (hay phá). Trường xài Blackboard để quản lý hầu hết các học phần, và cái UI của thằng này xấu ghê gớm. Dùng nó chán đến mức tôi chẳng muốn viết. Nhưng chân thành mà nói, viết trực tiếp trên máy tính với tôi vốn đã rất khó rồi, con trỏ cứ nhấp nhánh như thúc giục. Để sống chung với lũ, tôi viết báo cáo lên một trang blog, rồi chép mỗi link vào Blackboard. Cuối cùng tôi được ra trường, và trang blog sống sót.

Tôi học được rằng viết blog cũng như nhiều việc khác, không cần một khởi đầu lớn lao. Khởi đầu với một thứ nhỏ xíu dễ hơi nhiều, đặc biệt nếu tận dụng được phụ phẩm của thứ tôi đằng nào cũng (phải) làm, như viết báo cáo, viết documentation cho dự án, hay một lô lốc Facebook statuses. Dần dà, nếu việc viết lách thú vị, tôi luôn có thể dành nhiều thời gian hơn, có thêm người đọc, và vì vậy lại dành nhiều thời gian hơn, vòng xoay cứ lăn như cầu tuyết (snow ball).

Tôi viết ngu thuộc loại siêu cấp vô địch

Hồi nhỏ tôi học chương trình hệ 12 năm như bao đứa con nít Việt Nam khác. Và tôi nghĩ trong đủ thứ chương trình này không làm được có mục khuyến khích lũ chíp hôi mặt mụn giải bày cảm xúc và ý tưởng của chúng. Mãi tận năm 16 tuổi tôi mới có khái niệm viết luận, còn trước đó hả, học văn cái giờ mỏi tay nhất trần đời, tại phải chép trên bảng quá trời đất, không chép là "lạc đề" liền. Tại vì ngu khờ kém hiểu biết về viết lách như vậy nên bài tôi viết không ai dám đọc. Từ ngữ tôi nghĩ ra lục cục như con ngựa Đà Lạt, tôi thiếu vốn từ thành ra diễn đạt dài dòng và phép ẩn dụ của tôi thì ẩn kỹ quá, không ai thấy luôn. Từ hồi đó tới giờ gần mười năm tôi vẫn phải học viết đều đều, từ đề TOEFL rồi đến đề SAT. Lựa một chủ để bất kỳ để viết là điều tiếp theo vô cùng tự nhiên. Cách đây một năm tôi mới tập viết bằng tiếng Việt. Nghe điều này từ một thằng da vàng mắt đen thì thật kỳ cục, nhưng mà thật chuyện tôi nó vậy.

Tôi học được rằng chăm chỉ mỗi ngày thì tốt hơn tài năng. Dù tôi còn xa lắm cái mức độ của những người tôi ngưỡng mộ, nhưng so với tôi 5 năm trước tôi nghĩ mình đã khá hơn nhiều. Đây là động lực để tôi tiếp tục viết: chiến thắng bản thân mỗi ngày.

Build your product - Làm product

“Build your product” is a popular catchphrase these days, used so much that it makes its way to a small set of national keywords. From a young startup wishing to disrupt a traditional industry to an hundreds-employee outsourcing firm, everyone is talking about building a product, the one of their own. Though no one charges tax on dream, what makes “build a product” such a keyword? Without below things, I would have never left my life of luxury to engage in a long, painful journey.

* Build your product is the condition to be your own boss. IT workers, either as a freelancer or in corporate environment often find themselves providing service, offering the best possible technical solutions but possessing little authority to make decision. Except those who have accepted their places in the corporate ladder, the rest suffer from more or less depression of being a second-class citizen.

* Build your product makes you “rich”. Financially, a common thing about doing outsourcing or being employed is that you are only paid an amount enough to survive till the next paycheck, so that you are kept in the infinity circle of work. Emotionally, the journey of building a product (and an organization around it) drags you out of the moderate baseline of an office staff, and throws you into a roller coaster of feelings, from cheerful success to bitter failure. A colorful journey indeed.

* Build your product puts you onto a catapult that shoots you up high into the sky so you can see beyond the well hole and make a big bold step out of your comfort zone. No longer limited to a creasy specs piled up in a cubicle corner, the job opens itself to endless possibilities. Whatever that can add add value to your product, from customer support, business development to watch out for competitors are all now parts of your job description. And oh boy no one gonna “spec” that.

* Build your product lets you climb your private mount Everest. Not everybody can reach the submit, many will fail and be forgotten. But unless for at least one time you seriously put on those hiking boots, many years from now you will find yourself ugly, old, looking at the past and find emptiness. Identify your own Everest is half the battle. Onward!

* Build your product is a chance to write your story, a story worth sharing. Many great ideas started with an unrealistic action. Believe that not all pages are born equal, some are more equal than others and decide to do something about it from a dorm room is an unrealistic action - Google. Publicize the source code of one of the most complex software application in history and expect free contribution from community is an unrealistic action - Linux. Exchange millions of messages that last a few minutes is an unrealistic action - SnapChat. These stories are attracting and inspiring because they go against common convention (at the moment they were created) and that gives everyone a hope. A hope to triumph over adversity. People don’t buy what you do, they buy why you do it, the story that isn’t about yourself, but about them and what they can be.

========

“Làm product” là catchphrase khá nổi hiện nay, xếp vào hàng từ vựng quốc dân, anh mà không biết thì dốt như con tốt. Từ hội “trẻ-khoẻ-rẻ” làm khởi nghiệp nuôi chí "build cái app" nức lòng quần chúng nhân dân, hay công ty gia công gần trăm người “outsource nuôi miệng thôi, ước mơ làm product chứ”. Dẫu “đời không như là mơ, nên đời thường giết chết mộng mơ”, điều gì làm hai chữ “làm product” có giá dữ vậy? Cực thí mồ, không có những điều sau thì tôi chẳng bỏ chăn ấm nệm êm mà đi làm product.

* Làm product là điều kiện để làm chủ. Người làm phần mềm dù freelance hay trong doanh nghiệp thường rơi vào cái thế của người làm service, mang đến các giải pháp khả thi nhất nhưng không nắm quyền quyết định cuối cùng. Trừ những người xác định rõ “người ra tiền là người có quyền”, còn lại đều ít nhiều ức chế với cuộc sống của công dân hạng hai.

* Làm product mới “giàu". Nói về kim tiền, làm gia công, làm thuê ở đâu cũng vậy, người ta chỉ trả cho mình một khoản tiền đủ giúp mình tồn tại, để tiếp tục nai lưng ra làm. Về đời sống tinh thần, làm product kéo ta ra khỏi đường trung bình ảm đạm của anh nhân viên văn phòng, quăng vào tàu lượn siêu tốc của những rạng ngời thành công và cay đắng thất bại. Là một chuyến đi nhiều màu sắc.

* Làm product để nhìn ra khỏi miệng giếng, bơi khỏi cái ao làng. Không còn là bản specs cong queo vứt ở góc bàn, công việc mở ra rộng khắp. Bất kỳ hoạt động nào gia tăng giá trị của sản phẩm, từ dịch vụ chăm sóc khách hàng, qua phát triển thương hiệu đến cạnh tranh với đối thủ, giờ đều là việc của bạn. Làm product như cái ná chun bắn bạn lên thật cao, nhìn khắp bốn phương tám hướng, nhìn lại chính mảng ghép của mình trong guồng máy kinh tế. Còn rơi xuống sao thì kệ thây.

* Làm product là vượt qua đỉnh Everest của mình. Rõ ràng không phải ai cũng thành công chinh phục đỉnh vinh quang, có thể bạn sẽ thất bại, sẽ bị lãng quên. Nhưng nếu bạn không ít nhất một lần nghiêm túc xỏ chân vào đôi giày đinh, có một ngày bạn sẽ già, sẽ xệ, nhìn lại và muộn màng hối tiếc. Xác định đỉnh Everest của mình là một nửa trận chiến rồi. Xông lên!

* Làm product để viết câu chuyện của chính mình, một câu chuyện truyền mãi. Nhiều ý tưởng vĩ đại thai nghén từ hành động hoang tưởng. Tin rằng không phải mọi trang web đều bình đẳng và cố gắng chứng minh từ phòng ký túc xá là hành động hoang tưởng - Google. Công khai mã nguồn một trong những chương trình phức tạp nhất trong lịch sử để đổi lại đóng góp từ cộng đồng là hành động hoang tưởng - Linux. Trao đổi hàng triệu tin nhắn chỉ tồn tại trong phút chốc là hành động hoang tưởng - SnapChat. Những câu chuyện này cuốn hút và truyền cảm hứng, vì chúng đi ngược lại suy nghĩ thông thường (tại thời điểm chúng ra đời) và mang cho ta hy vọng. Hy vọng chiến thắng nghịch cảnh của chính mình. Mọi người không chỉ mua sản phẩm bạn làm, họ mua câu chuyện bạn kể, câu chuyện không chỉ có bản thân bạn, mà có cả hình bóng của họ, những gì họ muốn trờ thành.

[RMIT Alumni Profile] - Nguyen Nam Khang, Bachelor of Information Technology

Know what you want and make it happen

Graduating from RMIT with a GPA of 4.0, organizing educational activities for the non-profit group MultiUni, and working as Vietnam's Chief Representative of Hong Kong software company Cogini, Nguyen Nam Khang knows how to get the best out of himself.

“Know what you want, but never lock yourself into just one thing. Instead, try to develop a variety of knowledge areas and skill sets,” Khang says.

Motivated to learn

Khang always wanted to become a computer programmer, so when the time came he chose the Information Technology program at RMIT Vietnam

“During my three years at the university, besides gaining and extending specialised knowledge, I took every chance to develop other important skills such as self-directed learning, time management, presentation skills and teamwork. These are significant skills for every job."

According to Khang, it was thanks to the student-centred teaching methodology at RMIT that he effectively managed many aspects of his study, including choosing class schedules, learning new methods and deciding his future direction.

“In an environment where students have the chance to interact, discuss and even debate directly with lecturers and classmates, where different learning objectives are respected equally, I felt motivated to dig deeply into IT knowledge from many sources and to apply the learning method that worked best for me.”

Inspired to spread his wings

Khang believes that participating in extracurricular activities is another effective way for students to try various roles. Leading RMITC, the University’s student-run information technology club, was Khang’s first management experience. The club gave him the opportunity to not only expand his IT knowledge but also develop organizational and project management skills.

Khang also participated in educational projects with MultiUni, a non-profit organisation that aims to help young people better transition into the real working world. Khang helped organise the workshops and shared his knowledge and experience of IT with the program’s participants.

“Pursue your passion with all your heart. As long as you try your best and do everything with the fullest enthusiasm, success will come to you sooner or later,” he says.

Realising his dreams

In 2010, one of the IT lecturers at the University introduced him to an internship opportunity at Cogini Hong Kong, an international software development and systems integration company serving clients from all over the world.

“Having studied in the international environment at RMIT, I was able to work well with other colleagues from different countries.”

In February 2011, Cogini established its first office in Vietnam and Khang was appointed as their Chief Representative. He is now in charge of running the office, developing relationships with customers and managing human resources. However, Khang still manages to find time for his true calling as a senior web developer.

Willing to step out of his comfort zone to experience different roles, Nguyen Nam Khang succeeded in pursuing his dream. He is typical of today’s successful youth: dynamic, eager to learn and always devoted to his passion.

[P/v ITViec] - Tính xấu nhất của developer là “Lười”

This dated back to December 2013 when I was working at Cogini, but recently I have some free time and figure that it is nice to keep a copy of this interview for myself. And sorry folks, the interview was in Vietnamese.

=============

Sinh năm 1990, đã đi làm được 3 năm với hiện là trưởng đại diện của Cogini tại Việt Nam với văn phòng khang trang ở quận 7 và hơn 20 nhân viên. Khang Nguyễn là 1 trường hợp dân IT làm ở vị trí quản lý nhanh và sớm so với tuổi. Hãy cùng ITviec khám phá xem anh chàng này có gì đặc biệt.

“Học xong 2 năm đầu ở RMIT, Khang được thực tập 6 tháng tại Cogini Đài Loan nhờ mối quan hệ của các thầy dạy trong trường. Sau 6 tháng, sếp hỏi có muốn về Việt Nam mở chi nhánh Research & Development của Cogini không. Khang về nước, gọi mấy thằng bạn học cùng ở RMIT vào thành lập công ty luôn.”

Làm thế nào để Khang thuyết phục được sếp cho phép mở chi nhánh R&D ở Việt Nam khi còn chưa tốt nghiệp đại học?

Lúc đó Khang cũng chơi liều thôi, dù giờ nghĩ lại thấy cũng có thể hiểu được. Khang đã có kiến thức khá vững về công nghệ, chứng minh được điều đó bằng kết quả làm việc của mình khi ở Đài Loan, và đã có kinh nghiệm thành lập và điều hành CLB IT của RMIT được 1 năm.

Làm rồi mới biết hóa ra điều hành công ty cũng không khác điều hành CLB IT là mấy, trừ chuyện bây giờ mình làm với khách hàng thật và mất tiền là tiền thật.

Vision của Khang cho Cogini là gì?

Là xây dựng Cogini thành 1 nơi làm việc vui vẻ (a fun place to work).

Có rất nhiều điều bạn có thể tập trung vào làm khi xây dựng 1 công ty: lương bổng, chương trình đào tạo, khách hàng… Khang chỉ có thể tập trung vào làm 1 điều và làm thật tốt điều đấy, và Khang chọn yếu tố fun cho Cogini. Mọi quyết định của công ty đều được dựa theo tiêu chí nó có tạo ra 1 nơi làm việc vui vẻ hay không.

Cogini = a fun place to work

Nhưng còn rất nhiều yếu tố khác, như ý nghĩa trong công việc, cảm giác quan trọng, doanh thu… Tại sao lại chỉ là vui vẻ?

Có thể Khang đã sai lắm chứ. Khang không biết hết được, nên Khang cứ làm thôi, rồi có gì sửa sau.

Cogini team building tại Cần Giờ

Ở công ty có nhiều người giỏi hơn Khang?

Hầu hết mọi người đều giỏi hơn Khang ở 1 điểm nào đó. Khang không thể tự mình làm hết mọi việc được, nên muốn mời những người giỏi hơn về để làm việc tốt hơn mình ở các mảng khác.

Vậy Khang có gì hơn họ để Khang tiếp tục ngồi ở vị trí leader của công ty?

Nếu có 1 điều Khang làm đặc biệt tốt, đó là giữ vững vision về môi trường làm việc vui vẻ của công ty trong mọi tình huống, mọi quyết định. Chắc là làm cũng được, nên đến giờ vẫn chưa thấy bị đuổi.

Ví dụ cho điều này?

Nói 1 cách hình tượng vui như thế này, mỗi khi nghĩ đến việc đưa offer cho ai, Khang đều tự hỏi mình: sau 3 tháng làm việc với người này, mình có dám nhìn thẳng vào mặt họ và nói “F you” không, và họ có phản ứng lại theo kiểu “F you, too” không. Trả lời có cho câu hỏi này là điều kiện cần.

Khang là người làm việc cá nhân hay đồng đội?

Khang thích câu “What you do doesn’t matter; whom you do it with matters.” Nói cách khác tính bầy đàn của Khang rất cao. Tất nhiên là đồng đội rồi.

Khang và team mình ở Cogini

Quan niệm của Khang về nghề lập trình viên?

LTV là nghề đưa ra giải pháp, chứ không phải là xây dựng sản phẩm.

Nói theo 1 cách khác là LTV học code không thôi không đủ. Họ phải ra ngoài kia, ngắm nhìn cuộc sống, nhìn ra những vấn đề hiện có và suy nghĩ về việc dùng công nghệ để xây dựng giải pháp cho những vấn đề đó.

Các trường ĐH và kể cả xã hội nói chung quá chú trọng vào việc giới thiệu những công nghệ mới nhất, hiện đại nhất. Điều này làm LTV nhiều khi quên mất rằng bản thân công nghệ chỉ có ý nghĩa khi nó được dùng để giải quyết 1 vấn đề nào đó.

Khanh áp dụng điều này vào công việc thực tế như thế nào?

Nguyên tắc của Khang là không bao giờ tin tưởng khách hàng của mình ngay trong lần gặp đầu tiên, và không bao giờ tự cho rằng khách hàng biết về sản phẩm của họ nhiều hơn mình. Khách hàng thuê mình để giúp họ giải quyết 1 vấn đề mà tư họ không giải quyết được, vậy có gì đảm bảo giải pháp họ vẽ ra cho mình xây là giải pháp tối ưu?

Ví dụ nếu 1 bà chủ quán cà phê đến nhờ Khang xây 1 billing system cho quán. Nếu muốn tìm ra giải pháp tối ưu, người Khang cần nói chuyện với lại không phải là bà ấy, mà là nhân viên quầy thu chẳng hạn.

(Đọc thêm về bài blog của Khang về chủ đề LTV và bài tập về nhà tại đây)

Tính xấu nhất của developer ở Việt nam?

Lười nâng cao giá trị bản thân. Ví dụ như 1 anh chàng sẵn sàng ngồi 5h liền chỉ để chơi Dota, trong khi anh ta có thể chơi 5 games khác nhau để tăng kỹ năng. LTV mà chỉ biết làm đi làm lại một thứ thì sẽ chỉ đứng mãi 1 chỗ, mà nguyên nhân chính chỉ tại chữ “lười.”

Làm thế nào để nâng cao giá trị bản thân?

Khang hay hỏi nhân viên của mình là: “Tao không hứa được là Cogini sẽ ăn đời ở kiếp với tụi bây. Nếu ngày mai Cogini phá sản, tụi bây có chắc chắn mình sẽ tìm được việc gì mới ở 1 công ty tốt hơn và trả lương tốt hơn không?” Nếu câu trả lời là không, tức là họ đang không tự nâng cao giá trị bản thân.

Nói 1 cách sách vở hơn, hãy tự hỏi mỗi ngày là hôm nay mình có làm điều gì có tính rủi ro hay không. Rủi ro chính là thước đo xem bạn có đang học được điều gì hay không.

ITviec muốn phỏng vấn Khang với tư cách là 1 kỹ sư IT trẻ thành công sớm, để truyền lửa và đam mê cho những bạn trẻ khác.

Ồ vậy thì Khang không chắc mình có phải là người ITviec đang tìm kiếm đâu nhé. Khang sợ 1 bạn trẻ lửa cháy hừng hực tìm đến Khang có thể dễ bị dập tắt lửa vì Khang không chém gió giỏi. Ngày xưa Khang nói dối 1 cây đấy, nhưng giờ Khang nhận ra nói dối hay chém gió lúc đầu cuối cùng sự thật vẫn là sự thật.

Khang sẽ không nói về với Khang để cùng xây dựng những sản phẩm có tầm quốc tế, rồi hôm sau giao cho bạn ấy 1 project về quán cà phê nhỏ trên đường Đồng Khởi. Khang có gì nói nấy, và nói “Tôi không biết” rất nhiều, vì thực sự có rất nhiều điều Khang không biết. IT cũng như những ngành khác, có lúc này lúc khác. Tốt nhất là nên nhìn thẳng vào thực tế và tìm ra giải pháp, chứ chém gió quá cũng chỉ đến thế mà thôi ha.

Cám ơn Khang đã có 1 bài phỏng vấn ít gió nhưng vẫn chất lượng.

Cám ơn ITviec.

http://blog.itviec.com/2013/12/cogini-khang-nguyen-phong-van/

Deploy (aka Đi Đẻ)

(Scroll down for Vietnamese)

The end of the day is approaching, dragging along a dimming sunlight. Breezes from the river bank bring respite to the scorching heat of summer. Despite of that, thousands of exhaust pipes, stuck up in every intersection, are releasing enormous smoke and heat, burning the street like a frying pan. Taking a breath full of the smell of sweat and exhaust gas, he is mumblingly cursing this full-of-construction god-damn city. Moving step-by-step in an endless traffic jam, he is breathing heavily, his heart is missing a beat here and there and his adrenal gland is filling him up with adrenaline. Everything reminds him of the uneasy feeling he had in the dates with his first lover after colleague. But no, he has no date tonight. There is no one in this god-damn city looking for him. Tonight he deploys!

3 hours prior to deploy.

The web site is given the last check. It is hard to keep looking at these web pages with a fresh eye. For many weeks, he has been staring at them as much as his own nose. And just as with the nose, his brain has already decide to remove the web site interface out of its vision. Regardless of Gestalt and his theory, at this moment, he is only capable of noticing tiny, little bugs. Margins left and right are not even. The mouse cursor isn’t changed when hovering over the logo. Some log lines are left in JavaScript.

     PM: Hey why is the new CSS not displaying?
     Designer: Have you cleaned your cache yet? And which browser is that, by the way?
     PM: IE6 ma’am. The client keeps mentioning there is a portion of his users who are still using it so I thought I should give it a try.
     Designer: Bloody hell! Remove that motherfucker browser from the contract next time, ya hear me?! 
     PM: Arggg just fix it. Next time when we do our own product, you can remove as many browsers as you want.
     Designer: Man, this HTML is ugly. This Friday meeting, I gotta repeat the convention of…

An hour prior to deploy.

His brain works best when it is cool down. And in this tropical summer, that is precisely sixty minutes right before the deploy time. The dull mind filled with sweat and exhaust gas earlier suddenly brightens. The spec, as long as the Ramayana, that he has miserably paged through the last few weeks, now becomes transparent and comprehensible. And huge bugs start to slap him right in the face. Handicap load balancing. Undocumented features. And greatest of them all, the specs itself has bugs!

     PM: Dude, why can’t I extract patient medical info from the system?
     Developer: Duh! The other day you said it was for the next release, didn’t you?
     PM: Right right, but without medical info, we can’t draw graphs in the report, which is for this release.
     Developer: That code was written centuries ago, all hard-coded man!
     PM: WTF. I told you to re-write that ancient code months ago!
     Developer: Whaaat?!

15 minutes prior to deploy.

The clock is ticking to a new day. In the small alley, his room is the only left light on. Like nocturnal animals, this is the time the deploy troop most active. In the darkness of the sleeping city, the troop holds a hope of changing its life with a magical deploy. By different means, all the people involving in the project are staring at the website. Client and designer, through browsers' interface, are looking at the glorious outfit of their brainchild. Developer and sysadmin keep looking at the dark terminal, skimming through thousands line of code. And he, running back and forth between the two. The server, resides in an unknown corner of the world, is taking its chance to act as quirky as it can, refusing to work until everything, yes every single thing, is perfect.

     Sysadmin: Holy shit! It is giving a database error! Dude check it out!
     Developer: Hey I can’t access to it! You haven’t created an ssh account for me yet!
     Sysadmin: There you go, hurry up!
     Developer: Oh here it is, the database is empty. Lets upload a dump from your local server.
     Sysadmin: Huh, wouldn’t it be quicker to just use yours?
     Developer: He he, I don’t remember that long command. Sorry... :D
     Sysadmin: WTF are all developers as lazy as you?
     Developer: Well, Bill Gates once said that….
     Sysadmin: Shut up!!!

Finally, after all the troubles, hardware, software, and peopleware, the deploy is completed. One more project is delivered on time. Everyone congratulates each other perfunctorily then quickly retreat to bed, hoping for a short nap before the working day tomorrow. The last light in the alley eventually goes out. The body that has been run on adrenaline since the afternoon refuses to sleep, yet has no energy left for any activity. His eyes half close from sleepiness, dreaming of the heart attacks when server crashes. Taking a deep breath, “the night is long” he talks to himself...

===================================

Tan tầm, trời tắt nắng. Cái nóng bức người mùa hè đã dịu bớt và gió từ bờ sông thổi vào man mát. Nhưng hàng ngàn cái ống bô dồn ứ mỗi ngã tư vẫn nhả khói, phả hơi nóng vào mặt đường như hoả lò. Hít một hơi đặc mùi mồ hôi và khói bụi, hắn lầm bầm chửi rủa cái thành phố chết tiệt đầy những lô cốt và chiến hào. Trong cái điệp khúc chạy-thắng, nhích từng bước một, hắn thở gấp gáp, tim đập loạn nhịp và tuyến thượng thận bơm đầy adrenaline vào máu. Hắn nhớ đến những lần hẹn với cô người yêu đầu sau đại học, hắn cũng nôn nao như vậy. Nhưng không, đêm nay hắn không gặp ai cả. Chẳng còn ai trong cái thành phố chết tiệt này trông mong hắn. Đêm nay hắn deploy!

3 tiếng trước deploy.

Trang web được rà soát lại. Thật khó để nhìn những trang web này với con mắt tươi mới. Từ nhiều tuần nay, hắn đã nhìn chúng nhiều như cái mũi của chính hắn. Và cũng như với cái mũi, bộ não đã quen với việc loại hẳn giao diện trang web ra khỏi tầm nhìn của nó. Mặc kệ thuyết Gestalt của lão Ehrenfels tuốt tận bên Áo Địa Lợi, giờ phút này hắn chỉ nhìn thấy những lỗi vụn vặt. Canh lề trái phải không đều. Logo di chuột lên con trỏ không thay đổi. Code JavaScript còn mấy dòng log.

     PM: Ê bà sao CSS mới không chạy vậy nè?
     Designer: Ông có xoá cache chưa đó? Mà xài browser nào vậy?
     PM: IE6 má ơi. Cái này lần nào họp với client cũng bị nhắc hết nên bữa nay tui test xem.
     Designer: Tiên sư! Lần sau gạch IE ra khỏi hợp đồng đi nghe chưa!
     PM: Mệt quá sửa lẹ đi. Ráng cái này, khi nào làm product của mình rồi bà muốn 1 gạch hay 2 gạch cũng được.
     Designer: Mà sao code HTML gớm quá vậy nè. Họp cuối tuần này phải nhắc lại vụ...

1 tiếng trước deploy.

Bộ não hắn hoạt động tốt nhất khi được làm mát. Mà trong mùa hè miền nhiệt đới này, đó là vào lúc còn vỏn vẹn 60 phút là deploy. Đầu óc ban chiều đặc lại trong mùi mồ hôi và khói bụi giờ minh mẩn hẳn. Bản spec dài như bộ Ramayana mà nhiều tuần qua hắn khổ sở lật qua lật lại, dò tới dò lui giờ rõ ràng, dễ hiểu. Và những lỗi to vật vã đập vào mặt. Không có cơ chế cân bằng tải khi nhiều người cùng truy cập. Tính năng không theo spec, thiếu trước hụt sau. Và vĩ đại nhất, ngay trong spec cũng có lỗi.

     PM: Ủa sao không trích thông tin từ hồ sơ thăm bệnh của bệnh nhân được vậy nè?
     Developer: Ơ chưa. Hôm trước ông chẳng bảo cái đấy đến kỳ sau mới làm là gì?
     PM: Ừ thì có, nhưng mà không lấy thông tin được thì sao mà vẽ đồ thị báo cáo?
     Developer: Cái code đấy viết từ đời thuở nào rồi, toàn hard-code nấy nệ thôi!
     PM: Đậu xanh!!! Cái code cũ đấy tao bảo viết lại từ đời tám hoánh rồi mà!
     Developer: Thế đ-o nào...

15 phút trước deploy.

Đồng hồ sắp chuyển sang ngày mới. Trong con hẻm nhỏ, chỉ còn phòng hắn sáng ánh đèn. Như con cú ăn đêm, giờ là lúc bọn deploy đêm như hắn hoạt động mạnh nhất. Cơ hồ đều mong trong bóng tối của thành phố say ngủ làm một cú đổi đời. Lúc này đây, những con người nhiều tuần qua cày cuốc với trang web nhìn vào nó chằm chằm, qua những phương thức khác nhau. Client và designer, qua browser, nhìn vào cái vẻ ngoài trau chuốt. Developer và sysadmin dán mắt vào màn hình terminal đen sì, những dòng lệnh chạy ngang dọc. Còn hắn, lăng xăng giữa hai bên. Cái máy chủ, quanh năm nằm trong xó một data center nào đó chẳng ai rõ, được dịp đỏng đảnh, từ chối hoạt động cho đến khi mọi thứ, xin nhắc lại là mọi thứ, thật hoàn hảo.

     Sysadmin: Chết cha! Sao báo lỗi database vậy nè? Ku, vô máy chủ xem coi sao!
     Developer: Không vô được ông ơi! Ông chưa tạo account cho tôi này!
     Sysadmin: Xong rồi đó, vô lẹ đi.
     Developer: À đây này, database trống không, chưa có dữ liệu gì cả. Chép dữ liệu từ máy ông lên đi.
     Sysadmin: Ủa, sao không chép từ máy mày luôn đi?
     Developer: Hè hè, tôi không có nhớ lệnh đấy, dài quá, ông thông cảm.
     Sysadmin: Trời đất, developer mà lười như quỉ vậy?
     Developer: Ông không nghe Bill Gates nói là…
     Sysadmin: Im ngay và luôn!!!

Lục đục mãi, deploy cũng xong. Dự án lần này coi như giao đúng hẹn. Hai bên chúc tụng nhau lấy lệ rồi rút lẹ đi ngủ, mong chợp mắt chút mai lại đi làm. Ánh đèn cuối cùng trong con hẻm rồi cũng tắt. Cái cơ thể suốt từ chập tối đã chạy bằng adrenaline giờ không chịu đi ngủ, nhưng cũng chẳng còn sức mà thức. Hắn lim dim, nửa tỉnh nửa mơ nhớ về những lần đau tim khi server sập. Hắn thở dài, tự nhủ đêm còn dài…

On being busy

I am busy, you are busy, everybody is busy. Being busy and working hard are conventional indicators of a workplace hero, a model managers want their subordinates to follow. In his book, Outliers, author Malcolm Gladwell stated that it takes roughly ten thousand hours of practice to achieve mastery in a field. By the point the book gained its fame, many arguments against the point, that ten thousand hours may not make a master after all, were made. While Gladwell made a solid point that everyday hard work beats natural talent, I believe that mastery is a complex entity that can’t be measured by a single-dimensional unit. And here is why.

If we understand being busy as doing more work, for longer hours, giving up evenings and weekends, then the busier an engineer is, the closer she is to master her craft? Interestingly, this instinctive appreciation of hard work turns out to be a problem when it comes to managing knowledge workers. 

Imaging there are two developer teams, same environment, same requirement.

Team Hercules appear to work really hard. There is constant activity in the team. They would often be seen working into the night and at weekends. Everyone would drop what they were doing to help production errors, often by offering their guesses on what could have gone wrong. Every deploy is a herculean joint effort of everyone. Their code base has long procedures here and there where all the stuff happens.

Team Apollo work no more than eight hours a day. They never work weekends and rarely spend hours around each other’s desk throwing out guesses about system errors. They deploy every day with an engineer or two. Their code base consists of small classes and methods with just a few lines of code. The work is a collection of design patterns, the SOLID principles and unit testing.

To a casual observer, the first team is working really hard and the second one isn’t. Hard work is good and laziness is bad, no? And if pay rises are given based on performance, which team is qualified? Team Hercules are putting together all what they have got for success, time and effort. But in the nutshell, they seem to be in a death match, burning their stamina to the last drop. The journey of mastering a craft is not one crazy intensive stressful period but years of practice. One needs to maintain a sustainable pace so that she wouldn’t be burned out by the time her effort bears fruit. 

Software development is new, unfamiliar to anything man kind have done in previous centuries. Conventional metrics that have been hard wired into our instinct won’t work in that new found land. Software developers should by judged by results, by working software, not by how hard they appear to be working. I would submit that the appearance of hard work is often an indication of failure. Being good at virtually anything is like figure-staking - the definition of being good at it is being able to make it look elegantly easy. But it never is easy, just that’s what people conveniently stupidly forget.

==========================

Tôi bận, anh bận, ai cũng bận. Bận rộn và làm việc chăm chỉ là hình ảnh tiêu biểu của một siêu nhân văn phòng, hình mẫu các sếp luôn muốn nhân viên mình noi theo. Trong cuốn Outliers, tác giả Malcolm Gladwell nhấn mạnh rằng cần xấp xỉ mười ngàn giờ luyện tập để thành thục một lĩnh vực bất kỳ. Khi cuốn sách tạo được tiếng vang trong đọc giả, đã có những quan điểm trái chiều xuất hiện, rằng mười ngàn giờ suy cho cùng không làm nên tài năng. Dù Gladwell hoàn toàn đúng khi chỉ ra rằng làm việc cần cù quan trọng hơn khả năng thiên bẩm, cá nhân tôi tin rằng một hoá trình luyện tập phức tạp thì khó đo đếm bằng một đại lượng đơn chiều. Tại sao?

Nếu hiểu bận rộn là làm nhiều việc hơn, nhiều giờ hơn, và, hy sinh ngày đêm và cuối tuần, vậy một kỹ sư càng bận rộn sẽ có tay nghề càng cao? Ngộ cái, tiềm thức đánh giá cao việc cày ải lại mang đến nhiều rắc rối khi quản lý giới trí thức. 

Tưởng tượng hai đội developer, cùng môi trường, cùng yêu cầu.

Đội Hercules rất chăm cày bừa. Trong đội, luôn có dòng chảy công việc cuồn cuộn. Họ thường làm việc ngày đêm và cả cuối tuần nữa. Mọi người luôn sẵn sàng bỏ ngang việc của mình để giúp sửa lỗi trong hệ thống, thường bằng cách đoán xem điều gì đang diễn ra trong những đoạn code hàng trăm dòng. Mỗi lần "đi đẻ” (deploy) là một đêm trắng của mọi người.

Đội Apollo làm ngày không quá tám tiếng y như tinh thần ngày 1/5. Hiếm khi bu lại "diệt sâu bọ” và chẳng khi nào làm việc vào cuối tuần. Ngày nào cũng có một hai người deploy code mới lên server. Nhìn code của Apollo, thấy toàn classes nhỏ, mỗi methods có vài dòng. Dự án có đủ design patterns, nguyên tắc SOLID và unit testing.

Từ bên ngoài, Hercules rất chăm chỉ, còn Apollo thì không. Chăm chỉ tốt, lười biếng xấu. đúng hông? Và nếu mức lương phản ánh năng lực làm việc, đội nào nên được thưởng cho nỗ lực của mình? Đội Hercules có lẽ đang dành tất cả tâm huyết của mình vào dự án, nhưng cách họ làm việc không phải là cách mà người ta nuôi dưỡng sức bền. Không ai liên tục làm việc như cảm tử quân được quá vài năm cả. Phần lớn mọi người cần nuôi dưỡng tinh anh của mình theo một tốc độ bền vững, để khi nỗ lực thành công, vẫn còn trẻ, khoẻ và đẹp lão.

Nghề lập trình là một nghề mới, khác lạ với cách lao động của con người trong nhiều thế kỷ trước đó. Những đại lượng truyền thống thâm canh cố đế trong tiềm thức con người phản tác dụng trên mảnh đất chưa khai phá này. Developers cần được đánh giá theo kết quả, theo sản phẩm, chứ không phải bằng việc cày ải. Tôi thực sự tin rằng, trong nghề này, cày cuốc là một dấu hiệu đáng ngại. Giỏi bất kỳ việc gì cũng giống như trượt băng nghệ thuật - càng giỏi càng trông thật dễ dàng. Nhưng thực chất chẳng bao giờ dễ dàng cả. Đây là điều những kẻ ngớ ngẩn toàn quên.

7 things I learned from software industry

1. An old fox ain't safe to trap. There are people with 10 years of experience in their CVs, but actually have a year of experience repeating 10 times. Each language, framework is meant to solve its own set of problems. A developer who fails to renew his knowledge everyday is like a carpenter without a toolbox, resorting to hammer a nail with a wrench. Usable, but simply not what someone in his right mind would do
2. Get out of your station once in a while. Meet more people, from all kind of careers and classes. Information Technology doesn't exist on its own but forms symbiosis relationships with other industries by providing additional values. In every career, people with rich experience outside of their professions are always appreciated. Especially in IT, the more a developer understands his users, the more down to earth his solutions are.
3. Quality is free, if you invest heavily for it. That being said, a good product isn't built by money. A good product is a result of multiple factors, such as capable developer, sufficient hardware power, suitable working environment, etc. and each of them needs (lot of) money. Interesting enough, investing in quality is a long-term cost reduction solution. Developers who compromise the quality of their work for the sake of cost reduction can look up to Japan, the country where the idea quality and cost reduction are two sides of a coin is well spread.
4. This is a hard job. Don't let luxurious office like that of Google or cool gadgets fool your mind. Developers are 21st century farmers. For one thing, I am pretty confident that developers kill just as many bug as farmers do. While farmers can sleep tight at 2AM, the risk for a developer to be waken up because of a crash server is very real. Even worse, everyday some where in the earth, a developer is tearing his hair off, for his hard written code is to be removed as the spec has changed. Big thank to clients who have "mastered" the art of Lean Startup.
5. "Good developer doesn't need test". Together with "I will get back to it tomorrow" are the two biggest lies in the whole IT industry. Unless you are the almighty Chuck Norris. Chuck Norris' code doesn't have bug. His code always works. ALWAYS. He kills bugs by staring at them.
6. Argument is good. I am not criticizing walking away from an intensive argument as a cowardly act. I believe in a healthy argumentative and non-consensus culture where the need to follow courtesy and command from upper level is not overrated. Argument needs to be based on the good will of understanding and sharing. An argument whose goal is to win the fight is intellectually bullshit and no better than a trivial slander.
7. The high-tech illusion. In their casual conversations, developers tend to drop phases such as "in computer science" or "the IT people", implying they are part of the high-tech world. Just among us, we usually aren't. The researchers who made fundamental breakthroughs are in the high-tech world. The rest of us are appliers of their work. And because we go about this work in teams and projects, we are more like in the human communication business. Our successes stem from good interactions between team members and our failures stem from poor ones. So the next time you are in a death match, it might not because your developers don't know how C pointer works, they might haven't read "How to win friends and influence people".

===================================================

1. Sống lâu không lên lão làng. Có những người CV 10 năm kinh nghiệm nhưng thật ra là 1 năm kinh nghiệm lặp lại 10 lần. Mỗi ngôn ngữ, framework được tạo ra để giải quyết một bài toán của riêng mình. Developer kiến thức hạn hẹp, không được làm mới mỗi ngày cũng giống như anh thợ mộc không đủ đồ nghề, dùng cờ lê để đóng đinh. Vẫn dùng được, nhưng méo mó vặn vẹo và dễ lên tăng-xông.
2. Đặt bàn phím xuống và đi. Gặp nhiều người hơn, những con người đủ loại ngành nghề và tầng lớp. Công nghệ thông tin không tồn tại riêng lẻ, mà tựa lưng vào những nhóm ngành khác, đóng góp giá trị gia tăng. Bất kỳ nghề nghiệp nào cũng hoan nghênh những con người có vốn sống đa dạng. Đặc biệt với CNTT, vốn sống là vựa ý tưởng, đưa sản phẩm đến gần hơn với người dùng.
3. Chất lượng không mất tiền mua; nhưng tiền không có, chẳng thấy chất đâu. Sự thật, sản phẩm tốt không mua được bằng tiền. Để có sản phẩm tốt, bạn cần có developers giỏi, server mạnh, môi trường làm việc phù hợp, etc, và mỗi thứ đó đều cần (rất nhiều) tiền. Thú vị hơn đầu tư vào chất lượng là giải pháp giảm chi phí lâu dài. Những developers thoả hiệp chất lượng để giảm chi phí nên học tập người Nhật, nơi quan điểm chất lượng và giảm chi phí song hành.
4. Đời rất dở nhưng vẫn phải niềm nở. Lập trình là một nghề vất vả. Đừng bị văn phòng lung linh như Google và đủ thứ đồ chơi làm mờ mắt, làm nghề này cực chả khác đi đồng. Ngoài chuyện bắt sâu bọ, developer còn có cơ bị lôi đầu dạy lúc 2 giờ sáng vì server sập. Hãi nhất là khách hàng "quán triệt” tư tưởng Lean Startup, specs đồi xoành xoạch. Lợi thì có lợi nhưng răng không còn. Nay làm mai sửa, mà vẫn phải cắm mặt làm, code vị nhân sinh anh ơi!
5. "Developer giỏi không cần test". Cùng với câu "Để đó mai sửa" là hai câu nói dối vĩ đại nhất trong lịch sử nghề lập trình. Trừ khi bạn là lão Chuck Norris xứ Mỹ. Code của lão khi nào cũng chạy và luôn luôn đúng. Giai thoại đồn rằng lão chỉ cần nhìn code chằm chằm là nó tự sửa.
6. Trang luận là tốt. Không phải tôi chê "một điều nhịn là chín điều lành", cũng không cổ suý "một điều nhịn là chín điều nhục". Tôi tin vào một văn hoá tranh luận và không nhất trí khoẻ mạnh, nơi sự lịch thiệp và mệnh lệnh ở trên truyền xuống không quá quan trọng. Tranh luận có văn hoá lấy chia sẻ và thấu hiểu làm nền tảng. Bước vào cuộc tranh cãi với mục đích duy nhất là dành phần đúng về mình thì đó là một cuộc mạt xát và thoá mạ.
7. Ảo tưởng vĩ đại. Trong các buổi chuyện trò, dân máy tính thường có những câu đệm "trong ngành khoa học máy tính" hay "giới công nghệ thông tin", hàm ý mình góp một phần trong bức tranh công nghệ cao. Thực chất ta không "công nghệ cao" như mơ. Ngoài một nhóm nhỏ các nhà nghiên cứu đầu ngành, đại đa số dân công nghệ dừng lại ở ứng dụng các nghiên cứu đó. Và việc này ta làm theo nhóm, theo dự án. Tất thảy chúng ta đều trong ngành nhân sự thì đúng hơn. Thành công trong công việc đến từ sự liên kết của các cá nhân trong tập thể, và thất bại từ sự lỏng lẻo trong chính các liên kết ấy. Vậy nên lần tới dự án sa lầy, có thể không phải vì các developers không biết con trỏ trong C, mà vì họ chưa đọc "Đắc nhân tâm".