7 sai lầm tưởng chừng vô hại khiến dev bị sa thải

admin

Nếu bạn bị sa thải vì những lý do quậy phá không đâu, đó chỉ là cái cớ cho nguyên nhân sâu sa thực sự mà thôi. Hãy cùng điểm qua một số sai lầm và nguyên nhân thật sự khiến dev chúng ta bị sa thải!

Sai lầm 1: Lươn lẹo & mưu mô

Chắc các bạn cũng biết chuyện rồi. Có một anh lập trình viên làm ứng dụng cho Nissan bị lộ tẩy đã “cướp” code trên Stack Overflow. Phần mô tả nguyên văn từ Stack Overflow ở bản update gần đây đã “lật mặt” anh này.

Chao ôi! Đa phần lập trình viên là những cá nhân trung thực, chăm chỉ. Chúng ta học tập và làm việc rất siêng năng để cho ra các sản phẩm tốt.

Nhưng ngành công nghiệp nào cũng có những bí mật “bẩn” của riêng mình. Và với ngành lập trình này, chúng ta rất hay copy paste code từ internet, ai cũng đã từng làm qua.

Chúng ta đều bị áp lực deadline rất nặng nề, và sẽ tìm mọi cách để hoàn thành công việc. Và ngoài việc mò lên Stack Overflow hay CodePen tìm kiếm chỉ trong vài giờ, rồi copy/patse, thì còn còn cách nào nhanh bằng nữa. Một cách làm quá thông minh luôn đúng không?

Cũng chưa hẳn, xã hội hiện nay vô cùng soi mói. Đặc biệt là trong môi trường công nghệ vô cùng cạnh tranh, nhà báo, blogger, hay thậm chí các vị đồng nghiệp ngồi bên cạnh, sẽ lăm le không từ thủ đoạn bới móc cuộc sống và công việc của bạn từng chút một.

Bạn chỉ cần bất cẩn một tý thôi, để sai lầm của mình lên mặt báo, thí đúng là “một phúc bốc đồng, ngàn năm bốc… đất”, cả sự nghiệp tiêu tùng.

Sai lầm dù “ngây ngô”, nhưng lại thiếu trung thực có thể thể kể đến:

  • Copy/paste/steal code (đạo/cắp)
  • Lời nói dối (tưởng như vô hại) về con người, công việc, thỏa thuận,…
  • Truy cập và chia sẻ tài liệu không thuộc quyền hạn.
  • Sử dụng tài nguyên công ty cho mục đích cá nhân.

Ngay cả sự nghiệp vẫn chưa bị đe dọa, thì áp lực từ cộng đồng và dư luận sẽ dần dẫn dev đến những sai lầm còn lớn hơn nữa.

Sai lầm 2: Phán đoán thiếu cẩn trọng

Nhắc đến vấn đề này, tôi lại nhớ đến một sự cố với website của American Airlines. Dustin Curtis có viết một bài blog phàn nàn về thiết kế giao diện của web này. Dustin chỉ viết để xả tức thôi, chứ cũng không mong đợi hồi âm gì cả.

Ấy vậy mà lại có, Anh nhận được một email từ người designer bên American Airlines. Người thiết kế front-end này thú nhận (từ này quan trọng lắm đấy) là trang web còn rất nhiều vấn đề phải giải quyết. Designer tiếp tục giải thích những khó khăn khi phải thiết kế cho các công ty lớn.

Anh designer này quá tốt đúng không?

Sai rồi. Đây cũng là một trường hợp phán đoán chộp giựt thiếu suy nghĩ. Hóa ra, American Airlines chả cho phép, và cũng chả muốn anh ta quá cởi mở với khách hàng như vậy.

Và kết quả, designer này bị sa thải.

Ý đồ của anh designer này, không nghi ngờ, rất đáng kính và cao thượng. Nhưng cứ cho là American Airlines là bên phạm lỗi đi. Anh ta có ở vị trí với quyền hạn hoặc nhiệm vụ cung cấp bồi thường không? Liệu anh ta có biết được mọi mặt của vấn đề?

