Tôi đã trở thành Nhà phát triển 100x như thế nào - Khi còn là một Junior

Ý tưởng về một nhà phát triển 10x, hay một nhà phát triển ngôi sao nhạc rock, giỏi hơn mọi nhà phát triển khác ở mọi lĩnh vực, là một chuyện hoang đường.

Thay vào đó, bạn nên cố gắng trở thành nhà phát triển 100x trong các tình huống rất cụ thể, nhà phát triển 10x trong một số trường hợp và nhà phát triển 1x trong nhiều trường hợp nhất có thể. Điều quan trọng là phải nhận thức được những lĩnh vực mà bạn xuất sắc và những lĩnh vực mà bạn có thể cần phải cải thiện.

Trừ khi bạn làm việc cho một công ty công nghệ lớn, còn không thì rất có thể bạn sẽ phải đảm đương nhiều nhiệm vụ. Trên cơ sở hàng ngày, bạn sẽ cần có khả năng chuyển đổi giữa phát triển giao diện người dùng, phụ trợ và phát triển theo ngôn ngữ cụ thể, chẳng hạn như Java hoặc TypeScript. Điều này là do tính chất luôn thay đổi trong ngành của chúng ta và vô số cách để đạt được các nhiệm vụ giống nhau - chẳng hạn như in “Xin chào thế giới” bằng hơn 400 ngôn ngữ lập trình khác nhau.

Không thể giỏi tất cả mọi thứ, nhưng có thể trở nên tuyệt vời ở một thứ gì đó.

Để giải thích chi tiết hơn, tôi muốn chia sẻ một câu chuyện từ hơn một thập kỷ trước, đó là thời điểm thay đổi cuộc đời và có tác động rất lớn đến sự nghiệp của tôi.

Tôi đã trở thành Nhà phát triển 100x như thế nào - khi còn là một Junior

Tôi đã làm việc với một MNC lớn và là thành viên của một nhóm đang phải vật lộn để theo kịp nhu cầu.

Họ đã xây dựng một ứng dụng web Java tùy chỉnh mà hàng nghìn nhân viên đang sử dụng hàng ngày, nhưng khi số lượng bản ghi vào và ra khỏi máy chủ SQL tăng lên. Mọi thứ đang chậm lại. Họ đã nâng cấp máy chủ SQL đến giới hạn của nó và cần các giải pháp mới. Một điều hiển nhiên là sử dụng memcache để lưu trữ một số kết quả.

Thật không may, memcache đã bị cấm do một số sự cố bảo mật trong quá khứ và thiếu HA. Các nhà quản lý đã cố gắng xin phép memcache trong hơn một năm nhưng không thành công. Trong khi đó, các nhà phát triển đã chiến đấu trong một trận chiến khó khăn khi mỗi 10% cải thiện đều bị phủ nhận bởi gấp đôi mức tăng trưởng người dùng.

Đây là nơi tôi đến và tham gia.

Tôi không biết gì về 1 năm đấu tranh vừa qua của họ và đã được mời làm nhà phát triển cấp dưới để giúp thực hiện một số cải tiến nhỏ cho giao diện người dùng, trong khi các tiền bối tập trung vào hiệu suất.

Tuy nhiên vì, tôi rất khó chịu vì hiệu suất chậm của máy chủ nhà phát triển. Và tôi đã chơi với Hazelcast - một thư viện bộ nhớ đệm và cụm máy chủ hoàn toàn mới dựa trên Java.

Tôi đã sử dụng nó như một giải pháp thay thế cho memcache. Và đã có thể làm cho nó chạy trên ứng dụng không có hạn chế đặc biệt hoặc yêu cầu phê duyệt đặc biệt nào đã giết chết tất cả các giải pháp trước đó.

Và đã có một nguyên mẫu hoạt động với bản demo sẵn sàng trong cùng một tuần. Đối với một trang trong nền tảng, lệnh gọi API kéo dài từ hơn 10 giây xuống dưới một giây. Đó là một người thay đổi cuộc chơi.

Toàn bộ nhóm đã bắt tay vào làm và trong vòng một tháng, chúng tôi đã có một "giải pháp phân cụm chắc chắn không phải là memcache" trong quá trình sản xuất.

