[Bình Dân Học Vụ] - 8 điều cơ bản dành cho ai muốn đổi qua nghề IT

Đông Môn Khánh

Đẹp trai mà lại có tài
Chào tụi mày,

Nhân đợt ân xá sắp tới 30/4, nhằm để hồi hướng công đức cho thành viên bị án tử, để chánh niệm tỏa ra khắp diễn đàn.
Thanh tịnh hay ô nhiễm đều do tâm bởi tâm làm chủ, tâm tạo tác. Người tạo nghiệp bất thiện phải đoạn trừ tâm ô uế chứ không phải gột rửa ngoài thân. Ví như người luyện sắt phải gạn lọc phần cặn bã để được sắt tinh luyện chứ không thể chỉ đem rửa quặng sắt dưới nước trong mà được.

Cho nên tụi bây phải tập giữ chánh niệm, tụi tao không phải bồ tát mà lúc nào cũng cứu tụi bây được hoài.

Hôm nay tao bèn nghĩ ra một bài viết về CNTT, chuyên ngành của tao là Game Dev(Programmer). Để vừa giúp hồi hướng công đức cho tụi mày.
Mà còn giúp cho tụi mày chút ít phần nào đó kinh nghiệm mà tao đã tích lũy được thông qua hơn 12 năm làm nghề. Những thằng đã trong nghề có thể xem qua, nếu tụi mày có ý kiến nào hay hơn, thì hãy đóng góp hoặc làm bài viết. Còn những thằng có ý định học tập, chuyển nghề để có tương lai tươi sáng. Thì hãy đọc cho kỹ, và áp dụng vào việc học, làm. Để giúp ích cho bản thân tụi mày.
IT là nghề không bao giờ hết hot, chỉ có con người mới không có đủ sự kiên nhẫn mà theo đuổi nghề này mà thôi.

Vì vậy, hôm nay tao sẽ chia sẻ 8 hướng dẫn có thể hoạt động như một sơ đồ để cải thiện kỹ năng lập trình của mày. Những điều tao ghi dưới này được thu thập và tổng hợp từ 35 năm trong ngành công nghiệp máy tính, nhiều người trong số đó đã sử dụng ít nhất là một trong 8 điều bên dưới để ghi nhớ trong sự nghiệp của họ, trong đó có tao.
Nếu học được điều nào đó trong 8 điều này, ít ra tụi mày cũng có ích cho đời lắm. Vô đề thôi.

1. Nhắc nhở bản thân rằng mày phải học bao nhiêu.

Bước đầu tiên khi học một cái gì đó là nhận ra rằng mày không biết nó. Điều đó nghe có vẻ hiển nhiên, nhưng các lập trình viên có kinh nghiệm luôn nhớ rằng tụi nó đã mất bao lâu để vượt qua giả định này. Quá nhiều sinh viên khoa học máy tính tốt nghiệp với một kiểu xạo Lồn đó là: “Tao rành cái này lắm, dcm dễ vcl”, một sự chắc chắn rằng tụi nó biết tất cả mọi thứ và tụi nó hay xạo lồn thể hiện điều đó với mọi đồng nghiệp hoặc bạn học của tụi nó. Nói cách khác hơi thực tế là: "Con cặc gì tụi nó cũng biết!" thái độ có thể cản trở việc học của tụi mày ở toàn bộ các lĩnh vực, bất cứ điều gì mới, cũng sẽ khó khăn. Nên hãy ngưng tánh xạo lồn, và giấu dốt, thể hiện. Mày không biết, mày học, không ai chửi mày dốt cả. Nên đừng ngại tỏ ra mình không biết.

2. Ngừng cố gắng chứng minh mày đúng

Để trở nên vĩ đại — không chỉ giỏi — mày phải học hỏi từ kinh nghiệm nữa. Nhưng hãy cẩn thận, kinh nghiệm có thể dạy tụi bây lặp lại hành vi xấu và hình thành thói quen xấu. Để tránh thói quen này, hãy nhìn vào mọi thứ mày làm và tự hỏi bản thân, "Làm thế nào để mày có thể làm cho việc này tốt hơn?"

Các nhà phát triển phần mềm mới bước chân vào nghề (và kể cả người có kinh nghiệm) hay nhìn vào code của tụi nó rồi "thủ dâm", rồi khen đáo để: "dcm đéo thể tin mình đã viết được code thế này, vô địch cmnr." Tụi nó viết các đoạn code test để chứng minh rằng code của tụi nó hoạt động thay vì cố gắng làm cho nó bị lỗi(tức là nó đéo dám đối diện sự thật, và đéo dám làm cho nó hư đi, để tìm ra lỗi và khắc phục). Các lập trình viên thực sự tuyệt vời luôn tích cực tìm kiếm chỗ họ sai — bởi vì tụi nó biết rằng cuối cùng người dùng sẽ tìm thấy những khiếm khuyết mà tụi nó đã bỏ qua.

Nói đơn giản dễ hiểu: "Mày phải tự tìm ra khuyết điểm của mày, chứ đừng chỉ nhìn ra điểm tốt của mày rồi thủ dâm"

3. "Code đã chạy" không phải là mày đã xong việc và dừng lại; đó là nơi mày bắt đầu

Đúng vậy tml, bước đầu tiên của mày luôn là viết phần mềm chất lượng đáp ứng các thông số kỹ thuật. Tụi lập trình viên trung bình, non tay hay bỏ việc tại thời điểm đó và chuyển sang việc tiếp theo.(tức là chạy được là mừng rồi, đéo làm nữa, qua làm cái khác)

Một khi "xong" việc, và dừng lại. Cũng giống như mày chụp một bức ảnh nhanh và mong đợi nó trở thành một tác phẩm nghệ thuật. Các lập trình viên giỏi biết rằng lần chạy đầu tiên chỉ là lần lặp đầu tiên mà thôi. Phần mềm, code đã chạy rồi — xin chúc mừng! —Nhưng mày vẫn chưa làm xong. Bây giờ, hãy làm cho nó tốt hơn .

