Lập trình phần lớn là quá trình suy nghĩ (2014)
(agileotter.blogspot.com)- Sản phẩm hiện ra dưới dạng code không phải toàn bộ công việc trong ngày, mà gần với kết quả tinh lọc còn lại sau khi đọc, nghiên cứu, gỡ lỗi, kiểm chứng và ra quyết định
- Trong một câu hỏi không chính thức đặt ra cho các lập trình viên suốt nhiều năm, câu trả lời phổ biến nhất cho việc chỉ nhìn diff rồi nhập lại một thay đổi mất 6 giờ là khoảng 30 phút
- Tỷ lệ này không dựa trên nghiên cứu khoa học mà dựa trên khảo sát và quan sát diff, nhưng trở thành một chuẩn thực dụng để nhìn lập trình là 1/12 hành động, 11/12 suy nghĩ
- Phát triển phần mềm gần với công việc thiết kế hơn là sản xuất kiểu nhà máy; sau thiết kế đầu tiên, việc sao chép được máy móc thực hiện với chi phí biên gần như bằng 0
- Nếu quản lý và quy trình được tối ưu theo hướng tăng thời gian gõ phím, chúng sẽ tạo ra hiệu ứng lệch hướng; môi trường và cách cộng tác giúp nâng cao chất lượng suy nghĩ quan trọng hơn
Mất bao lâu để nhập lại công việc 6 giờ
- Giả định là vào một ngày thuận lợi, gần như không có họp hành hay gián đoạn, lập trình viên đã thực hiện 6 giờ lập trình nghiêm túc
- Trước khi tan làm, họ in diff ra, nhưng qua đêm hệ thống quản lý phiên bản bị hỏng, được khôi phục về bản sao lưu ngày hôm trước và công việc cả ngày biến mất
- Trọng tâm câu hỏi là: khi lập trình viên nhận được diff đó, họ mất bao lâu để nhập lại 6 giờ công việc ấy vào codebase
- Suốt nhiều năm, câu hỏi này được đặt ra tại các hội nghị, với khách hàng, đồng nghiệp và cả những lập trình viên mới gặp; câu trả lời phổ biến nhất là khoảng 30 phút
- 6 giờ chứa 12 lần 30 phút, nên quan sát này dẫn đến cách diễn đạt rằng lập trình là 1/12 hành động, 11/12 suy nghĩ
Bản chất và giới hạn của tỷ lệ này
- Con số này không đến từ một nghiên cứu khoa học chặt chẽ, cũng không phải một khảo sát chính thức có ghi chép đầy đủ
- Mục tiêu không phải tìm ra quy luật thống kê hay toán học của hoạt động lập trình, mà là tìm một câu trả lời hợp lý cho một câu hỏi hợp lý
- Vì không công ty nào muốn thực sự xóa toàn bộ công việc trong ngày để chứng minh hay bác bỏ thí nghiệm, cơ sở chỉ dừng ở ước lượng và quan sát diff hằng ngày
- Sau khi xem nhiều changelog và diff, lượng thay đổi thuần túy của một ngày tốt thường có vẻ vào khoảng 30 phút ± 10 phút
Gõ phím không phải nút thắt cổ chai
- Câu “gõ phím không phải nút thắt cổ chai” đã được lặp lại từ lâu trên sticker và mạng xã hội
- Với một số lập trình viên, bản thân việc gõ phím có thể là nút thắt, nhưng cốt lõi của việc tạo code nhanh thường không nằm ở tốc độ gõ hay mức độ thành thạo công cụ
- Trong một bài dài trên Quora với câu hỏi “How do programmers code so quickly?”, một người trả lời đã nhắc đến trí nhớ cơ bắp, độ thành thạo công cụ, khả năng gỡ lỗi, kỹ năng gõ phím và khả năng tìm kiếm thông tin
- Tuy nhiên, trong việc tạo code nhanh, gõ phím và công cụ gần như chỉ là phương tiện hỗ trợ; thời gian phán đoán cần làm gì chiếm tỷ trọng lớn hơn
Khác biệt giữa nhà máy phần mềm và công việc thiết kế
- Trong sản xuất sản phẩm vật lý, phần lớn công việc nhìn thấy được là chuyển động: lăn, dập, ép, phay, bố trí và lắp ráp thép trông giống như công việc
- Nhà máy hiện đại thực hiện các chuyển động chính xác dựa trên mô hình trừu tượng, tức dữ liệu, giống như máy CNC; con người quản lý máy móc thay vì trực tiếp thao tác thủ công trên chúng
- Ở phía phần mềm, nhà máy đã hoàn thiện sẵn; người dùng nhấn nút “copy” hoặc “download” để nhận một bit-perfect copy
- Khi mô hình đầu tiên đã tồn tại, chi phí biên của các bản sao sau đó gần như bằng 0; phần mềm là hàng hóa trí tuệ
- Uncle Bob Martin từng nói rằng phát triển phần mềm không phải công việc chế tạo mà là công việc thiết kế, và việc sao chép sau thiết kế đầu tiên được máy móc thực hiện với chi phí gần như bằng 0
- Lập trình viên, tester, PO, Scrum Master và quản lý phần mềm thiết kế mô hình dữ liệu làm nền tảng cho các bản sao mà khách hàng và cộng đồng sẽ sử dụng
Công việc trí tuệ khó quan sát
- Lối tư duy thời đại công nghiệp muốn nhìn phát triển phần mềm như một nhà máy, và lập trình viên chịu áp lực phải khiến nó trông giống lao động vật lý dù điều đó gây hại cho quy trình thực tế
- Hoạt động trí tuệ khó quan sát và đo lường; một ý tưởng hoàn thành 80% không có hình dạng vật lý
- Có thể có thí nghiệm, code proof-of-concept, ghi chú, nhưng chúng không thể cho thấy tỷ lệ hoàn thành chính xác như công việc vật lý
- Một chiếc ghế đang được chế tạo ở mốc 50% trông đại khái như đã hoàn thành 50%, và khi hoàn tất thì trông như thành phẩm
- Thiết kế ghế có thể chưa tồn tại trên giấy cho đến khi tiến triển hơn 70%, và trước khi thiết kế xong, cũng khó biết liệu nó có thực sự hoàn thành 70% hay không
Vì sao thay đổi 30 phút lại nghĩa là 6 giờ làm việc
- 30 phút là thời gian tái tạo kết quả tinh lọc của phần code đã được viết, xóa, chỉnh sửa và làm lại suốt cả ngày, chứ không phải toàn bộ nỗ lực đã bỏ ra
- Lập trình viên liên tục đánh giá và đặt giả thuyết trong khi viết code để tránh lỗi và lỗ hổng bảo mật
- Văn bản code chỉ chứa chương trình cần làm gì khi chạy; phần lớn không lưu lại vì sao chọn cách đó, nó ảnh hưởng thế nào đến các phần khác của hệ thống, hay những lỗi nào đã được đưa vào rồi loại bỏ
- Phần lớn công việc thực tế không nằm ở bản thân thay đổi, mà ở việc quyết định cách thay đổi; vì phải hiểu code hiện có, các nguồn có code lộn xộn hoặc thiết kế không lộ rõ sẽ tốn nhiều thời gian hơn
- Sản phẩm của lập trình viên được tích hợp vào codebase dùng chung nên có bối cảnh xã hội; việc giúp lập trình viên khác, tester và người vận hành hiểu công việc cũng tạo ra chi phí và lợi ích không hiện rõ trong code
Số dòng code không phải thước đo tiến độ
- 6 giờ làm việc trí tuệ có thể qua các bước đọc, nghiên cứu, quyết định, xác nhận, kiểm chứng và rà soát để biến thành 30 phút thay đổi thuần túy trong codebase
- Điều này không có nghĩa là số dòng code được thêm vào; có khi đã sửa lỗi và thêm tính năng nhưng số dòng code cuối tuần lại ít hơn đầu tuần
- Từng có trường hợp nhiều tuần ghi nhận số dòng code âm và gặp vấn đề, trong khi không biết rằng quản lý cấp cao của đội đang báo cáo SLOC như một chỉ số tiến độ
- Việc lập trình viên thực sự làm gần với đọc, học, hiểu, suy đoán, nghiên cứu, gỡ lỗi, kiểm thử, biên dịch, chạy, lập giả thuyết và phản chứng
- Rốt cuộc, nhiều công việc vẫn là suy nghĩ và ra quyết định
Viết ít hơn có thể là phát triển nhanh hơn
- Một câu trả lời trên Quora nói rằng có thể thấy các ngón tay di chuyển trên bàn phím, nhưng không thấy thời gian trò chuyện với người dùng, thảo luận vấn đề với đồng nghiệp, nghiên cứu và suy nghĩ
- Một người trả lời khác nói rằng giúp khách hàng loại bỏ những ý tưởng không cần thiết mà họ gọi là “yêu cầu” hoặc “must have” là cách tăng tốc việc chuyển giao giải pháp mạnh nhất
- Một người khác nữa nói rằng lập trình viên xuất sắc hoàn thành hơn 90% công việc bằng cách hiểu yêu cầu và hình dung giải pháp phù hợp trước khi chạm vào bàn phím
- “Biết không viết gì”, “làm ít hơn”, “làm theo các bước nhỏ hơn”, “trước hết nắm rõ cần làm gì” là những câu trả lời xuất hiện lặp đi lặp lại
- Người gõ nhiều hơn hoặc copy-paste nhiều hơn có thể thiếu suy nghĩ và hiểu biết; kết quả là lỗi tăng lên, đồng thời làm tăng gánh nặng để lập trình viên khác hiểu và chỉnh sửa
Quy trình phải được thiết kế cho việc suy nghĩ
- Nếu lập trình là 1/12 hành động và 11/12 suy nghĩ, thì không nên ép mọi người gõ phím trong 11/12 thời gian
- Điều cần thiết là vật liệu, môi trường và quy trình giúp nâng cao chất lượng suy nghĩ
- Làm ngược lại sẽ tối ưu hệ thống cho những hiệu ứng sai lệch
- Năng suất có thể tăng khi ta chủ ý xây dựng hệ thống để cùng suy nghĩ về phần mềm và đưa ra quyết định dễ dàng hơn
- Cần thử nghiệm việc học trong công việc và suy nghĩ về cách tạo ra một hệ thống tối ưu hóa cho tư duy
1 bình luận
Ý kiến Hacker News
Câu trong bài rằng “những lập trình viên thực sự xuất sắc hoàn thành hơn 90% công việc trước khi chạm vào bàn phím” đôi khi đúng, nhưng theo tôi nó bỏ qua thực tế là con người không thể cùng lúc giữ quá nhiều ràng buộc và khái niệm trong đầu
Phạm vi có thể chỉ suy nghĩ thuần túy mà không viết gì ra là rất hạn chế, nên hễ nghĩ ra dù chỉ một cách tiếp cận khả thi thì tôi thường gần như lập tức bắt tay vào gõ phím trước khi gọt giũa nó thành một thiết kế được đặc tả hoàn chỉnh
Khi thử nhiều hướng tiếp cận bằng cách viết mã thật, rất nhiều lần giải pháp ban đầu tôi nghĩ là tốt nhất hóa ra lại tệ hơn hẳn những hướng thoạt nhìn kém hứa hẹn hơn, và không gì phơi bày vấn đề rõ bằng đoạn mã cụ thể đang chạy được
Cuối cùng, lập trình là quá trình vật chất hóa ý tưởng thành mã để kiểm chứng, và cũng như góc nhìn tạo mẫu kiểu vứt bỏ vòng lặp đầu tiên, việc viết mã nên được xem là một phần của quá trình tư duy
Kiểu truyền thuyết rằng ông nghĩ về Git khoảng một tháng rồi hoàn thành nó trong 6 ngày và nghỉ ngày thứ 7, nhưng với đa số mọi người, đặc biệt là tôi, nó giống một quá trình tương tác hơn: nghĩ xem sẽ viết gì, viết, kiểm thử, nghĩ lại, rồi sửa một phần
Rốt cuộc, quá trình đi đến phiên bản cuối cùng hoạt động đúng ở mức nào đó khá giống nghệ thuật
Khi đã có ý tưởng sơ bộ, tôi bắt đầu viết mã từ những phần “dính” nhất, nơi có vẻ dễ phát sinh vấn đề nhất
Không thể lường trước mọi vấn đề nên phải va vào thực tế mới biết, và cách này thường khiến tôi phải bỏ đi khá nhiều công sức đã làm
Tôi hầu như không viết tài liệu cho đến khi cảm thấy khá chắc rằng mình đang đi đúng hướng[0], vì như vậy sẽ giảm bớt trạng thái mà tôi gọi là Concrete Galoshes[1]
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/concrete-galoshes/
Cách duy nhất để có được điều đó là rất nhiều lần viết mã thực chiến và học một cách chủ động, đồng thời cũng có nghĩa là cứ tiếp tục dùng đi dùng lại cùng một stack công nghệ
Tôi thích ở lại với cùng một stack để tập trung vào chính vấn đề cần giải quyết, nhưng “lập trình viên giỏi” theo nghĩa đang nói ở đây có lẽ sẽ khá một chiều trong việc chọn công cụ
Càng lớn tuổi tôi càng thấy quá rõ rằng kiến trúc quan trọng hơn các quyết định vi mô
Phần vi mô thì có thể tối ưu, còn các quyết định vĩ mô thường gần như là vĩnh viễn
Nhiều khi tôi thiết kế mã ngay trong bài kiểm thử và để nó dẫn dắt phần nào việc triển khai
Tôi hình dung kết quả cuối cùng trong đầu, rồi viết test theo hình dạng mà tôi cho là một API tốt cho hệ thống, và bắt đầu từ đó
Kết quả là mã gần như mặc định có thể kiểm thử được, và tôi lặp đi lặp lại Red → Green → Refactor cho đến khi đạt trạng thái hài lòng
Tôi khá tò mò không biết người khác có làm việc theo cách này không
Phần giải thích trong cuốn “The Secret Life of Programs” của Jonathan E. Steinhart là phần tôi thấy hay nhất
Lập trình máy tính gồm hai bước: 1. hiểu vũ trụ 2. giải thích nó cho một đứa trẻ ba tuổi
Ý là bạn không thể viết một chương trình làm thứ mà chính bạn không hiểu, không biết quy tắc chính tả thì không thể làm trình kiểm tra chính tả, và không hiểu vật lý thì khó làm ra một game hành động hay
Muốn trở thành lập trình viên giỏi thì nên học càng nhiều càng tốt về mọi thứ khác, vì lời giải cho vấn đề thường đến từ những nơi không ngờ tới, nên đừng bỏ qua chỉ vì trước mắt có vẻ không liên quan
Bước thứ hai là giải thích điều mình biết cho một cỗ máy nhìn thế giới rất cứng nhắc như một đứa trẻ ba tuổi
Nếu hỏi một đứa trẻ “giày đâu rồi?” thì nó có thể trả lời “ở kia”, tức là có trả lời câu hỏi nhưng không suy ra được ý định thực sự là bạn muốn nó đi giày vào để ra ngoài
Trẻ con lớn lên sẽ học được sự linh hoạt và khả năng suy luận, nhưng máy tính thì giống Peter Pan, không bao giờ lớn lên
Mỗi người và mỗi bài toán sẽ hợp với những cách tư duy khác nhau, và học cách suy nghĩ cũng như lập trình theo nhiều kiểu sẽ cho bạn nhiều công cụ để lựa chọn hơn
Vì vậy tôi không thích những khẳng định kiểu như lập trình nhất định phải diễn ra theo một cách đúng duy nhất
Câu “bạn không thể lập trình thứ mình không hiểu” cũng không đúng hẳn, vì nhiều khi người ta dùng phần mềm để hiểu xem một thứ thực sự hoạt động như thế nào
Ngay cả mô hình vật lý cũng thường không nhắm đến việc trung thành hoàn toàn với thực tại, mà là một quá trình tìm sự cân bằng giữa trải nghiệm người dùng và độ khó của game
Lập trình có thể là một công cụ nhận thức mang tính khám phá, và điều đó không có nghĩa là phần lớn suy nghĩ lúc nào cũng phải đến trước
Tôi thích kiểu người tổng quát và người tự học, nhưng đó không phải bước đầu tiên bắt buộc để trở thành lập trình viên giỏi
Nói trẻ con có một “thế giới quan cứng nhắc” thì không đúng bằng việc nói chúng không phải lúc nào cũng suy ra được các hàm ý xã hội, còn máy tính thì cũng có thể được lập trình để rút ra kết luận logic từ các sự kiện đã biết
Tôi đã giải thích nhiều thứ cho trẻ em ở nhiều độ tuổi khác nhau, kể cả trẻ ba tuổi, nhưng trải nghiệm đó hoàn toàn không giống với lập trình máy tính chút nào
Tôi khá tự tin rằng con số này về cơ bản là đúng, nhưng đến giờ vẫn chưa có công ty nào đồng ý xóa sạch trọn một ngày làm việc để kiểm chứng hay bác bỏ thí nghiệm này
Hồi trước, vào thời tôi còn kiên nhẫn hơn nhiều, có một ông sếp mỗi tối đều xem lại toàn bộ thay đổi mã và xóa những gì ông ta không thích
Ông sếp đó tin rằng version control phức tạp quá mức, nên đã cố biến việc truy cập từ xa vào ổ đĩa mạng ở nhà mình thành chuẩn của công ty
Vì thế thỉnh thoảng hôm sau đi làm thì công việc của ngày trước đã biến mất, và cuối cùng trước khi lén cài SVN, tôi đã trở nên rất thành thạo trong việc làm lại phần việc của ngày hôm trước
Kể cả tính cả việc kiểm thử edge case thì chuyện đó hiếm khi mất hơn một giờ
Ở công ty đầu tiên tôi bị sang chấn kiểu đó, nên sang công ty thứ hai tôi hỏi ngay có kho Git không, và sếp trả lời rằng ông ấy nghĩ Git cũng giống Github và không muốn công khai mã
Về sau công ty bị một công ty lớn hơn mua lại và tôi có quyền truy cập intranet, rồi tìm thấy một instance GitLab trong đó, đưa phần lớn mã mà tôi gần như làm một mình vào đó để quản lý phiên bản và tài liệu hóa, thậm chí còn cài cả GitLab Runner
Tôi cũng tài liệu hóa từng bước cách chạy mã, và khi bị sa thải, họ bảo tôi bàn giao mã nên tôi cho xem toàn bộ và chỉ cách tái hiện, khiến sếp khá ấn tượng và cảm ơn tôi
Có lẽ nhờ cứ làm theo cách mà tôi tin là đúng trong một chỗ làm tồi tệ, tôi cũng để lại được chút ảnh hưởng tích cực
Trước khi tìm thấy GitLab đó, tôi đã tạo một kho Git thô trên network share và push vào đó
Dù có ý tốt, khi quản lý dính vào mã hoặc review thì gần như lúc nào cũng là tổn thất ròng cho cả đội
Đây là bài viết rất hợp để gửi cho người không phải lập trình viên
Cũng như lập trình viên cần domain knowledge, người muốn lấy được điều gì đó từ lập trình viên cũng phải hiểu lập trình ở mức nào đó
Ngay cả một diff rất nhỏ cũng có thể mất hàng giờ vì debug, thiết kế, và học hỏi
Rất dễ thấy sản lượng đầu ra rồi chẳng ấn tượng gì, nhưng việc nghe ai đó giải thích và việc tự mình đập đầu vào tường hàng giờ để tìm ra là hai chuyện hoàn toàn khác nhau
Chẳng hạn mất mấy ngày để tìm ra một commit một dòng giúp cải thiện hiệu năng gấp 100 lần, trong khi đồng thời ở cuộc họp đồng bộ thì phải giải thích vì sao ticket chưa nhúc nhích
Vì vậy domain knowledge mới là cốt lõi
Tôi làm trong lĩnh vực tài chính, ngồi ở trading desk theo dõi nhiều sàn giao dịch và viết mã triển khai đủ loại chiến lược
Nếu không biết doanh nghiệp cần làm gì thì cũng không thể nghĩ ra máy tính cần làm gì
Từ góc nhìn này, việc đào tạo coder như những người phiên dịch là hoàn toàn có lý
Một người bạn làm biên dịch của tôi rất giỏi ngữ pháp và thành ngữ của nhiều ngôn ngữ, và cũng học ngôn ngữ mới giống như chúng ta học ngôn ngữ lập trình mới, nhưng cô ấy cũng dành khá nhiều thời gian để học về ngành dược và giờ dịch tài liệu y tế
Luật sư và kế toán cũng là những nghề có rào cản ngôn ngữ
Khi trở thành chuyên gia, bạn học ngôn ngữ của luật, kế toán, hay phần mềm, nhưng chuyên gia giỏi sẽ trả lời bằng ngôn ngữ kinh doanh chứ không phải ngôn ngữ chuyên môn
Luật sư kém hơn sẽ liệt kê mọi kết quả có thể bằng thuật ngữ pháp lý rồi để bạn tự quyết, còn luật sư giỏi sẽ nói rằng dù có nhiều khả năng nhỏ lẻ, nhưng trên thực tế các khách hàng ở vị thế này đều làm X vì mục tiêu kinh doanh đó
Ở công việc trading đầu tiên của tôi, có một trader đã làm một module Excel VBA để quét qua các mã và chạy quy trình tìm đối tượng giao dịch
Chỉ có một file lưu trên đĩa, không có version control, rồi một người mới vào chỉ sau vài tuần đã lưu đè sau khi xóa sạch toàn bộ module VBA đó, và không có backup cũng chẳng có hỗ trợ nào từ IT
Người trader đó đỏ mặt lên rồi bình tĩnh lại, chấp nhận thực tế rằng lẽ ra phải có backup và cũng phải tự hỏi mình đang làm gì với VBA, rồi ngồi xuống và gõ lại toàn bộ như một màn hình terminal thập niên 80 hiện từng ký tự một
Quan điểm của tôi là để tạo ra lời giải tốt, trước hết phải có kinh nghiệm trong domain đó
Hiện giờ tôi dành phần lớn thời gian để tích lũy trải nghiệm ở domain mới, và đang ngồi cạnh chuyên gia domain để nhanh chóng bổ sung kiến thức cần thiết
Họ thích một software engineer đã làm phần mềm kế toán 15 năm hơn là một người có nền tảng như tôi, và chọn cách để người đó nói chuyện với kế toán viên 30 phút
Cứ lặp đi lặp lại những kiểu chỉ dẫn rằng lập trình nhất định phải vận hành theo một cách nào đó, nhưng giữa các phân ngành thì loại công việc khác nhau rất nhiều
Thay vì cố học hay dạy một phương pháp luận hoàn hảo duy nhất áp dụng cho mọi lĩnh vực, tôi nghĩ tốt hơn là có một túi đồ nghề gồm nhiều cách tiếp cận và phương pháp khác nhau, cùng với hiểu biết về hoàn cảnh mà từng cách phù hợp nhất
Vì vậy người ta sẽ tập trung vào các kỹ năng lập trình tổng quát có thể chuyển đổi giữa các ngành
Phần đầu cuốn PPP của Bjarne[0] cũng có ý tương tự
Đại ý là: “Ngay cả những lập trình viên giỏi nhất, đặc biệt là những người giỏi nhất, cũng dành phần lớn thời gian không phải để viết mã mà để hiểu vấn đề. Việc hiểu vấn đề đòi hỏi thời gian nghiêm túc và thường cần nỗ lực trí tuệ đáng kể. Chính đó là thử thách trí tuệ mà nhiều lập trình viên muốn nói tới khi họ bảo rằng lập trình thú vị.”
Tôi cũng đã mua ấn bản mới[1] từng lên trang nhất gần đây[2]
[0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
[1]: https://www.stroustrup.com/programming.html
[2]: https://news.ycombinator.com/item?id=40086779
Dùng cơ sở dữ liệu nào, ngôn ngữ nào là tốt nhất, có nên cho phép
nulltrong mã và cơ sở dữ liệu hay không, định dạng API, định dạng log, những thứ như vậyChúng không đặc biệt thú vị, và dù đôi khi cần xem xét lại, kiểu lãng phí thời gian này ở ba công ty gần đây nhất tôi từng làm đều giống như những vấn đề lẽ ra phải được giải quyết từ trước
Thực ra, nếu công ty có một lối tư duy mạnh, thì ngay cả khi đáng nghi ngờ, nó vẫn có thể năng suất hơn nhiều
Nếu đã chốt cứng là dùng Perl, MongoDB và CGI, thì tôi nghĩ dù với stack đó tôi vẫn sẽ làm việc năng suất hơn hiện tại
“Lập trình chủ yếu là suy nghĩ” là một trong những câu người ta tự nói với mình như thể đó là chân lý sâu sắc, nhưng với tư cách một quan sát thì nó không mấy hữu ích
Việc lập trình là suy nghĩ cũng đúng theo chính cái nghĩa mà mọi lao động trí óc đều là suy nghĩ
Thiết kế cũng chủ yếu là suy nghĩ, kế toán cũng chủ yếu là suy nghĩ, và quản lý phần lớn cũng là suy nghĩ
Khác biệt có ý nghĩa không nằm ở bản thân việc suy nghĩ mà ở chỗ bạn đang nghĩ về điều gì
Quản lý phải debug các vấn đề về con người, nên cần rất nhiều thời gian với con người, tức là họp
Lập trình viên thì debug các vấn đề của máy tính, nên cần rất nhiều thời gian với máy tính
Ở đây rõ ràng có một sự căng thẳng, và không cực đoan nào là hiệu quả, nên cần tìm ra sự cân bằng để hai bên bớt cản trở công việc của nhau
Tôi không nói đến thứ mã kiểu code golf khó hiểu, mà là ở chỗ mọi thứ bạn tạo ra đều phải được bảo trì
Điều này rõ ràng khác với tiểu thuyết gia, những người có thể ít quan tâm đến bảo trì hơn và quan tâm nhiều hơn tới cảm xúc do văn bản tạo ra
Tối ưu hóa tốt nhất cho câu hỏi “làm sao tạo ra một hệ thống tối ưu hóa tư duy bằng cách thử nghiệm học ngay trong công việc?” là giảm bớt gián đoạn
Theo nghiên cứu, gián đoạn có tác động tàn phá đối với việc lập trình
Sau một lần bị gián đoạn phải mất 10~15 phút để quay lại công việc, và rất có thể một lập trình viên chỉ có được duy nhất một phiên làm việc 2 tiếng không bị gián đoạn trong ngày; thời điểm tệ nhất để ngắt quãng là khi đang chỉnh sửa, tìm kiếm hoặc cố hiểu điều gì đó
Tôi tự hỏi có cách nào để theo dõi và hiển thị các gián đoạn này không
[0] http://blog.ninlabs.com/2013/01/programmer-interrupted/
Thế nhưng lập trình viên lại bị kỳ vọng phải hoàn thành công việc coding kéo dài nhiều tiếng giữa vô số cuộc họp, các cú ping ngắn trên Slack/Zoom và những lần đồng bộ
Vài lần tôi phải làm việc ở nhà vào cuối tuần, tôi nhận ra chất lượng công việc trong một cuối tuần không bị làm phiền tốt hơn hẳn so với ngày thường hỗn loạn
Cách này không hợp với tất cả mọi người hay mọi trường hợp; 20% còn lại là để phối hợp với những người làm việc ban ngày, nhưng năng suất đến từ những phiên làm việc không gián đoạn kéo dài nhiều tiếng thì không thể so sánh được
Nói lại lần nữa, đây không phải cách phù hợp với tất cả mọi người, có lẽ thậm chí không phù hợp với đa số
Ở nhà không ai làm phiền tôi, và ngay cả khi có gián đoạn, tôi cũng tự quyết định khi nào phản hồi
Đặc biệt khi đang xử lý vấn đề khó mà cứ 10~20 phút lại bị ngắt quãng, thì tốt hơn là nên bỏ hẳn; nếu không rất dễ tạo ra thứ mã tệ hại khiến bạn đau đầu về sau
Nó được thiết kế để tôn trọng quyền riêng tư: hệ thống ghi nhận việc bạn đã dùng trình duyệt web, nhưng không ghi URL cụ thể như intranet nội bộ hay fb.com
Thỉnh thoảng sẽ có popup để người dùng tự đánh giá năng suất của mình và để lại bình luận tự do; chúng tôi không gắn dữ liệu đó với ID người dùng để mọi người không nói dối chỉ nhằm trông như siêu nhân
Chúng tôi đã xây dựng frontend Windows và backend Scala, rồi triển khai cho một nhóm tình nguyện viên gồm lập trình viên, luật sư và nhân viên tài chính, nhưng đúng lúc mọi thứ bắt đầu trở nên thú vị sau lần phân tích dữ liệu đầu tiên thì hết thời gian và ngân sách, nên không thể xuất bản thành bài báo
Tôi cũng đã xem các công cụ sẵn có như Rescue Time( https://www.rescuetime.com/
), nhưng kết luận rằng việc lưu dữ liệu năng suất nội bộ lên một đám mây bên ngoài là điều không thể chấp nhận được
Lập trình tốt đôi khi chủ yếu là suy nghĩ, nhưng câu “không kế hoạch nào sống sót sau lần tiếp xúc đầu tiên với kẻ địch” là đúng
Lập trình thực dụng là sự kết hợp cẩn trọng giữa việc lập kế hoạch và đưa mã vào IDE để thử, và sự cân bằng đó phải thay đổi cho phù hợp với từng trường hợp sử dụng
Nếu bạn không viết mã trong nhiều ngày, thì либо bạn đã hiểu hoàn toàn bề mặt của vấn đề, либо bạn chỉ đang đoán mò
Nếu là trường hợp sau thì thực ra cũng chẳng có nhiều thứ để nghĩ đến vậy
Lần thứ hai sẽ nhanh hơn
Tôi đồng ý rằng có thể mở rộng khái niệm suy nghĩ thành “tư duy với sự trợ giúp của công cụ”
Đây là cách diễn đạt lặp lại ý của Programming as Theory Building của Peter Naur, và có ý nghĩa mang tính quyết định đối với việc tôi hiểu bản chất của lập trình
Lập trình không phải là công việc tạo ra bản thân chương trình, mà là công việc hình thành một sự thấu hiểu cụ thể về các sự việc trong thế giới; đoạn mã được xuất ra cuối cùng chỉ đơn thuần là biểu hiện của lý thuyết mà bản thân đã xây dựng