10 thói quen xấu mà developer cần tránh để ảnh hưởng đến code

5278
developer không nên làm gì

Mỗi developer có một số thói quen xấu trong suốt sự nghiệp hoặc thậm chí là kinh nghiệm học lập trình của họ. Trong bài viết này, chúng ta sẽ cùng xem xét một số thói quen xấu phổ biến mà bản thân tôi đã trải qua hoặc đã thấy từ số đông trong giới lập trình viên.

Hy vọng là nếu các bạn là người mới bắt đầu, bạn có thể tránh những thứ này, và nếu bạn đang có những thói quen này, bạn có thể nhận thức được và bắt đầu thay đổi chúng.

1. Không giành thời gian nghỉ ngơi đầy đủ

Điều đầu tiên, chắc chắn nhiều hoặc tất cả các bạn đều rơi vào. Tôi vẫn còn đang có thói quen xấu này: không giành thời gian nghỉ ngơi hoặc nghỉ ngơi không đủ. Tôi đã có những khoảng thời gian ngồi từ 6 giờ sáng và có lẽ chỉ đứng dậy để ăn trưa vào khoảng 1h và sau đó lại tiếp tục làm việc đến 6 hoặc 7 giờ tối, đây là 1 điều phổ biến, có thể nói là mỗi ngày.

Tôi đã làm những điều còn kinh khủng hơn nhiều khi tôi đang trong thời gian khủng hoảng. Tôi nghĩ rằng rất cả chúng ta đã có những dịp hiếm hoi nghĩ đến việc khi chúng ta cần một thứ gì đó được thực hiện vào ngày hôm sau, đó không thực sự là những gì tôi nói cho riêng bản thân mình, mà nó là thói quen hàng ngày của bạn.

Tôi sẽ đề nghị rằng mỗi ngày, bạn hãy cố gắng giành những khoảng thời gian để nghỉ ngơi. Tôi không thể nói một kế hoạch cụ thể vì mỗi người có timeline làm việc khác nhau, nhưng nói chung, tôi sẽ nói: mỗi sáng bạn thức dậy, bạn hãy vươn vai và giành thời gian đi dạo, uống cafe và ăn gì đó.

Hãy thực hiện nó một cách thường xuyên, mỗi khi bạn gặp bế tắc, khó khăn trong công việc, hãy nghỉ ngơi và quay trở lại với nó, công việc sẽ trở nên dễ dàng hơn sau khi bộ não của bạn được nghỉ ngơi. Vì vậy, hãy làm việc một cách khoa học. Ngay cả khi bạn không nghĩ rằng bạn cần nghỉ ngơi, chỉ cần thử nó, bạn có thể thấy rằng bạn làm việc hiệu quả hơn đó.

2. Từ chối yêu cầu giúp đỡ từ người khác

Nhiều người trong chúng ta không có yêu cầu giúp đỡ. Nó có thể vì một số lý do nhưng tôi nghĩ rằng phần lớn là sự tự ti và nỗi sợ người khác nghĩ là bạn kém cỏi. Nhiều người trong chúng ta mắc hội chứng kẻ mạo danh mà chúng ta không cảm thấy tự tin với vị trí của mình.

Tôi đã cảm thấy như thế này trong môi trường công ty khi gặp phải những điều khó khăn hoặc trong các cuộc thảo luận. Vì vậy, cái nhu cầu cần sự giúp đỡ chỉ cần khẳng định lại cảm giác đó mà thôi. Nhưng trong thực tế, nó lãng phí rất nhiều thời gian và cản trở sự phát triển của bạn.

Các nhà phát triển khác thực sự cần chỉ là một nguồn tài nguyên như một video hoặc cuốn sách mà thôi. Tôi thậm chí còn nói tốt hơn những thứ đó. Họ có thể trực tiếp trả lời câu hỏi của bạn và giúp bạn thực sự hiểu nó.

Chỉ có số ít những người sẽ chỉ trích bạn vì yêu cầu giúp đỡ. Nếu bạn không muốn yêu cầu sự giúp đỡ bởi vì bạn muốn có kinh nghiệm tự mình tìm ra câu trả lời, nhưng hãy tự giới hạn thời gian cho việc này nhé. Đừng mất nhiều ngày tìm kiếm giải pháp khi bạn có bạn bè ngay bên cạnh có thể biết hoặc ít nhất có thể giúp bạn tìm ra hướng xử lý.

3. Khi bạn không còn là sinh viên

Tôi không quan tâm nếu bạn là 1 senior developer có kinh nghiệm 20 năm, bạn nên luôn nghĩ rằng mình là một sinh viên. Đặc thù của ngành IT là luôn luôn thay đổi. Không có bất kỳ nhà phát triển nào có thể biết được sự thay đổi này ra sao.

