Cách để trở thành một nhà phát triển phần mềm tốt hơn

Tác giả: Pavels đăng trên https://medium.com/devtrailsio/how-to-become-a-better-software-developer-dd16072c974e.

Dịch giả: Togahepi a.k.a Hà Hiệp.

Hôm nay tôi muốn chia sẻ tới các bạn vài suy nghĩ của bản thân trên con đường mà một nhà phát triển phần mềm nâng cao kĩ năng chuyên nghiệp bản thân và làm việc tốt hơn. Chủ đề nêu ra ở đây không giới hạn trong bất kì một lĩnh vực đặc biệt nào trong ngành công nghệ. Thậm chí nó còn chẳng đặc thù cho ngành IT nữa cơ. Đây là những lời khuyên cơ bản để làm sao bạn phát triển cá tính, nâng cao khả năng hợp tác với đồng nghiệp và khách hàng, và phát triển sự nghiệp nhà phát triển phần mềm của mình.

Trong bài viết này có những ý kiến phản ánh kinh nghiệm thực tế của bản thân tôi, và cũng có những ý kiến tham khảo từ những người khác.

Hiểu rõ quy trình khép kín End-to-End

Nhiều lập trình viên nghĩ rằng việc phát triển phần mềm chỉ là liên quan đến những dòng code, và mọi việc khác chỉ làm xao nhãng và phí phạm thời gian quý báu của họ. Điều này chẳng đúng tẹo nào. Trước khi bạn viết những dòng code đầu tiên của 1 phần mềm, nó phải trải qua một quá trình lên ý tưởng sơ khai cho đến một thiết kế kĩ càng để triển khai. Và sau khi bạn đẩy toàn bộ code mình lên Git thì phần mềm lại được kiểm thử, triển khai, theo dõi, phân tích và tiếp tục cải thiện. Việc code chỉ là một bước rất nhỏ trong cả quy trình này.

Vậy tại sao điều này lại diễn ra? Thông thường, nhất là khi làm việc trong những tổ chức lớn, mỗi khâu khác nhau của những dự án được chịu trách nhiệm bởi những nhóm khác nhau hay bộ phận khác nhau. Chúng đều bắt đầu với những chuyên gia phân tích kinh doanh (đội Sales? :v), những người tập hợp các yêu cầu của khách hàng. Sau đó chúng sẽ được chuyển tới nhà thiết kế (designer) để lên khung mô hình cho lập trình viên. Lập trình viên code xong sau đó chuyển cho những kĩ sư kiểm thử. Nếu mọi thứ ổn thỏa, kiệt tác đó sẽ được chuyển cho nhóm vận hành để triển khai nó tới người dùng. Do sự thiếu liên kết giữa các nhóm, ý tưởng của họ có thể bị hiểu lầm bởi nhóm khác dẫn đến những xung đột.

Thường những quy trình này riêng rẽ nhau và không có sự feedback nào cả.

Hiện tại thì nhiều người cho rằng đây chỉ là sự phóng đại thái quá. Với sự lên ngôi của phương thức quản lý agile, nhiều công ty từ bỏ cách quản lý truyền thống và hướng tới những đội ngũ nhỏ hơn với tập hợp những người với chuyên môn khác nhau. Nhưng kể cả như vậy chúng ta vẫn thấy mọi người thiếu sự phối hợp với nhau. Đã bao lần bạn bực bội với designer chỉ bởi vì họ muốn có 1 checkbox mà quá tốn thời gian để code? Vân vân và mây mây, nhận lại từ họ thì lại là những chỉ trích chỉ bởi bạn quên sử dụng đúng font chữ.

Tất cả những khác biệt này đều có thể san lấp nếu bạn quan tâm, chăm chút chú ý hơn tới công việc của người khác. Hãy ngồi xuống đây bạn và cạn chén rượu này, đùa thôi hãy nói chuyện với designer và giải thích cho họ rằng thêm 1 checkbox tùy biến sẽ mất nhiều thời gian trong khi có những thư viện với những checkbox tương tự có thể sử dụng ngay. Ở chiều ngược lại, học cơ bản về typhography - cách trình bày chữ nghĩa và hiểu tại sao phải chọn đúng font chữ sẽ tạo ra khác biệt. Hãy làm tương tự như vậy với quản lý, đội phân tích kinh doanh, đội kiểm thử, đội hỗ trợ và đội marketing. Như T.Huxley nói:

"Try to learn something about everything and everything about something."

"Hãy cố gắng học hỏi mọi thứ một ít và tất cả về một thứ nào đó."

Bằng cách học hỏi từ mỗi người 1 chút, bạn sẽ có thể thỏa mãn mong muốn của họ, rút ngắn những vòng lặp feedback vô tận và công việc sẽ trôi chảy hơn. Thêm vào đó bạn sẽ nhận được sự yêu quý và tôn trọng từ mọi người.

Hiểu những điều mà khách hàng thực sự cần

Có một điều vô cùng quan trọng là bạn nên biết đó những thượng đế khách hàng của chúng ta chẳng hiểu tí teo gì về những thứ mà chúng ta thực sự làm. Agile, lập trình hàm hay dữ liệu bất liên quan thực sự là ma thuật đối với họ. Thậm chí đối với những người theo sát công việc của bạn và tỏ ra hứng thú cũng vẫn chỉ là màn đêm tăm tối mà thôi. Điều này sẽ dẫn tới những hệ lụy khôn lường.

Việc thuê các lập trình viên đối với khách hàng cần một chút tin tưởng. Mọi người thường cảm thấy không thoải mái khi phải trả quá nhiều tiền cho những thứ mà họ chẳng hiểu gì cả. Hãy nhớ lần cuối cùng bạn vô một gara sửa chữa ô tô và cảm thấy không an tâm tẹo nào khi trao quả xế của bạn cho họ? Vâng, khách hàng của bạn cũng cảm thấy như vậy đó. Chỉ khác là chẳng có cái xe nào, chỉ có một mớ khái niệm mờ hồ vô thực trừu tượng mà sẽ bằng cách nào đó thành sản phẩm và ra doanh thu. Khi bắt đầu làm việc với khách hàng mới, điều quan trọng là phải khiến họ tin tưởng bạn. Đảm bảo rằng họ hiểu bạn làm việc ra sao và đưa ra kết quả công việc từng chút một. Bằng cách đó họ có thể hiểu tiến độ công việc của bạn, đánh giá được kết quả tạm thời và đưa ra phản hồi.

Thường khách hàng sẽ đưa ra giải pháp riêng của họ thay vì chia sẻ vấn đề của họ. Khi họ không hiểu năng lực của bạn, những giải pháp của họ sẽ gặp sai lầm như dưới tầm hoặc quá tham vọng. Hãy nhớ tới câu nói nổi tiếng (hơi có phần giả tưởng) của Henry Ford:
"If I had asked people what they wanted, they would have said faster horses."
Nếu tôi hỏi ai đó điều họ mong muốn, họ sẽ liến thoắng như ngựa cho coi.

Thay vì lặng im và làm theo bất cứ mong muốn nào của khách hàng, đôi khi sẽ tốt hơn nếu bạn mời họ cùng nhau thảo luận vấn đề thực sự mà họ muốn giải quyết. Khi kết hợp ý kiến của khách hàng và công lực công nghệ của bạn, bạn sẽ đưa ra được giải pháp tối ưu.

Hãy nhớ rằng, không phải ai cũng thích ý tưởng của họ bị chất vấn và chiến thuật của bạn là phải thật tế nhị và lấy được sự tin tưởng trong mắt khách hàng. Bạn cũng cần thoát khỏi vùng an toàn bản thân và thực sự hòa mình vào công việc của họ, để có thể hiểu rõ vấn đề và đưa ra giải pháp tốt hơn. Có thể đó sẽ là cả một thử thách nếu bạn làm việc với những đối tượng đặc biệt như ngành tài chính hay chăm sóc sức khỏe. Nhưng nếu bạn thử dù chỉ một lần, gần như chắc chắn lần sau khách hàng sẽ trở lại với tâm lý cởi mở hơn.

Lựa chọn đúng công cụ cần thiết cho công việc

Nếu trong tay bạn chỉ có cái búa, thì mọi thứ sẽ trông giống cái đinh!

