Tôi đang xem một đoạn mã. Đây có thể là mã tồi tệ nhất tôi từng thấy. Để chỉ cập nhật một bản ghi trong cơ sở dữ liệu, nó sẽ truy xuất tất cả các bản ghi trong bộ sưu tập rồi gửi yêu cầu cập nhật tới mọi bản ghi trong cơ sở dữ liệu, ngay cả những bản ghi không cần cập nhật. Có một hàm bản đồ chỉ trả về giá trị được truyền cho nó. Có các bài kiểm tra có điều kiện cho các biến có cùng giá trị, chỉ được đặt tên theo các kiểu khác nhau (firstName и first_name). Đối với mỗi CẬP NHẬT, mã sẽ gửi thông báo đến một hàng đợi khác, được xử lý bởi một hàm serverless khác, nhưng thực hiện tất cả công việc cho một bộ sưu tập khác trong cùng một cơ sở dữ liệu. Tôi đã đề cập rằng chức năng không có máy chủ này là từ “kiến trúc hướng dịch vụ” dựa trên đám mây chứa hơn 100 chức năng trong môi trường phải không?
Làm thế nào nó thậm chí có thể làm được điều này? Tôi che mặt và rõ ràng là đang nức nở vì cười. Đồng nghiệp của tôi hỏi chuyện gì đã xảy ra và tôi kể lại bằng màu sắc Lượt truy cập tệ nhất của BulkDataImporter.js 2018. Mọi người gật đầu thông cảm với tôi và đồng ý: sao họ có thể làm điều này với chúng tôi?
Sự tiêu cực: một công cụ cảm xúc trong văn hóa lập trình viên
Sự tiêu cực đóng một vai trò quan trọng trong lập trình. Nó gắn liền với văn hóa của chúng ta và được sử dụng để chia sẻ những gì chúng ta đã học được (“bạn không bạn sẽ tin điều đó, đoạn mã đó như thế nào!”), để bày tỏ sự cảm thông thông qua sự thất vọng (“Chúa ơi, TẠI SAO lại làm vậy?”), để thể hiện bản thân (“Tôi sẽ không bao giờ để đã không làm điều đó”), đổ lỗi cho người khác (“chúng tôi thất bại vì mã của anh ấy, không thể duy trì được”), hoặc, như thông lệ trong các tổ chức “độc hại” nhất, kiểm soát người khác thông qua một cảm giác xấu hổ (“Bạn thậm chí đang nghĩ về điều gì?” ? Đúng”).
Sự tiêu cực rất quan trọng đối với các lập trình viên vì nó là một cách rất hiệu quả để truyền tải giá trị. Tôi đã từng tham dự một trại lập trình và thông lệ tiêu chuẩn để truyền đạt văn hóa công nghiệp cho sinh viên là cung cấp rộng rãi các meme, câu chuyện và video, những nội dung phổ biến nhất được khai thác. . Thật tốt khi có thể sử dụng các công cụ cảm xúc để xác định Điều Tốt, Điều Xấu, Điều Xấu, Đừng Làm Điều Đó, Không bao giờ làm điều đó. Cần phải chuẩn bị cho những người mới làm quen với khả năng có thể sẽ bị đồng nghiệp ở xa CNTT hiểu lầm. Rằng bạn bè của họ sẽ bắt đầu bán cho họ những ý tưởng ứng dụng trị giá hàng triệu đô la. Rằng họ sẽ phải lang thang qua những mê cung vô tận của những mật mã lỗi thời với một đàn nhân ngưu quanh quẩn ở góc đường.
Khi mới học lập trình, sự hiểu biết của chúng ta về chiều sâu của “trải nghiệm lập trình” dựa trên việc quan sát phản ứng cảm xúc của người khác. Có thể thấy rõ điều này qua các bài viết trong , nơi có rất nhiều lập trình viên mới tham gia. Nhiều câu chuyện hài hước, ở mức độ này hay mức độ khác, mang màu sắc tiêu cực khác nhau: thất vọng, bi quan, phẫn nộ, trịch thượng, v.v. Và nếu điều này có vẻ chưa đủ với bạn, hãy đọc bình luận.
Tôi nhận thấy rằng khi các lập trình viên tích lũy được kinh nghiệm, họ ngày càng trở nên tiêu cực hơn. Những người mới bắt đầu, không nhận thức được những khó khăn đang chờ đợi mình, bắt đầu với lòng nhiệt tình và sẵn sàng tin rằng nguyên nhân của những khó khăn này chỉ đơn giản là do thiếu kinh nghiệm và kiến thức; và cuối cùng họ sẽ phải đối mặt với thực tế của mọi việc.
Thời gian trôi qua, họ tích lũy được kinh nghiệm và có khả năng phân biệt mã Tốt và Mã Xấu. Và khi thời điểm đó đến, các lập trình viên trẻ cảm thấy thất vọng khi phải làm việc với những đoạn mã rõ ràng là tệ. Và nếu họ làm việc theo nhóm (từ xa hoặc trực tiếp), họ thường áp dụng thói quen cảm xúc của những đồng nghiệp giàu kinh nghiệm hơn. Điều này thường dẫn đến sự tiêu cực gia tăng, bởi giới trẻ giờ đây có thể nói chuyện sâu sắc về code và phân chia nó thành tốt và xấu, từ đó chứng tỏ rằng họ “biết rõ”. Điều này càng củng cố thêm mặt tiêu cực: vì thất vọng, bạn dễ dàng hòa hợp với đồng nghiệp và trở thành thành viên của một nhóm; chỉ trích Bad Code sẽ nâng cao địa vị và tính chuyên nghiệp của bạn trong mắt người khác: .
Sự tiêu cực gia tăng không hẳn là một điều xấu. Các cuộc thảo luận về lập trình, trong số những thứ khác, cực kỳ tập trung vào chất lượng của mã được viết. Mã này hoàn toàn xác định chức năng mà nó dự định thực hiện (ngoài phần cứng, mạng, v.v.), vì vậy điều quan trọng là bạn có thể bày tỏ ý kiến của mình về mã đó. Hầu như tất cả các cuộc thảo luận đều xoay quanh việc liệu mã có đủ tốt hay không và lên án chính những biểu hiện của mã xấu về mặt ý nghĩa cảm xúc đặc trưng cho chất lượng của mã:
- "Có rất nhiều điểm không nhất quán về logic trong mô-đun này, nó là một ứng cử viên sáng giá để tối ưu hóa hiệu suất đáng kể."
- “Mô-đun này khá tệ, chúng ta cần cấu trúc lại nó.”
- "Mô-đun này không có ý nghĩa gì, nó cần phải được viết lại."
- “Mô-đun này tệ quá, nó cần được vá lại.”
- “Đây là một mảnh ram, không phải mô-đun, nó không cần phải viết gì cả, tác giả của nó đang nghĩ cái quái gì vậy.”
Nhân tiện, chính sự "giải tỏa cảm xúc" này đã khiến các nhà phát triển gọi mã là "sexy", điều này hiếm khi công bằng - trừ khi bạn làm việc tại PornHub.
Vấn đề là con người là những sinh vật kỳ lạ, bồn chồn, giàu cảm xúc và việc nhận thức cũng như biểu hiện bất kỳ cảm xúc nào đều thay đổi chúng ta: lúc đầu một cách tinh tế, nhưng theo thời gian, sẽ thay đổi đáng kể.
Một con dốc trơn trượt rắc rối của tiêu cực
Một vài năm trước, tôi là trưởng nhóm không chính thức và đã phỏng vấn một nhà phát triển. Chúng tôi thực sự thích anh ấy: anh ấy thông minh, hỏi những câu hỏi hay, hiểu biết về công nghệ và rất phù hợp với văn hóa của chúng tôi. Tôi đặc biệt ấn tượng bởi sự tích cực và sự dũng cảm của anh ấy. Và tôi đã thuê anh ta.
Vào thời điểm đó, tôi đã làm việc ở công ty được vài năm và cảm thấy văn hóa của chúng tôi không hiệu quả lắm. Chúng tôi đã cố gắng ra mắt sản phẩm hai, ba lần và một vài lần nữa trước khi tôi đến, điều này dẫn đến chi phí làm lại lớn, trong thời gian đó chúng tôi không có gì để trưng bày ngoại trừ những đêm dài, thời hạn chặt chẽ và những sản phẩm hoạt động. Và mặc dù tôi vẫn đang làm việc chăm chỉ nhưng tôi vẫn nghi ngờ về thời hạn cuối cùng mà ban quản lý giao cho chúng tôi. Và anh ấy thản nhiên chửi thề khi thảo luận về một số khía cạnh của mã với đồng nghiệp của tôi.
Vì vậy, không có gì đáng ngạc nhiên—dù tôi cũng rất ngạc nhiên—rằng vài tuần sau, chính nhà phát triển mới đó cũng nói những điều tiêu cực tương tự như tôi đã làm (bao gồm cả việc chửi thề). Tôi nhận ra rằng anh ấy sẽ cư xử khác ở một công ty khác với nền văn hóa khác. Anh ấy chỉ thích nghi với nền văn hóa mà tôi tạo ra. Tôi choáng ngợp với cảm giác tội lỗi. Vì kinh nghiệm chủ quan của mình, tôi đã gieo rắc sự bi quan vào một người mới đến mà tôi cho là hoàn toàn khác. Ngay cả khi anh ấy thực sự không như vậy và chỉ giả vờ để chứng tỏ rằng anh ấy có thể hòa nhập, tôi vẫn áp đặt thái độ tồi tệ của mình với anh ấy. Và mọi điều được nói ra, dù là đùa cợt hay thoáng qua, đều có cách xấu để biến thành điều người ta tin.
Những cách tiêu cực
Hãy quay lại với những cựu lập trình viên newbie của chúng ta, những người đã có được một chút trí tuệ và kinh nghiệm: họ đã quen thuộc hơn với ngành lập trình và hiểu rằng code xấu ở khắp mọi nơi, không thể tránh khỏi. Nó xảy ra ngay cả ở những công ty tiên tiến nhất tập trung vào chất lượng (và hãy để tôi lưu ý: rõ ràng, sự hiện đại không bảo vệ khỏi mã xấu).
Kịch bản hay. Theo thời gian, các nhà phát triển bắt đầu chấp nhận rằng mã xấu là một thực tế của phần mềm và công việc của họ là cải thiện nó. Và nếu không thể tránh được mã xấu thì việc làm ầm ĩ lên về nó cũng chẳng ích gì. Họ đi theo con đường Thiền, tập trung vào giải quyết các vấn đề hoặc nhiệm vụ mà họ phải đối mặt. Họ học cách đo lường và truyền đạt chính xác chất lượng phần mềm cho chủ doanh nghiệp, viết các ước tính có căn cứ dựa trên số năm kinh nghiệm của họ và cuối cùng nhận được những phần thưởng hậu hĩnh cho giá trị đáng kinh ngạc và liên tục của họ đối với doanh nghiệp. Họ làm tốt công việc của mình đến mức được trả 10 triệu USD tiền thưởng và nghỉ hưu để làm những gì họ muốn trong suốt quãng đời còn lại (xin đừng coi đó là điều hiển nhiên).
Một kịch bản khác là con đường của bóng tối. Thay vì chấp nhận mã xấu như một điều không thể tránh khỏi, các nhà phát triển tự mình chỉ ra mọi thứ xấu trong thế giới lập trình để họ có thể khắc phục nó. Họ từ chối cải thiện mã xấu hiện có vì nhiều lý do chính đáng: “mọi người nên biết nhiều hơn và đừng ngu ngốc như vậy”; "thật khó chịu"; “điều này không tốt cho việc kinh doanh”; “điều này chứng tỏ tôi thông minh đến mức nào”; “nếu tôi không nói cho bạn biết đây là một đoạn mã tệ hại như thế nào thì cả công ty sẽ chìm xuống biển,” v.v.
Chắc chắn không thể thực hiện được những thay đổi mà họ mong muốn vì tiếc rằng doanh nghiệp phải tiếp tục phát triển và không thể dành thời gian lo lắng về chất lượng của code, những người này mang tiếng là người hay phàn nàn. Họ được giữ lại vì năng lực cao, nhưng bị đẩy ra rìa công ty, nơi họ sẽ không làm phiền nhiều người nhưng vẫn sẽ hỗ trợ vận hành các hệ thống quan trọng. Không tiếp cận được các cơ hội phát triển mới, họ sẽ mất đi các kỹ năng và không còn đáp ứng được nhu cầu của ngành. Sự tiêu cực của họ biến thành sự cay đắng cay đắng, và kết quả là họ nuôi dưỡng cái tôi của mình bằng cách tranh luận với những sinh viên hai mươi tuổi về hành trình mà công nghệ cũ yêu thích của họ đã trải qua và tại sao nó vẫn còn hot đến vậy. Cuối cùng, họ nghỉ hưu và sống đến già và chửi bới chim chóc.
Thực tế có lẽ nằm ở đâu đó giữa hai thái cực này.
Một số công ty đã cực kỳ thành công trong việc tạo ra những nền văn hóa cực kỳ tiêu cực, thiển cận và ý chí mạnh mẽ (như Microsoft trước đây). ) - đây thường là những công ty có sản phẩm hoàn toàn phù hợp với thị trường và có nhu cầu phát triển nhanh nhất có thể; hoặc các công ty có hệ thống chỉ huy và kiểm soát theo thứ bậc (Apple trong những năm thành công nhất của Jobs), nơi mọi người đều làm những gì họ được yêu cầu. Tuy nhiên, nghiên cứu kinh doanh hiện đại (và lẽ thường) cho thấy rằng sự khéo léo tối đa, dẫn đến sự đổi mới trong công ty và năng suất cao ở các cá nhân, đòi hỏi mức độ căng thẳng thấp để hỗ trợ tư duy sáng tạo và có phương pháp liên tục. Và cực kỳ khó để thực hiện công việc sáng tạo, dựa trên thảo luận nếu bạn thường xuyên lo lắng về những gì đồng nghiệp sẽ nói về từng dòng mã của bạn.
Tiêu cực là kỹ thuật văn hóa đại chúng
Ngày nay, thái độ của các kỹ sư được chú ý nhiều hơn bao giờ hết. Trong các tổ chức kỹ thuật, quy tắc “". Ngày càng có nhiều giai thoại và câu chuyện xuất hiện trên Twitter về những người rời bỏ nghề này vì họ không thể (sẽ) tiếp tục chịu đựng thái độ thù địch và ác ý đối với người ngoài. Ngay cả Linus Torvalds năm thù địch và chỉ trích đối với các nhà phát triển Linux khác - điều này đã dẫn đến tranh luận về tính hiệu quả của phương pháp này.
Một số người vẫn bảo vệ quyền phê phán của Linus - những người lẽ ra phải biết nhiều về ưu và nhược điểm của "sự tiêu cực độc hại". Đúng, sự lịch sự là vô cùng quan trọng (thậm chí là cơ bản), nhưng nếu tóm tắt lại những lý do khiến nhiều người trong chúng ta để cho việc bày tỏ quan điểm tiêu cực trở thành “độc hại” thì những lý do này có vẻ gia trưởng hoặc trẻ con: “họ đáng bị như vậy vì họ là những kẻ ngốc”. ", "anh ấy phải chắc chắn rằng họ sẽ không tái phạm nữa", "nếu họ không làm vậy thì anh ấy sẽ không phải la mắng họ", v.v. Một ví dụ về tác động của phản ứng cảm xúc của người lãnh đạo đối với cộng đồng lập trình là từ viết tắt MINASWAN của cộng đồng Ruby - "Matz rất tử tế nên chúng tôi rất tử tế."
Tôi nhận thấy rằng nhiều người ủng hộ nhiệt thành phương pháp "giết kẻ ngốc" thường quan tâm rất nhiều đến chất lượng và tính chính xác của mã, đồng thời xác định bản thân họ với công việc của họ. Thật không may, họ thường nhầm lẫn độ cứng với độ cứng. Nhược điểm của vị trí này bắt nguồn từ mong muốn đơn giản nhưng không hiệu quả của con người là cảm thấy mình vượt trội hơn người khác. Những người đắm chìm trong ham muốn này sẽ bị mắc kẹt trong con đường bóng tối.
Thế giới lập trình đang phát triển nhanh chóng và đang vượt qua ranh giới của vùng chứa nó - thế giới không lập trình (hay thế giới lập trình là vùng chứa cho thế giới không lập trình? Câu hỏi hay).
Khi ngành công nghiệp của chúng ta mở rộng với tốc độ ngày càng nhanh và việc lập trình trở nên dễ tiếp cận hơn, khoảng cách giữa “công nghệ” và “thông thường” đang nhanh chóng thu hẹp. Thế giới lập trình ngày càng tiếp xúc với sự tương tác giữa các cá nhân của những người lớn lên trong nền văn hóa mọt sách biệt lập của thời kỳ đầu bùng nổ công nghệ, và chính họ là những người sẽ định hình thế giới lập trình mới. Và bất chấp bất kỳ tranh luận xã hội hay thế hệ nào, tính hiệu quả nhân danh chủ nghĩa tư bản sẽ thể hiện trong văn hóa công ty và phương pháp tuyển dụng: những công ty tốt nhất sẽ không thuê bất kỳ ai không thể tương tác trung lập với người khác, chứ đừng nói đến việc có mối quan hệ tốt.
Những gì tôi học được về sự tiêu cực
Nếu bạn để quá nhiều tiêu cực kiểm soát tâm trí và tương tác của mình với mọi người, trở thành độc hại thì sẽ gây nguy hiểm cho nhóm sản phẩm và gây tốn kém cho doanh nghiệp. Tôi đã thấy (và nghe nói) vô số dự án tan rã và được xây dựng lại hoàn toàn với chi phí rất lớn vì một nhà phát triển đáng tin cậy có ác cảm với công nghệ, nhà phát triển khác hoặc thậm chí một tệp duy nhất được chọn để thể hiện chất lượng của toàn bộ cơ sở mã.
Sự tiêu cực cũng làm mất tinh thần và phá hủy các mối quan hệ. Tôi sẽ không bao giờ quên việc một đồng nghiệp đã mắng tôi vì đưa CSS vào sai tệp, điều đó khiến tôi khó chịu và không cho phép tôi thu thập suy nghĩ trong vài ngày. Và trong tương lai, tôi khó có thể cho phép một người như vậy ở gần một trong những đội của mình (nhưng ai biết được, mọi người sẽ thay đổi).
Cuối cùng, tiêu cực .
Tôi nghĩ đây chính là nội dung của một lớp học nâng cao về nụ cười.
Tất nhiên, đây không phải là lập luận ủng hộ việc rạng rỡ hạnh phúc, chèn mười tỷ biểu tượng cảm xúc vào mỗi yêu cầu kéo hoặc tham gia một lớp học nâng cao về nụ cười (không, à, nếu đó là điều bạn muốn thì không cần bàn cãi). Sự tiêu cực là một phần cực kỳ quan trọng trong lập trình (và cuộc sống con người), báo hiệu chất lượng, cho phép một người bày tỏ cảm xúc và đồng cảm với đồng loại. Sự tiêu cực cho thấy sự sáng suốt và thận trọng, chiều sâu của vấn đề. Tôi thường nhận thấy rằng một nhà phát triển đã đạt đến một cấp độ mới khi anh ta bắt đầu bày tỏ sự hoài nghi về những gì trước đây anh ta còn rụt rè và không chắc chắn. Mọi người thể hiện tính hợp lý và tự tin với ý kiến của mình. Bạn không thể bác bỏ biểu hiện tiêu cực, đó sẽ là kiểu Orwellian.
Tuy nhiên, sự tiêu cực cần được điều chỉnh và cân bằng với những phẩm chất quan trọng khác của con người: sự đồng cảm, kiên nhẫn, thấu hiểu và hài hước. Bạn luôn có thể nói với một người rằng anh ta đã làm sai mà không cần la hét hay chửi thề. Đừng đánh giá thấp cách tiếp cận này: nếu ai đó nói với bạn mà không có bất kỳ cảm xúc nào rằng bạn đã sai lầm nghiêm trọng thì điều đó thực sự đáng sợ.
Vào thời điểm đó, vài năm trước, CEO đã nói chuyện với tôi. Chúng tôi thảo luận về tình trạng hiện tại của dự án, sau đó anh ấy hỏi tôi cảm thấy thế nào. Tôi trả lời rằng mọi thứ đều ổn, dự án đang tiến triển, chúng tôi đang làm việc chậm chạp, có lẽ tôi đã bỏ sót điều gì đó và cần phải xem xét lại. Anh ấy nói rằng anh ấy đã nghe tôi chia sẻ những suy nghĩ bi quan hơn với các đồng nghiệp trong văn phòng và những người khác cũng nhận thấy điều này. Anh ấy giải thích rằng nếu tôi có nghi ngờ, tôi hoàn toàn có thể bày tỏ với ban quản lý chứ không thể “gỡ bỏ”. Là một kỹ sư trưởng, tôi phải lưu tâm đến việc lời nói của mình ảnh hưởng đến người khác như thế nào vì tôi có rất nhiều ảnh hưởng ngay cả khi tôi không nhận ra điều đó. Và anh ấy đã nói với tôi tất cả những điều này một cách rất tử tế, và cuối cùng nói rằng nếu tôi thực sự cảm thấy như vậy thì có lẽ tôi cần phải suy nghĩ về những gì tôi muốn cho bản thân và sự nghiệp của mình. Đó là một cuộc trò chuyện cực kỳ nhẹ nhàng, bắt đầu hoặc rời khỏi chỗ ngồi của bạn. Tôi cảm ơn anh ấy vì thông tin về thái độ thay đổi của tôi trong hơn sáu tháng đã ảnh hưởng đến những người khác mà tôi không để ý.
Đó là một ví dụ về sự quản lý hiệu quả, đáng chú ý và sức mạnh của cách tiếp cận mềm mại. Tôi nhận ra rằng dường như tôi chỉ hoàn toàn tin tưởng vào công ty và khả năng đạt được mục tiêu của công ty, nhưng trên thực tế, tôi đã nói chuyện và giao tiếp với người khác theo một cách hoàn toàn khác. Tôi cũng nhận ra rằng ngay cả khi cảm thấy hoài nghi về dự án mình đang thực hiện, tôi cũng không nên bộc lộ cảm xúc của mình với đồng nghiệp và gieo rắc sự bi quan như lây lan, làm giảm cơ hội thành công của chúng tôi. Thay vào đó, tôi có thể tích cực truyền đạt tình hình thực tế cho quản lý của mình. Và nếu tôi cảm thấy họ không lắng nghe mình, tôi có thể bày tỏ sự không đồng tình bằng cách rời công ty.
Tôi nhận được cơ hội mới khi đảm nhận vị trí trưởng phòng đánh giá nhân sự. Với tư cách là cựu kỹ sư trưởng, tôi rất cẩn thận trong việc bày tỏ ý kiến của mình về mã kế thừa (không ngừng cải tiến) của chúng tôi. Để chấp thuận một thay đổi, bạn cần phải tưởng tượng ra tình huống hiện tại, nhưng bạn sẽ chẳng đi đến đâu nếu đắm chìm trong tiếng rên rỉ, tấn công hoặc những điều tương tự. Cuối cùng, tôi ở đây để hoàn thành một nhiệm vụ và không nên phàn nàn về mã để hiểu, đánh giá hoặc sửa mã.
Trên thực tế, tôi càng kiểm soát phản ứng cảm xúc của mình đối với mật mã thì tôi càng hiểu nó có thể trở thành gì và tôi càng ít cảm thấy bối rối hơn. Khi tôi bày tỏ bản thân một cách kiềm chế (“ở đây phải có chỗ để cải thiện hơn nữa”), tôi đang làm cho bản thân và những người khác hạnh phúc và không coi tình hình là quá nghiêm trọng. Tôi nhận ra rằng tôi có thể kích thích và giảm bớt sự tiêu cực ở người khác bằng cách tỏ ra hợp lý một cách hoàn hảo (thật khó chịu?) (“bạn nói đúng, mã này khá tệ, nhưng chúng tôi sẽ cải thiện nó”). Tôi vui mừng thấy mình có thể đi được bao xa trên con đường Thiền.
Về cơ bản, tôi không ngừng học đi học lại một bài học quan trọng: cuộc đời quá ngắn ngủi để thường xuyên tức giận và đau đớn.
Nguồn: www.habr.com