Giây phút họ làm việc, có hàng nghìn thứ đang thay đổi và họ luôn luôn phải tích cực tìm hiểu và cập nhật những kiến thức mới. Nếu bạn tự mãn, ngừng đọc và ngừng học, bạn có thể sẽ bị tụt lại phía sau. Ngay cả khi bạn có một công việc không yêu cầu bạn phải học những kiến thức mới, giống như bạn xây dựng dự án với cùng một phần mềm, cùng phiên bản và mọi thứ về tech, thì nguy cơ bạn ở lại phía sau là rất có khả năng nếu trì hoãn sự làm mới bản thân.

Vì vậy, ngay cả với một công việc như vậy, bạn vẫn nên học những thứ mới bên cạnh chính những thứ quen thuộc mà bạn đang làm nhé. Luôn cập nhật với bất kỳ ngôn ngữ, framework, thư viện mà bạn động vào. Có rất nhiều công việc như tôi vừa giải thích và có thể hiểu được bởi vì nhiều teamlead tại các công ty nghĩ rằng nếu nó vẫn đang hoạt động tốt thì không nên động vào, không nên sửa nó.

Vì vậy, bạn vẫn thấy các nhóm sử dụng các công nghệ lỗi thời và không được hỗ trợ bởi vì nó vẫn đang hoạt động tốt. Nếu bạn đọc được những thứ mới và bạn có thể cho nhóm của bạn thấy rằng có thể làm cho dự án của bạn nhanh hơn, hiệu quả hơn và dễ dàng hơn, bạn có thể giúp họ cập nhật công nghệ của họ và cải thiện công ty.

4. Code thối

Đây là có lẽ là thói quen xảy ra thường xuyên trong mảng kỹ thuật chúng ta. Bạn muốn code của mình viết ra được trực quan, sạch, hiệu quả và an toàn. Điều này thực sự rất khó khăn khi bạn tự học thông qua các tutorial và khóa học nào đó, bởi vì cái người dạy bạn, họ chỉ chú tâm vào việc làm rõ định nghĩa của việc viết clean code, và thực tế khi làm dự án thì mỗi TH sẽ viết clean code theo các cách hoàn toàn khác nhau.

Vì vậy, bạn sẽ phải tự tìm kiếm, bổ sung kiến thức từ những base được người hướng dẫn chỉ dạy để có thể tìm ra cách tốt nhất để bạn có thể viết ra các đoạn code sạch. Một suggest mà đa số người sử dụng đó là nguyên tắc DRY. Mỗi khi bạn gặp các đoạn mã bị lặp, hãy tạo ra các lớp hoặc các hàm để thực thi nó, và bạn chỉ cần gọi lại hàm đó thay vì phải lặp lại những đoạn mã code dài và giống nhau.

Nó làm cho code của bạn sạch hơn, ngắn hơn, tiết kiệm được rất nhiều dòng, và mỗi khi có người khác đọc cũng dễ dàng hiểu hơn. Và cũng giúp phần cho việc nâng cao performace của hệ thống. Ngoài ra, khi thiết kế API, thì bạn cũng nên tránh gọi những API không cần thiết, tiêu chí cơ bản là sẽ thực hiện ít request nhất nhưng vẫn thực hiện đúng chức năng của nó.

Viết test, đây có thể là nơi dễ mắc phải việc lặp code nhiều nhất, nhưng đừng lo lắng, hãy lọc ra những TH response giống nhau và đưa nó vào các định nghĩa riêng, và thành quả sau đó sẽ rất lớn, nhìn file cũng ngắn hơn, và mình case test cũng dễ hiểu hơn rất nhiều.

  17 thói quen thường ngày đang vắt kiệt năng lượng của bạn, số 5 phải loại bỏ ngay nếu không muốn ngày nào cơ thể cũng "cạn pin"
  Warren Buffett chia sẻ một thói quen đơn giản cần có để thành công

5. Công việc tồi tệ / Cân bằng cuộc sống

Điều này thực sự rất quan trọng, đặc biệt nếu chúng ta là những người có gia đình. Công việc lập trình viên của bất kỳ level nào đều chiếm rất nhiều thời gian. Có rất nhiều lý do giải thích cho việc này: mọi thứ xung quanh ta luôn thay đổi, đặc biệt trong ngành kỹ thuật chúng ta, lúc đó ta sẽ gặp phải những vấn đề có thể cản trở chúng ta nhưng chúng ta lại cần thời gian để nghiên cứu và cập nhật liên tục kiến thức.

