Developer thực dụng - Phần 1 - Triết lý

Đó là cuộc đời của bạn

  • Hãy thay đổi khi bạn thấy không ổn
  • Kiến thức ngành dev không bị giới hạn bởi văn hóa và giới hạn vật lý
  • Ngành developer là một ngành có thể mang lại cơ hội và sự kiểm soát cao nhất cho bạn, hãy chủ động nắm lấy

Lời khuyên thứ 3: Bạn có quyền tự quyết

Con mèo ăn code của tôi rồi

Lòng tin trong đội nhóm

  • Những người trong nhóm cần có thể tin tưởng và dựa vào bạn, cũng như bạn cũng tin tưởng và dựa vào họ.
  • Đó là điều kiện tiên quyết cho việc sáng tạo và làm việc nhóm
  • Ở một môi trường lành mạnh dựa vào lòng tin, bạn có thể yên tâm trình bày những suy nghĩ của mình

Lãnh trách nhiệm

  • Lãnh trách nhiệm cần có sự chủ động chấp nhận của bạn
  • Cần đánh giá tình hình để nhận ra những nguy cơ nằm ngoài tầm của bạn
  • Bạn có quyền không lãnh trách nhiệm cho một vấn đề bất khả thi, hoặc có nguy cơ quá cao
  • Khi đã chấp nhận lãnh tránh nhiệm, thì bạn là người chịu trách nhiệm chính
  • Khi có vấn đề xảy ra, hãy thành thực nhận lỗi và đưa ra những phương án giải quyết
  • Ngưng đổ lỗi, ngưng ngụy biện, nhiệm vụ của bạn là đưa ra những phương án giải quyết
  • Hãy có phương án dự phòng cho những vấn đề nằm ngoài tầm kiểm soát
  • Hãy thử giải thích cho con rubber duck trong tay, xem thử ý kiến của bạn có hợp lý hay ngu ngốc

Lời khuyên thứ 4: Hãy đề ra những phương án, dừng ngụy biện

Thuyết hỗn loạn của phần mềm

  • Sự hỗn loạn trong vũ trụ thường hướng đến cực điểm
  • Tương tự, hỗn loạn trước sau gì cũng xảy ra trong phần mềm, khi hỗn loạn xảy ra, ta gọi đó là tech debt, hoặc software rot
  • Nhiều yếu tố cấu thành: tâm lý, văn hóa trong công việc hay dự án
  • Yếu tố kích hoạt: theo thuyết một cửa sổ hỏng, sự vô vọng có tính lây lan
  • Làm lơ sự hư hỏng dễ củng cố suy nghĩ, rằng, vấn đề đó không thể sửa chữa, không có ai quan tâm nữa, suy nghĩ tiêu cực này sẽ lây lan trong nhóm

Lời khuyên thứ 5: Đừng sống chung với những cửa sổ hỏng

  • Sửa chúng ngay khi phát hiện, nếu không có thời gian, hãy ghim lên bảng trắng
  • Việc bỏ lơ làm gia tăng tốc độ hư hỏng nhanh nhất
  • Nếu ai cũng cho rằng không có thời gian để dọn dẹp, thì hãy chuẩn bị sẵn một xe rác bự, hoặc chuyển qua nơi làm khác, đừng để sự hỗn loạn thắng thế
  • Điều đầu tiên và trước nhất: Đừng làm điều ác
  • Đừng tạo ra tổn thất, hư hại chỉ vì đang giải quyết một vấn đề cấp bách
  • Trong một dự án mà code được viết gọn gàng, sạch sẽ, sẽ tạo ra tâm lý đây là những thứ nên được chăm sóc, không làm tổn hại

Nồi súp đá cuội và con ếch luộc

  • Câu chuyện về món súp đá
  • Bạn thấy được những thay đổi, thiết kế mới là cần thiết, nhưng để được thông qua là điều không dễ dàng. Lúc này, bạn nên làm tốt nhất những gì trong tầm được cho phép, cho mọi người thấy và để họ trầm trồ.
  • Khi đã hứng khởi, bạn sẽ mời chào rằng ‘nếu thêm tính năng abc này thì sẽ hay hơn đó’
  • Đám đông sẽ dễ hưởng ứng theo thành công bước đầu