Một phần của quá trình đó là xác định “cái tốt hơn” nghĩa là gì. Nó có giúp cho phần mềm của mày tối ưu để làm cho nó chạy nhanh hơn? Dễ dàng hơn để lập documents? Có thể tái sử dụng code nhiều hơn? Đáng tin cậy hơn? Câu trả lời thay đổi theo từng ứng dụng, nhưng quy trình thì không.

Chốt: "Mày làm cho nó chạy chưa hẳn là xong chuyện, mày cần phải tối ưu hết mức có thể, theo trình độ của mày".

4. Viết lại cái mày đã viết 3 lần.

Lập trình viên giỏi viết phần mềm hoạt động, chạy được là mừng. Những người tuyệt vời, pro thì viết phần mềm hoạt động cực kỳ tốt. Điều đó hiếm khi xảy ra trong lần thử đầu tiên, chỉ hơn nhau giữa tốt và tạm được thôi. Nhưng phần mềm tốt nhất thường phải được viết ba lần:

Đầu tiên, mày viết phần mềm để chứng minh với bản thân (hoặc khách hàng) rằng giải pháp là khả thi. Những người khác có thể không nhận ra rằng đây chỉ là một bằng chứng về khái niệm, nhưng đối với mày, dĩ nhiên nếu mày là thằng làm có kinh nghiệm, hay không đi nữa, mày cũng thừa biết là cái code của mày chỉ là để demo, chạy thử cho coi thôi. Còn làm lại hoàn thiện hơn phải từ từ, đúng chưa?

Lần thứ hai, mày làm cho nó hoạt động.

Lần thứ ba, mày làm cho nó hoạt động "đúng".

Mức độ công việc này có thể không rõ ràng khi mày nhìn vào công việc của những nhà phát triển giỏi nhất. Mọi thứ tụi nó làm có vẻ rất xuất sắc, nhưng điều mày không thấy là ngay cả những nhà phát triển "thuộc hàng top" , tụi nó cũng có thể bỏ luôn phiên bản 1, và phiên bản 2 trước khi đưa phần mềm của tụi nó cho khách hàng(nó giấu cái xấu, và đưa cái tốt nhất của nó ra). Dẹp bỏ những thứ đã làm và bắt đầu lại từ đầu, có thể là một cách hiệu quả để "làm cho dự án của mày tốt hơn", và đưa nó vào quy trình làm việc cá nhân của mày.

Nói cách khác, "Viết lại phần mềm của mày ba lần" cho mày biết có bao nhiêu cách để tiếp cận một vấn đề. Và nó giúp mày không bị mắc kẹt trong một con đường mòn. OK chưa?

5. Đọc mã. Đọc nhiều mã

Thực sự đây là gợi ý phổ biến nhất và có giá trị nhất để cải thiện kỹ năng lập trình của tụi bây.

Khi mày đọc code của người khác, mày sẽ thấy cách người khác giải quyết vấn đề lập trình. Nhưng đừng coi nó là văn học; coi đó như một bài học và một thách thức. Để trở nên tốt hơn, hãy tự hỏi bản thân:

"Tao đã viết khối mã đó như thế nào? Mày sẽ làm gì khác đi, bây giờ mày đã thấy một giải pháp khác?"

"Tao vừa học cái Lồn gì dzậy? Làm thế nào tao có thể áp dụng kỹ thuật đó cho project của tao, cái phần mềm mà tao đã viết trong quá khứ, đưa code đó vô sao ta? (“Tao chưa bao giờ nghĩ đến việc sử dụng phương thức truy xuất đệ quy ở đó, sao thằng ml này nó làm cái này chi vậy ta…”).

Tao sẽ cải thiện đoạn code này như thế nào? Và nếu đó là một dự án mã nguồn mở mà mày tự tin rằng mình có giải pháp tốt hơn, hãy làm điều đó!

Viết code theo phong cách của tác giả . Thực hành điều này giúp mày hiểu được tâm trí của người đã viết phần mềm, điều này có thể cải thiện sự đồng cảm của mày.

Đừng chỉ nghĩ vẩn vơ về các bước này. Viết ra câu trả lời của mày, cho dù trong nhật ký cá nhân, blog, trong quá trình đánh giá mã hoặc diễn đàn cộng đồng với các nhà phát triển khác. Cũng giống như việc giải thích một vấn đề với một người khác, mà mày có thể giúp nó tìm ra giải pháp, việc viết ra và chia sẻ phân tích của mày có thể giúp mày hiểu lý do tại sao mày phản ứng với đoạn code của người khác theo một cách nhất định. Đó là tất cả một phần của sự xem xét nội tâm mà tao đã đề cập trước đó, giúp mày tự đánh giá điểm mạnh và điểm yếu của mày một cách công tâm.

Cảnh báo: Thật dễ dàng để đọc nhiều code mà không trở thành một lập trình viên giỏi, giống như một nhà văn muốn viết có thể đọc những tác phẩm văn học tuyệt vời mà không cần cải thiện văn xuôi của chính mình. Nhiều nhà phát triển xem xét mã nguồn mở hoặc phần mềm khác để “tìm câu trả lời” và rất có thể là sao chép và dán mã của người ta(copy & paste) để giải quyết một vấn đề tương tự. Làm điều đó thực sự có thể khiến mày trở thành một lập trình viên tồi tệ hơn, vì mày đang mù quáng chấp nhận sự khôn ngoan của người khác mà không kiểm tra nó. (Vì mày không dành thời gian để hiểu về nó, mày sẽ không bao giờ nhận ra rằng mày vừa nhập một nhà máy sản xuất lỗi).

6. Viết code, và không chỉ là nhiệm vụ

Làm việc trên các dự án lập trình cá nhân có nhiều lợi thế. Đầu tiên, nó cung cấp cho mày một cách để tìm hiểu các công cụ và công nghệ không có sẵn trong công việc hiện tại của mày, nhưng giúp mày có khả năng tiếp cận nhiều hơn cho công việc tiếp theo. Cho dù mày đóng góp cho một dự án mã nguồn mở hay đảm nhận công việc chuyên nghiệp trong một tổ chức, doanh nghiệp nào đó. Tất cả đều đòi hỏi mày phải có kỹ năng công nghệ và sự tự tin. (Ngoài ra, các dự án cá nhân của mày chứng tỏ với các nhà tuyển dụng rằng mày là người tự bắt đầu và không ngừng học hỏi.)