Khi người quản lý nhóm của tôi và sếp của anh ấy chiêu đãi mọi người một bữa tiệc, người quản lý của tôi nói với tôi rằng khi anh ấy đưa tôi vào làm việc như một đứa trẻ thông minh, anh ấy chưa bao giờ mong đợi tôi trở thành một lập trình viên 10x hoặc 100x có thể giải quyết vấn đề của họ chỉ sau một đêm.

Và câu nói đó đã tác động mạnh đến tôi.

Bởi vì tôi là một kẻ mạo danh – chẳng qua là một kẻ mạo danh may mắn.

Kẻ mạo danh may mắn – Ai là nhà phát triển 0,1x

Về mặt kỹ thuật, tôi không phải là nhà phát triển 1x hay thậm chí là 10x. Tôi biết ít hơn các đồng đội của mình và tôi đang học hỏi trong công việc.

Các đồng nghiệp của tôi có thể làm giao diện người dùng tốt hơn tôi và nhóm biết cách tối ưu hóa SQL (và đã dạy tôi, cảm ơn!). Tín dụng lớn nhất của tôi là tôi đã có thể thực hiện tương đương với “phép lạ cài đặt npm” và đọc hướng dẫn cách định cấu hình nó.

Nhìn lại, có rất nhiều vấn đề mà tôi đã may mắn tránh được.