Đáng lẽ anh ta phải tính đến hậu quả với hành động của mình: Đây quả thực là do lỗi thiết kế, hay lỗi người dùng, hay lỗi trình duyệt? Đây có thể là xung đột phần mềm hay không?

  • Email này sẽ đẩy cả American Airlines vào kiện tụng chứ?
  • Vụ lùm xùm này có ảnh hưởng đến các tranh chấp pháp lý hiện nay hay không?
  • Nguyên nhân thật sự của vấn đề?
  • Email này có thể làm bằng chứng (pháp lý) bất lợi cho công ty?

Trong trường hợp này, designer đã đưa ra đánh giá khi chưa hiểu hết được vấn đề. “Phán đoán thiếu cẩn trọng” không chỉ đưa đến các quyết định sai lầm, mà còn là lối suy nghĩ không xem công ty là công ty của mình. Và đồng nghiệp không phải là người thân của mình. Khi developer có quan điểm về công việc như vậy, họ không những đưa ra các quyết định sai lầm, mà còn đi đến những quyết định ảnh hưởng đến đồng lương của đồng nghiệp, và gây bao khó khăn gia đình của họ.

“Phán đoán thiếu cẩn trọng” mang nhiều hình thái:

  • Lộ bí mật công ty (đến người không nên lộ)
  • Sử dụng tài sản công ty sai mục đích
  • Hạ thấp đồng nghiệp hay sếp của mình
  • Vượt giới hạn trách nhiệm

Người designer này đáng lẽ phải hỏi Dustin thêm về trải nghiệm của anh. Và nhiều nhất là thông cảm với người này, chứ không nên đi quá giới hạn như vậy.

Sai lầm 3: Phòng thủ để giải tỏa áp lực

Có 3 cậu lập trình viên làm việc ở agency quảng cáo nọ, cả ba đều phải đáp ứng được deadline quan trọng. Họ buộc phải hoàn thành website cho khách hàng để kịp đáp ứng cho đợt marketing. Nhưng không may, deadline đã trôi qua, mà sản phẩm vẫn chưa hoàn thành.

Quy mô project tiếp tục mở rộng, với ngày càng nhiều tính năng chồng chất chờ họ hoàn thành trước ngày deadline ngày càng đến gần. Đây đây phải lỗi của họ.

Lỗi của họ ở đây là sự im lặng, cam chịu những thay đổi này mà không thèm hé môi một lời, dẫn đến tình huống deadline đến mà hàng không có như thế này đây.

Là con người, tất nhiên ai cũng sẽ từng ở trong tình huống như vậy, bị đổ lỗi khi có sự cố xảy ra. Và khi chúng ta bị công kích, ta sẽ đứng lên vì bản thân. Nhưng ba người này lại không làm như vậy.

Khi có vấn đề xuất hiện rành rành trước mặt, ta lại ngó lơ chả làm gì cả. Vấn đề ngày càng nghiêm trọng, ta cũng lại im re. Chỉ khi ta chạm phải hàng tá cảm xúc giận dữ áp lên mình, ta mới quyết định hành động, thường là với những câu nói biện minh như:

  • “Đúng rồi, nhưng mà…”
  • “Vậy chứ hồi anh/chị…”
  • “Ít nhất thì tôi cũng không…”
  • “Coi ai đang nói kìa! Cũng… vậy thôi.”

Nổi đóa lên và công kích bậy bạ là dấu hiện chúng ta đang “phòng thủ”. Khi điều đó sảy ra, ta đã đi quá giới hạn. Chúng ta đang tạo khó khăn khi người khác muốn ta giải thích vấn đề, hay tham gia vào ‘mâu thuẫn lành mạnh’.