Một ưu điểm khác của việc viết code để giải trí là nó buộc mày phải tự tìm hiểu mọi thứ. Mày không thể giao việc khó cho người khác, vì vậy mày không thể yêu cầu giúp đỡ quá sớm.

Mẹo chuyên nghiệp: Mày đừng chỉ chọn những dự án cá nhân mà mày không bao giờ thất bại. Mày cần phải thất bại! Nhưng có lẽ mày không muốn thất bại trong công việc hoặc khi mày có deadline. Giấu dốt hoặc không chấp nhận rằng mày là 1 thằng thất bại, dễ làm mày ngu lắm.

7. Làm việc riêng với các nhà phát triển khác theo bất kỳ cách nào mày có thể

Nó giúp ích cho việc mày sẽ lắng nghe người khác. Nghĩa là lập trình theo cặp, hoặc tham gia một cuộc thi hackathon, hoặc tham gia một nhóm lập trình, hội nhóm gì đó như facebook hay discord.... Khi mày đóng góp cho một dự án mã nguồn mở, hãy chú ý đến phản hồi mày nhận được từ người dùng và từ các nhà phát triển khác. Mày thấy điểm chung nào trong những lời chỉ trích của tụi nó?

Mày có thể đủ may mắn để tìm được một người cố vấn cá nhân mà mày có thể tin tưởng để hướng dẫn mày mọi thứ từ kỹ thuật viết code, đến các quyết định nghề nghiệp. Đừng lãng phí những cơ hội như vậy.

8. Học kỹ thuật, không phải công cụ

Ngôn ngữ lập trình, công cụ và phương pháp trong nghề này nó cứ đến rồi đi, tức là nó đổi mới liên tục. Đó là lý do tại sao mày phải cần học nhiều ngôn ngữ và frameworks chừng nào thì càng tốt chừng nấy. Tập trung vào các nguyên tắc cơ bản về lập trình, bởi vì các nguyên tắc cơ bản không bao giờ thay đổi; cần quan tâm nhiều hơn đến architect(kiến trúc) hơn là việc lập trình. Nếu mày cảm thấy chắc chắn rằng chỉ có một cách đúng để làm điều gì đó, có lẽ đã đến lúc kiểm tra thực tế. Giáo điều có thể cản trở khả năng học hỏi những điều mới của mày và khiến mày chậm thích nghi với sự thay đổi.

Nguyên lý quan trọng của việc hoàn thiện bản thân là biết khi nào tụi mày nên dừng lại. Vì tụi mày đéo phải là thánh. Nên biết mày là ai, và ở đâu.
 
Sửa lần cuối:
Chào tụi mày,

Nhân đợt ân xá sắp tới 30/4, nhằm để hồi hướng công đức cho thành viên bị án tử, để chánh niệm tỏa ra khắp diễn đàn.
Thanh tịnh hay ô nhiễm đều do tâm bởi tâm làm chủ, tâm tạo tác. Người tạo nghiệp bất thiện phải đoạn trừ tâm ô uế chứ không phải gột rửa ngoài thân. Ví như người luyện sắt phải gạn lọc phần cặn bã để được sắt tinh luyện chứ không thể chỉ đem rửa quặng sắt dưới nước trong mà được.

Cho nên tụi bây phải tập giữ chánh niệm, tụi tao không phải bồ tát mà lúc nào cũng cứu tụi bây được hoài.

Hôm nay tao bèn nghĩ ra một bài viết về CNTT, chuyên ngành của tao là Game Dev(Programmer). Để vừa giúp hồi hướng công đức cho tụi mày.
Mà còn giúp cho tụi mày chút ít phần nào đó kinh nghiệm mà tao đã tích lũy được thông qua hơn 12 năm làm nghề. Những thằng đã trong nghề có thể xem qua, nếu tụi mày có ý kiến nào hay hơn, thì hãy đóng góp hoặc làm bài viết. Còn những thằng có ý định học tập, chuyển nghề để có tương lai tươi sáng. Thì hãy đọc cho kỹ, và áp dụng vào việc học, làm. Để giúp ích cho bản thân tụi mày.
IT là nghề không bao giờ hết hot, chỉ có con người mới không có đủ sự kiên nhẫn mà theo đuổi nghề này mà thôi.

Vì vậy, hôm nay tao sẽ chia sẻ 8 hướng dẫn có thể hoạt động như một sơ đồ để cải thiện kỹ năng lập trình của mày. Những điều tao ghi dưới này được thu thập và tổng hợp từ 35 năm trong ngành công nghiệp máy tính, nhiều người trong số đó đã sử dụng ít nhất là một trong 8 điều bên dưới để ghi nhớ trong sự nghiệp của họ, trong đó có tao.
Nếu học được điều nào đó trong 8 điều này, ít ra tụi mày cũng có ích cho đời lắm. Vô đề thôi.

1. Nhắc nhở bản thân rằng mày phải học bao nhiêu.

Bước đầu tiên khi học một cái gì đó là nhận ra rằng mày không biết nó. Điều đó nghe có vẻ hiển nhiên, nhưng các lập trình viên có kinh nghiệm luôn nhớ rằng tụi nó đã mất bao lâu để vượt qua giả định này. Quá nhiều sinh viên khoa học máy tính tốt nghiệp với một kiểu xạo lồn đó là: “Tao rành cái này lắm, dcm dễ vcl”, một sự chắc chắn rằng tụi nó biết tất cả mọi thứ và tụi nó hay xạo lồn thể hiện điều đó với mọi đồng nghiệp hoặc bạn học của tụi nó. Nói cách khác hơi thực tế là: "Con cặc gì tụi nó cũng biết!" thái độ có thể cản trở việc học của tụi mày ở toàn bộ các lĩnh vực, bất cứ điều gì mới, cũng sẽ khó khăn. Nên hãy ngưng tánh xạo lồn, và giấu dốt, thể hiện. Mày không biết, mày học, không ai chửi mày dốt cả. Nên đừng ngại tỏ ra mình không biết.

