Nhái Cốm Blog

I love you just the way you are


1 Comment

Phát triển phần mềm theo định hướng YOLO và những phương pháp hài ước khác

Tác giả: Natali Vlatko
Bài gốc: YOLO Driven Development (and other hilarious IT methodologies)

Lược dịch

<< trong trường hợp bạn chưa biết, YOLO là viết tắt của cụm từ You Only Live Once – Bạn chỉ sống duy nhất một lần mà thôi >>

Bạn có biết sự tồn tại của một phương pháp có thể thay đổi hoàn toàn cách bạn lập trình: YDD – YOLO Driven Development. Bỏ qua những dòng mã rõ ràng, cặn kẽ sang một bên; hãy cởi mở với những phương pháp phát triển thay thế khác.

Bạn có thể tưởng tượng chúng tôi vui đến thế nào khi nhìn thấy những tuyên ngôn của một phương pháp mang tính đột phá trong hòm thư của mình không? Todor Grudev, nhà tiên tri của YDD, đã khắc lên đá (tại GidHub) 17 điều răn của phương pháp phát triển này.

Hãy khắc ghi, YOLO Driven Development!

# Không tái cấu trúc (refactor) lại mã lệnh, coi nó như một cách làm tồi. YOLO

# Việc không hiểu tại sao và làm thế nào một vấn đề được thực hiện luôn là điều tốt. YOLO

# Đừng bao giờ kiểm tra lại mã lệnh của chính mình, hãy yêu cầu một người nào đó. YOLO

# Sẽ chẳng ai đọc mã lệnh của bạn đâu, vì vậy đừng tốn công viết chú thích làm gì. YOLO

# Tại sao phải làm một việc theo cách dễ dàng khi bạn có thể “phát minh lại cái bánh xe”? Việc kế thừa và phát triển trong tương lai chỉ dành cho lũ ngốc mà thôi. YOLO

# Không bao giờ đọc tài liệu. YOLO

# Đừng phí thời gian với những vấn đề cốt lõi. YOLO

# Không viết tài liệu đặc tả . YOLO cũng chính là YDD (YOLO DRIVEN DEVELOPMENT)

# Không cần tuân theo các qui ước đặt tên. YOLO

# Trả tiền cho những bài hướng dẫn trực tuyến luôn tốt hơn việc đọc và nghiên cứu. YOLO

# Luôn sử dụng môi trường thành phẩm (production evironment) khi làm việc. YOLO

# Không mô tả điều bạn đang muốn làm, hãy hỏi những câu hỏi vu vơ về việc làm thế nào để hoàn tất nó. YOLO

# Không thụt lề mã lệnh. YOLO

# Các hệ thống kiểm soát phiên bản chỉ dành cho những kẻ bất tài. YOLO

# Phát triển trên một hệ thống tương tự như hệ thống triển khai cũng chỉ dành cho những kẻ bất tài! YOLO

# Không phải lúc nào tôi cũng kiểm thử mã lệnh của mình. Nhưng nếu tôi phải làm, tôi sẽ thực hiện công việc đó trên môi trường thực tế. YOLO

# “Người đàn ông thực thụ” sẽ triển khai ứng dụng qua ftp (File Transfer Protocol – giao thức truyền tệp tin). YOLO

Hãy quên đi những truyền thống cũ kĩ của phương pháp phát triển hướng kiểm thử hay hướng hành vi. Phương pháp mới sẽ giúp bạn tống cổ các chuyên gia tin học đi! Ruby.zigzo tóm tắt lại tuyên ngôn của YDD như sau: “Đây là một trò đùa, đừng làm theo bất cứ điều gì hoặc… cứ làm theo! YOLO!”

