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.