Thường khi lập trình viên chỉ biết tới một công nghệ duy nhất thì họ sẽ vội vã áp dụng nó với mọi vấn đề họ gặp phải. Không ngạc nhiên gì, kiểu tiếp cận này sẽ dẫn tới kết quả kém tối ưu. Thay vào đó, khi đối mặt với vấn đề mới, hãy suy nghĩ và lựa chọn công cụ tối ưu nhất cho công việc này. Nếu bạn còn nghi ngại, hãy đầu tư lựa ra một danh sách những giải pháp thay thế. Để mọi thứ dễ dàng hơn, hay soạn ra một danh sách câu hỏi và đánh giá từng lựa chọn một. Câu hỏi có thể khác nhau với mỗi sự đánh giá, nhưng nó sẽ tương tự như:

• Nền tảng hay thiết bị nào mà phải hỗ trợ?
• Những yêu cầu không phải tính năng như hiệu suất hay dung lượng bộ nhớ sử dụng?
• Mua phần mềm có bản quyền có là 1 lựa chọn, hoặc bạn sẽ cần tới mã nguồn mở hoặc miễn phí?
• Giải pháp có cung cấp toàn bộ điều bạn cần hay bạn phải tự viết phần nào đó?
• Có giới hạn gì khác không, như chính sách của công ty, những quan ngại pháp lý hoặc thiếu chuyên gia trong đội của bạn.

Thử nghiệm an toàn

Vậy điều gì sẽ xảy ra nếu tất cả kiến thức của bạn chẳng phù hợp với công việc và bạn cần phải thử nghiệm thứ gì đó mới mẻ? Sự thực là bạn chưa có kinh nghiệm với thứ gì đó không tự động đồng nghĩa rằng không có thắc mắc nào nữa. Nó chỉ nghĩa là bạn cần cân nhắc tới một số điều sau:

• Bạn có đủ thời gian chuẩn bị? Nếu như lịch trình của dự án không quá gấp gáp, và bạn có thể học mọi thứ có thể trước khi bắt đầu triển khai. Hoặc ít nhất hãy "Hành động như là bạn đã làm được nó" - "fake it till you make it" và thuyết phục khách hàng vào những việc bạn đang làm.
• Phân tích những thứ mà bạn cần kiểm tra đầu tiên. Hãy tiếp cận theo cách "Trả về sai lầm nhanh nhất có thể" - "fail fast" và phân thích những điểm chiến lược và bạn cần xác định trước khi có thể kết thúc thử nghiệm. Có nghi ngờ gì về hiệu suất của hệ thống? Hãy xây dựng thử nghiệm nhỏ rồi chạy thử khả năng tải. Không chắc chắn về một thư viện cụ thể hoặc liên kết với những dịch vụ bên ngoài? Triển khai một cách riêng rẽ sau đó mới xây dựng hoàn thiện.

Lưu ý rằng đi theo hướng tiếp cận này vẫn vô cùng rủi ro cho cả bạn lẫn khách hàng và họ cần nhận biết đầy đủ cả nguy cơ lần những lợi ích tiềm năng. Sau cùng, 2 tuần điều tra thử nghiệm có thể tiết kiệm hàng tháng trời quần quật làm lụng, nghe vẻ hợp lý đó nha. Ngay cả khi thử nghiệm thất bại, bạn cũng sẽ sẽ mất có 2 tuần thôi. Bạn càng lấy được lòng tin từ khách hàng thì bạn càng có được sự đồng thuận của họ về những thử nghiệm này.

Hãy đứng trên vai những người khổng lồ

Dân IT thường có 2 tính cách: chúng ta sáng tạo và chúng ta yêu thích công việc của mình. Nghe có vẻ đó là điều tốt, nhưng nó sẽ có những tác dụng phụ kì quặc: chúng ta đưa ra giải pháp riêng để giải quyết những vấn đề đã được giải quyết từ trước. Do đó bất cứ khi nào chúng ta phải đối mặt với lựa chọn sử dụng 1 framework, 1 thư viện hoặc dịch vụ hoặc là tự triển khai lấy, chúng ta thường chọn giải pháp cuối cùng. Điều này dẫn tới hành trình phù phiếm đi phát minh lại cái bánh xe. Vài niềm tin sai lầm có thể dẫn tới điều đó là: 