2. Ngừng cố gắng chứng minh mày đúng

Để trở nên vĩ đại — không chỉ giỏi — mày phải học hỏi từ kinh nghiệm nữa. Nhưng hãy cẩn thận, kinh nghiệm có thể dạy tụi bây lặp lại hành vi xấu và hình thành thói quen xấu. Để tránh thói quen này, hãy nhìn vào mọi thứ mày làm và tự hỏi bản thân, "Làm thế nào để mày có thể làm cho việc này tốt hơn?"

Các nhà phát triển phần mềm mới bước chân vào nghề (và kể cả người có kinh nghiệm) hay nhìn vào code của tụi nó rồi "thủ dâm", rồi khen đáo để: "dcm đéo thể tin mình đã viết được code thế này, vô địch cmnr." Tụi nó viết các đoạn code test để chứng minh rằng code của tụi nó hoạt động thay vì cố gắng làm cho nó bị lỗi(tức là nó đéo dám đối diện sự thật, và đéo dám làm cho nó hư đi, để tìm ra lỗi và khắc phục). Các lập trình viên thực sự tuyệt vời luôn tích cực tìm kiếm chỗ họ sai — bởi vì tụi nó biết rằng cuối cùng người dùng sẽ tìm thấy những khiếm khuyết mà tụi nó đã bỏ qua.

Nói đơn giản dễ hiểu: "Mày phải tự tìm ra khuyết điểm của mày, chứ đừng chỉ nhìn ra điểm tốt của mày rồi thủ dâm"

3. "Code đã chạy" không phải là mày đã xong việc và dừng lại; đó là nơi mày bắt đầu

Đúng vậy tml, bước đầu tiên của mày luôn là viết phần mềm chất lượng đáp ứng các thông số kỹ thuật. Tụi lập trình viên trung bình, non tay hay bỏ việc tại thời điểm đó và chuyển sang việc tiếp theo.(tức là chạy được là mừng rồi, đéo làm nữa, qua làm cái khác)

Một khi "xong" việc, và dừng lại. Cũng giống như mày chụp một bức ảnh nhanh và mong đợi nó trở thành một tác phẩm nghệ thuật. Các lập trình viên giỏi biết rằng lần chạy đầu tiên chỉ là lần lặp đầu tiên mà thôi. Phần mềm, code đã chạy rồi — xin chúc mừng! —Nhưng mày vẫn chưa làm xong. Bây giờ, hãy làm cho nó tốt hơn .

Một phần của quá trình đó là xác định “cái tốt hơn” nghĩa là gì. Nó có giúp cho phần mềm của mày tối ưu để làm cho nó chạy nhanh hơn? Dễ dàng hơn để lập documents? Có thể tái sử dụng code nhiều hơn? Đáng tin cậy hơn? Câu trả lời thay đổi theo từng ứng dụng, nhưng quy trình thì không.

Chốt: "Mày làm cho nó chạy chưa hẳn là xong chuyện, mày cần phải tối ưu hết mức có thể, theo trình độ của mày".

4. Viết lại cái mày đã viết 3 lần.

Lập trình viên giỏi viết phần mềm hoạt động, chạy được là mừng. Những người tuyệt vời, pro thì viết phần mềm hoạt động cực kỳ tốt. Điều đó hiếm khi xảy ra trong lần thử đầu tiên, chỉ hơn nhau giữa tốt và tạm được thôi. Nhưng phần mềm tốt nhất thường phải được viết ba lần:

Đầu tiên, mày viết phần mềm để chứng minh với bản thân (hoặc khách hàng) rằng giải pháp là khả thi. Những người khác có thể không nhận ra rằng đây chỉ là một bằng chứng về khái niệm, nhưng đối với mày, dĩ nhiên nếu mày là thằng làm có kinh nghiệm, hay không đi nữa, mày cũng thừa biết là cái code của mày chỉ là để demo, chạy thử cho coi thôi. Còn làm lại hoàn thiện hơn phải từ từ, đúng chưa?

Lần thứ hai, mày làm cho nó hoạt động.

Lần thứ ba, mày làm cho nó hoạt động "đúng".

Mức độ công việc này có thể không rõ ràng khi mày nhìn vào công việc của những nhà phát triển giỏi nhất. Mọi thứ tụi nó làm có vẻ rất xuất sắc, nhưng điều mày không thấy là ngay cả những nhà phát triển "thuộc hàng top" , tụi nó cũng có thể bỏ luôn phiên bản 1, và phiên bản 2 trước khi đưa phần mềm của tụi nó cho khách hàng(nó giấu cái xấu, và đưa cái tốt nhất của nó ra). Dẹp bỏ những thứ đã làm và bắt đầu lại từ đầu, có thể là một cách hiệu quả để "làm cho dự án của mày tốt hơn", và đưa nó vào quy trình làm việc cá nhân của mày.

Nói cách khác, "Viết lại phần mềm của mày ba lần" cho mày biết có bao nhiêu cách để tiếp cận một vấn đề. Và nó giúp mày không bị mắc kẹt trong một con đường mòn. OK chưa?

5. Đọc mã. Đọc nhiều mã

Thực sự đây là gợi ý phổ biến nhất và có giá trị nhất để cải thiện kỹ năng lập trình của tụi bây.

Khi mày đọc code của người khác, mày sẽ thấy cách người khác giải quyết vấn đề lập trình. Nhưng đừng coi nó là văn học; coi đó như một bài học và một thách thức. Để trở nên tốt hơn, hãy tự hỏi bản thân:

"Tao đã viết khối mã đó như thế nào? Mày sẽ làm gì khác đi, bây giờ mày đã thấy một giải pháp khác?"