Lời khuyên thứ 6: Hãy là chất xúc tác cho sự thay đổi

  • Không nên quá chăm chú vào những vấn đề hạn hẹp mà quên mất những thứ xung quanh
  • Liên tục xem xét những thứ đang xảy ra xung quanh mình
  • Tổng hợp những vấn đề nhỏ sẽ bẻ gãy tinh thần và đội nhóm
  • Câu chuyện: nếu bỏ con ếch vào nồi nước sôi, nó sẽ nhảy ra ngay. Nhưng khi bỏ nó vào nồi nước lạnh và đun nóng từ từ, nó sẽ không nhận ra sự thay đổi và từ từ bị luộc chín

Lời khuyên thứ 7: Luôn giữ bức tranh lớn trong đầu

Một chương trình đủ tốt

  • Trong môi trường thực tế: thời gian, công nghệ, những thói quen sẽ gây áp lực khi bạn xây dựng chương trình, nên khó có thể đạt được một chương trình hoàn hảo
  • Bạn có thể đặt nguyên tắc chỉ cần xây dựng một chương trình đủ tốt, tốt cho người dùng, cho những người bảo trì, cho nhẹ tâm trí của bạn
  • Đủ tốt có nghĩa là phải đạt được những yêu cầu của người dùng, vấn đề tốc độ, an toàn, bảo mật được đảm bảo theo tiêu chuẩn
  • Nên ủng hộ việc cho phép người dùng tham gia vào việc quyết định những gì cần hoàn thành một cách đủ tốt, và làm vào khi nào
  • Đối với một sản phẩm mới, sẽ có những giới hạn khác nhau, bộ phận quảng bá sản phẩm sẽ có nhiều những hứa hẹn, người dùng sẽ có những kế hoạch riêng dựa vào ngày ra mắt của sản phẩm, công ty của bạn sẽ có giới hạn về dòng tiền. Nên cần tính đó là những yêu cầu từ người dùng, không nên dành thời gian để xây dựng những chức năng mới hoặc dọn dẹp code trước khi hoàn thành những yêu cầu đó
  • Phạm vi và chất lượng cần được nêu ra trong requirement xây dựng hệ thống

Lời khuyên thứ 8: Chất lượng sản phẩm nên được tính là một requirement

  • Người dùng thường lựa chọn sử dụng một sản phẩm có một vài khiếm khuyết chấp nhận được, thay vì phải chờ thêm 1 năm để có một sản phẩm hoàn hảo
  • Một chương trình ngon lành hôm nay sẽ tốt hơn ảo tưởng cho một chương trình hoàn hảo ở tương lai
  • Tốt hơn bạn nên cho người dùng vọc chương trình của bạn sớm, những phản hồi của họ có thể là kim chỉ nam cho giải pháp của bạn tốt hơn
  • Biết điểm dừng: đừng quá bày vẽ, đừng tinh lọc quá kĩ lưỡng, vì nó có thể làm hỏng một chương trình tốt. Có thể nó không hoàn hảo, và có thể chẳng bao giờ hoàn hảo.

Danh mục tri thức

  • Kiến thức và kinh nghiệm là những tài sản quan trọng
  • Nhưng những điều đó có thể lỗi thời, làm ảnh hưởng đến khách hàng và doanh nghiệp của bạn
  • Nên cần quản lý danh mục tri thức tương tự như việc quản lý danh mục đầu tư
  • Nhà đầu tư nghiêm túc thường đầu tư một cách định kỳ - như một thói quen
  • Đa dạng hóa là chìa khóa cho sự thành công dài hạn
  • Nhà đầu tư thông minh biết cân bằng giữa những danh mục đầu tư phòng thủ và những danh mục có rủi ro cao
  • Mua giá thấp và bán giá cao để sinh lời tốt nhất
  • Danh mục được xem xét và tái cân bằng theo chu kỳ

Đầu tư định kỳ

  • Đầu tư một cách cố định
  • Sắp xếp thời gian và địa điểm, một nơi không ai làm phiền

Đa dạng hóa

  • Bạn biết càng nhiều, bạn càng có giá trị
  • Căn bản nhất: nắm rõ trong lòng bàn tay những công nghệ mà bạn làm việc hằng ngày
  • Công nghệ thay đổi nhanh và liên tục, nên việc biết nhiều công nghệ giúp bạn dễ dàng điều chỉnh cho phù hợp với xu thế
  • Đừng quên những kỹ năng khác ngoài phạm vi kỹ thuật

Quản lý rủi ro

  • Cũng giống như đầu tư, có những công nghệ mang tính an toàn, số khác có nguy cơ cao, nhưng mang lại kết quả cao