• Tự mình triển khai thứ gì đó dễ dàng hơn là học những giải pháp bên thứ 3. Đây có thể là lý do không thể hợp lý hơn, điều quan trọng là đừng tầm thường hóa quá công việc của người khác. Thường thì có những việc có vẻ dễ dàng khi bắt đầu làm nhưng hóa ra nó lại trở nên khó khăn trong quá trình phát triển. Rốt cuộc bạn có thể bị nhấn chìm trong một mớ bòng bong của bug và những trường hợp đặc biệt mà người khác đã giải quyết xong hộ bạn.
• Giải pháp này làm được quá nhiều thứ mà tôi chẳng cần tới. Trừ khi có một vài lý do mà điều này là xấu, như là tăng dung lượng bộ nhớ không cần thiết, có những lỗ hổng tiềm tàng hoặc làm chậm quá trình build, còn lại thì chẳng có gì là không tốt ở đây cả. Bạn có thể cần tới chúng về sau mà. Mặt khác, thêm cả một thư viện nhưng chỉ sử dụng có một hàm thì lại là thảm họa đó.
• Chúng ta có thể làm tốt hơn mà. Mặc cho có nhiều dự án thành công như vậy nhưng thường thì nó không phổ biến. Những giải pháp chất lượng bên thứ 3 được bảo trì liên tục bởi những đội ngũ có nhiều kinh nghiệm và nguồn lực để giải quyết những vấn đề hóc búa. Hầu hết các dự án chẳng thể nào có đủ nguồn lực như vậy hoặc cần phải làm điều đó.
• Quyền sở hữu code và khả năng bảo trì dài hạn sẽ là vấn đề lớn. Một số người sợ rằng nếu bạn dùng những giải pháp bên thứ 3, bạn sẽ gặp nguy cơ dự án của mình một lúc nào đó không đẹp trời sẽ bị bỏ rơi hoặc không thể sử dụng được nữa vì lý do trời ơi nào đấy. Nguy cơ sản phẩm bị khóa là thực tế, và bạn nên cân nhắc tới những chiến lược thay thế khả thi khác. Nếu là một dự án phần mềm mã nguồn mở, có nên chăng bạn tự làm mọi thứ và bảo trì luôn? Hoặc nếu đó là dự án độc quyền, cái giá nào đủ để thay thế nó? Dựa vào những cân nhắc này bạn cần đưa ra quyết định tỉnh táo dù cho có thể có vài nguy cơ.

Học qua quá trình tự làm lại

Có một khía cạnh khác mà bạn nên biết. Tự làm lại từ đầu thứ gì đó thực ra là cách tuyệt vời nhất để học tập. Trong khi tự mình viết những framework riêng cho sản phẩm mình là một ý tưởng tồi tệ, thì tự tạo ra một phần nhỏ framework như một bài tập thì đem lại nhiều giá trị. Chẳng có cách nào tốt hơn là giúp bản thân làm quen với các vấn đề bằng cách mổ xẻ nhiều vấn đề tương tự. Nhưng cũng đừng đi quá sâu vô hang thỏ tăm tối, một vài ví dụ đơn giản và thực tế sẽ là đủ để giúp bạn hiểu vấn đề.

Khi bạn làm việc, đừng ngại ngần gì mà không xem ké mã nguồn của những dự án tương tự. Học những dòng code của những dự án mã nguồn mở sẽ giúp bạn học được nhiều thứ từ những lập trình viên kinh nghiệm.

Tạo ra phương pháp làm việc của bạn

Phấn đấu để tiến bộ không chỉ trên khía cạnh công nghệ mà cả về mặt phương pháp nữa. Giống như một thiết kế hợp lý hay một phần mềm được tối ưu tốt, một luồng làm việc được thiết lập kĩ càng sẽ giúp bạn làm việc nhẹ nhàng và đỡ căng thẳng hơn mà lại đem tới kết quả tốt hơn. Tạo ra tiến trình công việc hiểu quả và năng suất lại chẳng dễ dàng gì dù cho có nhiều cuốn sách hay kiến thức có sẵn để tham khảo. Vạn sự khởi đều nan, nhưng hãy cân nhắc những vấn đề sau để tiến bộ nha:

• Phương pháp làm việc nhóm và quản lý dự án. Bởi hầu hết chúng ta luôn làm việc trong nhóm, vì vậy sẽ vô cùng cần thiết có một quy trình mà giúp mọi người phối hợp và tạo dựng nhịp độ công việc cho tất cả mọi người. Phương pháp agile trong phát triển phần mềm đã từ nó khai sinh ra nhiều phương pháp làm việc khác như Scrum hoặc Kanban. Chúng giúp quản lý tổng thể cấu trúc công việc nhưng không thể quản lý tất cả. Và có những phương pháp khác sẽ giúp bạn thiết lập, những vấn đề ưu tiên và nâng cao giao tiếp,v.v. Bạn cần đánh giá lĩnh vực nào mà mình đang gặp khó để tìm những giải pháp giúp bạn xử lý những khúc mắc đó.
• Quy trình cá nhân. Giống như một giàn nhạc giao hưởng, một nhóm làm việc hiệu quả phải chung một nhịp điệu, nhưng nó không có nghĩa mọi người phải làm việc với một thái độ giống hệt nhau. Mỗi cá nhân có những cá tính riêng và nên làm việc theo cách mà họ thấy hiệu quả nhất. Ví dụ như, có nhiều lập trình viên không muốn bị làm phiền khi đang code nhiều giờ liền, nhưng như tôi thì chỉ làm việc hiệu quả 1-2 tiếng sau đó sẽ là những khoảng nghỉ ngắn (một  phiên bản ít chặt chẽ hơn của phương pháp quản lý thời gian pomodoro technique). Tôi cũng không thích làm việc ở nhà để tránh những xao nhãng bởi công việc nhà, và thích làm việc ở văn phòng hay quán cafe. Hãy tìm ra cách làm việc phù hợp với bạn và cứ thế triển thôi, nhưng cũng đừng để thói quen riêng của bạn là vấn đề với những người khác trong nhóm nhé!
• Rèn luyện như một kĩ sư thực thụ. Nhiều cách luyện tập dựa trên khung của cả công nghệ và phương pháp luận và nâng cao quy trình phát triển thực tế. Ví dụ như: Phát triển phần mềm dựa vào kiểm thử chỉ bằng test TDD và kết hợp hành vi BDD sẽ giúp code của bạn sẽ có cấu trúc tốt và kiểm thử kĩ càng. Đánh giá code sẽ giúp giảm thiếu sót và giúp nâng cao kiến thức cho mọi người trong nhóm. Liên tục liên kết và liên tục phát hành giúp cho quá trình triển khai dễ dàng và an toàn hơn. Sử dụng phối hợp những phương pháp này cùng những phương pháp quản lý khác để tối ưu hóa kết quả.

Nên nhớ rằng, sẽ chẳng có tiến trình nào mà chuẩn chỉ cho tất cả mọi người được, bạn cần thử và sai để tìm ra tiến trình riêng cho mình. Và phải đảm bảo là bản hiểu tiến trình một cách kĩ càng và triển khai nó đúng cách. Hãy học hỏi những lời khuyên từ những nhóm đã từng trải và tiếp thu kinh nghiệm từ họ. Đừng cẩu thả với phần mềm hay những công cụ sẽ giúp bạn trong tiến trình làm việc. Hãy tạo một bảng công việc Kanban, và một nền tảng hiện đai để có thể liên tục phát hành. Tiếp thu một quy trình mới cần nhiều công sức và có thể làm giảm năng suất trong ngắn hạn. Hãy kiên nhẫn với nó một chút rồi nó sẽ là một bước tiến nhảy vọt nâng cao mọi thứ đó!

Loại bỏ các chướng ngại vật

Có nhiều thứ ta cần bàn để xác định các chướng ngại vật. Có hiểu một lỗi cơ bản là không để ý tới những mối nguy hại nhỏ nhặt có vẻ chẳng quan trọng mà có thể gây ra những hiệu ứng nguy hại tới công việc của bạn. Designer sản phẩm của bạn ngồi ở một phòng riêng biệt hay một tòa nhà khác? Đó sẽ là khó khăn nếu như bạn muốn sang thăm hỏi nhau chat chit, à nhầm :v, ý tôi là có những cuộc thảo luận công việc nghiêm túc ý. Viết những test mới có khó quá không? Rồi sao sẽ có quá nhiều thứ sẽ chẳng được test.