"Tao vừa học cái lồn gì dzậy? Làm thế nào tao có thể áp dụng kỹ thuật đó cho project của tao, cái phần mềm mà tao đã viết trong quá khứ, đưa code đó vô sao ta? (“Tao chưa bao giờ nghĩ đến việc sử dụng phương thức truy xuất đệ quy ở đó, sao thằng ml này nó làm cái này chi vậy ta…”).

Tao sẽ cải thiện đoạn code này như thế nào? Và nếu đó là một dự án mã nguồn mở mà mày tự tin rằng mình có giải pháp tốt hơn, hãy làm điều đó!

Viết code theo phong cách của tác giả . Thực hành điều này giúp mày hiểu được tâm trí của người đã viết phần mềm, điều này có thể cải thiện sự đồng cảm của mày.

Đừng chỉ nghĩ vẩn vơ về các bước này. Viết ra câu trả lời của mày, cho dù trong nhật ký cá nhân, blog, trong quá trình đánh giá mã hoặc diễn đàn cộng đồng với các nhà phát triển khác. Cũng giống như việc giải thích một vấn đề với một người mày có thể giúp mày tìm ra giải pháp, việc viết ra và chia sẻ phân tích của mày có thể giúp mày hiểu lý do tại sao mày phản ứng với đoạn code của người khác theo một cách nhất định. Đó là tất cả một phần của sự xem xét nội tâm mà tao đã đề cập trước đó, giúp mày tự đánh giá điểm mạnh và điểm yếu của mày một cách công tâm.

Cảnh báo: Thật dễ dàng để đọc nhiều code mà không trở thành một lập trình viên giỏi, giống như một nhà văn muốn viết có thể đọc những tác phẩm văn học tuyệt vời mà không cần cải thiện văn xuôi của chính mình. Nhiều nhà phát triển xem xét mã nguồn mở hoặc phần mềm khác để “tìm câu trả lời” và rất có thể là sao chép và dán mã xuất hiện để giải quyết một vấn đề tương tự. Làm điều đó thực sự có thể khiến mày trở thành một lập trình viên tồi tệ hơn, vì mày đang mù quáng chấp nhận sự khôn ngoan của người khác mà không kiểm tra nó. (Vì mày không dành thời gian để hiểu về nó, mày sẽ không bao giờ nhận ra rằng mày vừa nhập một nhà máy sản xuất lỗi).

6. Viết code, và không chỉ là nhiệm vụ

Làm việc trên các dự án lập trình cá nhân có nhiều lợi thế. Đầu tiên, nó cung cấp cho mày một cách để tìm hiểu các công cụ và công nghệ không có sẵn trong công việc hiện tại của mày, nhưng giúp mày có khả năng tiếp cận nhiều hơn cho công việc tiếp theo. Cho dù mày đóng góp cho một dự án mã nguồn mở hay đảm nhận công việc chuyên nghiệp trong một tổ chức, doanh nghiệp nào đó. Tất cả đều đòi hỏi mày phải có kỹ năng công nghệ và sự tự tin. (Ngoài ra, các dự án cá nhân của mày chứng tỏ với các nhà tuyển dụng rằng mày là người tự bắt đầu và không ngừng học hỏi.)

Một ưu điểm khác của việc viết code để giải trí là nó buộc mày phải tự tìm hiểu mọi thứ. Mày không thể giao việc khó cho người khác, vì vậy mày không thể yêu cầu giúp đỡ quá sớm.

Mẹo chuyên nghiệp: Mày đừng chỉ chọn những dự án cá nhân mà mày không bao giờ thất bại. Mày cần phải thất bại! Nhưng có lẽ mày không muốn thất bại trong công việc hoặc khi mày có deadline. Giấu dốt hoặc không chấp nhận rằng mày là 1 thằng thất bại, dễ làm mày ngu lắm.

7. Làm việc riêng với các nhà phát triển khác theo bất kỳ cách nào mày có thể

Nó giúp ích cho việc mày sẽ lắng nghe người khác. Nghĩa là lập trình theo cặp, hoặc tham gia một cuộc thi hackathon, hoặc tham gia một nhóm lập trình, hội nhóm gì đó như facebook hay discord.... Khi mày đóng góp cho một dự án mã nguồn mở, hãy chú ý đến phản hồi mày nhận được từ người dùng và từ các nhà phát triển khác. Mày thấy điểm chung nào trong những lời chỉ trích của tụi nó?

Mày có thể đủ may mắn để tìm được một người cố vấn cá nhân mà mày có thể tin tưởng để hướng dẫn mày mọi thứ từ kỹ thuật viết code, đến các quyết định nghề nghiệp. Đừng lãng phí những cơ hội như vậy.

8. Học kỹ thuật, không phải công cụ

Ngôn ngữ lập trình, công cụ và phương pháp trong nghề này nó cứ đến rồi đi, tức là nó đổi mới liên tục. Đó là lý do tại sao mày phải cần học nhiều ngôn ngữ và frameworks chừng nào thì càng tốt chừng nấy. Tập trung vào các nguyên tắc cơ bản về lập trình, bởi vì các nguyên tắc cơ bản không bao giờ thay đổi; cần quan tâm nhiều hơn đến architecture(kiến trúc) hơn là việc lập trình. Nếu mày cảm thấy chắc chắn rằng chỉ có một cách đúng để làm điều gì đó, có lẽ đã đến lúc kiểm tra thực tế. Giáo điều có thể cản trở khả năng học hỏi những điều mới của mày và khiến mày chậm thích nghi với sự thay đổi.

Nguyên lý quan trọng của việc hoàn thiện bản thân là biết khi nào tụi mày nên dừng lại. Vì tụi mày đéo phải là thánh. Nên biết mày là ai, và ở đâu.
bài hay mà sao chưa đứa nào vodka nhỉ :)) đợi mấy bài tâm huyết như này
 
thằng thớt có tuyển đệ ko m , giờ 3x muốn theo IT thấy gian nan vl , không có định hướng
 
Chào tụi mày,