Tuy nhiên, một lệnh tìm kiếm đơn giản “because YOLO” trên GitHub cũng mang lại hơn 600 kết quả, điều đó chứng minh rằng khá nhiều lập trình viên đã bắt đầu áp dụng phương pháp YOLO:

                            (map(lambda __suchwoow:\
                map(lambda  __because___yolo__:\
      __lololol_.__setitem__((      (__because___yolo__))  ,                (0)),
range(2*(__suchwoow),               ((very_math)),     __suchwoow               ) ),

Ôi không, bạn không áp dụng…

YOLO Driven Development không phải là cách bạn thích? Tốt thôi, dưới đây là một số phương pháp phát triển hài ước khác bạn có thể vận dụng.

Phương pháp chim bồ câu

Sếp bay đến, ị lên mọi thứ rồi bay đi.

ADD (Asshole Driven Development – phát triển hướng “hậu môn” :D)

Một phương pháp yêu thích trước đây dành cho bất kì nhóm nào, trong đó những gã xuẩn ngốc nhất luôn đưa ra quyết định chính. Sự từng trải, cách thực hiện và tính lô-gíc mặc nhiên không cần tính đến.

Phương pháp NDAD (No Developers Allowed in Decisions – không ai được đưa ra quyết định)

Về cơ bản các lập trình viên bị cấm đưa ra các quyết định liên quan đến dự án, từ thiết kế những phần cốt lõi cho đến thời điểm kết thúc dự án. Lý do là những nhà lãnh đạo trung và cao cấp hiểu rõ điều họ muốn, làm thế nào để thực hiện và mất bao lâu để hoành thành nó.

FDD (Fear Driven Development – phát triển hướng sợ hãi)

Phân tích chứng minh rằng trạng thái tê liệt, điều có thể làm chậm lại toàn bộ dự án, là do những nhà phát triển sợ gây ra sai lầm, làm hỏng bản build hoặc gây ra lỗi. Khởi nguồn cho lo ngại của một lập trình viên có thể được qui cho việc thất bại trong vấn đề chia sẻ thông tin hoặc quy trách nhiệm cho những thành viên có thể thay thế trong nhóm.

CYAE (Cover Your Ass Engineering – bao che cho những kĩ thuật viên cặn bã)

Scott Berkun diễn tả hùng hồn rằng: động cơ đằng sau những nỗ lực cá nhân là để đảm bảo rằng khi sản phẩn bị chê bai, họ không phải là người gánh nhận tội lỗi.

Liệu còn phương pháp kỳ lạ nào khác mà chúng tôi quên chưa đề cập tới không? Nếu bạn biết, hãy cùng chia sẻ nhé!


Leave a comment

Sự trỗi dậy và suy tàn của lập trình viên đa năng


Tác giả: Peter Yared là người sáng lập và CTO (Chief technology officer – Giám đốc công nghệ) của Sapho, CTO/CIO (Chief Information Officer – Giám đốc truyền thông) của CBS Interactive.
Bài gốc: The Rise And Fall Of The Full Stack Developer

(lược dịch)

Ngày nay, trong lĩnh vực công nghệ, dường như tất cả mọi người đều ái mộ lập trình viên đa năng (full-stack developer). Khái niệm “đa năng” có thể đúng trong thời đại Web 2.0. Nhưng việc một thế hệ mới các công ty khởi nghiệp đang nổi lên đã mang đến những giới hạn ở phần lớn các lĩnh vực phần mềm khác nhau. Từ máy móc thông minh cho đến dự báo tính toán, phân tích dữ liệu, thiết bị di động, thiết bị đeo được và nhiều thứ khác. Tất cả những thứ trên khiến việc một lập trình viên có thể lập trình cho bất kì lĩnh vực nào trở nên bất khả thi.

Tôi bắt đầu viết các chương trình cho máy tính từ nhỏ, khoảng cuối những năm 1970, đầu những năm 1980. Khi đó các thiết bị di động hay web vẫn chưa xuất hiện và một người có thể tự mình viết toàn bộ một chương trình phần mềm từ đầu đến cuối. Các chương trình cũng không bị phân chia thành nhiều lớp (layer) giữa lập trình viên và phần cứng. Việc sử dụng hợp ngữ (assembly language) là bắt buộc với các lập trình viên nếu họ buộc phải cải thiện hiệu năng cũng như tiết kiệm bộ nhớ trên những máy tính sử dụng bộ xử lý 8 bit và có bộ nhớ hạn chế.

Lập trình ứng dụng nhanh chóng trở thành một môn thể thao đồng đội với sự ra đời của mô hình máy chủ / máy khách (client-server) vào cuối những năm 1980, đầu những năm 1990 cùng với làn sóng tính toán qua mạng cuối những năm 1990, đầu những năm 2000. Từng khía cạnh nhỏ trong công nghệ mới cũng trở nên vô cùng phức tạp, cần phải có chuyên gia riêng hay chậm chí là nhiều chuyên gia cho các tầng (tier) ứng dụng khác nhau như tầng giao diện, tầng cơ sở dữ liệu, tầng ứng dụng phía máy chủ… Việc quản lý các trang web kinh doanh trở thành một lĩnh vực đặc biệt bao gồm quản lý thiết bị mạng (như thiết bị định tuyến hay cân bằng tải), tinh chỉnh các máy ảo Java và sử dụng các kĩ thuật đánh chỉ mục cơ sở dữ liệu khác nhau.

Khoảng giữa những năm 2000, chi phí tạo ra bất kì thứ gì, từ những trang web đơn giản cho đến thế hệ tiếp theo của các phần mềm dịch vụ (SaaS – Software as a Service), trở nên cực kì tốn kém. Chi phí tăng cao này có tương quan trực tiếp chi phí dành cho các cá nhân ở nhiều tầng giao tiếp (và thường là thiếu sự giao tiếp) với nhau. Sự thay đổi ở một tầng ứng dụng nào đó sẽ ảnh hưởng đến các tầng ứng dụng khác cũng như ảnh hưởng đến quá trình triển khai. Điều này tương tự như điều mà Marc Andreessen đã đề cập: “Việc thêm người sẽ làm tăng chi phí cho việc giao tiếp theo cấp số nhân, đồng thời sẽ làm chậm mọi quá trình khác.”

Trái lại, công nghệ để tạo ra các trang web thế hệ 2 (Web 2.0) được tối ưu và đơn giản hóa nhanh chóng. Thay vì sử dụng những công nghệ phức tạp liên quan đến Java và những cơ sở dữ liệu như Oracle, lập trình viên chuyển sang sử dụng LAMP (Linux, Apache, MySQL, PHP/Python/Perl) như một sự thay thế hiệu quả mà đơn giản hơn nhiều. Những ngôn ngữ và khung ứng dụng (framework) mới như Django, Ruby hay Rails tự động hóa các lớp giữa trang web và cơ sở dữ liệu. Các khung ứng dụng cho giao diện như jQuery giúp thống nhất sự khác nhau giữa các trình duyệt. Các dịch vụ đám mây như Amazon Web Services đơn giản hóa việc triển khai, đồng thời cung cấp hệ thống mạng hoàn chỉnh cho người dùng.

Cuối những năm 2000, nhiều lập trình viên có khả năng tạo ra ứng dụng hoàn chỉnh hay phần mềm dịch vụ (SaaS – Software as a Service); từ trang web động, các lôgíc kinh doanh phía máy chủ, cơ sở dữ liệu khả mở, triển khai hệ thống và hỗ trợ sử dụng. Thế hệ lập trình viên đa năng mới này có thể được đặt vào bất kì vị trí nào trong một nhóm các lập trình viên đang làm cùng nhiệm vụ. Việc thêm vào nhiều lập trình viên đa năng cho phép một cá nhân có thể thêm vào một tính năng dù phải thay đổi nhiều tầng ứng dụng. Thời gian đưa ra một tính năng mới được rút ngắn thông qua việc giảm thời gian (và chi phí) giao tiếp giữa nhiều người ở các tầng ứng dụng khác nhau.

Nếu bạn đang xây dựng một trang web sử dụng đầy đủ các công nghệ như minh họa trên, hãy tìm một lập trình viên đa năng, người có thể tự mình kham mọi việc. Nhưng vào thời điểm này, bạn có thể cho tôi là điên nếu bạn muốn, tôi cho rằng nó chưa đề cập đầy đủ. Dưới đây là hình minh họa đầy đủ hơn cho những công nghệ cần dùng:

Tôi cá rằng không ai có đầy đủ kiến thức chuyên sâu trong mọi lĩnh vực nêu trên để có thể tự mình hoàn thiện thế hệ ứng dụng tiếp theo này. Chỉ nguyên việc theo kịp những tính năng mới cũng như những giao diện lập trình mới của một lĩnh vực nào đó cũng đã chiếm gần như toàn bộ thời gian rồi.

Chúng ta đang ở giai đoạn giữa trong việc nhanh chóng chuyển sang những công nghệ phức tạp yêu cầu chuyên gia ở từng tầng ứng dụng (quá trình chuyển đổi này rồi sẽ kết thúc theo thời gian). Việc phát triển những ứng dụng iOS hay Android tuyệt vời cần đến những chuyên gia trong từng nền tảng, những người hiểu sự phức tạp của nền tảng đó. Quá trình chuyển sang những cơ sở dữ liệu đối tượng mới như MongoDB cần sự lưu tâm nhất định. Chạy một ứng dụng trên các dịch vụ đám mây như Amazon yêu cầu bạn phải biết dữ liệu đầu vào, đầu ra của những dịch vụ khác nhau và quyết định cách thức chuyển sang sử dụng các vùng khác khi có lỗi. Thậm chí giao diện trang web cũng liên quan đến CSS4, JSON và các khung ứng dụng JavaScript MVC như AngularJS hay BackboneJS.

Trong thế giới mới đầy thách thức này, điều cấp thiết là có ít nhất một người có thể hiểu chức năng các phần ứng dụng với nhau. Người này cũng phải có khả năng liên kết các tầng ứng dụng khác nhau, làm việc với các chuyên gia để đảm bảo rằng tính năng có thể được hoàn thiện. Nói cách khác, những kiến trúc sư kết nối các tầng ứng dụng và xây dựng cầu nối trong phần mềm này không phải là những lập trình viên đa năng; họ là những chuyên gia tích hợp đa năng (full-stack integrator), những người chỉ là chuyên gia trong một hoặc một vài tầng cụ thể.

Hãy yên nghỉ, những lập trình viên đa năng! Chúng ta chào đón những chuyên gia tích hợp đa năng cùng với những kĩ sư có hiểu biết sâu sắc về công nghệ ở một lĩnh vực cụ thể. Trước mắt chúng ta là một thế giới phần mềm vô cùng hấp dẫn và chúng tôi cần bạn hơn bao giờ hết.


Leave a comment

5 phương pháp giúp lập trình viên ước lượng tốt hơn

Author: jsonmez
Original Post in English: 5 Ways Software Developers Can Become Better at Estimation

(lược dịch)

Phương pháp 1: Chia nhỏ vấn đề

Tôi đã từng đề cập (chưa đọc nên chả rõ anh ý đề cập lúc nào và ở đâu 😀) đến vấn đề tạo ra thời hạn quá xa làm việc ước lượng trở nên khó khăn và thiếu chính xác như thế nào; không may điều đó lại thường thấy trong bất kì dự án phát triển phần mềm nào.

Nếu bạn được yêu cầu ước lượng và bạn cho rằng công việc này sẽ tốn 5 phút để hoàn thành, kết quả ước lượng đó sẽ chính xác hơn nhiều so với việc ước lượng một công việc bạn cho rằng cần 5 tháng để hoàn thành.

Vậy thì làm thế nào để giải quyết vấn đề này?

Thật sự thì cách giải quyết tương đối đơn giản: Chia nhỏ công việc ra thành nhiều phần nhỏ và ước lượng cho những phần việc nhỏ đó.

Tôi biết điều này nghe có vẻ đơn giản và dễ thực hiện. Tôi cũng biết sẽ có những hoài nghi với cách tiếp cận này. Bạn sẽ có hàng tá lý do để bào chữa cho việc tại sao mình không chia nhỏ công việc ra. Nhưng sự thật là phần lớn công việc đều có thể chia nhỏ nếu bạn thực sự muốn làm.

Tuy nhiên, tôi đang bàn về việc tại sao việc chia nhỏ công việc ra lại tốt hơn và làm thế nào để chia nhỏ công việc tồn đọng từ trước tới giờ. Vì vậy, tôi sẽ không lan man thêm vào những chi tiết vụn vặt trong bài viết này.

Chìa khóa cho vấn đề ở đây là bạn không bao giờ đưa ra được một ước lượng chính xác với những công việc lớn. Tôi xin phép nhắc lại một lần nữa: Cách duy nhất bạn có thể ước lượng chính xác những công việc lớn là học cách chia nhỏ chúng thành những phần việc nhỏ hơn.

Nếu bạn thực sự cần ước lượng chính xác một việc nào đó, việc dành thời gian và công sức chia nhỏ việc đó thành những phần việc nhỏ sẽ thực sự đáng giá.

Ví dụ, giả sử tôi phải ước lượng khoảng thời gian cần thiết để hoàn thành một bài viết. Đó không phải là một công việc quá lớn, nhưng nó đủ lớn để gây ra sai lệch trong việc ước lượng.

Nếu tôi muốn kết quả chính xác hơn, tôi có thể chia nhỏ công việc của mình thành những việc nhỏ hơn.

Bạn có thể so sánh sự khác nhau giữa việc cố gắng phải ước lượng:

  • Viết và đăng lên một bài viết

So với việc ước lượng:

  • Nghiên cứu và đưa ra những vấn đề sẽ đề cập đến trong bài viết
  • Định hình bài viết
  • Viết một bản nháp
  • Thêm ảnh và liên kết
  • Lên kế hoạch đăng bài viết

Bằng cách phân chia ra, tôi có thể ước lượng chính xác hơn những công việc nhỏ này. Trên thực tế, khi vấn đề được chia nhỏ, tôi có thể giới hạn thời gian cho từng tiến trình một. Điều này đặc biệt hữu ích giúp kết quả ước lượng của tôi chính xác (để tránh đi quá xa, tôi sẽ đề cập đến vấn đề này sau).

Lần tới, khi được yêu cầu ước lượng một vài tính năng nào đó, thay về ước lượng xem bạn cần bao lâu để hoàn thành toàn bộ công việc, hãy cố gắng chia nhỏ tính năng và ước lượng xem bạn cần bao lâu để hoàn thành từng phần việc nhỏ một. Lúc nào bạn cũng có thể thêm vào những ước lượng, đánh giá mới để đưa ra kết quả chung chính xác hơn.

Đợi một chút! Tôi biết chính xác điểm sai bạn sẽ đề cập đến với kiểu ước lượng này. Hiển nhiên việc ước lượng các phần việc nhỏ sẽ chính xác hơn; nhưng khi bạn kết hợp chúng lại với nhau, tính chung lại bạn sẽ nhận được sai số tương đương với việc bạn ước lượng một công việc lớn.

Tất cả những gì tôi có thể trả lời với thắc mắc này là “hãy thử xem”. Ở một góc độ nào đó bạn có thể đúng. Nhiều sai số nhỏ gộp lại sẽ tạo thành một sai số lớn. Nhưng những sai số nhỏ này cũng có xu hướng bù trừ lẫn nhau. Một số công việc cần nhiều thời gian hơn những một số khác lại cần ít hơn. Điều này có nghĩa gộp chung lại, bạn sẽ có kết quả ước lượng chính xác hơn nhiều so với việc ước lượng một công việc lớn.

Phương pháp 2: Dành thời gian nghiên cứu

Tại sao bạn lại tệ trong việc ước lượng?

Lý do là bạn chưa hiểu đầy đủ về công việc bạn đang ước lượng.

Tôi từng đề cập đến việc không nắm được những điều mình không hiểu (đây là hiểm họa với rất nhiều dự án phát triển phần mềm) gây khó cho việc ước lượng như thế nào. Tuy nhiên, tôi chưa giải thích làm thế nào để giải quyết vấn đề chúng ta không nắm được những điều chúng ta không hiểu.

Thêm một lần nữa, câu trả lời cũng rất đơn giản: Nghiên cứu.

Cách tốt nhất để tránh việc không nắm được những điều mình không hiểu là biết rõ về nó.

Mỗi khi bạn được giao nhiệm vụ ước lượng, điều đầu tiên bạn nên nghĩ đến là nghiên cứu, cố gắng khám phá ra những gì mình chưa biết.

Thật không may là phần lớn lập trình viên không nghĩ đến việc nghiên cứu ngay khi họ ước lượng một công việc. Thay vì vậy, họ chủ yếu dựa vào kinh nghiệm trong quá khứ của mình. Nếu họ đã hoàn thành một việc tương tự trước đây, học sẽ tự tin ước lượng công việc mới mà bỏ qua tất cả những gì mình chưa nắm rõ. Nếu họ chưa bao giờ thực hiện một công việc tương tự, họ sẽ cho rằng có rất nhiều vấn đề cần phải làm và đưa ra kết quả ước lượng vống lên so với thực tế.

Cả hai cách làm trên không có cách nào tốt. Thay vì vậy, bạn nên tìm hiểu, đánh giá xem mình cần bao nhiêu thời gian để nghiên cứu về công việc trước ước lượng thời gian cần để thực hiện công việc đó. Bạn sẽ nhận ra rằng phần lớn lập trình viên ước lượng khá tốt thời gian họ cần để nghiên cứu; cho dù họ có thể rất tệ trong việc ước lượng thời gian cần để hoàn thành công việc đó.

Khi bạn đã hoàn thành việc nghiên cứu, bạn sẽ ít phải đối mặt với những vấn đề bạn không biết là mình không hiểu hơn. Tất nhiên, sẽ có những vấn đề bạn chưa hiểu nhưng ít nhất bạn cũng biết về điều đó.

Việc nghiên cứu trên thực tế là như thế nào?

Làm cách nào bạn nghiên cứu những công việc bạn sẽ phải ước lượng?

Đôi khi nó liên quan đến việc lên kế hoạch ra xa hơn một chút so với thời hạn. Tôi sẽ đưa ra một ví dụ về cách thực hiện trong một nhóm sử dụng Scrum hay Agile.

Giả sử bạn muốn cải thiện khả năng ước lượng của mình bằng việc thực hiện nghiên cứu trước khi tiến hành ước lượng công việc. Vấn đề ở đây là khi bạn làm việc trong một dự án sử dụng mô hình Agile, bạn luôn luôn phải ước lượng các công việc thực hiện trong một chu trình phát triển và không thật sự có thời gian để nghiên cứu từng công việc trước khi ước lượng công việc đó, đặc biệt là với những công việc lớn.

Tôi thấy rằng cách tốt nhất có thể làm trong hoàn cảnh này là chuyển công việc đó sang chu trình tiếp theo thay vì ước lượng nó ngay lập tức. Công việc bạn sẽ làm ở chu trình hiện tại là đánh giá xem mình cần bao nhiêu thời gian để nghiên cứu công việc đó.

Bạn có thể có rất nhiều việc nhỏ trong chu trình phát triển hiện tại với mục đích cung cấp đầy đủ thông tin giúp ước lượng chính xác hơn những công việc lớn ở chu trình phát triển tiếp theo. Trong quá trình thực hiện những công việc nhỏ này, bạn cũng có thể chia nhỏ những việc lớn thành những việc nhỏ hơn khi bạn hiểu rõ hơn.

Đợt chút! Tôi biết bạn đang nghĩ gì. Tôi không thể chỉ đơn giản là đẩy công việc sang chu trình phát triển tiếp theo. Sếp tôi và những người làm kinh doanh không thích điều đó. Họ muốn công việc được hoàn hiện ở chu trình phát triển hiện tại.

Tất nhiên là bạn đúng. Vậy làm thế nào bạn giải quyết vấn đề này?

Điều này cũng rất đơn giản. Bạn chỉ cần lên kế hoạch những công việc lớn cần hoàn thiện vào thời gian nào. Nếu bạn làm việc trong nhóm sử dụng mô hình Agile, bạn nên nhắm đến việc nghiên cứu những công việc lớn, những công việc sẽ phải thực hiện ở các chu trình phát triển sau.

Bằng cách luôn tìm tòi, nghiên cứu trước khi ước lượng bất kì việc gì, bạn sẽ tạo tạo dựng cho mình thói quen đưa ra những ước lượng chính xác hơn nhiều.

Cách làm này cũng có thể áp dụng với các công việc nhỏ, bằng cách dành ra khoảng 5 đến 10 phút để tìm hiểu về công việc đó trước khi đưa ra ước lượng.

Lần kế, khi bạn ước lượng một công việc, hãy dành ra một chút thời gian để nghiên cứu. Bạn sẽ ngạc nhiên khi nhận ra rằng kết quả ước lượng của mình trở nên chính xác hơn nhiều như thế nào.

Phương pháp 3: Theo dõi thời gian

Một trong những vấn đề lớn chúng ta gặp phải trong việc ước lượng là cảm giác chính xác thời gian. Việc nhớ lại thời gian thực hiện các dự án trong quá khứ của tôi thường bị sai lệch ít nhiều tùy theo mức độ yêu thích của tôi với dự án cũng như việc tôi đã đói đến như thế nào.

Sự sai lệch thời gian này có thể dẫn đến kết quả ước lượng cực kỳ sai lầm.

Vì lý do này, việc theo dõi thời gian bạn thực sự dùng cho công việc là rất quan trọng.

Tạo cho mình thói quen theo dõi thời gian của bất kì công việc nào bạn làm là một ý tưởng tuyệt vời. Hiện tại, trong khi đang viết bài này, đồng hồ của tôi vẫn đang chạy để theo dõi thời gian tôi bỏ ra. Vì thế, tôi có thể biết được việc viết các bài viết cần bao nhiêu thời gian. Tôi cũng có thể biết được liệu tôi có tiêu tốn quá nhiều thời gian vào một giai đoạn nào đó hay không.

Khi bạn tạo được cho mình thói quen theo dõi thời gian, bạn sẽ mường tượng tốt hơn khoảng thời gian cũng như địa điểm sử dụng cho một công việc nào đó.

Sẽ là điên rồi nếu cho rằng bạn có thể ước lượng tốt những công việc chưa làm trong khi bạn thậm chí không thể nói chính xác thời gian bạn đã làm một việc trước đây.

Bạn nên nghiêm túc suy nghĩ về vấn đề này trong một phút. Đừng cười, tôi nói thật đấy! Theo tôi bạn nên nghĩ về việc sẽ vô lý đến như thế nào nếu tin rằng mình có thể ước lượng tốt bất kỳ công việc gì trong khi bạn không thể nhớ lại được mình đã làm một công việc nào đó trước đây trong bao lâu.

Nhiều người phàn nàn rằng việc phát triển phần mềm không giống như những công việc khác, và rằng công việc này không thể ước lượng chính xác. Tôi đồng ý rằng việc phát triển phần mềm khó ước lượng hơn việc trải thảm hay lợp lại mái nhà. Nhưng tôi nghĩ rằng nhiều lập trình viên không làm tốt trong việc ước lượng là do họ không có ý tưởng gì về khoảng thời gian dành cho những công việc đó.

Hãy tự giúp bản thân mình và bắt đầu theo dõi thời gian. Có rất nhiều công cụ tốt giúp bạn thực hiện việc này:

Nhân tiện, làm theo cách này đã giúp tôi tốt hơn rất nhiều trong việc ước lượng. Tôi luôn có thể ước lượng chính xác toàn bộ công việc trong tuần trong 1 đến 2 giờ. Và tất nhiên, tôi biết được thời gian mình cần để ước lượng bởi vì tôi đã theo dõi thời gian cho việc đó.

Phương pháp 4: Giới hạn thời gian cho công việc

Tôi đã nói rằng tôi sẽ quay lại vấn đề này. Và đây chính là thời điểm đề cập đến.

Một bí mật lớn để trở thành một lập trình viên, người có thể ước lượng tốt công việc, là giới hạn thời gian cho từng công việc một. Điều này gần giống như là gian lận.

Khi bạn giới hạn thời gian cho công việc, bạn đảm bảo nó tiêu tốn đúng khoảng thời gian mà bạn đã lên kế hoạch.

Có lẽ bạn đang nghĩ rằng phần lớn công việc phát triển phần mềm không thể giới hạn thời gian; bạn đã sai. Tôi sử dụng công cụ này thường xuyên và tôi phát hiện ra rằng nhiều công việc chúng ta làm có xu hướng không cố định thời gian phải dành cho chúng.

Tôi cũng phát hiện ra rằng nếu bạn sử dụng một khoảng thời gian cố định (và chỉ dùng đúng khoảng thời gian đó) cho một việc, bạn có thể làm việc theo hướng đảm bảo công việc được hoàn thanh đúng hạn.

Hay xem một ví dụ về việc viết mã kiểm thử đơn vị (Unit test):

Với phần lớn lập trình viên, viết mã kiểm thử đơn vị (Unit test) là một công việc có tính chủ quan. Trừ khi bạn hướng tới mục đích kiểm tra toàn bộ mã, bạn luôn chỉ viết mã kiểm thử đơn vị (Unit test) khi bạn cảm thấy bạn phải kiểm tra đầy đủ đoạn mã. (Nếu bạn đang phát triển phần mềm theo hướng kiểm thử, Test Driven Development – TDD, điều này có lẽ không còn chính xác).

Nếu bạn giới hạn một khoảng thời gian dành cho việc viết mã kiểm thử đơn vị (Unit test), bạn có thể ép mình làm việc với những khối mã quan trọng trước và thực hiện theo nguyên tắc 80/20 để đảm bảo rằng bạn sẽ thu lợi lớn nhất trong giới hạn cho phép.

Đối với nhiều công việc, bạn có thể kết thúc với việc tiêu tốn thêm nhiều giờ cho những chi tiết vụn vặt mà chẳng tạo nên nhiều khác biệt. Giới hạn thời gian ép buộc bạn làm việc với những việc quan trọng trước, tránh thực hiện những công việc như tối ưu hóa ngay trong giai đoạn đầu hay bị ám ảnh về việc đặt tên làm sao cho đúng.

Hiển nhiên rằng sẽ có lúc bạn sử dụng vượt quá thời gian mình thiết lập ra. Nhưng trong nhiều lần khác, bạn sẽ thấy rằng mình thực sự có thể hoàn thành công việc cần thiết; sau đó, bạn luôn có thể quay lại sửa cho nó tốt hơn khi có thời gian.

Tôi xin nhắc lại một lần nữa: bạn hãy yêu thích việc theo dõi thời gian; nó là một thói quen bạn phải gây dựng. Đến khi bạn đã quen với nó, bạn sẽ có khả năng sử dụng nó như một mánh lới giúp các ước lượng của mình trở nên chính xác hơn bất kì thứ gì bạn có thể tưởng tượng.

Phương pháp 5: Kiểm tra lại ước lượng của bạn

Đây là một bí mật nhỏ: Bạn không phải ước lượng chính xác ngay lần đầu tiên. Thay vì thế, bạn có thể xem lại ước lượng của mình như một tiến trình trong công việc.

Tôi biết sếp bạn muốn bạn đưa ra một ước lượng chính xác ngay từ đầu chứ không phải lúc bạn gần hoàn thành công việc đó. Nhưng bạn luôn được phép đưa ra ước lượng chính xác nhất có thể và xem lại ước lượng của mình như một tiến trình trong công việc.

Tôi không thể nghĩ ra bất kỳ tình huống nào trong đó việc cập nhập thêm thông tin lại không được hoan nghênh.

Hãy sử dụng bốn phương pháp trên để đảm bảo rằng ước lượng ban đầu của bạn sẽ chính xác hết mức có thể. Nhưng bạn nên định kỳ dành ra một chút thời gian để đánh giá lại tình trạng thực tế của ước lượng đó.

Hãy nghĩ theo hướng nay: Bạn biết thời điểm bạn tải về một tệp tin và máy tính thông báo với bạn cần bao lâu để hoàn tất công việc đó. Liệu bạn có nghĩ rằng nó tính toán quãng thời gian này ngay từ đầu và không bao giờ cập nhập lại? Tất nhiên là không. Thay vì vậy, phần lớn các chương trình quản lý đều định kỳ cập nhập khoảng thời gian ước tính còn lại.

Nói chung, tiến hành phương pháp này có thể giúp bạn ước lượng tốt hơn. Khi bạn định kỳ xem lại và cập nhập ước lượng của mình, bạn sẽ nhận ra lý do tại sao ước lượng ban đầu của mình lại chưa chính xác.


Leave a comment

11 nguyên tắc lập trình viên nên tuân theo

Author: jsonmez
Original Post in English: 11 Rules All Programmers Should Live By

(lược dịch)

Cá nhân tôi là một người sống có nguyên tắc.

Phải thừa nhận rằng những nguyên tắc dưới đây tôi tự đặt ra cho chình mình, nhưng dẫu sao chúng vẫn là những nguyên tắc.

Tôi nhận ra rằng việc tạo những nguyên tắc cho bản thân giúp tôi làm việc hiệu quả hơn. Tôi có thể quyết định sớm nhiều vấn đề thay vì phải đối mặt với những quyết định một cách thụ động.

Liệu tôi có nên đi tập thể hình sáng hôm nay không?

Tôi có một nguyên tắc là sang thứ 4 tôi sẽ đi tập thể hình và hôm nay chính là thứ 4. Vì vậy tôi sẽ đi, việc đó đã được quyết định.

Tuần này, trong lúc nhớ lại những nguyên tắc tôi áp đặt cho chính mình, tôi đã nghĩ rằng sẽ rất tốt nếu tôi tổng hợp chúng lại thành một bộ nguyên tắc; bộ nguyên tắc bất kì lập trình viên nào cũng nên tuân theo.

Tôi cũng phải thừa nhận rằng phần lớn những nguyên tắc dưới đây tương tự như là những lời chỉ dẫn. Dù sao đi nữa, đây là những nguyên tắc mà tôi đề cập:

1. Công nghệ là cách bạn tìm ra giải pháp, bản thân công nghệ không phải là giải pháp

Chúng ta có thể sử dụng bộ khung ứng dụng Javascript (Javascript framework), Angular chẳng hạn , ngôn ngữ lập trình hay thậm chí là hệ điều hành mới nhất; nhưng bản thân chúng không phải là những giải pháp thực sự cho những vấn đề mà chúng ta, với tư cách những lập trình viên, phải giải quyết. Chúng chỉ đơn giản là những công cụ giúp chúng ta giải quyết vấn đề.

Chúng ta phải thật cẩn thận để không quá cuồng tín vào một công nghệ nào đó mà chúng ta thích hoặc được sử dụng rộng rãi. Đừng giết gà bằng dao mổ trâu!

2. Thông minh là kẻ thù của sự rõ ràng

Khi viết mã, bạn nên hướng đến việc viết sao cho rõ ràng và dễ hiểu.

Những dòng mã có khả năng liên hệ với mục đích thực hiện một cách rõ ràng có giá trị hơn nhiều so với những dòng mã khó hiểu, bất kể chúng tuyệt vời đến thế nào đi nữa.

Không hẳn luôn đúng nhưng nói chung, thông minh là kẻ thù của sự rõ ràng.

Khi ta viết mã “thông minh”, mã đó thường là không rõ ràng.

Mỗi khi bạn định làm gì đó “một cách thông minh”, bạn thực sự cần nhớ đến nguyên tắc này.

Thi thoảng chúng ta viết code “thông minh” nhưng vẫn sáng sủa nhưng đó không phải là vấn đề tôi đề cập đến.

3. Chỉ viết mã khi bạn buộc phải viết

Nguyên tắc này có vẻ hơi mâu thuẫn. Dù sao đi nữa, chẳng phải công việc của một lập trình viên là viết mã sao?

Câu trả lời là nó vừa đúng, vừa sai.

Công việc của chúng ta liên quan đến việc viết mã, nhưng chúng ta nên hướng đến việc viết sao cho ít nhất có thể mà vẫn giải quyết được vấn đề.

Điều này không có nghĩa chúng ta nên thu gọn mã của mình nhiều nhất có thể hay đặt tên biến chỉ bằng 1, 2 kí tự. Nó có nghĩa là chúng ta nên cố gắng chỉ viết mã cần thiết phục vụ cho tính năng được yêu cầu.

Thông thường, bạn sẽ bị cám dỗ bởi việc thêm vào thật nhiều tính năng hấp dẫn hay viết mã thật tổng quát và linh hoạt, sao cho nó có thể bao quát tất cả những tình huống khác nhau có thể xảy ra. Nhưng điều thường diễn ra là mỗi khi chúng ta cố gắng đoán xem tính năng nào là hữu ích hay vấn đề nào có thể xảy ra sau này, chúng ta thường đưa ra câu trả lời sai.

Những đoạn mã thêm thắt này không mang lại giá trị gì cả, trái lại nó ẩn chứa rất nhiều nguy cơ tiềm tàng. Càng nhiều mã, càng nhiều cơ hội xuất hiện lỗi cũng nhưng chúng ta phải tốn nhiều công sức hơn nhằm bảo trì phần mềm.

Một kĩ sư phần mềm tốt không viết mã trừ khi nó thật sự cần thiết.

Một kĩ sư phần mềm tuyệt vời sẽ xóa bớt đi nhiều mã nhất có thể.

4. Chú thích đa phần là không tốt

Tôi không ủng hộ cho việc viết chú thích kèm với mã và hoàn toàn đồng ý với Bob Martin khi anh ấy phát biểu rằng:

“Mỗi lần bạn viết một câu chú thích, bạn nên cau có và cảm thấy bực mình vì sự thất bại trong việc diễn tả của mình.” — Clean Code: A Handbook of Agile Software Craftmanship

Điều này khôgn có nghĩa bạn không nên viết bất kì lời chú thích nào; nhưng trong phần lớn trường hợp, bạn nên tập trung vào việc đặt tên cho dễ hiểu thay vì viết những câu chú thích.

Những câu chú thích chỉ nên được sử dụng khi không có cách nào xây dựng mối liên hệ rõ ràng giữa tên biến, tên hàm với mục đích của chúng. Chú thích được sử dụng để mô tả cho mục đích thực sự khi bạn không thể dễ dàng diễn đạt bằng mã.

Chẳng hạn một câu chú thích nói rằng một thứ tự bất bình thường xảy ra khi thực thi một đoạn mã không phải do lỗi mà là kết quả được biết trước, gây ra bởi một lỗi của hệ thống bên dưới.

Nói chung, những câu chú thích không chỉ không tốt vì sự không cần thiết trong phần lớn trường hợp mà còn bởi vì chúng không diễn đạt chính xác vấn đề.

Lập trình viên có xu hướng không cập nhập lại những câu chú thích cùng với mã, điều này dẫn đến việc những câu chú thích trở nên nguy hiểm bởi vì chúng có thể lái bạn sang một hướng đi hoàn toàn sai lầm.

Bạn có đối chiếu từng câu chú thích với mã tương ứng để đảm bảo rằng mã đang thực hiện chính xác điều mà câu chú thích đang diễn đạt? Trong trường hợp bạn làm như vậy, mục đích của việc sử dụng chú thích ở đây là gì? Trong trường hợp bạn không làm, liệu bạn có thể tin tưởng nội dung mà câu chú thích thể hiện hay không?

Đây là một tình huống cực kì khó xử, vì vậy tốt hơn hết là tránh nó càng xa càng tốt.

5. Luôn chắc chắn điều đoạn mã sẽ thực hiện trước khi viết

Điều này có vẻ hiển nhiên nhưng thực sự không phải như vậy.

Bao nhiêu lần bạn ngồi xuống, bắt đầu viết mã mà không hiểu cặn kẽ đoạn mã bạn sẽ viết sẽ làm những gì?

Tôi không thể nhớ nổi đã bao nhiêu lần mình làm như vậy. Vì thế đây là nguyên tắc tôi cần phải đọc thường xuyên.

Việc thực hành phát triển phần mềm theo hướng kiểm thử (Test Driven Development – TDD) có thể giúp bạn trong vấn đề này bởi vì rõ ràng là bạn phải biết đoạn mã thực hiện cái gì trước khi bạn viết nó. Nhưng nó sẽ không giúp bạn ngăn việc tạo ra những đoạn mã sai. Vì vậy, việc đảm bảo bạn hiểu chính xác và đầy đủ yêu cầu của tính năng mình đang xây dựng trước khi bạn thực hiện là cực kì quan trọng.

6. Kiểm tra mã trước khi chuyển đi

Đừng ném mã bạn viết qua và bắt đội ngũ kiểm thử chịu gánh nặng kiểm tra; bạn đang tiêu tốn thời gian của tất cả mọi người chỉ để có những báo cáo và giải pháp sửa lỗi không cần thiết.

Thay vì đó, hãy dành một chút thời gian kiểm tra toàn bộ các tình huống trước khi bạn thông báo mình đã hoàn thành việc thực thi mã.

Chắc chắn rằng bạn sẽ không thể tìm ra mọi lỗi trước khi bạn chuyển phần mềm đến đội ngũ kiểm thử. Nhưng ít nhất bạn sẽ tìm ra trước những lỗi ngớ ngẩn, những lỗi chúng ta vẫn thường mắc phải hết lần này đến lần khác.

Rất nhiều lập trình viên nghĩ rằng chỉ có đội ngũ kiểm thử mới thực hiện việc kiểm tra. Điều này đơn giản là không đúng. Chất lượng sản phẩm là trách nhiệm của tất cả mọi người.

7. Học kiến thức mới hàng ngày

Nếu bạn không cập nhập kiến thức mới hàng ngày, bạn sẽ ngày càng thụt lùi bởi vì tôi cá rằng bạn sẽ quên một cái gì đó.

Sẽ không quá tốn thời gian để học một cái gì đó mới hàng ngày.

Bạn chỉ phải dành khoảng 15 phút để đọc một cuốn sách. Tôi đã đọc trọn vẹn rất nhiều sách trong năm vừa qua chỉ với 45 phút mỗi ngày.

Những tiến bộ nhỏ bạn có được hàng ngày sẽ được tích lũy qua thời gian và trở nên to lớn trong tương lai. Nhưng bạn phải bắt đầu ngay bây giờ nếu bạn muốn giành được phần thưởng đó.

Bên cạnh đó, công nghệ đang thay đổi rất nhanh chóng.Nếu bạn không liên tục nâng cao các kĩ năng của mình và học những kĩ năng mới, bạn sẽ rất nhanh chóng bị bỏ rơi lại phía sau.

8. Lập trình là niềm vui

Thật vậy! Tôi nghĩ có lẽ bạn không chọn nghề này chỉ vì thu nhập cao.

Ý tôi là không có gì sai khi chọn một nghề có thu nhập tốt, nhưng bác sĩ hay luật sư có lẽ là một lựa chọn tốt hơn nhiều.

Lý do lớn nhất bạn trở thành một lập trình viên là bởi vì bạn yêu thích lập trình. Vì vậy, đừng quên rằng bạn đang làm điều mình yêu thích.

Lập trình mang lại rất nhiều niềm vui. Tôi ước rằng tôi có thể viết ra nhiều mã hơn nữa.

Trong thời gian này, tôi luôn quá bận với công việc của mình để dành nhiều thời gian cho việc lập trình. Đó là một trong những lý do tại sao tôi có thể hình dung rõ ràng niềm vui mà việc lập trình mang lại.

Có lẽ bạn đã quên đi niềm vui trong việc lập trình. Đây là lúc nhớ lại bạn đã từng vui vẻ thế nào với việc bắt đầu một dự án hoặc đơn giản là thay đổi cách nghĩ và nhận ra rằng bạn được lập trình và được trả tiền cho công việc đó.

9. Bạn không thể biết tất cả

Càng học nhiều bạn càng nhận ra rằng có quá nhiều điều bạn chưa biết.

Nhận ra điều này rất quan trọng bởi nếu không, bạn sẽ tự huyễn hoặc với suy nghĩ mình biết mọi thứ.

Sẽ chẳng có gì to tát nếu bạn không biết mọi câu trả lời.

Sẽ là bình thường nếu bạn phải nhờ ai đó trợ giúp hoặc giảng giải khi bạn không hiểu vấn đề.

Trong nhiều trường hợp, bạn có thể học điều mình cần biết ngay khi bạn phải biết. Bạn có thể tin tôi về vấn đề này vì nó diễn ra với tôi rất nhiều lần.

Ý tôi là đừng ép mình học tất cả mọi thứ bởi vì đó là nhiệm vụ bất khả thi. Thay vì vậy, bạn nên tập trung học những gì bạn cần biết và xây dựng cho mình các kĩ năng giúp bạn học hỏi nhanh hơn.

10. Phương pháp thực hiện tốt nhất tùy thuộc vào từng tình huống

Liệu phát triển phần mềm theo hướng kiểm thử (Test Driven Development – TDD) có phải là phương pháp tốt nhất?

Liệu chúng ta nên luôn luôn áp dụng lập trình theo cặp (pair program).

Bạn sẽ chẳng là gì nếu bạn không sử dụng IoC?

Câu trả lời cho tất cả những câu hỏi trên là “Nó phụ thuộc”.

Nó phụ thuộc vào từng tình huống.

Mọi người luôn cố gắng đưa ra cách làm tốt nhất. Họ sẽ nói với bạn rằng họ luôn làm vậy và bạn cũng nên làm theo. Nhưng điều đó đơn giản là không đúng.

Tôi làm theo rất nhiều phương pháp khi tôi lập trình, nhưng tôi cũng không làm theo vô điều kiện.

Các nguyên tắc là bất di bất dịch nhưng phương pháp thực hiện luôn thay đổi tùy theo tình huống.

11. Luôn hướng đến sự đơn giản

Tất cả các vấn đề đều có thể được chia nhỏ.

Giải pháp hiệu quả nhất thường lại là giải pháp đơn giản nhất.

Nhưng sự đơn giản không phải dễ dàng mà có. Bạn phải lao động để có được nó.

Mục đích của blog này nhằm đề cập đến sự phức tạp trong phát triển phần mềm, cũng như cuộc sống nói chung, và làm cho chúng trở nên dơn giản hơn.

Có lẽ bạn cũng như tôi đều thấy rằng đó không phải là một nhiệm vụ dễ dàng.

Bất kì gã ngốc nào đều có thẻ tạo ra một giải pháp phức tạp cho một vấn đề. Sẽ tốn nhiều công sức và thời gian để thay đổi một giải pháp nhằm giúp nó trở nên đơn giản hơn mà vẫn chính xác.

Hãy dành thời gian. Hãy nỗ lực hết mức. Và hướng đến sự đơn giản.

Những nguyên tắc của bạn là gì?

Trên đây là những nguyên tắc của tôi. Thế còn bạn thì sao?

Những nguyên tắc của cá nhân bạn là gì?

Bạn nghĩ cái gì là quan trọng, đáng để ghi nhớ hàng ngày?


Leave a comment

5 cách để triệt tiêu năng suất lao động

Author: jsonmez
Original Post in English: 5 Ways to Destroy Your Productivity

(lược dịch)

Bạn đang tìm cách triệt tiêu hoàn toàn năng suất lao động của mình?

Bạn tìm đúng chỗ rồi đấy!

Việc đạt năng suất lao động đang được đánh giá quá mức.

Ý tôi là nó có mang lại gì tốt đẹp cho bạn không?

Bạn càng hoàn thành nhiều việc, bạn càng bị yêu cầu làm nhiều việc hơn nữa.

Vì thế, đây là vài lời khuyên giúp bạn giúp bạn dậm chân tại đúng vị trí hiện tại trong sự nghiệp mà không phải hoàn thành bất kỳ công việc nào.

Lời khuyên 1: Cho phép mình phân tâm

Ngay tại thời điểm tôi viết bài này, tôi đang kiểm tra Facebook, đăng vài lời nhắn trên Twitter, âu yếm chú chó của tôi và tập chạy.

Chắc chắn tôi không ngồi đây, tập trung vào máy tính, cố gắng ngăn chặn mọi thứ khác trong khi viết. Làm như vậy sẽ quá hiệu quả. Tôi sẽ gặp rủi ro là hoàn thành bài viết này trong khoảng thời gian hợp lý để rồi bị cám dỗ vào việc viết một bài khác.

Nếu bạn thật sự muốn mình lánh xa nhiệm vụ càng lâu càng tốt, bạn nên mở tất cả các cửa sổ trình duyệt.

Tôi nói điều này hoàn toàn nghiêm túc. Bạn thử nghĩ xem tại sao họ lại phát minh ra các tab?

Tất cả các trình duyệt hiện tại đều hỗ trợ tab là có lý do của nó. Bạn được mong đợi kiểm tra thường xuyên để xem liệu có ai đăng phim đời tư trên Facebook hay trả lời những tin nhắn quái gở mà bạn đăng lên vài phút trước.

Và đừng quên để tiếng và chế độ rung chiếc điện thoại của bạn ở mức cao nhất. Nếu ai đó gọi hay nhắn tin cho bạn, đó sẽ là một lý do tuyệt vời để nghỉ ngơi 2 phút. Bạn đã làm việc rất chăm chỉ và bạn xứng đáng với 2 phút đó.

IM (Instant Messenger) cũng rất cần thiết. Hãy cố gắng đăng nhập nhiều dịch vụ nhất có thể. Một vài lời khuyên dành cho bạn là Skype, Google Hangouts, Facebook Messaging và thậm chí là ICQ.

Địa điểm cũng cự kỳ quan trọng. Đừng bao giờ giấu mình trong phòng riêng hay văn phòng. Bạn nên ra ngoài tận hưởng sự tự do vì chẳng ai lại thích một kẻ ẩn dật cả. Hãy cố gắng tìm một chỗ càng đông người càng tốt và đừng bao giờ nghĩ đến việc lấy tai nghe ra để nghe nhạc cổ điển.

Bạn phải là người đàn ông của hiện tại.

Hãy hòa nhập với vũ trụ. Cảm nhận nhịp sống hối hả đang cuồn cuộn trôi.

Bạn phải sớm nắm bắt mọi thứ trước khi nó trôi ra khỏi tầm tay của bạn.

Lời khuyên 2: Cố gắng làm nhiều việc cùng lúc

Làm nhiều việc cùng lúc cực kỳ tuyệt vời. Tôi nói nghiêm túc đấy.

Bạn có thể giả vờ như bạn đang đang hoàn thành rất nhiều công việc mặc dù bạn chẳng hoàn thành bất kỳ công việc nào cả.

Chẳng có cách nào tốt hơn để thu thập thông tin theo tốc độ của con ốc sên là làm nhiều việc cùng lúc như một ông sếp.

Vừa lập trình vừa xem tivi? Siêu sao!

Vừa viết thư điện tử vừa trò chuyện với đồng nghiệp? Siêu ninja!

Bạn thậm chí có thể làm nhiều việc cùng lúc mặc dù trông bạn rất tập trung.

Bạn có thể thực hiện công việc này hiệu quả hơn bằng cách sử dụng tổ hợp phím tắt “Alt+Tab” (hay “Command+Tab trên Mac)

Với tổ hợp phím đơn giản này, bạn có thể chuyển qua lại giữa bảng tính, môi trường phát triển tích hợp, các cửa sổ trình duyệt và bất kì chương trình nào bạn thích bằng một tốc độ cực nhanh.

Khi bạn thực hiện tốt, bạn có thể hình thành thói quen không bao giờ tập trung vào một công việc đủ lâu để hoàn thành nó. Bạn chỉ việc chuyển đối qua lại giữa các cửa sổ cả ngày. Chẳng phải công nghệ mang lại hạnh phúc cho chúng ta sao?

Nghĩ về việc viết một dòng mã… Alt+Tab

Kiểm tra thư điện tử… Alt+Tab

Nghĩ lại về việc viết một dòng mã… Alt+Tab

Ôi nhìn kìa! Có thư mới…

Lời khuyên 3: Ưu tiên làm những việc vô thưởng vô phạt

Bạn có biết điều gì xảy ra nếu bạn ngồi xuống và làm công việc quan trọng đầu tiên không?

Bạn biết không nào?

OK, để tôi nói cho bạn điều gì sẽ diễn ra.

Bạn sẽ trở thành một kẻ nhàm chán chỉ biết làm theo ý người khác, năng suất công việc cao nhưng buồn tẻ và hèn nhát.

Bạn có muốn là một kẻ hèn nhát?

Bạn có muốn được đề bạt và phải làm nhiều việc quan trọng khác nữa?

Chắc là không rồi!

Vậy câu hỏi tiếp theo là tại sao bạn lại làm những thứ quan trọng thay vì ngay lập tức kiểm tra thư điện tử và Facebook trước tiên vào buổi sáng?

Năng suất công việc chỉ là hoàn thành công việc theo thứ tự ưu tiên.

Nếu bạn sống như vậy, bạn sẽ trở nên vô cùng buồn tẻ.

Công việc quan trọng có thể chờ. Bạn còn có rất nhiều việc vụn vặt, không quan trọng cần làm mà chúng lại thú vị hơn nhiều.

Bạn có biết nhiều người trên mạng có những sai lầm?

Tôi nghiêm túc đấy. Họ đã sai và họa đang gửi cho bạn những thông tin sai lạc.

Bạn sẽ bỏ qua và mặc kệ họ sai lầm? Tất nhiên bạn không nên làm vậy.

Bạn phải để lại nhận xét của mình về bài viết của họ. Bạn phải nói với họ rằng họ đã sai. Bạn thậm chí phải chia sẻ cả những thước phim vui vẻ về những con mèo.

Những chuyện thú vị như vậy sẽ bị bỏ lỡ nếu bạn tập trung vào những công việc quan trọng đầu tiên.

Bạn cũng không bao giờ biết những chuyện thú vị này nếu bạn quá bận rộn cho việc hoàn thành công việc quan trọng.

Và trong lúc hấp hối, bạn có nghĩ rằng mình sẽ nói: “Ước gì tôi có thể làm việc chăm chỉ và sống một cuộc sống ý nghĩa hơn!”.

Không thể nào! Bạn sẽ nói “Ước gì tôi có thể chia sẻ nhiều phim trên YouTube hơn, nhận xét nhiều bài viết chính trị trên Facebook hơn và trả lời tất cả những thư vô bổ”. Đó mới chính là cuộc sống; là những điều có ý nghĩa.

Khi bạn nhìn lại cuộc đời mình, về cơ bản nó được định nghĩa bởi số cuộc tranh cãi bạn thắng trên mạng – hãy tin tôi về điểm này.

Hãy làm những việc vô bổ và những việc dễ trước, việc giải quyết công việc quan trọng hãy để sau.

Ngoài ra, thỉnh thoảng công việc tự dưng hoàn thành như có phép màu dù bạn bỏ qua không làm.

Khi tôi bỏ lại bát đĩa trên bàn và quần áo trên sàn, bạn có nghĩ rằng chúng cứ ở yên đó không?

Tất nhiên là không. Một bà tiên nào đó đã dọn dẹp chúng trong khi tôi ngủ.

Các vấn đề thường có thể được giải quyết ổn thỏa chỉ bằng cách bỏ qua chúng.

Lời khuyên 4: Trì hoãn công việc một cách chuyên nghiệp

Programmer. Pro-grammer. (chơi chữ: Lập trình viên – Người giỏi ngữ pháp)

Bạn có giỏi ngữ pháp không?

Tất nhiên tôi thì không rồi.

Thế bạn có biết tôi giỏi trong lĩnh vực nào không?

Để đến mai.

Đúng là vậy đấy. Và bạn cũng có thể tốt như tôi trong việc này. Việc này không quá khó, thậm chí là một trong những việc tốt nhất bạn có thể làm để ngay lập tức giảm năng suất công việc. Bạn có thể là một Chuck Norris trong việc trì hoãn.

Tôi sẽ nói cho bạn nghe một câu nói bí mật được lưu truyền trong nhiều thế hệ những người chây ì, từ giáo sư cho đến sinh viên. (Có một thời kì câu nói này đã biến mất hoàn toàn khi những giáo sư trong việc chây ì trì hoãn và chết trước khi truyền đạt lại nó cho sinh viên; nhưng hiện giờ câu nói này đã lại được khám phá ra.)

Câu nói đó là “Tí nữa tôi sẽ làm”.

Hãy coi đó là kim chỉ nam của bạn.

Sống với nó. Hít thở cùng nó.

Khi bạn ngồi xuống làm việc, hãy hít một hơi dài, mở IDE (Intergrated Development Evironment – Môi trường phát triển tích hợp) hay tài liệu ra rồi đứng dậy tuyên bố hùng hồn: “Tí nữa tôi sẽ làm.”

Đoán thử xem điều gì sẽ xảy ra nếu bạn hoàn thành việc gì đó trước thời hạn?

Bạn sẽ phải tiếp tục làm việc với nó, làm cho nó trở nên tốt hơn.

Bạn có muốn làm thêm nhiều hơn không? Tôi thì không. Tôi thà đợi cho đến phút cuối, làm một phần công việc tẻ nhạt và tuyên bố rằng không phải lỗi của tôi vì tôi không có đủ thời gian.

Và như bạn thấy, đó là lý do tại sao họ gọi tôi là người trì hoãn công việc chuyên nghiệp chứ không phải tay mơ.

Nó cũng không quá khó như bạn nghĩ. Thực tế là khi bạn thích việc trì hoãn, bạn sẽ thấy việc này ngày càng trở nên dễ dàng hơn.

Sau một thời gian, cách xử lý công việc mặc nhiên của bạn sẽ là để mọi thứ lại đó cho đến những phút cuối.

Bạn sẽ không bao giờ phải làm việc thực sự trừ khi bạn bị ép buộc, và thậm chí khi bị ép buộc, nếu bạn đủ thông minh và trung thành với cách làm này, bạn sẽ tìm ra cách để không phải làm việc đó.

Tôi phải cảnh báo bạn rằng rất nhiều người tập tành trì hoãn công việc đã thất bại trong việc đạt đến trình độ cao và trở thành người chây ì thật sự. Đó là vì họ đã bỏ qua một vài điểm quan trọng.

Tôi sẽ liệt kê những điểm đó ở đây để bạn có thể tránh lặp lại những sai lầm tương tự:

  • Không bao giờ bắt đầu công việc sớm. Luôn luôn đợi đến phút cuối mới bắt đầu.
  • Khi bạn ngồi xuống làm việc, đừng thực sự làm mà hãy làm một việc gì đó khác. Luôn luôn có một việc hay một thứ gì đó mang lại nhiều niềm vui hơn là công việc bạn phải làm. Hãy tin vảo bản năng và bạn sẽ tìm ra niềm vui đó.
  • Công việc càng khó khăn phức tạp bao nhiêu bạn càng có cơ hội trì hoãn thành công bấy nhiêu. Hãy cố gắng tạo ra một núi công việc phức tạp đến hết mức có thể. Nếu bạn chia nhỏ chúng, nó sẽ dễ dàng được hoàn thành hơn và giấc mơ trì hoãn công việc của bạn sẽ sớm trở thành cơn ác mộng.

Hãy nhớ nằm lòng bài học này, bạn sẽ tìm ra “cách làm riêng” của mình.

Lời khuyên 5: Yêu cầu mọi thứ bạn làm phải hoàn hảo

Một số người coi sự hoàn hảo là một yếu điểm, tôi không nghĩ vậy.

Nếu bạn muốn giảm năng suất công việc và đảm bảo rằng bạn rất, rất hiếm khi phải hoàn thành một việc nào đó, bạn phải luôn luôn tâm niệm rằng: tôi sẽ không làm trừ phi nó được thực hiện hoàn hảo.

Thực tế việc nghĩ đến mức độ hoàn hảo của một việc cần được thực hiện là một rào cản lớn trong việc thực hiện nó. Nếu bạn có cách để không phải làm gì, năng suất lao động cũng sẽ biết mất và nhiệm vụ coi như đã hòan thành.

Trong khi mọi người thực hiện những công việc vụn vặt và hoàn thành rất nhiều, nếu bạn cố gắng cầu toàn, có thể bạn sẽ không đạt được kết quả nào. Nhưng ít nhất bạn hoàn toàn đảm bảo về bất kỳ thứ gì mình tạo ra.

Trái ngược với suy nghĩ thông thường, bạn xứng đáng được nhận huy chương vì đã tiêu tốn nhiều giờ mày mò với một giải thuật, khi mà nó đã giải quyết được vấn đề bạn cố gắng giải quyết, nhằm tăng một chút hiệu năng hay đơn giản chỉ là đặt lại tên các biến cho đúng.

Tối ưu hóa ngay trong giai đoạn đầu không chỉ là một người bạn bình thường mà còn là người đồng hành tri kỉ của bạn, nếu bạn muốn hướng đến những thứ hoàn hảo.

Bạn sẽ thường xuyên cảm thấy buồn chán với việc làm cho mọi thứ trở nên hoàn hảo vì nó tiêu tốn một khoảng thời gian đáng kể. Vì vậy sẽ không ai trách móc gì nếu bạn chuyển sang việc tiếp theo mà không bao giờ kết thúc công việc trước đó. Tất nhiên, bạn sẽ làm nó sau 🙂

Mã nguồn được viết hoàn hảo tất nhiên tốt hơn cả trăm lầm mã nguồn chỉ đơn giản là làm được việc. Một số lập trình viên có tiêu chuẩn rất thấp nhưng bạn không nằm trong số họ.

Khi đối mặt với việc chọn lựa sẽ bàn giao sản phẩm không hoàn hảo 100% hoặc bàn giao sản phẩm trễ hạn, luôn luôn chọn cái sau.

Bàn càng trễ hạn nhiều dự án, mức độ nghiêm trọng của việc đó với bạn càng giảm đi. Và khi bạn trở nên vô cảm với việc trễ hạn, thời điểm bàn giao cũng giống như việc bạn tìm đến điểm đầu của một vòng tròn và buông xuôi với năng suất lao động của mình.

Triệt tiêu năng suất lao động thật dễ

Tôi biết 5 lời khuyên trên là hơi nhiều nhưng đừng quá lo lắng về chúng.

Khi bạn bắt đầu thực hiện theo, chúng sẽ tự động đến với bạn một cách tự nhiên.

Thực tế bạn có lẽ đã thực hiện nhiều những việc như trên mà không hay biết gì về chúng. Nhưng cũng đừng lo lắng về điều đó, bạn luôn luôn có cơ hội khám phá ra chúng vào ngày hôm sau.