Giá Trị mà mình muốn nói đến ở đây chính là giá trị của chính bản thân mỗi Developer, cái mà chúng ta có thể dùng nó để đánh giá năng lực thực sự của một Developer, và có thể dùng để so sách Developer này với một Developer khác.
Nói về năng lực của developer thì nó cũng muôn hình vạn trạng, cũng giống như tính cách của con người. Mỗi người mỗi khác, mỗi người một thế mạnh, một cách làm việc khác nhau, và tạo ra giá trị khác nhau cho bản thân. Nhưng mà mấu chốt cuối cùng thì năng lực đó cũng là để đem đi phục vụ công việc. Cho nên để đánh giá khách quan nhất về một developer chính là hiệu suất công việc. Nhưng cứ nói chung chung thế thì quả thật hơi mơ hồ, như thế nào mới là hiệu quả công việc?, hay làm thế nào để có hiệu quả công việc cao?
Theo kinh nghiệm của mình, mình nhận thấy năng lực làm việc của một developer sẽ có những thể loại phân hoá theo cấp độ như sau:
- Hoàn thành task vừa CHẬM vừa phát sinh NHIỀU BUG => (Chất lượng kém)
- Hoàn thành task NHANH, nhưng phát sinh NHIỀU BUG => (Chất lượng thấp)
- Hoàn thành task CHẬM, nhưng được cái phát sinh ÍT BUG => (Chất lượng trung bình)
- Hoàn thành task vừa NHANH vừa ÍT BUG (có thể gần như KHÔNG CÓ BUG) => (Chất lượng cao)
Mình tin rằng, ai trong chúng ta đều muốn trở nhành một Developer chất lượng cao đúng không nào? 
. Và tất cả công ty trên thế giới này đều muốn đào tạo nhân sự của mình trở nên như vậy. Nhưng vấn đề ở chổ làm thế nào để trờ thành một nhân lực chất lượng cao?. Có bao nhiều người biết được một Keyword cụ thể như là một Kim Chỉ Nam để học tập, để phấn đấu trở thành người như vậy?. Mình nghĩ chỉ là số ít, và không phải công ty nào cũng có thể chỉ cho bạn trong quá trình đào tạo. Có thể bạn sẽ nghĩ rằng: Chỉ cần nổ lực học nhiều công nghệ, làm qua nhiều dự án, kinh nghiệm tích tụ dần thì cũng sẽ có ngày trở thành nhân lực chất lượng cao thôi chứ có gì phải soắn, mình nghĩ nó cũng đúng thôi vì ai cũng đang học theo cách như vậy cả, nhưng mà 100% người học theo cách như vậy thì cũng chỉ có tầm 20% người trở thành nhân lực chất lượng cao sau một thời gian, và chỉ có khoảng 1% số người trở thành chất lượng cao rất sớm, còn lại là nhân lực chất lượng trung bình hay thậm chí là chất lượng kém. Bởi vì chỉ số ít người có thể nhận thức ra được cái keyword dùng để làm kim chỉ nam để học tập, phấn đấu như mình nói ở trên. Và cái Keyword thần thánh đó chính là "Khả năng lường trước vấn đề" hay thực ra có thể nói cao siêu hơn đó chính là "Tư Duy Phản Biện", và đây mới thực sự là giá trị của một Developer mà mình muốn nói đến.
Mình có một ví dụ thế này, có 2 Developers A và B cùng làm việc với khách hàng K về một tính năng T cho một dự án. Và 2 người này cho ra hai câu chuyện như sau:
1. Câu chuyện của A:
A rất chăm chú nghe ông K truyền tải thông tin và cố gắng ghi chú cẩn thận để không bỏ sót bất kỳ thông tin nào từ ông K. A nghĩ rằng tất cả những thông tin đó là đủ để mình có thể bắt đầu và hoàn thành tính năng T. Không cần suy nghĩ nghĩ gì nhiều, vui vẻ cầm quyển sổ mình đã noted các thông tin về bàn và hăng hái làm việc. Sau khi làm được 10% thì bắt đầu gặp một vấn đề mới, những thông tin mà anh ấy đã tiếp nhận và đã noted không đủ để tiếp tục. Thế là A chạy đi hỏi ông K về vấn đề đó, sau khi hỏi xong lại hăng hái quay về tiếp tục coding, nhưng khi làm được 15% lại gặp một vấn đề khác. A lại tiếp tục đi hỏi K, và cứ như vậy cho đến khi gặp vấn đề lần thứ N, nhưng lần N này không đơn giản như các lần trước, mà sau khi hiểu được thông tin mới thì A nhận ra cách mà mình tổ chức coding trước giờ không phù hợp phải sửa đổi thì mới tiếp tục coding được. Thế là A thay đổi lại cấu trúc và tiếp tục hoàn thành tính năng. May quá cuối cùng cũng đã hoàn thành , vội vàng chuyển task T qua cho Tester kiểm thử với vẻ mặt tự hào vì mình đã hoàn thành một task khó. Khi tester vào kiểm tra thì phát hiện khá nhiều BUG, A kiểm tra lại lần đầu tiên thì phát hiện rằng, tại vì sau khi mình thay đổi cấu trúc code lại để hoàn thành thông tin cuối của khách hàng, thì không lường trước một số trường hợp gây lỗi trong logic của các thông tin cũ, thế là A tập trung fix để các trường hợp đó chạy ngon lành. Nhưng vì A chỉ tập trung vào logic cũ và Evidence mà Tester cung cấp, không hề phân tích và lường thêm các trường hợp có thể gây lỗi khác, thế là sau khi chuyển qua Tester kiểm thử lần hai thì lại phát sinh bug khác, cứ như vậy TESTING rồi lại FIXING, FIXING rồi lại TESTING vài lần mới hoàn thành task T 100%.
2. Câu chuyện của B: B thì khác, tất nhiên cũng rất chăm chú để đảm bảo nhận đủ thông tin của K muốn truyền đạt, sau khi nhận đủ thông tin, B nhìn các thông tin mà mình noted được, trong đầu bắt đầu phân tích và suy luận tình huống, cố gắng liên kết những thông tin vào logic lập trình. Lúc này chính là B đang xử dụng Tư Duy Phản Biện. B phát hiện để hoàn thành task T thì những thông tin mà K đã cung cấp ở trên là không đủ, và một số thông tin không được nhất quán với nhau, thế là B bắt đầu phản biện với K để làm rõ thêm về yêu cầu, sau đó mới quay về bắt đầu coding. Sau đó B hoàn thành task T mà không làm tốn thời gian của K thêm lần nào nữa, rồi chuyển qua cho đội Tester kiểm thử. Vẫn phát hiện có bug nhưng chỉ một bug thôi, không nhiều như bạn A. Khi nhận bug, B lại bắt đầu phân tích, không chỉ nhìn vào Evidence mà Tester cung cấp, B còn suy luận thêm các tình huống khác có thể gặp liên quan đến bug này, và suy luận thêm các trường hợp có thể gây lỗi sau khi fix bug đó nữa. Thế là B hoàn thành 100% task T chỉ sau một lần kiểm thử.
Qua câu chuyện của A và B ở trên, các bạn thấy B là người có Tư Duy Phản Biện tốt, còn A thì không, hai trường hợp cho ra 2 kết quả khác nhau. Có thể A cũng là một người nhiều kiến thức, có kinh nghiệm, sành sỏi nhiều công nghệ nên task T đó với A chỉ là một task đơn giản, nhưng chỉ vì không có hay Tư Duy Phản Biện kém nên dẫn đến hiệu suất công việc không cao bằng B. Các bạn thấy A phải tốn thêm nhiều thời gian của ông K mới có thể hiểu hết thông tin, phải tốn thêm nhiều thời gian của Tester, và phải tốn thêm rất nhiều thời gian của chính mình để đi fix bug thì mới có thể hoàn thành được task T. Trong khi đó B thì tiết kiệm được rất nhiều thời gian. Như vậy rõ ràng giá trị của B cao hơn rất nhiều so với A, và có thể nhận định rằng năng lực của B cao hơn A.
Chốt lại, mình muốn nói với các bạn rằng: "Cái keyword dùng để làm kim chỉ nam để một developer có thể học tập và phấn đấu trở thành một developer chất lượng cao, thậm chí trở thành nhân lực chất lượng cao sớm đó chính là Tư Duy Phản Biện". Mình nghĩ rằng nếu tất cả chúng ta đều nhận ra điều này sớm, và cố gắng nâng cao tư duy này mỗi ngày thì chắc năng lực sẽ vượt ra ngoài sự tưởng tượng của bạn 
.
Dài dòng quá nhỉ , Thế làm méo nào có thể cải thiện được Tư Duy Phản Biện?, OK đây . Trước tiên bạn nên thử vào đây để hiểu về Tư Duy Phản Biện. Có thể có rất nhiều bài viết hướng dẫn nâng cao kỹ năng này, bạn có thể tìm hiểu thêm trên google. Nhưng đứng ở gốc độ của một Developer mình xin được đưa ra 2 cách để cái thiện như sau:
1. Cố cắng rèn luyện kỹ năng Đặt Câu Hỏi: Nghe qua có vẻ đơn giản nhưng kỹ năng này không dễ ăn đâu nhé . Có khi nào bạn thấy sau một buổi thuyết trình nào đó, người thuyết trình hỏi bạn có câu hỏi nào cho họ không?. Hay đơn giản cuối một cuộc phỏng vấn tuyển dụng, nhà tuyển dụng hỏi bạn có bất kỳ câu hỏi nào về công ty không?. Trong các trường hợp như vậy, có khi nào bạn thấy đầu óc trống rỗng, không biết hỏi gì chưa?. Hãy luôn cố gắng suy nghĩ để đặt câu hỏi, có thể cho chính mình hay cho người khác trong mọi tình huống. Bởi vì để đặt được câu hỏi, chắc chắn bạn phải biết cách thu nạp thông tin, biết cách suy luận và phân tích được thông tin cơ bản mới được, như vậy chính là bạn đang rèn luyện khả năng lập luận, phân tích thông tin.
2. Đừng bao giờ nói rằng "Tôi không hiểu gì về task này cả, hãy giải thích cho tôi": Khi các bạn nhận một đầu việc thì chắc chắn ít nhiều cũng đã có một thông tin cụ thể nào đó về yêu cầu rồi, nhiều người đọc qua không hiểu liền nói ngay câu trên. Điều đó có nghĩa là bạn không chịu dùng đầu óc để suy luận và phân tích vấn đề trước, mà các bạn muốn có ngay một thông tin rõ ràng, các bạn đang lười suy nghĩ, lười phân tích, lập luận thông tin. Hãy tự mình dùng hết các kiến thức mà mình có để suy luận vấn đề trước, sau đó đưa ra được một thông tin theo cách mình hiểu và đi xác nhận lại những suy luận hay những phân tích của bạn về yêu cầu đó có đúng không thay vì đi nói ngay rằng tôi không hiểu. Nếu đúng thì họ chỉ trả lời YES, không cần tốn thêm nhiều thời gian. Còn nếu sai thì chắc chắn họ sẽ giải thích lại cho bạn thôi, và chắc chắn bạn có thêm một kinh nghiệm, nâng cao được Tư Duy Phản Biện lên một cấp độ rồi .
Cuối cùng, mình nghĩ rằng Tư Duy Phản Biện không chỉ giúp cho Developer trở nên tốt hơn, mà cho dù ở đâu, cho dù là lĩnh vực nào, chỉ cần bạn có nó thì chắc chắn bạn sẽ dễ tiến đến thành công hơn những người khác.