Nhân đợt ân xá sắp tới 30/4, nhằm để hồi hướng công đức cho thành viên bị án tử, để chánh niệm tỏa ra khắp diễn đàn.
Thanh tịnh hay ô nhiễm đều do tâm bởi tâm làm chủ, tâm tạo tác. Người tạo nghiệp bất thiện phải đoạn trừ tâm ô uế chứ không phải gột rửa ngoài thân. Ví như người luyện sắt phải gạn lọc phần cặn bã để được sắt tinh luyện chứ không thể chỉ đem rửa quặng sắt dưới nước trong mà được.

Cho nên tụi bây phải tập giữ chánh niệm, tụi tao không phải bồ tát mà lúc nào cũng cứu tụi bây được hoài.

Hôm nay tao bèn nghĩ ra một bài viết về CNTT, chuyên ngành của tao là Game Dev(Programmer). Để vừa giúp hồi hướng công đức cho tụi mày.
Mà còn giúp cho tụi mày chút ít phần nào đó kinh nghiệm mà tao đã tích lũy được thông qua hơn 12 năm làm nghề. Những thằng đã trong nghề có thể xem qua, nếu tụi mày có ý kiến nào hay hơn, thì hãy đóng góp hoặc làm bài viết. Còn những thằng có ý định học tập, chuyển nghề để có tương lai tươi sáng. Thì hãy đọc cho kỹ, và áp dụng vào việc học, làm. Để giúp ích cho bản thân tụi mày.
IT là nghề không bao giờ hết hot, chỉ có con người mới không có đủ sự kiên nhẫn mà theo đuổi nghề này mà thôi.

Vì vậy, hôm nay tao sẽ chia sẻ 8 hướng dẫn có thể hoạt động như một sơ đồ để cải thiện kỹ năng lập trình của mày. Những điều tao ghi dưới này được thu thập và tổng hợp từ 35 năm trong ngành công nghiệp máy tính, nhiều người trong số đó đã sử dụng ít nhất là một trong 8 điều bên dưới để ghi nhớ trong sự nghiệp của họ, trong đó có tao.
Nếu học được điều nào đó trong 8 điều này, ít ra tụi mày cũng có ích cho đời lắm. Vô đề thôi.

1. Nhắc nhở bản thân rằng mày phải học bao nhiêu.

Bước đầu tiên khi học một cái gì đó là nhận ra rằng mày không biết nó. Điều đó nghe có vẻ hiển nhiên, nhưng các lập trình viên có kinh nghiệm luôn nhớ rằng tụi nó đã mất bao lâu để vượt qua giả định này. Quá nhiều sinh viên khoa học máy tính tốt nghiệp với một kiểu xạo lồn đó là: “Tao rành cái này lắm, dcm dễ vcl”, một sự chắc chắn rằng tụi nó biết tất cả mọi thứ và tụi nó hay xạo lồn thể hiện điều đó với mọi đồng nghiệp hoặc bạn học của tụi nó. Nói cách khác hơi thực tế là: "Con cặc gì tụi nó cũng biết!" thái độ có thể cản trở việc học của tụi mày ở toàn bộ các lĩnh vực, bất cứ điều gì mới, cũng sẽ khó khăn. Nên hãy ngưng tánh xạo lồn, và giấu dốt, thể hiện. Mày không biết, mày học, không ai chửi mày dốt cả. Nên đừng ngại tỏ ra mình không biết.

2. Ngừng cố gắng chứng minh mày đúng

Để trở nên vĩ đại — không chỉ giỏi — mày phải học hỏi từ kinh nghiệm nữa. Nhưng hãy cẩn thận, kinh nghiệm có thể dạy tụi bây lặp lại hành vi xấu và hình thành thói quen xấu. Để tránh thói quen này, hãy nhìn vào mọi thứ mày làm và tự hỏi bản thân, "Làm thế nào để mày có thể làm cho việc này tốt hơn?"

Các nhà phát triển phần mềm mới bước chân vào nghề (và kể cả người có kinh nghiệm) hay nhìn vào code của tụi nó rồi "thủ dâm", rồi khen đáo để: "dcm đéo thể tin mình đã viết được code thế này, vô địch cmnr." Tụi nó viết các đoạn code test để chứng minh rằng code của tụi nó hoạt động thay vì cố gắng làm cho nó bị lỗi(tức là nó đéo dám đối diện sự thật, và đéo dám làm cho nó hư đi, để tìm ra lỗi và khắc phục). Các lập trình viên thực sự tuyệt vời luôn tích cực tìm kiếm chỗ họ sai — bởi vì tụi nó biết rằng cuối cùng người dùng sẽ tìm thấy những khiếm khuyết mà tụi nó đã bỏ qua.

Nói đơn giản dễ hiểu: "Mày phải tự tìm ra khuyết điểm của mày, chứ đừng chỉ nhìn ra điểm tốt của mày rồi thủ dâm"

3. "Code đã chạy" không phải là mày đã xong việc và dừng lại; đó là nơi mày bắt đầu

Đúng vậy tml, bước đầu tiên của mày luôn là viết phần mềm chất lượng đáp ứng các thông số kỹ thuật. Tụi lập trình viên trung bình, non tay hay bỏ việc tại thời điểm đó và chuyển sang việc tiếp theo.(tức là chạy được là mừng rồi, đéo làm nữa, qua làm cái khác)

Một khi "xong" việc, và dừng lại. Cũng giống như mày chụp một bức ảnh nhanh và mong đợi nó trở thành một tác phẩm nghệ thuật. Các lập trình viên giỏi biết rằng lần chạy đầu tiên chỉ là lần lặp đầu tiên mà thôi. Phần mềm, code đã chạy rồi — xin chúc mừng! —Nhưng mày vẫn chưa làm xong. Bây giờ, hãy làm cho nó tốt hơn .

Một phần của quá trình đó là xác định “cái tốt hơn” nghĩa là gì. Nó có giúp cho phần mềm của mày tối ưu để làm cho nó chạy nhanh hơn? Dễ dàng hơn để lập documents? Có thể tái sử dụng code nhiều hơn? Đáng tin cậy hơn? Câu trả lời thay đổi theo từng ứng dụng, nhưng quy trình thì không.