Chúng ta phải làm việc muộn, làm việc sớm, làm việc cuối tuần, hoặc tất cả. Điều này làm mất thời gian của mọi thứ khác trong cuộc sống của bạn, bao gồm cả những khoảng thời gian giành cho những người thân yêu. Những sở thích thể thao, đi bộ, đi ăn, hoặc bất kể điều gì và nếu bạn không ngừng làm việc, bạn sẽ không thể làm thêm bất kỳ điều gì. Đừng biến những dòng code thành cuộc sống của bạn, nó sẽ nhàm chán đó. Hãy ra ngoài và làm những việc mà bạn thích để cân bằng giữa cuộc sống và công việc của một developer.

6. Kỹ năng giao tiếp kém

Điều tiếp theo là dành cho những bạn đang làm việc tại công ty. Bạn làm việc với những người khác, xung đột, bất đồng và tranh luận có thể thể ra bất kỳ lúc nào. Nhiều nhà phát triển kiêu ngạo và luôn cho mình là đúng. Ngay cả khi họ biết rằng họ đã phạm sai lầm và lỗi là của họ; một số người trong số họ sẽ không bao giờ thừa nhận điều đó.

Tôi không nói các nhà phát triển đều như vậy, nhưng tôi nghĩ rằng tất cả chúng ta đã gặp những người như này. Tôi được nghe từ rất nhiều người rằng đội của họ rất tuyệt và tất cả họ đều hòa thuận, happy và điều đó thực sự tốt nhưng điều đó không phải lúc nào cũng diễn ra. Nhiều lần bạn sẽ gặp conflict về ý tưởng và giải pháp. Hãy cố gắng và có khả năng giao tiếp và tôn trọng mọi người, cùng lắng nghe và đóng góp ý kiến cho nhau, thúc đẩy mọi người cùng phát triển.

7. Không học hỏi từ những sai lầm

Là một nhà phát triển, bất kỳ ai cũng sẽ mắc phải những sai lầm. Nó là điều không thể tránh khỏi và điều này không có gì sai trái cả. Nhưng nó sẽ là một vấn đề được chú ý nếu những sai lầm của bạn lặp đi lặp lại và bạn không học được bài học gì từ nó.

Tôi được nghe một câu chuyện từ anh Brse team tôi, rằng khách hàng hàng của anh đấy đưa một file check rằng anh ấy có gần 100 bug cho sprint 1, và rồi, anh ấy có nói với khách hàng một câu rằng: “Tuy tôi có 100 bug nhưng không có bug nào giống nhau cả”, khách hàng sau khi nghe xong, họ kiểm tra lại và nhận ra điều này là đúng.

Và sau đó không những họ không phê bình mà ngược lại, họ lại khá happy vì điều này, và còn happy hơn nữa khi ở các sprint tiếp theo, dự án của anh ấy dường như không còn bug nữa….

Điều quan trọng rằng , khi mắc lỗi, việc truy cứu trách nhiệm cho ai là không cần thiết, điều cần thiết lúc đó là việc tìm ra nguyên nhân của nó, tìm giải pháp để khắc phục và ngăn chặn nó không xảy ra lần nữa.

8. Từ bỏ quá sớm

Chắc làm bất kỳ việc gì, với những khoảng thời gian đủ lớn, cái cảm giác thất vọng và muốn từ bỏ ai cũng đã từng trải qua. Khi đến giai đoạn này, không ít người lựa chọn từ bỏ và tìm đến 1 cái gì đó mới mẻ hơn, nhưng bên cạnh đó, vẫn còn những người vượt qua bằng tất cả sự cố gắng và kiên trì.

Tôi đã thấy rất nhiều người từ bỏ quá sớm do sự thất vọng mà công việc đó mang lại, điều này thì không trừ bất kỳ công việc nào nhé. Dự án thì thực sự khó khăn, và dường như khi bạn sửa chữa một chỗ nào đó, thì nó lại bị ảnh hưởng đến những phần khác và nó cứ thế tiếp tục diễn ra. Trong đầu bạn bắt đầu nảy sinh những suy nghĩ tiêu cực.

Nếu bạn từ bỏ dự án hoặc bỏ công việc của mình, thì tất cả những điều bạn làm trong dự án và công việc đó sẽ chẳng là gì cả. Tôi không nói rằng là không có dự án nào mà bạn nên từ bỏ, nhưng tôi đã thấy nó nhiều lần mà mọi người từ bỏ và từ quan điểm của người ngoài, tôi có thể biết rằng họ có bị mắc kẹt với nó trong thời gian dài hay không, dự án có lẽ đã thành công.