• Chính trị (đã chặn memcache ngay từ đầu)
• Trường hợp sử dụng (chúng tôi không có sự an toàn về tranh chấp ghi, nghĩa là nếu 2 lần chỉnh sửa xảy ra trong cùng một ms, bộ đệm sẽ bị cập nhật kém. Rất may, điều này hiếm khi xảy ra)
• Tính ổn định (v1 của hazelcast gặp sự cố như điên, may mắn thay, máy chủ API được thiết kế để triển khai ở chế độ HA, vì vậy điều này gây khó chịu nhất cho nhóm cơ sở hạ tầng)
• Bảo mật (Có một cổng mở cho tất cả dữ liệu trên máy chủ API trong một cụm, về phía tôi là một ý tưởng tồi và là một sai lầm rất nhỏ cho đến khi một tiền bối khác đọc tài liệu về cách bảo mật nó)
• Ngăn xếp ngôn ngữ (nếu máy chủ bằng Python, .NET, C# hoặc Ruby, tôi sẽ không biết làm thế nào để bao gồm bộ đệm cụm cục bộ)

Tôi đã may mắn có được một số ít những chú ngựa con chỉ biết một mẹo, giúp tôi kiếm được gấp 100 lần trong những tình huống phù hợp. Điều này chỉ có thể thực hiện được nhờ công việc nền tảng được thực hiện bởi các thành viên còn lại trong nhóm.

Tôi cũng may mắn khi các quản lý và sếp của tôi cho phép tôi chọn những vấn đề mà tôi muốn khắc phục, vì họ nhanh chóng theo dõi tôi và giao tôi cho nhiều nhóm để "khắc phục sự cố của họ". Trong khi cho phép tôi tối đa hóa tỷ lệ may mắn trên tác động của mình và lặp lại “phép màu”.

Với kinh nghiệm, tôi cũng nhận ra điều ngược lại – tôi chậm phát triển front-end. Đây là điều ban đầu tôi phải làm trước khi được thăng tiến nhanh chóng với tư cách là một kỹ sư 10x và nó khiến tôi suy ngẫm rất nhiều trong nhiều năm. Vì nó có thể là con đường mà tôi sẽ bị mắc kẹt.

Tôi cũng nhận ra rằng trong nhận thức muộn màng, đã "làm chủ" hazelcast và nhiều công nghệ khác. Nó sẽ thất bại biết bao nhiêu đối với các đội khác, ngay cả trong cùng một tổ chức, nếu không phải vì tình huống duy nhất và các biện pháp bảo vệ, những thứ lẽ ra phải được ghi nhận cho những người còn lại trong đội.

Tôi đã may mắn, với tư cách là một đàn em, nếu có bất cứ điều gì khác.

Đây là lý do tại sao Senior Developer có xu hướng trở thành Junior Developer gấp 10 lần

Khi chúng ta nhìn xa hơn những khái quát về kỹ thuật, rõ ràng là mọi người đều có kỹ năng của mình, có thể dao động từ 100x đến 0,1x.

Trong nhiều năm, khi tôi chuyển qua nhiều nhóm và dự án, cuối cùng tôi đã trở thành một nhà phát triển “cao cấp”. Trong thời gian này, tôi nhận ra rằng những người lớn tuổi thường có nhiều kỹ năng hơn và biết họ giỏi và dở ở điểm nào. Họ có thể chủ động thông báo cho người quản lý của mình và ưu tiên các nhiệm vụ phù hợp. Điều này không có nghĩa là họ biết cách làm mọi thứ, nhưng điều đó có nghĩa là họ biết những gì không nên làm.

Mặt khác, những người trẻ tuổi phải vật lộn với điều này vì họ thiếu kinh nghiệm để biết họ giỏi hay dở ở điểm nào. Không có cách nào dễ dàng để tìm ra điều này ngoài việc chỉ “thử”.

Một khi hiểu được điều này, rõ ràng là tất cả chỉ nhằm tối đa hóa số lượng những việc bạn biết mình có thể làm tốt và đáng tin cậy. Đó cũng là việc tối đa hóa yếu tố may mắn của bạn khi được giao nhiệm vụ và đảm bảo rằng bạn không bị mắc kẹt với những thứ mà bạn không giỏi.

Theo một cách nào đó đối với đàn em, sự tiến bộ của họ sẽ phụ thuộc rất nhiều vào sự liên kết giữa may mắn và kỹ năng của họ. Người cao niên, có nhiều quyền kiểm soát hơn (nhưng không đầy đủ), về cách điều khiển tiến trình của họ.

Trong trường hợp này: May mắn không phải là nhị phân. Bạn có thể tăng số lượng các tình huống phù hợp với bạn.

Làm thế nào để tối đa hóa vận may của bạn ở mức 100x và 10x

Đối với tất cả mọi người, nhưng đặc biệt là đối với những người mới bắt đầu và những người mới bắt đầu, điều tốt nhất nên làm là tiếp tục thử những điều mới trong công nghệ và khám phá. Điều này sẽ giúp bạn tìm ra những gì bạn giỏi và những gì bạn kém.

Đối với những người có ý tưởng tốt hơn về những gì họ giỏi, bước tiếp theo là mở rộng số lượng tình huống mà họ có thể thực hiện tốt nhất. Điều này liên quan đến một số thực hành và nghiên cứu về các công nghệ liền kề với những công nghệ mà họ đã biết. Một khi bạn trở nên xuất sắc ở một lĩnh vực nào đó, hãy đảm bảo sở hữu nó để người quản lý và sếp của bạn biết rằng đây là thứ họ nên trao cho bạn. Điều này sẽ tăng cơ hội đạt được các tình huống 10x hoặc 100x đó thường xuyên hơn.

Hãy tìm ra ít nhất một thứ mà bạn giỏi, ngay cả khi đó là một thứ rất nhỏ và hạn hẹp. Xây dựng từ đó. (Một số ví dụ đáng chú ý bao gồm regex và cấu hình webpack.)

Đối với người cao niên, nếu bạn chưa làm như vậy, hãy bắt đầu nhìn xa hơn các khía cạnh kỹ thuật của sự phát triển. Điều này không có nghĩa là bạn phải chuyển sang làm quản lý. Nhưng với kiến thức kỹ thuật độc đáo của mình, bạn có thể đóng vai trò tích cực hơn trong việc hiểu trường hợp sử dụng của người dùng hoặc doanh nghiệp. Điều này sẽ cho phép bạn tối ưu hóa với người quản lý của mình để đảm bảo tỷ lệ thành công gấp 10 hoặc 100 lần cho bạn và nhóm của bạn.

Đối với những người đang tìm việc, nếu bạn biết mình giỏi một thứ gì đó, ngay cả khi nó gấp 10 lần, hãy thực hiện một số nghiên cứu và tìm hiểu sâu hơn về quá trình tìm việc của bạn. Cố gắng tìm một công ty khởi nghiệp hoặc MNC được tài trợ tốt đang gặp khó khăn trong chính lĩnh vực mà bạn giỏi. Mặc dù điều này có thể khó thực hiện và liên quan đến một số mạng lưới, nhưng nếu bạn đặt mình vào đúng thời điểm và địa điểm, nó sẽ tối đa hóa tác động cho cả bạn và công ty có liên quan.

Đây là tất cả những điều, bạn có thể làm từ từ theo thời gian, để cải thiện yếu tố may mắn. Và cung cấp trải nghiệm gấp 10 lần đó một cách nhất quán hơn.

Đặc biệt hét to để đọc bài viết swyx về cách tạo may mắn: swyx.io/create-luck

Với tư cách là CTO và Trưởng nhóm ngày nay, điều này vẫn đúng - 10x là chuyện hoang đường - Mọi người đều là 100x và 0,1x

Một số người có thể nghĩ rằng CTO của một công cụ kiểm tra giao diện người dùng như Uilicious.com sẽ phù hợp với các công nghệ giao diện người dùng. Tuy nhiên, điều này là xa sự thật. Nhân viên mới hoặc cấp dưới trung bình của chúng tôi trong công ty thường nhanh hơn tôi, CTO khi viết các thành phần giao diện người dùng với các khung giao diện người dùng hiện đại như Vue.js hoặc React.

Điều này đã thay đổi quan điểm của tôi với tư cách là trưởng nhóm/quản lý. Nó cho tôi thấy huyền thoại về kỹ sư 10x độc hại và tồi tệ như thế nào. Đó là sự đơn giản hóa quá mức các nhãn và khái quát hóa các tình huống rất độc đáo. Đó là một quan niệm sai lầm độc hại cần được sửa chữa.

Hầu hết mọi huyền thoại về kỹ sư 10x khởi nghiệp, khi tìm hiểu sâu hơn, hóa ra đều có một cá nhân với kiến thức độc đáo ở đúng nơi và đúng lúc. Và đã có thể tránh được các nhiệm vụ mà họ đã thực hiện 0,1 lần.

Trong trường hợp của tôi, nó đang tập trung vào cơ sở hạ tầng hơn là phát triển giao diện người dùng. Thay vào đó, tôi có các thành viên khác trong nhóm giỏi hơn gấp 1000 lần trong việc phát triển giao diện người dùng.

Đây là một nhận thức quan trọng với tư cách là người quản lý bởi vì, đối với mỗi cá nhân làm 100 lần một nhiệm vụ, sẽ có một nhiệm vụ khiến họ phải làm 0,1 lần khi họ bị mắc kẹt trong khoảng thời gian chìm. Đó là về việc hiểu và nhận ra mỗi cá nhân đang ở mức 100 lần và những gì họ đang ở mức 0,1 lần.

Mặc dù điều này nghe có vẻ rất đơn giản, nhưng điều này khó hơn đáng kể trong thực tế.

Có nhiều điều mà một trưởng nhóm hoặc nhà phát triển sẽ không biết cho đến khi họ đã thử trước đó. Hoặc được cung cấp thời gian và cơ hội để trau dồi và thành thạo các kỹ năng liên quan đến những tình huống cụ thể đó. Cũng có nhiều thứ, đặc biệt là công nghệ mới, không ai giỏi cả, đều là chấp nhận rủi ro và cơ hội.

Công việc của trưởng nhóm là tổ chức các nhiệm vụ sao cho phù hợp nhất với nhu cầu của mọi người. Và nếu điều đó là không thể, thì bạn cũng nên hiểu rằng ngay cả khi ai đó không thể ở vị trí gấp 100 lần trong tình huống của bạn bây giờ, thì họ vẫn có thể ở những nơi khác trong các nhóm khác.

Và mỗi nhà phát triển đều phải tìm ra điểm giỏi và điểm yếu của họ, đồng thời truyền đạt điều đó cho nhóm của họ một cách phù hợp.

Vậy là chết với Huyền thoại Kỹ sư 10x, Kỹ sư 100x muôn năm trong những tình huống cụ thể

Tái bút: Nếu bạn chưa thực hiện bất kỳ nghị quyết nào cho năm mới. Có lẽ tăng diện tích bề mặt may mắn của bạn có thể là nó!

~ 🖖 sống lâu và thịnh vượng

Eugene Cheah: CTO của uilicious.com

Ban đầu được đăng trên: https://substack.tech-talk-cto.com/p/dev-to-cto-how-do-i-become-a-10x

tín dụng hình ảnh

• Austin Neill - hình ảnh ngôi sao nhạc rock: unsplash.com/photos/sxxnM-tRlVg
• XKCD - truyện tranh theo tiêu chuẩn: xkcd.com/927
• CenturiiC - Truyện tranh về các kỹ sư giàu kinh nghiệm: twitter.com/CenturiiC/status/15660603678258..
• Lucas Santos - Hình xúc xắc: unsplash.com/photos/XIIsv6AshJY
• Vlad Hilitanu - Những quả sung Lego: unsplash.com/photos/1FI2QAYPa-Y