Mua thấp, bán cao

  • Học một công nghệ mới nổi trước khi nó trở nên phổ biến sẽ mang cho bạn nguồn lợi cao
  • VD tìm hiểu Java khi nó mới được ra đời và chưa phổ biến là một canh bạc, nhưng những người tiên phong sẽ thu được lợi lớn khi nó đã trở thành tiêu chuẩn trong ngành

Xem xét và tái cân bằng

  • Phần mềm là một ngành năng động, công nghệ bạn biết trước đó một vài tháng, có thể sau đó không còn ai quan tâm đến nó
  • Cần tái cân bằng, bỏ đi những công nghệ không còn sức sống trên thị trường nữa

Nhưng điều quan trọng nhất là:

Lời khuyên thứ 9: Đầu tư định kỳ vào danh mục tri thức của bạn

Những mục tiêu

  • Học một ngôn ngữ mới mỗi năm: một vấn đề, mỗi ngôn ngữ có thể giải quyết một cách khác nhau. Đây là cách để mở rộng tư duy của bạn. Đọc code các phần mềm nguồn mở sẽ giúp bạn rất nhiều trong việc này.
  • Đọc một cuốn sách kỹ thuật mỗi tháng: mặc dù nguồn bài viết và các câu trả lời ngắn rất đa dạng trên mạng, nhưng để có thể hiểu sâu, bạn cần những cuốn sách dài dòng. Hãy tìm đọc những loại sách kỹ thuật liên quan đến dự án của bạn, tạo thói quen đọc một cuốn mỗi tháng. Một khi đã thành thục, hãy chuyển qua học những loại kỹ thuật khác.
  • Và đọc những loại sách khác: nên nhớ rằng máy tính được sử dụng bởi con người, và bạn là người làm thỏa mãn những người đó, nên đây là kỹ năng bạn nên rèn luyện
  • Tham gia vào các lớp học: tìm những khóa học bạn thấy hứng thú xung quanh nơi bạn ở, hoặc trên mạng
  • Tham gia vào nhóm: sự cô lập sẽ chặn đứng con đường sự nghiệp của bạn, hãy tìm hiểu thế giới bên ngoài đang làm gì, và chủ động giao lưu
  • Thử nghiệm bản thân ở những môi trường mới: nếu bạn chỉ làm trên Windows, hãy thử trên những môi trường khác như Linux …
  • Không bỏ lỡ: năng đọc nhưng tin tức công nghệ là một cách để biết được kinh nghiệm của những người khác

Cơ hội học hỏi

  • Khi bạn có một câu hỏi về kỹ thuật và bạn không có câu trả lời chính xác, đừng dừng lại ở đó, hãy đi tìm ra câu trả lời cuối cùng
  • Đừng để thời gian chết, luôn có kế hoạch cho việc học hỏi

Suy nghĩ phản biện

  • Suy nghĩ thấu đáo về những gì bạn nghe hoặc thấy, bảo đảm những gì bạn biết phải là thông tin chính xác, không bị nhào nặn bởi trào lưu hay cá nhân nào đó
  • Ở một thế giới mà hầu hết mọi thứ có thể mua bằng tiền thì bạn hãy cẩn thận với những kết quả tìm kiếm

Lời khuyên thứ 10: Suy nghĩ thấu đáo về những điều bạn nghe và thấy

Một số câu hỏi có thể hỗ trợ cho việc này

  • “Hỏi “Tại sao?” 5 lần” : để biết được nguồn gốc của vấn đề
  • “Điều này làm lợi cho ai?” : nghe có vẻ thô, nhưng lợi ích tài chính có thể là điều cần phải làm rõ
  • “Ngữ cảnh là gì” : cần phải phân tích vấn đề trong ngữ cảnh nó xảy ra, vì một giải pháp cho tất cả thường là không thực tế. Ví dụ như những cuốn sách dạy “best practice”, tốt cho ai ? điều kiện tiên quyết là gì? hậu quả ngắn, dài hạn là gì?
  • “Khi nào và ở đâu thì giải pháp này khả thi?” : trong hoàn cảnh nào thì áp dụng được? có phải là quá trễ / quá sớm để áp dụng? điều gì xảy ra sau đó?
  • Tại sao đây lại là vấn đề: có mô hình nào có thể giải thích

Giao tiếp

  • Điều quan trọng không chỉ ở những điều bạn biết, mà còn là cách bạn truyền tải nó
  • Một ngày làm việc của dev có rất nhiều khoảnh khắc cần phải giao tiếp với khách hàng, đồng nghiệp, trình bày ý tưởng … nên cần phải làm tốt việc này
  • Hãy đối xử với ngôn ngữ bạn dùng để giao tiếp như là một ngôn ngữ lập trình: có DRY không, có dễ dàng thích ứng với sự thay đổi không, có tính tự động hóa …