Mới đầu, đa số mọi người sẽ chịu đựng hay cho qua được. Nhưng nếu chúng ta cứ tiếp tục lặp lại, khoảng cách quan hệ với đồng nghiệp sẽ ngày càng kéo giãn, và bạn sẽ mất việc khi người ta không còn kiên nhẫn được nữa.

Sai lầm 4: Phong tỏa & tự cô lập

Chúng ta sẽ lại bắt đầu với một tình huống. Công ty của bạn vừa giành được khách hàng, Sếp yêu cầu bạn đứng đầu project này. Khách hàng muốn sản phẩm thật cụ thể, như một site dùng Bootstrap chẳng hạn. Đồng nghiệp của bạn ngó lơ khách hàng, không nói gì cả.

Sau đó, họ “hồn nhiên như cô tiên” dùng Foundation thay cho Boostrap mà không nói tiếng nào với sếp hay khách hàng cả.

Sếp, và khách hàng của bị – vừa bị ‘phong tỏa’. Phong tỏa ở đây có thể được hiểu như sau: không biết hoặc cố tình không biết câu hỏi, hay yêu cầu, đặc biệt để hoãn hoặc ngăn chặn việc gì đó.

Đây là thói quen khá thường thấy trong ngành lập trình. Một lượng lập trinh viên không nhỏ trong cộng đồng đang có lối xử lý công việc như thế này. Sếp đòi A, dev lại nộp B. Xin lời khuyên, lại nhận được ánh nhìn trống rỗng.

Nói cách khác, thái độ này chả khác gì bắt nạt kiểu passive-aggressive (gây hấn thụ động) cả. Biểu hiện có thể rất đa dạng, từ ngó lơ đồng nghiệp và sếp của bạn, đến việc “quên” báo bạn khi có hợp hay sự kiện nào đó.

Giả sử bạn bị một đồng nghiệp ‘phong tỏa’. Bạn sẽ gặp phải tình cảnh như thế nào?

  • Họ giao tiếp bằng mắt với mọi người, trừ bạn ra
  • Bắt tay với mọi người khác, trừ bạn ra
  • Báo mọi người về sự kiện, hội hợp, buổi gặp gỡ; trừ bạn ra
  • Loại bạn khỏi communication loop.

Mô hình ‘phong tỏa’ này dần dần phá tan mọi mối quan hệ. Nếu bạn bị cho ra rìa, có thể bạn sẽ là người đầu tiên ra đi. Nên, đừng để bị bắt nạt nhé.

Sai lầm 5: Phê bình & Dè bỉu

Lập trình viên rất thông minh. Bạn đã được dạy dỗ và đào tạo để suy nghĩ một cách trừu tượng, từ trên xuống dưới, từ đầu đến cuối. Đây là một kỹ năng vô cùng quý báu và yêu cầu một mức tư duy khá cao. Nhưng sở trường luôn đi kèm sở đoản.

Trong đó có ‘chủ nghĩa tinh hoa’

‘Chủ nghĩa tinh hoa’ dựa trên sự thật đơn giản, bạn thường là người thông minh nhất phòng (tự sướng một chút). Nhưng như vậy, không có nghĩa bạn có thể đưa ra những phê bình trí tuệ hay dè bĩu xấu tính? Tuyệt đối không luôn.

Developer “có tiếng” là kiểu người thô ráp, cộc cằn, thậm chí trịch thượng. Chúng ta thường cười nhạo sự thiết hiểu biết (về lập trình) của khách hàng, khinh thường những lập trình viên khác, đối xử tồi tệ mọi người.

Điển hình như scandal của Linus Torvalds (cha đẻ của Linux), dí ngón tay giữa vào mặt Linux kernel developers. Ông vẫn khăng khăng thái độ của mình là đúng, và sẵn sàng tiến đến đe dọa “tay chân” và “chửi đổng” nếu bạn không đồng ý với ông.