Chốt: "Mày làm cho nó chạy chưa hẳn là xong chuyện, mày cần phải tối ưu hết mức có thể, theo trình độ của mày".

4. Viết lại cái mày đã viết 3 lần.

Lập trình viên giỏi viết phần mềm hoạt động, chạy được là mừng. Những người tuyệt vời, pro thì viết phần mềm hoạt động cực kỳ tốt. Điều đó hiếm khi xảy ra trong lần thử đầu tiên, chỉ hơn nhau giữa tốt và tạm được thôi. Nhưng phần mềm tốt nhất thường phải được viết ba lần:

Đầu tiên, mày viết phần mềm để chứng minh với bản thân (hoặc khách hàng) rằng giải pháp là khả thi. Những người khác có thể không nhận ra rằng đây chỉ là một bằng chứng về khái niệm, nhưng đối với mày, dĩ nhiên nếu mày là thằng làm có kinh nghiệm, hay không đi nữa, mày cũng thừa biết là cái code của mày chỉ là để demo, chạy thử cho coi thôi. Còn làm lại hoàn thiện hơn phải từ từ, đúng chưa?

Lần thứ hai, mày làm cho nó hoạt động.

Lần thứ ba, mày làm cho nó hoạt động "đúng".

Mức độ công việc này có thể không rõ ràng khi mày nhìn vào công việc của những nhà phát triển giỏi nhất. Mọi thứ tụi nó làm có vẻ rất xuất sắc, nhưng điều mày không thấy là ngay cả những nhà phát triển "thuộc hàng top" , tụi nó cũng có thể bỏ luôn phiên bản 1, và phiên bản 2 trước khi đưa phần mềm của tụi nó cho khách hàng(nó giấu cái xấu, và đưa cái tốt nhất của nó ra). Dẹp bỏ những thứ đã làm và bắt đầu lại từ đầu, có thể là một cách hiệu quả để "làm cho dự án của mày tốt hơn", và đưa nó vào quy trình làm việc cá nhân của mày.

Nói cách khác, "Viết lại phần mềm của mày ba lần" cho mày biết có bao nhiêu cách để tiếp cận một vấn đề. Và nó giúp mày không bị mắc kẹt trong một con đường mòn. OK chưa?

5. Đọc mã. Đọc nhiều mã

Thực sự đây là gợi ý phổ biến nhất và có giá trị nhất để cải thiện kỹ năng lập trình của tụi bây.

Khi mày đọc code của người khác, mày sẽ thấy cách người khác giải quyết vấn đề lập trình. Nhưng đừng coi nó là văn học; coi đó như một bài học và một thách thức. Để trở nên tốt hơn, hãy tự hỏi bản thân:

"Tao đã viết khối mã đó như thế nào? Mày sẽ làm gì khác đi, bây giờ mày đã thấy một giải pháp khác?"

"Tao vừa học cái lồn gì dzậy? Làm thế nào tao có thể áp dụng kỹ thuật đó cho project của tao, cái phần mềm mà tao đã viết trong quá khứ, đưa code đó vô sao ta? (“Tao chưa bao giờ nghĩ đến việc sử dụng phương thức truy xuất đệ quy ở đó, sao thằng ml này nó làm cái này chi vậy ta…”).

Tao sẽ cải thiện đoạn code này như thế nào? Và nếu đó là một dự án mã nguồn mở mà mày tự tin rằng mình có giải pháp tốt hơn, hãy làm điều đó!

Viết code theo phong cách của tác giả . Thực hành điều này giúp mày hiểu được tâm trí của người đã viết phần mềm, điều này có thể cải thiện sự đồng cảm của mày.

Đừng chỉ nghĩ vẩn vơ về các bước này. Viết ra câu trả lời của mày, cho dù trong nhật ký cá nhân, blog, trong quá trình đánh giá mã hoặc diễn đàn cộng đồng với các nhà phát triển khác. Cũng giống như việc giải thích một vấn đề với một người mày có thể giúp mày tìm ra giải pháp, việc viết ra và chia sẻ phân tích của mày có thể giúp mày hiểu lý do tại sao mày phản ứng với đoạn code của người khác theo một cách nhất định. Đó là tất cả một phần của sự xem xét nội tâm mà tao đã đề cập trước đó, giúp mày tự đánh giá điểm mạnh và điểm yếu của mày một cách công tâm.

Cảnh báo: Thật dễ dàng để đọc nhiều code mà không trở thành một lập trình viên giỏi, giống như một nhà văn muốn viết có thể đọc những tác phẩm văn học tuyệt vời mà không cần cải thiện văn xuôi của chính mình. Nhiều nhà phát triển xem xét mã nguồn mở hoặc phần mềm khác để “tìm câu trả lời” và rất có thể là sao chép và dán mã xuất hiện để giải quyết một vấn đề tương tự. Làm điều đó thực sự có thể khiến mày trở thành một lập trình viên tồi tệ hơn, vì mày đang mù quáng chấp nhận sự khôn ngoan của người khác mà không kiểm tra nó. (Vì mày không dành thời gian để hiểu về nó, mày sẽ không bao giờ nhận ra rằng mày vừa nhập một nhà máy sản xuất lỗi).

6. Viết code, và không chỉ là nhiệm vụ

Làm việc trên các dự án lập trình cá nhân có nhiều lợi thế. Đầu tiên, nó cung cấp cho mày một cách để tìm hiểu các công cụ và công nghệ không có sẵn trong công việc hiện tại của mày, nhưng giúp mày có khả năng tiếp cận nhiều hơn cho công việc tiếp theo. Cho dù mày đóng góp cho một dự án mã nguồn mở hay đảm nhận công việc chuyên nghiệp trong một tổ chức, doanh nghiệp nào đó. Tất cả đều đòi hỏi mày phải có kỹ năng công nghệ và sự tự tin. (Ngoài ra, các dự án cá nhân của mày chứng tỏ với các nhà tuyển dụng rằng mày là người tự bắt đầu và không ngừng học hỏi.)

