Lời khuyên cho các lập trình viên phần mềm mới vào nghề đã đọc hết những bài tư vấn khác
(buttondown.email)- Ở giai đoạn đầu sự nghiệp, ngay cả lời khuyên từ các lập trình viên nổi tiếng cũng không nên làm theo y nguyên, mà trước hết cần cân nhắc xem có phù hợp với hoàn cảnh của mình hay không; nhiều nhận định trong lĩnh vực phần mềm không có nhiều bằng chứng chắc chắn
- Nếu thích một ý tưởng nào đó, bạn có thể tự mình thử, nhưng việc trải qua thử-sai trong phạm vi không gây cản trở đồng nghiệp là một phần của quá trình học tập
Debugging: The 9 Rulesđược khuyến nghị như một sách nhập môn dễ đọc về năng lực gỡ lỗi, phần mà các sách cho người mới thường bỏ trống- “Cách làm đúng” hay “best practice” thường xuất phát từ những ca thất bại cụ thể và các con đường lịch sử, nên cần phân biệt giữa bản thân kỹ thuật và cách nó được truyền bá
- Nếu sớm tiếp xúc với các tính năng ẩn của công cụ, công việc của các bộ phận khác và nhiều kiểu lập trình khác nhau, bạn sẽ dễ tìm được công việc phần mềm phù hợp với mình hơn
Thái độ khi tiếp nhận lời khuyên
- Những lời khuyên dành cho lập trình viên được đọc rộng rãi thường lan truyền không phải vì tác giả là lập trình viên xuất sắc, mà vì họ viết hay
- Không cần tự động bác bỏ mọi lời khuyên, nhưng cần cân nhắc cẩn thận xem nó áp dụng vào hoàn cảnh của mình như thế nào
- Nên thận trọng với các tuyên bố về “chân lý khách quan” trong phần mềm; không có nhiều nội dung được nghiên cứu khoa học, và kết quả nghiên cứu nhìn chung cũng không có kết luận rõ ràng
- Không cần quá lo lắng rằng mình sẽ học phải “điều sai”
- Nếu bạn thích ý tưởng của ai đó, bạn có thể tự thử
- Miễn là không chủ động gây cản trở đồng nghiệp, thì ngay cả khi sau này nhìn lại và nghĩ đáng lẽ nên làm khác đi, rốt cuộc điều đó vẫn có thể dẫn đến học hỏi
- Debugging: The 9 Rules là một cuốn sách được khuyến nghị cho lập trình viên mới
- Dễ đọc, và đề cập đến một kỹ năng quan trọng là gỡ lỗi, điều mà các sách “lập trình viên mới” khác hầu như không nói tới
- Bạn cũng có thể mượn ở thư viện hoặc đề nghị công ty mua
Giới hạn của “cách làm đúng” và best practice
- Đến một lúc nào đó, bạn có thể phát hiện ra “Right Way” trong lập trình và tin chắc rằng nếu mọi người đều làm theo cách đó thì lĩnh vực này sẽ tốt hơn
- Ví dụ được nhắc đến gồm phát triển hướng kiểm thử, lập trình hàm, Lisp, các phương pháp hình thức
- Khó tránh khỏi việc bị cuốn vào một cách như vậy, và đó có thể là một trải nghiệm dễ chịu, nhưng điều quan trọng là đừng biến danh tính của mình thành “Right Way Guy”
- Theo thời gian, bạn sẽ học được rằng dù theo cách nào thì lập trình vẫn có thể bực bội và lộn xộn, và người ta vẫn có thể tạo ra phần mềm tuyệt vời mà không dùng cách đó
- Khi biết nhiều “Right Way”, bạn có thể trộn chúng cho phù hợp với vấn đề
- “Right Way” đầu tiên bạn gặp thường có khả năng đến từ một người hoàn toàn say mê cách đó
- Về sau đừng trách người đó quá nhiều; tốt hơn là đừng nhầm lẫn giữa kỹ thuật thực sự và cách người đó quảng bá nó
- Nhiều ý tưởng cần được điều chỉnh ở một mức nào đó để dùng cùng các ý tưởng khác, thay vì giữ nguyên dạng thuần túy
- Như Julia Evans nói, “đằng sau mọi best practice đều có một câu chuyện kinh hoàng”
- Nếu có một best practice mà bạn không hiểu, bạn có thể tìm câu chuyện thất bại đã sinh ra nó
- Nếu câu chuyện thất bại đó không liên quan đến hoàn cảnh của bạn, bạn hoàn toàn có thể chọn cách khác
- Nhiều best practice và quy ước mang tính phụ thuộc đường đi
- Bạn làm theo vì mentor đã làm vậy, và mentor đó cũng làm theo vì mentor trước đó đã làm vậy
- Một cách làm được sinh ra để giải quyết vấn đề trong quá khứ có thể hiện nay ít liên quan hơn
- Những quy ước nghe như lời giải thích hợp lý được nghĩ ra sau sự việc có thể đúng là như vậy; nếu tìm hiểu, bạn có thể lần ngược quá trình hình thành của chúng
Cách mở rộng cảm giác thực chiến
- Đi dạo được gợi ý như một thói quen giúp sắp xếp suy nghĩ
- Phần lớn công cụ bạn dùng đều có chiều sâu ẩn bên trong
- Bạn không cần học mọi công cụ như ngôn ngữ lập trình, Git, JIRA đến trình độ chuyên gia
- Tuy vậy, nên dành khoảng 5–10 phút để tìm hiểu xem chúng còn làm được gì nữa
- Trò chuyện với người ở các bộ phận khác trong công ty sẽ mở rộng hiểu biết về công việc
- Bạn có thể nói chuyện với hỗ trợ, bộ phận am hiểu domain kinh doanh, bán hàng, v.v.
- Nếu có thời gian và thấy dễ mở lời, cũng nên thử đi theo quan sát công việc của họ
- Ở giai đoạn đầu sự nghiệp, nếu có thể, nên trải nghiệm nhiều kiểu lập trình khác nhau
- Không nhất thiết phải đổi việc; hầu hết công ty đều làm nhiều kiểu lập trình cùng lúc
- Nếu là công ty phát triển web, bạn có thể thử frontend, backend, vận hành, công việc cơ sở dữ liệu, v.v.
- Điều này cũng giúp học hỏi, nhưng quan trọng hơn là tăng khả năng tìm được loại công việc phần mềm mà bạn thật sự yêu thích
- Có một ví dụ cá nhân rằng khi công việc đầu tiên là frontend thì rất vất vả, nhưng sau đó chuyển sang backend thì hạnh phúc hơn
- Vì lĩnh vực phần mềm luôn thay đổi, lời khuyên đừng bị cuốn theo trào lưu framework mà hãy tập trung vào năng lực nền tảng là có lý do
- Nhờ internet, mã nguồn mở, hội nghị, v.v., thông tin trong lĩnh vực phần mềm lan truyền rất nhanh
- Rào cản chia sẻ ý tưởng thấp, nên ngay cả một dự án cá nhân chỉ một người dùng cũng có thể trông như được nhiều người biết đến
- Trong số các công nghệ bạn nghe thấy, nhiều thứ có thể có tập người dùng nhỏ và không được áp dụng rộng rãi
- Nếu rất hứng thú, bạn có thể trở thành early adopter, nhưng nếu không thì chờ vài năm để xem nó có thật sự trụ lại hay không cũng không sao
- Không ai có thể dự đoán tương lai, và hiện tại cũng là một kết quả từng khó dự đoán
- Cần làm điều tốt nhất có thể, sống phù hợp với giá trị của mình và tận hưởng quá trình
1 bình luận
Ý kiến trên Hacker News
Gần đây tôi làm một dự án sở thích với một lập trình viên junior và một lập trình viên “ít junior hơn”, cả hai đều thuộc kiểu ám ảnh với “cách làm đúng”
Với một bot Discord + mã Rust khoảng 300 dòng mà chỉ chúng tôi chạy, họ đòi tài liệu hóa đầy đủ, VM riêng cho QA và “vận hành”, triển khai bằng systemd, hệ thống template cho vài chuỗi, thậm chí một lớp ORM cho bốn truy vấn SQL
Dự án nhiều lắm cũng chỉ khoảng 10 người dùng, mà đó mới chỉ là một nửa yêu cầu của bản phát hành “0.3”; họ còn đang lên kế hoạch thiết kế quá đà hơn nữa nên tôi đã rút khỏi dự án đó
Hồi mới lập trình, tôi cũng từng là người như vậy trong vài năm, nhưng rồi tôi học ra rằng ngoài best practice hay code style, khoa học máy tính còn có nhiều thứ sâu hơn rất nhiều, và cuối cùng điều quan trọng là code chạy được
Ý là dành sự chú ý mất cân đối cho những chi tiết tầm thường thay vì vấn đề cốt lõi; có một phép ví von về hội đồng phê duyệt nhà máy điện hạt nhân lại bỏ qua nhà máy điện mà chỉ bàn màu của nhà để xe đạp bên cạnh
Trong trường hợp này cũng vậy, việc tập trung vào tách VM QA/vận hành, triển khai systemd, template cho vài chuỗi và ORM cho vài câu SQL trong một dự án quy mô 10 người dùng trông đúng kiểu luật về sự tầm thường
Những phần này đặc biệt dễ để lập trình viên junior hiểu và tranh luận, nên họ càng dễ chen vào nhiều hơn, trong khi các tính năng cốt lõi khó hơn lại dễ bị sao nhãng
Tuy vậy, tôi không nghĩ việc tài liệu hóa đúng các phần có ý nghĩa của dự án là sa đà vào chuyện vụn vặt
Những việc như viết unit systemd hay dùng ORM không tốn nhiều thời gian như ta tưởng, nhưng về sau khi ai đó xem lại hoặc người khác muốn đóng góp thì khá hữu ích
Làm khi bối cảnh vẫn còn trong đầu thì dễ hơn, còn sau khi dự án lớn lên thì các việc lặt vặt kiểu này hầu như chẳng bao giờ được xử lý
Vì là dự án sở thích, có thể họ còn muốn làm cho bài bản để học công cụ và có cảm giác thỏa mãn
Đầu phim có cảnh họ cần mua một router 50 đô la; khi một người đề xuất thử sửa router hiện có, những người khác gần như đáp “thử rồi” trước khi anh ta nói hết câu
Cảnh đó cho thấy họ hiểu nhau quá rõ và dành nhiều thời gian bên nhau đến mức gần như đọc được suy nghĩ của nhau
Nhưng khi ai đó nói “yes” cho việc mua router mới, một người khác đáp rằng cần phải nói “aye”
Tức là quy tắc về từ phải dùng trong biểu quyết ra quyết định của nghề tay trái này cực kỳ nghiêm ngặt; việc họ thân đến mức có thể nói nốt câu của nhau, hay đó chỉ là router 50 đô la, hay thu nhập từ nghề tay trái chẳng đáng kể đều không quan trọng
Quy tắc yêu cầu phải nói aye
Một số người ám ảnh với “cách làm đúng” giống như những người đã thành công nhờ sao chép kiến thức được lưu trong trí tuệ tập thể xã hội, nhưng lại không thật sự biết chuyện gì đang diễn ra trong đầu mình
Lợi thế là họ thừa hưởng các phương pháp đã được kiểm chứng thay vì phải vất vả tự khám phá, nhưng điểm yếu là họ không hiểu theo nghĩa đen những tình huống mà cách đó sẽ dẫn tới thất bại
Trong phần bình luận của đạo diễn, ông nói cảnh này được cố ý đặt vào để cho thấy một số nhân vật coi quy tắc quá nghiêm túc, còn một số khác lại không coi đủ nghiêm túc
Lý do họ khuyên người khác làm theo những thực hành kiểu sùng bái hàng hóa này có lẽ cũng tương tự. Càng nhiều người làm theo, khi thực hành đó thất bại thảm hại, khả năng người thất bại không phải là chính họ càng cao
Dạo này tôi thấy những trường hợp như vậy quá thường xuyên, và tôi gọi họ là junior thông minh. Không quan trọng họ có 1 năm hay 20 năm kinh nghiệm
Junior thông minh biết hầu hết các design pattern và cũng đã đọc Mythical Man-Month, nhưng vì muốn thử công nghệ, ngôn ngữ, framework mới, họ cầm chiếc búa mới sáng loáng chạy khắp nơi tìm thứ trông như cái đinh
Rồi họ đưa ra những quyết định kỳ quặc vì không hiểu sức mạnh mà một cơ sở dữ liệu cũ được tối ưu tốt có thể mang lại
Với 20 năm kinh nghiệm, tôi đã thấy nhiều dự án như vậy kết thúc ra sao sau 5–10 năm, khi hơn một nửa đội ban đầu đã rời đi; tôi giữ lại phần thật sự có giá trị và cắt bỏ một nửa vô dụng
Chúng tôi không điều hành một nhà trẻ cho lập trình viên muốn vui bằng mọi giá, mà làm việc cho một doanh nghiệp trả tiền và kỳ vọng kết quả ổn định, tương đối nhanh
Việc thử thứ mới chỉ để dùng công nghệ tối tân hoặc tránh nhàm chán về lâu dài thường làm hỏng nhiều hơn là sửa
Cần đưa vào những công nghệ mà cả đội có thể hiểu và thành thạo, chứ không phải công nghệ chỉ một siêu sao đã chán việc biết dùng
Nếu muốn nhồi thật nhiều mục kỹ năng vào CV thì hãy làm ở những công ty như vậy, mà những nơi đó cũng có cái hay riêng
Nhưng dù sao những người này thường không ở lại lâu, nên giá trị gia tăng tổng thể cũng đáng nghi. Với ai đó thì có thể nhàm chán, nhưng tôi gọi đây là cách làm của người lành nghề
Nếu mục tiêu của side project là khiến các công ty xem GitHub của mình, thì trông như vậy cũng có vẻ thuyết phục hơn
Tài liệu hóa cực kỳ quan trọng. Tôi có vài dự án khá đơn giản dưới 300 dòng, gồm bot và web scraper, nhưng vì không tài liệu hóa nên giờ không chạy được nữa
Chiếc Raspberry Pi từng chạy chúng đã chết, và tôi bế tắc không biết phải sửa framebuffer ảo headless ra sao, hay debug một lỗi không rõ mà tìm kiếm cũng không ra kết quả hữu ích thế nào
Nếu khi đó tôi đã container hóa hoặc ít nhất tài liệu hóa quy trình thiết lập, thì đã không gặp vấn đề này
Đây là một bài viết hay và tôi mong nhiều người đọc hơn
Sau 15 năm làm trong lĩnh vực phần mềm, đặc biệt là quản lý dữ liệu, tôi đã học được đúng điều này
Kesamutti Sutta, mà tôi biết từ bối cảnh Phật giáo Theravada, cũng giúp ích rất nhiều
Nội dung là đừng cứ thế làm theo chỉ vì đã nghe đi nghe lại, vì đó là truyền thống, vì là lời đồn, vì có trong kinh điển, vì suy đoán hay tiên đề hay lập luận nghe có vẻ hợp lý, vì thiên kiến với một quan niệm đã nghĩ tới từ lâu, vì ai đó trông có vẻ có năng lực, hoặc vì đó là lời của thầy mình
Lời khuyên rằng hãy chấp nhận khi tự mình biết “điều này là thiện, không đáng bị chê trách, được người có trí khen ngợi, và nếu thực hành thì dẫn đến lợi ích và hạnh phúc” đã rất hữu ích trong cuộc sống của tôi, ngay cả sau khi tôi trở thành người vô thần từ thời trung học
Cũng có ý kiến cho rằng ai đó đã bóp méo bản dịch để nó mang vẻ duy lý hơn
Nếu đúng thì thật đáng tiếc. Vì tôi đã muốn tin rằng Buddha là một người “giác ngộ” theo cách như vậy
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
Tôi đồng cảm với phần nói rằng đừng quá lo mình đã “bị lừa” hay “học nhầm thứ sai”
Tôi có học TDD khi nó đang thịnh hành không? Có. Giờ tôi có dùng TDD không? Không. Nhưng TDD có dạy tôi cách viết code tốt hơn không? Có
Các ngôn ngữ mà tôi không còn dùng trong công việc cũng vậy. Mọi thứ đều dạy ta điều gì đó
Bạn không thể tìm được điểm trung dung tốt nếu chưa từng đi hơi quá về cả hai phía
Nếu đã có code và muốn mở rộng nó, thì viết vài test quanh cách sử dụng là hợp lý
Nếu chưa có code nhưng đã có cấu trúc trong đầu và có thể tách phần cần xây trước với phần cần test, thì lúc đó cũng có ý nghĩa
Nó không phải TDD theo nghĩa thuần túy, mà gần với phát triển được hỗ trợ bởi test hơn, nhưng vẫn là tận dụng tinh thần của TDD
Học cả những thứ dở cũng là một phần lớn trong việc hiểu cách tiếp cận nào tốt hơn hay tệ hơn
Không có ý nói bản thân TDD là xấu, nhưng nếu bám chặt quá mức thì nó có thể trở nên xấu
Rốt cuộc điều này cũng nối với quan niệm phổ biến rằng “sai lầm là con đường học hỏi”
Những hướng dẫn và nguyên tắc kiểu này nhìn chung nên biết, nhưng vấn đề xuất hiện khi người ta tiếp nhận chúng như tôn giáo
Trong ngành của chúng ta, những người giáo điều thật sự là một nỗi phiền toái
Ngắn gọn, đúng chỗ và rất dễ cảm nhận
Bài viết và lời khuyên hay
Sau cùng, khi thời kỳ trăng mật kết thúc, bạn sẽ học được rằng dù dùng bất kỳ “cách đúng” nào, lập trình vẫn bực bội và lộn xộn, và rằng người ta vẫn có thể tạo ra phần mềm tuyệt vời mà không cần tuân theo cách đó
Theo thời gian, bạn sẽ học thêm hàng chục “cách đúng” khác và trộn chúng cho phù hợp với vấn đề
Tuy nhiên trong vài năm gần đây, có vẻ nhiều lập trình viên bị mắc kẹt trong nỗi ám ảnh về cách đúng, khiến họ không mở rộng được kiến thức và góc nhìn
Nếu đúng thì thật đáng buồn, và tôi không rõ nguyên nhân là gì
Có thể vì khả năng tập trung ngày nay ngắn hơn khiến việc mở rộng kiến thức một cách hiệu quả trở nên khó khăn, và cũng có thể vì vị trí hiện tại đã quá thoải mái
Hoặc có thể vì phần thưởng cho việc chỉ học một framework cụ thể là quá lớn, còn động lực để học kiến thức nền tảng về cách nó vận hành bên trong lại quá ít
Vì vậy họ không có thời gian rút ra bài học từ công việc hiện tại, và rất có thể đến lúc bài học ấy thấm vào thì họ đã rời đi rồi
Đồng thời họ cũng không có dư địa để không tập trung vào công nghệ trào lưu mới
Dòng chảy này cản trở sự trưởng thành rất nhiều
Lời khuyên 1 xu của tôi là thế này. Trạng thái là kẻ thù. Cần giảm trạng thái ở mọi nơi có thể
Không chỉ là trạng thái trong code, mà còn gồm số lượng thứ bạn phải giữ trong trí nhớ ngắn hạn để làm việc, và cả các chi tiết riêng của từng dự án mà bạn phải nhớ
Trạng thái là kẻ thù. Nếu có thể suy ra từ các nguyên lý đầu tiên, hãy luôn cố làm như vậy
Một phần trong số này vượt ra ngoài lời khuyên chỉ dành cho lập trình viên
Mục đầu tiên đáng để mọi người suy ngẫm. Nhiều tác giả và người viết tiểu luận được đọc không phải vì họ là chuyên gia về chủ đề đó, mà vì họ viết hay
Cũng nên đi dạo
Nên thử nhiều loại công việc khác nhau và học cả những vai trò khác trong công ty
Đặc biệt ở các công ty lớn, việc bạn làm có thể là thứ ở đâu đó phải được sửa lại hoặc xử lý vòng qua, và nếu bạn thay đổi thì mọi người có thể dễ dàng hơn
Mục đầu tiên cũng là lý do nên hoài nghi những gì học được từ các dịch vụ chia sẻ video như YouTube
Nếu ai đó nói một cách đáng tin và trình bày ý tưởng chuyên nghiệp, mọi người sẽ nghiêm túc tiếp nhận ý tưởng đó dù nó có khiếm khuyết
Trong một thế giới nơi đã lộ ra rằng một số “người viết tiểu luận” thực chất chỉ ở mức đọc lại các bài Wikipedia và bài đăng Reddit, ta cần có thái độ tách vẻ thuyết phục của cách diễn đạt khỏi độ chính xác
Tôi cũng muốn mở rộng thêm mục 10. Khi trò chuyện với những người liên quan, bạn sẽ thấy rõ hơn vấn đề mà phần mềm hoặc công việc phát triển đang cố giải quyết, và cũng có thể tìm ra những điểm đau mà bản thân chưa nhìn thấy
Trừ một số rất ít ngoại lệ, phần mềm không được viết vì chính nó, mà để giải quyết vấn đề
Ở đâu đó trên Internet hoặc trong quá trình huấn luyện, nó có thể đã đọc một câu trả lời “đúng”, rồi lặp lại một cách nghe có vẻ hợp lý mà không xét xem nó có thật sự đúng hay không
Tôi thích cuốn sách về debugging được đề xuất trong bài đến mức đã mua nhiều cuốn để tặng
Tôi đã tặng cho bạn bè, thực tập sinh, nhà khoa học dữ liệu, thậm chí cả lãnh đạo, và tất cả những ai đọc đều cảm ơn
Sách chứa một vài kỹ thuật đơn giản tốt để giải quyết vấn đề trong các hệ thống kỹ thuật lớn, nên gần như ai cũng thấy hữu ích
Dễ đọc, thú vị, và có nhiều “chuyện chiến trường” thêm màu sắc và bối cảnh cho những lời khuyên vốn có thể khô khan
https://debuggingrules.com/
Câu “người ta lắng nghe tôi không phải vì tôi là một lập trình viên giỏi, mà vì tôi là người viết giỏi” không chỉ có nghĩa là cần cảnh giác khi đọc nội dung của những người viết hay, mà còn áp dụng cho cả cách chúng ta tiếp cận công việc
Viết tốt thì nhìn chung khả năng làm việc với người khác cũng tốt hơn
Với lập trình viên phần mềm, viết lách và giao tiếp là công việc cốt lõi
Nếu bạn là người mới, nên thử viết lại những khó khăn đã gặp, các thử nghiệm và quá trình suy nghĩ của mình
Nếu có thể, cũng nên viết essay. Đây sẽ là một kỹ năng thật sự hữu ích ở giai đoạn sau của sự nghiệp
Có một câu rất khó giải thích đúng cho người mới: “Công việc của bạn không phải là viết code”
Chúng ta dùng code như một công cụ để giải quyết vấn đề
Code là phương tiện để đạt mục tiêu, không phải bản thân mục tiêu
Nếu code chỉ vì bản thân code, bạn sẽ tạo ra kết quả sai
Cần tập trung vào giải quyết vấn đề, và nếu bạn không chắc code của mình đang giải quyết vấn đề gì, hãy dừng viết code và tìm hiểu điều đó trước
Tùy công ty, đó có thể là email
Trả lời câu hỏi, cộng tác, tác động đến định hướng của nhóm và tổ chức có thể tạo cảm giác như đó là công việc, nhưng giao tiếp cũng giống như code: là công cụ để tạo ra thứ hữu ích, chứ bản thân nó không phải là thứ hữu ích
Phần lớn code, kể cả code được viết như “code vì code”, cũng có thể xem là đang giải quyết một vấn đề nào đó
Nhiều lập trình viên ít nhất cũng biết điều đó trong tiềm thức, nên mới viết những đoạn code như vậy
Vấn đề thật sự nằm ở chỗ những người khác, chẳng hạn phía kinh doanh mặc vest, muốn đoạn code đó giải quyết một vấn đề khác
Tuy nhiên, code đó phải là code đúng
Nói tổng quát hơn, có thể mô tả là “áp dụng hệ thống phần mềm để giải quyết vấn đề kinh doanh”
Khi nói như vậy với junior, họ sẽ tập trung vào nhu cầu kinh doanh và có thể đánh giá một cách phản biện lời của MBA, quản lý hay PM để làm đúng việc cần làm
Nhưng việc có một phần mềm để bán cho VC tự nó cũng có giá trị
Vì vậy, đôi khi bạn thật sự được trả tiền để viết code