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.
==========================
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.