Một ưu điểm khác của việc viết code để giải trí là nó buộc mày phải tự tìm hiểu mọi thứ. Mày không thể giao việc khó cho người khác, vì vậy mày không thể yêu cầu giúp đỡ quá sớm.

Mẹo chuyên nghiệp: Mày đừng chỉ chọn những dự án cá nhân mà mày không bao giờ thất bại. Mày cần phải thất bại! Nhưng có lẽ mày không muốn thất bại trong công việc hoặc khi mày có deadline. Giấu dốt hoặc không chấp nhận rằng mày là 1 thằng thất bại, dễ làm mày ngu lắm.

7. Làm việc riêng với các nhà phát triển khác theo bất kỳ cách nào mày có thể

Nó giúp ích cho việc mày sẽ lắng nghe người khác. Nghĩa là lập trình theo cặp, hoặc tham gia một cuộc thi hackathon, hoặc tham gia một nhóm lập trình, hội nhóm gì đó như facebook hay discord.... Khi mày đóng góp cho một dự án mã nguồn mở, hãy chú ý đến phản hồi mày nhận được từ người dùng và từ các nhà phát triển khác. Mày thấy điểm chung nào trong những lời chỉ trích của tụi nó?

Mày có thể đủ may mắn để tìm được một người cố vấn cá nhân mà mày có thể tin tưởng để hướng dẫn mày mọi thứ từ kỹ thuật viết code, đến các quyết định nghề nghiệp. Đừng lãng phí những cơ hội như vậy.

8. Học kỹ thuật, không phải công cụ

Ngôn ngữ lập trình, công cụ và phương pháp trong nghề này nó cứ đến rồi đi, tức là nó đổi mới liên tục. Đó là lý do tại sao mày phải cần học nhiều ngôn ngữ và frameworks chừng nào thì càng tốt chừng nấy. Tập trung vào các nguyên tắc cơ bản về lập trình, bởi vì các nguyên tắc cơ bản không bao giờ thay đổi; cần quan tâm nhiều hơn đến architecture(kiến trúc) hơn là việc lập trình. Nếu mày cảm thấy chắc chắn rằng chỉ có một cách đúng để làm điều gì đó, có lẽ đã đến lúc kiểm tra thực tế. Giáo điều có thể cản trở khả năng học hỏi những điều mới của mày và khiến mày chậm thích nghi với sự thay đổi.

Nguyên lý quan trọng của việc hoàn thiện bản thân là biết khi nào tụi mày nên dừng lại. Vì tụi mày đéo phải là thánh. Nên biết mày là ai, và ở đâu.
Bài viết hay.
Nhân tiện cho tao hỏi,tao trước học xây dựng.Cũng có học qua C cơ bản trong trường đại học
Giờ tao muốn học thêm để có thể code dc blockchain, Dapp..
Tao phải bắt đầu từ đâu.
 
Cố lên chúng mày. Tao theo nghiệp IT 10 năm giờ làm manager cty lớn. Lương 10K++. Thu nhập theo năm cứ gọi là vài tỏi.

Chỉ làm công ăn lương 5-7 năm kiếm 20-30 tỏi là bt :vozvn (18)::vozvn (18)::vozvn (18):
 
Cố lên chúng mày. Tao theo nghiệp IT 10 năm giờ làm manager cty lớn. Lương 10K++. Thu nhập theo năm cứ gọi là vài tỏi.

Chỉ làm công ăn lương 5-7 năm kiếm 20-30 tỏi là bt :vozvn (18)::vozvn (18)::vozvn (18):
Giàu dữ mày.
donate đi thôi
 
Hiển nhiên. Tao cũng phải phấn đấu 7-8 năm để lên vị trí. Này để nói cho chúng mày biết nếu ko đi theo hướng chính trị và quan hệ thì đi theo hướng IT, thuần tuý bản thân cũng thành triệu phú.
Xin kính huynh 1 chén, không biết huynh đang xuất nội hay xuất ngoại nhỉ.? Lương 10k theo đệ biết chỉ có ở nước ngoài chứ VN không trả nổi mức này.
 
Hiển nhiên. Tao cũng phải phấn đấu 7-8 năm để lên vị trí. Này để nói cho chúng mày biết nếu ko đi theo hướng chính trị và quan hệ thì đi theo hướng IT, thuần tuý bản thân cũng thành triệu phú.

Đúng rồi, nhưng đã khoe thì khoe cho trót, at least mày cũng nó rõ mày làm tech stack nào, công ty VN hay nước nào, đầu tư hay làm thêm gì để có tiền chứ.
 
Xin kính huynh 1 chén, không biết huynh đang xuất nội hay xuất ngoại nhỉ.? Lương 10k theo đệ biết chỉ có ở nước ngoài chứ VN không trả nổi mức này.
Có đấy, tầm CTO :vozvn (20):
 
Xin kính huynh 1 chén, không biết huynh đang xuất nội hay xuất ngoại nhỉ.? Lương 10k theo đệ biết chỉ có ở nước ngoài chứ VN không trả nổi mức này.
Tao ở VN nha :vozvn (7):
Mỗi năm đóng thuế 700~800 củ tiếc đứt ruột cho cái bọn sở thuế.
 
Đúng rồi, nhưng đã khoe thì khoe cho trót, at least mày cũng nó rõ mày làm tech stack nào, công ty VN hay nước nào, đầu tư hay làm thêm gì để có tiền chứ.
Tao làm về hệ thống phân tán. 5~7 năm đầu ngồi code là chính. Vài năm nay làm architect do tao từng làm các hệ thống lớn + với review code.
 
Sửa lần cuối:
Tao làm về hệ thống phân tán. 5~7 năm đầu ngồi code là chính. Vài năm nay làm architect do tao từng làm các hệ thống to + với review code và lâu lâu vẫn code không sếp nó ý kiến.
Nếu anh làm hệ thống phân tán thì phải có tech stack chứ nhỉ? Có thể chia sẻ thêm không?

1 câu hỏi thôi: "Làm thế nào xử lý 1 triệu requests / 1s ?", cách triển khai của anh như nào ?
 

Có thể bạn quan tâm

Top