Kiểu lập trình viên này rất thích thấy người khác thất bại. Để chứng minh người khác sai, thể hiện họ thông minh hơn hay tốt đẹp hơn mọi người khác. Họ thường dè bỉu theo một cách rất “dã man”, tàn nhẫn hay khi nhục.

Những lập trình viên này không biết rằng, thái độ như vậy sẽ giết chết đạo đức. Sẽ mất một khoản thời gian, nhưng người tuyển dụng sẽ nhanh chóng đào thải kiểu người “tiêu cực” như thế này.

Sai lầm 6: Lo ngại hậu quả

Codingo, StackExchange user, là một developer mới vào nghề. Lúc này đang làm công việc đầu tiên sau tốt nghiệp. Và vừa bị đánh rớt tại buổi đánh giá năng lực đầu tiên của mình.

Cậu ta bị chỉ trích vì đã hỏi quá nhiều câu hỏi. Hiển nhiên vẫn còn nhiều lý do nữa, như chất lượng code thấp. Nhưng dù gì, lý do này cũng quá kỳ cục, vì cậu ta chỉ hỏi để có thể giỏi hơn thôi mà.

Những lập trình viên quá phục tùng và dè dặt cũng từ đây là ra.

Làm sao tôi biết được? Cậu ta đã bị nỗi sợ lắp đầy. Trong những câu hỏi cậu ta đặt ra, cậu nói:

“Sau sáu tháng với công việc đầu tiên sau tốt nghiệp, tôi vừa bị đưa vào Performance Improvement Plan (kế hoạch cải thiện năng lực). Tôi biết chắc sớm muộn gì mình cũng bị đuổi, nhưng tôi muốn nghe một vài lời khuyên để tốt hơn trong tương lai.”

Cứ thể như tất cả sự chăm chỉ của cậu ta chẳng đáng một đồng nào cả.

Lập trình viên hiển nhiên luôn đối mặt với khối lượng việc quá tải. Mọi người luôn mong đợi ở họ những “điều kỳ diệu” trong những trường hợp “bất đắc kỳ tử” không báo trước gì cả. Để thêm phần thê thảm, người tuyển dụng còn muốn họ phải thật phục tùng.

Những lập trình viên không may ở trong tình thế này, rất chật vật để đáp ứng được hết “yêu sách”. Họ rất sợ phạm lỗi, sợ bị sa thải, nên họ sẽ hoàn thành lượng công việc ít nhất, chỉ vừa đủ để sống sót. Họ không có không gian và môi trường để sáng tạo, để khởi sướng; họ sẽ chỉ nói với ông chủ của mình bất cứ thứ gì họ nghĩ ổng muốn nghe.

Và sớm hay muộn, có phục tùng hay không, cuối cùng họ cũng bị sa thải.

Sai lầm 7: Chỉ tên, ngồi lê đôi mách & nói xấu người khác

Gilbert Gottfried (nghệ sĩ hài, và giọng lồng tiếng của chú vịt Aflac), quyết định viết status vui, đùa cợt về sóng thần Nhật Bản. Ngay sau thảm họa sóng thần năm 2011.

Ông xát muối vào nỗi đau của cả một dân tộc vào một thời điểm không thể thích hợp hơn, chả có gì vui ở đấy cả.

Aflac ngay lập tức sa thải ông.

Cộng đồng lập trình cũng hay chứng kiến những tình huống tương tự. Chúng ta đùa cợt về khách hàng, cấp trên, đồng nghiệp. Chúng ta cứ rôm rả mọi người khác ngu ngốc như thế nào.

Thay vì thảo luận chân thành về vấn đề, chúng ta lại ngồi châm chọc chua cay. Chúng ta biến nó thành chuyện cá nhân.

Nếu có người đề xuất ý kiến, ta sẽ bác bỏ ý kiến đó ngay (tất nhiên là bằng logic và lý lẽ). Chúng ta chỉ trích người khác trên mạng xã hội. Chúng ta sẽ hoàn toàn “tiêu diệt” họ, để họ biết được họ đang sai lầm cỡ nào.