Sẽ chẳng nguy hiểm gì nếu chúng đứng riêng rẽ, nhưng thường thì chúng sẽ có xu hướng hợp thể và gây ra những hệ quả khủng khiếp. Và khốn nạn nhất là bạn sẽ chẳng để ý tới chúng cho tới khi mọi việc trở nên quá muộn. Đặc biệt là khi có quá nhiều mối nguy mà bạn phải nhận ra. Luôn nhớ tới câu chuyện ngụ ngôn về "luộc một chú ếch", chú ếch khi bị thả vô nước nóng sẽ nhảy ngay ra, nhưng nếu bị luộc từ từ nước lạnh thì chú sẽ nằm im chịu trận và bị luộc chín :(

Hãy luôn tỉnh táo và chiến đấu với những điều này ngay từ khi nó mới manh nha nhé!

Tập trung vào những kiến thức nền tảng

IT là một nền công nghiệp phát triển nhanh như tên lửa. Mỗi tuần lại có những công cụ mới được tung ra trên thị trường. Tôi cũng đã nhắc tới hội chứng khét tiếng "Mệt mỏi với JavaScript" ở bài viết trước của mình. Nhiều lập trình viên đã vô cùng stress và cảm thấy bị ép buộc khi phải sử dụng những JS stack khác nhau với mỗi dự án khiến họ thấy điên tiết, sôi máu. Thực sự thì luôn ở ranh giới có vẻ khó khăn, nhưng có một vài ý tưởng có thể đơn giản hóa mọi thứ.

Đầu tiên là, tập trung vào những kiến thức nền tảng. Mặc cho nhiều công nghệ mới thường xuyên xuất hiện, những khái niệm nền tảng đều giống nhau cả. Khi học một thứ gì đó mới mẻ, hãy đảm bảo bạn hiểu những ý tưởng sâu xa bên dưới dẫn đến sự ra đời của nó. Cơ hội ở đây là, những ý tưởng đó cũng được sử dụng trong những dự án khác, và một khi bạn gặp những vấn đề tương tự, bạn sẽ dễ dàng hơn để nắm vững được nó. Ví dụ, Những JavaScript UI framework hiện đại dựa trên nhiều thành phần, và một khi bạn hiểu cấu trúc của một ứng dụng hướng thành phần như React, thì nó cũng sẽ tương tự như vậy với Angular. Cùng ý tưởng đó của Redux cũng được tìm thấy ở Angular và quản lý trạng thái reactive từ Angular cũng được triển khai cho React hay MobX.

Hãy cố gắng dành thời gian với những cuốn sách kinh điển về những mô hình chung trong phát triển phần mềm như “Enterprise Integration Patterns” viết bởi Gregor Hohpe và Bobby Woolf, hay cuốn “Design Patterns: Elements of Reusable Object-Oriented Software” bởi Gang of Four. Mặc cho một vài kiến thức có thể đã lỗi thời, bạn vẫn có thể sử dụng chúng để học hỏi quá trình tiến hóa của những mô hình đến nay.

Hai là, đừng quá hấp tấp học mọi thứ mới. Tôi hiểu rằng nó vô cùng khó cưỡng lại khi làm theo những thứ mới mẻ trên Hackers News, nhưng hầu hết chúng chỉ là những ồn ào nhất thời thôi. Mà hãy để ý tới những thứ đã có cộng đồng đông đảo và trưởng thành. Đừng bị cuốn vào FOMO - Fear of missing out: Sợ bị bỏ rơi. Nếu bạn chú ý tới mọi thứ 1 chút thôi, sẽ không có điều quan trọng nào bị bỏ lỡ đâu.

Bo thêm vài lời khuyên nè

Chúng ta đã chém gió dài dài rồi, nhưng có vài điểm mà tôi muốn làm nổi bật trước khi chúng ta tạm biệt nhau. Những lời khuyên này chủ yếu là ý kiến cá nhân thôi, nhưng tôi tin rằng chúng cũng có những tác động tới cuộc sống công việc của bạn.

Chia sẻ kiến thức

Thường mọi người nghĩ rằng giấu nghề sẽ khiến họ trở nên "không thể không có anh"! Có những người như vậy trong nhóm sẽ khiến bạn rơi vào “bus factor” - hơi kinh dị nếu dự án của bạn sẽ bị dừng nếu một ai đó bị xe bus đâm?, hơi dã man, thực tế chỉ là ám chỉ người đó rời dự án và đẩy bạn vô thế khó khi bị bỏ rơi. Nếu bạn người như vậy, ngoài việc bạn không thể bị thay thế thì sự tinh thông đó cũng sẽ khiến bạn "không được lên chức" và "không có kì nghỉ luôn". Bạn có thể sẽ bị lỡ những cơ hội nghề nghiệp bởi bạn bị trói buộc vào nhiệm vụ. Thay vào đó, chia sẻ kiến thức với đồng nghiệp, nếu có thể trao một phần công việc của bạn cho họ và dùng sự phối hợp này giúp công việc của họ tiến bộ vượt bậc.

Đừng đổ lỗi cho mình hay người khác

Tôi nhớ một lần lâu rồi, chúng tôi đã gặp vấn đề với một dự án do lỗi của tôi. Chúng tôi đã có thể nhanh chóng giải quyết mọi vấn đề và tôi ghi tâm khắc cốt câu nói mà khách hàng nói với tôi:

You don't judge a team by how the perform when everything goes according to plan, but by how the operate when the shit hits the fan. (má dã man tục ngữ tiếng anh thả cứt vô cánh quạt đang quay á? really?)

Bạn không thể đánh giá một nhóm bằng cách mà họ thể hiện khi mọi thứ đi đúng kế hoạch mà bởi cách họ xử lý khi mà tai ương ập tới.

Không cần biết bạn giỏi cỡ nào, nhưng đôi khi thì vẫn có sai lầm thôi và trong khoảnh khắc bối rối đó, điều quan trọng nhất là phải giữ một cái đầu lạnh và xử lý tình huống bằng cách hỗ trợ nhau tình thương mến thương nhóe! :D Sau khi mọi sự đã êm dịu, đừng chỉ chăm chăm tìm lỗi để chỉ trích người khác. Nó cũng chẳng giúp bạn tránh được lỗi lầm trong tương lai đâu, nhưng nó sẽ gây ra tâm lý hoang mang, sợ hãi cho cả công ty. Thay vì tập trung nhau trong những bữa tiệc giả tạo và tìm sâu bắt lỗi. Hãy tập trung vào những thứ gây ra lỗi lầm, tìm hiểu tại sao nó xảy ra và "brainstorm" để có thể cải thiện hệ thống và luồng công việc để tránh xảy ra những vấn đề tương tự trong tương lai.

Đừng mất dạy

Cộng đồng lập trình viên vô cùng vui vẻ mà. Một mặt chúng ta thấy nhiều người với tư tưởng cởi mở sẵn sàng cống hiến cho cộng đồng bằng làm việc trong những dự án mã nguồn mở, nói chuyện ở những hội nghị hay viết bài chia sẻ. Mặt khác chúng ta cũng gặp không ít những kẻ mà cười chê những ý tưởng mới, không tôn trọng người mới và có những hành vi không tử tế với mọi người xung quanh. Đừng như những kẻ đó. Hãy tử tế và lan tỏa yêu thương nhoa!

Tóm cái váy lại nè! Dài quá hu hu! :((

Điều tuyệt vời nhất của công việc của bạn là khi nó chẳng có giới hạn nào cả. Luôn có những cung đường mới để ta khám phá và những con rồng mới để ta thuần phục. Dù cho bạn mới bắt đầu trên con đường sự nghiệp hay đã là một chuyên gia với nhiều kinh nghiệm, hãy lưu ý những lời tôi nói ở trên. Chúng sẽ giúp bạn tìm ra con đường và trở thành một lập trình viên tốt hơn, tử tế hơn.

Bạn có lời khuyên gì hay mà muốn chia sẻ không? Hãy comment bên dưới để chúng ta cùng chém gió nhoa! :xd

.      .      .

Nếu bạn thấy hứng thú với phát triển web hoặc nâng cao kĩ năng của mình? Ghé thăm devtrails.io nơi tập hợp nhiều hướng dẫn hữu ích giúp bạn tìm ra con đường đúng đắn nha.