Lời khuyên thứ 11: Ngôn ngữ giao tiếp cũng như ngôn ngữ lập trình

Hiểu thính giả của bạn

  • Bạn giao tiếp với mục đích là truyền tải những nội dung mà bạn hiểu cho người khác, nên bạn cần hiểu rõ nhu cầu, mối quan tâm, và khả năng của những người nghe bạn nói
  • Cho dù hình thức giao tiếp có thế nào, điều quan trọng là tiếp nhận phản hồi. Hãy chủ động trong việc xin phản hồi.
  • “Ý nghĩa của cuộc trao đổi nằm ở những phản hồi bạn nhận được”

Biết mình nên nói những gì

  • Chuẩn bị cho những gì bạn muốn nói
  • Viết một dàn bài và tự hỏi bản thân: “Nội dung này có truyền tải được những gì tôi muốn nói và họ có thể hiểu được?”. Hãy trui rèn đến khi bạn thỏa mãn được câu hỏi đó
  • Điều này cũng áp dụng cho những cuộc họp, hoặc gặp mặt khách hàng

Chọn thời điểm

  • Ngoài việc hiểu được thính giả của bạn cần nghe gì, cần phải biết được ưu tiên của họ là gì
  • Thời điểm nói cần phải phù hợp, tương tự với nội dung bạn nói
  • Đôi lúc chỉ cần đặt câu hỏi “Đây có phải là thời điểm tốt để nói về …”

Chọn cách thức

  • Chọn cách thức truyền tải phù hợp với thính giả
  • Có những người chỉ muốn tóm tắt những điểm chính yếu, một số muốn một cuộc trao đổi dài trước khi vào đề
  • Trình độ của họ trong lĩnh vực cần trao đổi là gì? Chuyên gia hay mới vào nghề? Nếu không chắc, phải hỏi

Trình bày tài liệu chỉnh chu

  • Hiện nay có rất nhiều phần mềm để hỗ trợ làm tài liệu, nên không lý do gì mà bạn có thể tạo ra một tài liệu xấu xí
  • Kiểm tra chính tả, tự động sau đó bằng mắt

Cho phép người đọc tham gia vào việc chuẩn bị

  • Nếu có thể, cho phép những người đọc xem những bản nháp của tài liệu và nhận phản hồi từ họ
  • Bạn có thể sẽ có mối quan hệ tốt hơn, và tài liệu có thể sẽ chỉnh chu hơn

Biết lắng nghe

  • Để người khác lắng nghe bạn thì bạn phải lắng nghe họ trước
  • Khuyến khích mọi người nói chuyện và đặt câu hỏi, hoặc mời họ trình bày lại nội dung cuộc họp theo ý hiểu của họ
  • Biến cuộc họp thành một cuộc trao đổi, thì quan điểm của bạn sẽ được khẳng định hiệu quả hơn

Trả lời thắc mắc

  • Nếu bạn hỏi ai đó, và họ không trả lời, bạn sẽ thấy họ thật bất lịch sự
  • Nhìn lại bản thân mình, có khi nào bạn cũng như thế? Trong cuộc sống bận rộn, rất dễ để chúng ta quên mất những thắc mắc của người khác
  • Luôn trả lời khi ai đó đặt câu hỏi, một câu đơn giản như “tôi sẽ trả lời bạn sau nhé” luôn khiến người khác dễ chấp nhận hơn khi bạn chậm trễ, và tạo cảm giác bạn không quên họ

Lời khuyên thứ 12: Giao tiếp tốt nằm ở cả nội dung và cách truyền tải

Làm tài liệu

  • Làm tài liệu cũng là một cách trao đổi thông tin
  • Đây nên là một phần thiết yếu trong quá trình phát triển phần mềm
  • Để không bị trùng lặp hay tốn nhiều thời gian, tài liệu có thể nằm trong code
  • Có thể tạo ra tài liệu chỉnh chu bằng cách comment trong code, trên những modules và các function được export
  • Những tài liệu không để mô tả API thì chỉ nên ghi lý do phát triển, mục đích tồn tại và điều nó giải quyết. Những dòng code đủ để mô tả nó được thực hiện như thế nào, comment thêm chỉ làm trùng lặp và vi phạm nguyên tắc DRY

Lời khuyên thứ 13: Tài liệu nên xây dựng trong code, tách rời rất dễ làm nó lỗi thời