Tệ hơn nữa, ta chửi thì cứ chửi, nhưng giải pháp lại chả đưa ra được cái nào cả.

Tại sao có nhiều người mắc những sai lầm này đến vậy

Những ai dính phải những sai lầm này, thường thiếu một trong những đức tính sau:

  1. Thái độ. những thành viên khó ưa và thiếu trung thực sẽ bòn rút sức sống của một team. Bạn sẽ học được cách tránh xa họ ra. Cấp trên bắt đầu để ý, và ngày tàn của họ đang đến gần.
  2. Đạo đức. Hậu quả của hành vi trái đạo đức sẽ tự động lan xa. Nếu bạn phát hiện đồng nghiệp đang trộm đồ, bạn sẽ khó xử. Nếu bạn làm ngơ, bạn sẽ mất uy tín khi mọi người phát hiện bạn đã biết mà không nói gì cả. Nếu bạn báo lại những gì bạn thấy, đồng nghiệp sẽ giảm lòng tin ở bạn vì đã báo lại chuyện đó.
  3. Khả năng phán đoán. Nếu bạn phán đoán thiếu cẩn trọng, ý tốt của bạn thường sẽ mang lại rắc rối. Và vì bạn có ý tốt, khả năng bạn trao đổi sự cố với người khác rất thấp, càng làm vấn đề nghiêm trọng hơn.

Nếu thiếu những tính chất trên, bạn đang trong vùng nguy hiểm. Câu hỏi đặt ra là, làm sao bạn có thể tránh phạm những sai lầm này, khi bạn còn lạ lẫm với những quy luật trên?

Đơn giản thôi. Hay chọn một “kiểu” người bạn muốn “đóng vai”.

Nhìn chung, trong cuộc sống, mỗi người được phân thành bốn “thế loại” sau:

  1. Đơn giản. Những dev này rất ngây thơ. Thực tế là không biết mô tê gì hết, nhưng cứ nghĩ là mình biết. Để trở thành kiểu người “ngây thơ (vô số tội)”, bạn chỉ việc thiếu kiến thức hay thiếu kinh nghiệm là đủ.
  2. Thằng khờ. Kiểu dev này hiểu luật. Họ biết họ cần phải làm gì, hay thậm chí là hậu quả nếu họ bơ vấn đề. Nhưng dù có biết thì họ vẫn ngó lơ như không thấy gì. Chỉ khi té nhào thì họ mới thấy đau, mới thấy hậu quả và học tập được. Nếu dành quá nhiều thời gian với kiểu người này, kiểu gì bạn cũng bị đau lây.
  3. Kẻ nhạo báng. Những dev không khác gì “thằng khờ”… dùng thuốc kích thích. Họ cười nhạo và làm bẽ mặt người khác, bất cứ ai . Họ có cảm giác thỏa mãn đặc biệt khi phát tán sự khinh miệt bất cứ nơi nào có mặt họ.
  4. Nhà “thông thái”. Những lập trình viên dày dặn kinh nghiệm này biết cách “thả con tép bắt con tôm”. Họ có thể phân tích và tiếp nhận feedback, ngay cả những feedback đầy mùi mỉa mai. Họ mang bản tính tò mò (chứ không phải tọc mạch), luôn đặt những câu hỏi hay ho và tìm đủ cách trả lời. Họ học tập và làm việc không ngừng để xây dựng hoàn thiện bản thân cùng những người xung quanh, bởi họ hiểu được kiểu người đơn giản là như thế nào.

Khi bạn đã quyết định (hoặc chấp nhận) được mình sẽ trở thành kiểu người nào, hãy tìm những người đáng tin có thể giúp bạn chạm được mục tiêu đó. Dành nhiều thời gian với họ, chia sẻ với họ những suy nghĩ và ý tưởng của bản thân.