Vì vậy, trước khi bạn định từ bỏ bất kỳ thứ gì, hãy chắc chắn rằng bạn không còn phương pháp nào với nó cả. Bạn đã tìm kiếm, yêu cầu giúp đỡ, bắt đầu thử một điều gì đó khác biệt, có thể là việc sử dụng một công nghệ khác, nghỉ một thời gian dài để suy nghĩ về việc có nên trở lại hay không, thậm chí là có thể đặt nó sang một bên nếu có thể.

Thường mọi người ai cũng cố gắng làm tất cả mọi thứ với nó trước khi từ bỏ. Nếu bạn vẫn thất bại, thì có lẽ đã đến lúc phải tiếp tục, nhưng tất cả phương pháp nên được thực hiện trước khi điều đó xảy ra. Thành công có thể ở ngay cạnh bạn và sẽ thật xấu hổ nếu như bạn lại bỏ cuộc ngay trước bước ngoặt đó.

9. Nghĩ rằng mình là siêu nhân – cái gì cũng biết

Ở trên, tôi đã nói với các bạn về những nhà phát triển kiêu ngạo, và tôi nghĩ điều khiến họ như vậy là do họ nghĩ rằng họ biết tất cả.Họ không nghe ý kiến của các đồng nghiệp đơn giản chỉ bởi vì họ nghĩ rằng họ đã có câu trả lời.

Chính bởi suy nghĩ này nó có thể làm mọi người xa lánh bạn, cũng gần như là tự mình làm tổn thương chính mình vì chả ai muốn làm đồng nghiệp với mình; nó làm bạn thụ động trong việc học hỏi nhiều hơn và cải thiện bản thân.

Và rất có thể một ngày nào đó, bạn sẽ bị đánh thức bởi một cuộc gọi khủng khiếp khi có điều gì đó sai diễn ra vì bạn không nghe lời góp ý của người khác, và không chịu nghiên cứu tìm hiểu những cái mới. Hầu hết những kẻ này là những kẻ troll trên StackOverflow, họ tạo niềm vui cho những nhà phát triển mới khi đặt những câu hỏi và chọc cười người khác khi trả lời, hay down vote mỗi khi có cơ hội.

Tôi thực sự quan ngại về những người này. Tôi nghĩ rằng nhiều người trong số họ đã được chọn ở lại trường và họ sử dụng kiến thức của mình để chọn những dev khác có thể đang gặp vấn đề hoặc không biết mình phải làm gì.

Bất kể tại sao họ làm điều đó, tôi nghĩ rằng nếu họ cởi mở hơn và họ ủng hộ, hoan nghênh và đóng góp ý kiến cho ý tưởng của người khác. Họ có thể là người thông mình nhất trong nhóm nhưng cũng là người tệ nhất trong team, bởi vì ở đó không ai muốn làm việc với họ và ở đó, những cuộc giao tiếp tốt không được diễn ra.

Để có được sự thành công cho cả team, cần có sự giao tiếp, đoàn kết và điều đó đến từ tất cả mọi người. Hãy học cách cởi mở hơn một chút, tôn trọng người khác cũng là tôn trọng chính mình, bạn sẽ đi xa hơn trong cuộc sống đó.

10. Nhận xét không mang tính xây dựng

Điều cuối cùng nhắc đến cách thức mà bạn đưa ra những lời phê bình, nhận xét. Có một sự khác biệt lớn giữa một người biết tất cả là troll và ai đó đang cố gắng thực sự giúp bạn. Đôi khi thật khó để nhận ra sự khác biệt bởi vì có người chỉ ra điều gì đó cho bạn rằng bạn đã làm sai hoặc bạn có thể làm tốt hơn, bạn không cảm thấy tốt và có thể cảm thấy giống như đang bị chỉ trích nhưng nhiều lúc không phải, họ chỉ đơn giản cho bạn thấy một cách tốt hơn hoặc chỉ chia sẻ một ý kiến.

Phê bình mang tính xây dựng là một nguồn tài nguyên tuyệt vời cho việc học, và lý do cho điều đó là vì nó nhắm đến mục tiêu để giúp giải quyết vấn đề trực tiếp và mang lại cho bạn một giải pháp cụ thể. Đó là vô giá. Trong thực tế, đánh giá mã là rất tốt bởi vì bạn nhận được các đề xuất và ảnh hưởng của người khác đối với mã của bạn và cách bạn có thể cải thiện nó và cải thiện chính bản thân mình.

Tôi hy vọng lời khuyên này sẽ giúp một số bạn vừa mới phát triển cũng như phát triển nhiều kinh nghiệm.

Nguồn tham khảo: https://medium.com/@traversymedia/10-bad-habits-to-avoid-as-a-developer-64a1677c60fe