Nếu bạn muốn thông thái, hãy tìm một người đàn anh thông thái, hay một senior làm ví dụ để hướng đến. Không cần biết đó là đồng nghiệp hay bạn bè; cũng không quan trọng nếu bạn gặp mặt trực tiếp hay online. Kiểu người thông thái thường có kinh nghiệm rất phong phú. Họ hiểu rõ môi trường xã hội, cũng như đã thành công nắm bắt thế giới “chính trị” nơi công sở. Hãy chia sẻ với họ những quyết định của bạn, học cách suy nghĩ như họ. Nhưng nên nhớ, bạn phải luôn là người tự đưa ra quyết định cuối cùng.

Khi bạn quyết định, hãy làm chủ lựa chọn đó. Như vậy, bạn có thể chuẩn bị bản thân trước bất cứ kết quả nào – ngay cả khi bạn mất việc.

Cũng có những trường hợp khác bị sa thải vì những lý do vô cùng nhỏ nhặt

Cảm giác mất việc rất đau khổ và ê chề. Đặc biệt khi bạn không làm gì sai cả.

Đúng thật như vậy: devs cũng bị sa thải vì những lý do vô cùng nhỏ nhặt.

Vấn đề về sai thả là như vầy, lý do họ đưa ra khi bạn bị sa thải, hiếm khi nào là lý do chân thực. Nếu nhân viên bị sa thải vì trộm tài sản. Đó cũng có thể là lý do thật sự, nhưng cũng có thể vì:

  • Tôi không tin tưởng anh được nữa
  • Tôi biết anh đã không thành thật
  • Tôi đang cần thải bớt người, cảm ơn đã cho tôi lý do nhá

Những khái niệm “vi mô” như mối quan hệ, uy tín, sự vui vẻ – còn quan trọng hơn khả năng code của bạn (vốn cũng rất quan trọng).

“Mấy ‘siêu sao’ hiển nhiên không phạm những lỗi này rồi.”

Sự thật là lại có đấy. Hãy tưởng tượng người bạn thân nhất giải trình với sếp, mách bạn trộm tài sản công ty. Kẻ tố cáo bạn sẽ cần phải có chứng cứ thật rõ ràng để gán tội lên đầu bạn. Ngay cả lúc này, bạn cũng có khả năng cao sẽ được tha thứ.

Không cần nghi nhờ, bạn có thể bị sa thải vì thiếu năng lực. Nhưng quá trình đi đến quyết định, hoàn toàn phụ thuộc vào những khái niệm “vi mô” ta đã bàn đến. Nắm bắt những khái niệm cao cấp này, bạn sẽ được tin tưởng hơn, tự tin hơn, và tôn trọng hơn – chính những khái niệm này sẽ bảo vệ vị trí của bạn.

Cho đến khi đồng nghiệp của họ bị bắt quả tang đang xem Porn

Nếu anh ta đã thuần thục những kỹ thuật cao cấp này,có khả năng cao, anh ta sẽ được cho qua. Điều này sẽ làm mọi người khó chịu, bạn cũng nên khó chịu.

Bạn sẽ chả bao giờ phạm mấy sai lầm ngu ngốc như vậy.

Như chúng ta đã thấy, chuyện không đơn giản như vậy. Những sai lầm này (gây tổn thất chi phí thảm trọng), tuy khá dễ nhận biết, ta biết đó là sai, nhưng lại vô cùng dễ dàng phạm phải.

Nhưng sau khi đọc bài, bạn đã là con người mới rồi. Bạn đã được phơi bày trước thực tế tàn khốc mà rất ít lập trình viên sẵn sàng chấp nhận. Hãy học hỏi những kỹ năng “thao túng” này từ những bậc thấy mà bạn biết. Cùng với sự luyện tập, bạn sẽ tránh bị những âm mưu của người khác hãm hại, và tránh được những sai lầm ngây ngô chết người.

ITZone via Sitepoint

Chia sẻ bài viết ngay

Nguồn bài viết : TechTalk