Phát triển phần mềm, một nghề khi đã vào bạn sẽ yêu nó mãi! – Nếu bạn đang làm việc trong ngành phát triển phần mềm hoặc đang băn khoăn đứng trước lựa chọn của mình, hãy đọc những chia sẻ của Tagir Valeev nhé.
Alina Komissarova, Điều phối viên Dự án JetBrains Educational có trụ sở tại Novosibirsk, Nga, đã phỏng vấn đồng nghiệp của cô ấy là Tagir Valeev người Siberia, Trưởng nhóm Công nghệ Java về IntelliJ IDEA. Họ đã nói về cuộc sống và công việc như thế nào đối với một người cảm thấy có động lực không ngừng để phát triển, chia sẻ kiến thức và học tiếng Nhật.
A.K: Hãy bắt đầu từ đầu hoặc thậm chí có thể sớm hơn một chút. Bạn đã làm gì trước JetBrains?
T.V: Tôi nhận công việc đầu tiên của mình vào năm 2004 – đó là khi tôi bắt đầu lập trình vì tiền chứ không chỉ vì lý do chính đáng. Tôi đang hoàn thành bằng Thạc sĩ tại Khoa Vật lý của Đại học Bang Novosibirsk, nơi tôi theo học chuyên ngành Khoa học Máy tính và Vật lý. Chương trình được cho là để chuẩn bị cho chúng ta các công việc trong tự động hóa máy va chạm, máy dò hạt hạ nguyên tử và các công nghệ tương tự khác. Một số sinh viên của tôi hiện đang làm công việc đó tại CERN. Nhưng tôi đến đó để học lập trình, không phải vật lý. Một người bạn mà tôi chơi cầu nối đã nói với tôi về một công ty tin sinh học đang tìm kiếm các lập trình viên C ++, và tôi đã được thuê. Công ty có quan hệ với Viện Hệ thống Tin học A. P. Ershov, vì vậy sau này tôi quyết định học cao học ở đó và lấy bằng Tiến sĩ.
A.K: Luận văn của bạn về chủ đề gì?
T.V: Tôi đã và đang xây dựng một mô hình điều hòa gen. Mỗi người có khoảng 20 nghìn gen, nói chung, tất cả đều giống nhau trong mọi tế bào và không bao giờ thay đổi trong suốt cuộc đời của người đó. Mặc dù rõ ràng, một con mắt khác với lá gan, một tế bào ốm yếu khác với một tế bào khỏe mạnh, v.v… Vấn đề là các gen của chúng ta hoạt động theo những cách khác nhau; một số được kích hoạt và một số bị hủy kích hoạt. Điều hòa gen là quá trình kích hoạt và vô hiệu hóa này. Các gen có chữ ký trong vùng khởi động của chúng, chẳng hạn như các vị trí liên kết. Bạn có thể nói chúng giống như chữ ký tệp. Vì vậy, nếu một tập hợp protein nhất định tập hợp trong một tế bào và chúng kết hợp với nhau để tạo ra dấu hiệu đó, thì gen sẽ được kích hoạt và bắt đầu hoạt động. Tuy nhiên, điều này không rời rạc, giống như “có hoặc không”. Một gen có thể tạo ra protein rất chậm, hoặc ngược lại, nó có thể tạo ra rất nhiều protein. Các quá trình này khác nhau ở mỗi tế bào, và đôi khi chúng phụ thuộc vào những gì đang xảy ra với cá nhân.
Nghiên cứu trong lĩnh vực này đã tiến triển nhanh chóng trước khi tôi vào đại học. Các nhà nghiên cứu khác đã đưa ra một số nền tảng thử nghiệm. Ví dụ, có một thiết bị mà bạn có thể đặt một mẩu mô vào và tìm ra gen nào được biểu hiện trong đó và gen nào không. Và gần đây họ đã cố gắng giải trình tự toàn bộ bộ gen của con người! Bạn có thể xem xét từng gen riêng lẻ và xem những gì có trong trình khởi động của nó, sau đó cố gắng tìm hiểu xem điều đó có liên quan như thế nào đến việc kích hoạt gen. Họ đã xây dựng các mô hình cấp cao hơn dựa trên đó và cố gắng tối ưu hóa chúng.
Trong công việc tiến sĩ của mình, tôi đã sử dụng một thuật toán di truyền để giải quyết một vấn đề di truyền, một thuật toán không trực quan hoặc không như mong đợi. Tôi đã viết một chương trình bằng C++ để xử lý dữ liệu thử nghiệm, như trình tự gen và sự hiện diện của một số vùng nhất định trong trình khởi động. Sử dụng dữ liệu đó, chương trình sẽ cố gắng dự đoán tình hình gen trong tế bào, chẳng hạn như loại protein và yếu tố phiên mã nào đang đóng vai trò trong tế bào. Đây là luận án của tôi, mà tôi đã bảo vệ vào năm 2006.
Hai năm, nhanh quá!
Tôi đoán vậy – tôi cố gắng tránh trì hoãn. Nhưng nó không chỉ phụ thuộc vào tôi. Có một số trường đào tạo sau đại học ở đó không ai có thể hoàn thành chương trình Tiến sĩ trong vòng chưa đầy mười năm, cho dù họ có thông minh hay chăm chỉ đến đâu. Ở trường đại học của tôi, nhiều người đã làm được điều đó trong hai hoặc ba năm.
Sau đó, công ty của chúng tôi đã phát triển một nền tảng toàn bộ mà bạn có thể tải dữ liệu vào, lọc danh sách gen cũng như sắp xếp và phân loại chúng. Nó kết hợp phân tích của tôi và một loạt các thuật toán khác, và nó đã trở thành một hệ thống khá tuyệt.
Sau đó, năm 2008 và 2009 đã xảy ra, và công ty đã rơi vào một số thời điểm khó khăn. Tôi biết một vài người tại phòng thí nghiệm tin sinh học của Viện Khoa học Máy tính và Công nghệ Thiết kế ở Novosibirsk. Họ đã làm việc trong một dự án có tên là BioUML, một môi trường tích hợp để hợp tác phân tích dữ liệu sinh trắc học. Họ đã đưa tôi vào, và đó là nơi tôi chọn Java, thứ mà tôi đã tích cực sử dụng từ năm 2009.
A.K: Làm thế nào bạn trở nên quan tâm đến phân tích tĩnh? Bạn đã làm việc trong lĩnh vực này ngay cả trước khi gia nhập JetBrains, phải không?
T.V: Nó xảy ra ít nhiều ngẫu nhiên. Tôi luôn xem mã như một chủ đề nghiên cứu – không chỉ là một công cụ thực hiện công việc mà nó được thiết kế để làm. Tại một số thời điểm, tôi bắt đầu chú ý hơn đến chất lượng của mã chúng tôi đang viết. Tôi đã tìm hiểu về các trình phân tích tĩnh, như FindBugs cho Java. Trở lại năm 2013, nó vẫn còn phù hợp, ít nhất là cho đến khi Java 8 ra mắt. Vì vậy, tôi đã cài đặt FindBugs và phân tích dự án của chúng tôi, vốn đã khá lớn với 10 nghìn lớp. Anh bạn, tôi đã tìm thấy một số điều đáng xấu hổ ở đó! Nói về khoảnh khắc facepalm. Khi đó chúng tôi đang sử dụng Eclipse, có một phân tích tĩnh tích hợp khá yếu – nó có một số cảnh báo biên dịch bắt buộc nhưng không có nhiều cảnh báo khác. Tôi đã rất ngạc nhiên khi biết rằng các lỗi mã có thể được phát hiện như vậy.
Tôi phải làm việc để khắc phục các sự cố FindBugs được xác định trong mã của chúng tôi. Mọi chuyện đã trở nên tuyệt vời cho đến khi tôi nhận ra rằng công cụ này không phải lúc nào cũng chính xác. Đôi khi nó không thấy một số vấn đề và đôi khi nó báo cáo những thứ không phải là vấn đề. Tôi tìm thấy dự án trên SourceForge và cho họ phản hồi về những gì tôi nghĩ có thể được cải thiện. Tôi đã báo cáo một số lỗi và đóng góp một vài bản vá lúc đầu. Sau đó, tôi bắt đầu bổ sung các tính năng mới nghiêm trọng mà FindBugs bị thiếu, chẳng hạn như phân tích phạm vi số nguyên. Máy dò của tôi có thể tìm thấy một số mùi mã thú vị. Giả sử bạn có một câu lệnh if như if (x> 0), sau đó bên trong nó, bạn kiểm tra xem x == –1. Máy dò sẽ cho bạn biết rằng phép so sánh này là thừa vì chúng ta đã biết x là số dương. Đây là một cải tiến thực sự.
Tại một số thời điểm, tôi nhận ra FindBugs là một ngõ cụt. Đó là khoảng thời gian mà người sáng lập Bill Pugh của nó đã rời khỏi dự án và những người đóng góp lớn khác ngừng hoạt động. Nhưng quan trọng hơn, công cụ này có kiến trúc cực kỳ cồng kềnh với rất nhiều biến toàn cục, đó là lý do tại sao nó không thể hỗ trợ đa luồng.
A.K: Bạn đã tạo ra một ngã ba của riêng mình?
T.V: Nó thậm chí không phải là một cái nĩa. Tôi chợt nhận ra rằng tôi có thể viết công cụ phân tích tĩnh của riêng mình. Bạn thấy đấy, FindBugs phân tích bytecode, không phải mã nguồn. Và nó cũng ở cấp độ rất thấp – nó hoạt động với các hướng dẫn bytecode riêng lẻ. Vì vậy, nếu bạn muốn tạo bất kỳ non-trivial checks nào, đó là một địa chỉ hoàn toàn, nghĩa là bạn phải vượt qua rất nhiều vòng. Nó không có mô hình toàn cầu của mã, chỉ là một chuỗi hướng dẫn. Tôi đã cố gắng tạo một mô hình tương tự như trong FindBugs, nhưng tôi nhanh chóng nhận ra rằng nó sẽ mất nhiều thời gian.
Khi tôi xem xét các giải pháp đầy hứa hẹn khác, tôi đã tìm thấy JetBrains, ’Fernflower và Procyon. Tôi đã sử dụng Procyon, chủ yếu là vì JetBrains không lớn trong việc cung cấp Fernflower như một công cụ độc lập. Tôi không biết bây giờ, nhưng hồi đó nó thậm chí không có đồ tạo tác của Maven. Tôi sẽ phải tự mình xây dựng nó, bên cạnh những thứ khác.
Procyon có vẻ tốt với tôi; Tôi có thể sử dụng nó như một thư viện. Bên dưới, nó xây dựng một mô hình cấp cao theo cách trên bytecode, cho phép bạn xem bức tranh lớn hơn – lồng ghép các vòng lặp, điều kiện, v.v. Nó cũng khá tốt trong việc khôi phục các kiểu chung từ mã bytecode sau khi chúng bị xóa.
Tôi rất thích viết bộ phân tích tĩnh của riêng mình ở mức độ trừu tượng đó. Tôi gọi nó là HuntBugs và tôi đã dành khá nhiều thời gian để cải thiện nó. Cuối cùng thì nó có hơn một trăm tấm séc khác nhau. Tôi đã cố gắng triển khai hầu hết các chức năng của FindBugs và thêm một số thứ mới của riêng tôi. FindBugs đã có khoảng 400 lần kiểm tra (chẩn đoán). Tôi nghĩ rằng tôi đã che khoảng 30% trong số chúng trước khi hết hơi.
A.K: HuntBugs hiện như thế nào?
T.V: Nó đã bị bỏ rơi, nhưng nó đóng một vai trò lớn trong việc tôi sẽ làm việc cho JetBrains. Trước khi JetBrains mở văn phòng mới tại Novosibirsk, công ty đã thông báo về sự kiện JetBrains Night và họ cho biết sẽ có các cuộc phỏng vấn. Tôi nhận ra đó là cơ hội để tôi tiếp tục làm những gì tôi thích, nhưng vì tiền.
Tôi cũng rút ra một mẹo mà tôi nghĩ là thông minh. Tôi lấy mã nguồn của IntelliJ IDEA Community Edition – tệp JAR lớn nhất của nó, lib / idea.jar, có kích thước ít nhất là 100 MB – và tôi đã phân tích nó với HuntBugs. Nó có rất nhiều kết quả để hiển thị, một số rác ở đây và ở đó, nhưng một số phát hiện rất thú vị. Nó quản lý để phát hiện ra một số đoạn mã kỳ lạ trong các tệp. Vì vậy, tôi đã viết một bài báo trên Habr về nó, về cơ bản để nói, “Nhìn này, tôi có bộ phân tích tuyệt vời này tên là HuntBugs, tôi đã kiểm tra IntelliJ IDEA với nó và đây là những gì tôi tìm thấy.” Ý tôi là, IntelliJ IDEA Community Edition có phân tích tĩnh của riêng nó được cho là rất mạnh và những người đóng góp cho nó phải cảnh giác về chất lượng mã của chính họ. Nhưng nhờ có HuntBugs, tôi vẫn tìm ra được một số thứ để chọn và cải thiện.
A.K: Khi bạn viết bài báo đó, bạn có biết JetBrains sẽ mở văn phòng tại Novosibirsk không?
T.V: Đó là trước khi tôi đi phỏng vấn, nhưng sau khi tôi đã lên lịch. Vì thế, đúng là như vậy, mục tiêu của tôi khi tôi viết bài báo là đưa tên tuổi của tôi ra khỏi đó.
A.K: Bạn cũng có xếp hạng cao trên Stack Overflow, cũng như các bài báo Habr đã xuất bản khác và tài khoản Twitter. Điều đó cũng đóng một vai trò trong việc bạn nhận được công việc?
T.V: Tôi nghĩ vậy. Và sau đó cũng là câu chuyện trước kia về các luồng (Java Stream API) mà Java 8 đã giới thiệu. Tôi thực sự đã tham gia các luồng một thời gian. Lúc đầu, tôi đã nói: “Chà, tôi có thể làm rất nhiều thứ hay ho với các luồng một cách dễ dàng!” – chỉ để nhận ra rằng một số điều không thể hoàn thành. Tôi bắt đầu viết thư viện của riêng mình mà tôi gọi là StreamEx. Tôi đã đưa nó lên GitHub và xuất bản một bài báo trên Habr mô tả một cách tốt hơn để làm việc với các luồng.
Tuy nhiên, tôi muốn quảng bá thư viện của mình và mở rộng ra ngoài đối tượng toàn người Nga của Habr. Tôi đã truy cập Stack Overflow để xem mọi người đang hỏi loại câu hỏi nào về luồng. Trước hết, những câu hỏi đó có thể giúp tôi quyết định những tính năng mới nào sẽ thêm vào StreamEx. Thứ hai, tôi có thể đăng các câu trả lời như “Bạn không thể làm những gì mình muốn nếu chỉ sử dụng API vani Stream. Chà, bạn có thể, nhưng nó sẽ rất xấu. Nhưng có thư viện này – nhân tiện, miễn phí và mã nguồn mở – có thể giúp bạn giải quyết vấn đề của mình một cách độc đáo và dễ dàng. ” Theo quy tắc Stack Overflow, điều đó được chấp nhận, trừ khi người đăng ban đầu chỉ định rằng họ không muốn sử dụng bất kỳ giải pháp nào của bên thứ ba.
Tôi tiếp tục trả lời các câu hỏi và chẳng bao lâu sau tôi bị nghiện. Nó đã phát triển thành một thứ gì đó lớn hơn là chỉ duy trì StreamEx. Stack Overflow thực hiện trò chơi hóa vừa phải, với xếp hạng, huy hiệu, biểu đồ, v.v. Vì vậy, tôi đã dành khoảng một năm để làm điều đó, chủ yếu là để làm với các luồng nhưng cũng có một số chủ đề liên quan khác. Đó là cách tôi gặp những người của Oracle như Brian Goetz và Stuart Marks, những người cũng sẽ tham gia và trả lời các câu hỏi. Tôi thậm chí còn tìm thấy một lỗi trong API và báo cáo nó bằng cách đăng một câu hỏi trên Stack Overflow.
A.K: Họ có trả lời không?
T.V: Có, Brian đã trả lời. Họ đã mở một ticket trong trình theo dõi OpenJDK và sửa lỗi trong một trong các bản cập nhật Java 8 sau đây. Nhưng tôi cũng biết được rằng Stack Overflow không phải là cách tốt nhất để báo cáo lỗi hoặc chuyển đến đúng người. Danh sách gửi thư là nơi thích hợp để làm điều đó. Tôi không có manh mối nào về quá trình phát triển Java. Ví dụ: tôi không biết rằng có rất nhiều thứ diễn ra ngoài trời, chẳng hạn như trong danh sách gửi thư. Tôi đã đăng ký, tham gia các cuộc thảo luận và sau đó dần dần bắt đầu tham gia. Sau một thời gian, tôi trở thành cộng tác viên, sau đó là tác giả và người cam kết trong OpenJDK.
Trong cuộc phỏng vấn của tôi với JetBrains, tôi đã đề cập đến StreamEx, nhưng chúng tôi chủ yếu nói về HuntBugs. Vì hai dự án nguồn mở đó, tôi không phải thực hiện bài tập kiểm tra. Những người phỏng vấn chỉ nhìn vào mã của tôi và hỏi tôi làm thế nào tôi chọn những giải pháp đó và tại sao tôi lại viết mã theo cách tôi đã làm. Bạn có thể biết nhiều điều về kỹ năng của nhà phát triển chỉ bằng cách nhìn vào mã của họ.
A.K: Sự hiện diện trên internet của bạn có tiếp tục ảnh hưởng đến cuộc sống của bạn không? Mọi người có đang mời bạn tham gia các sự kiện của họ hay đến làm việc cho công ty của họ không?
T.V: Có, và tôi cũng tham dự các hội nghị, vì vậy tôi nhận được rất nhiều lời mời nói chuyện tại các sự kiện và thuyết trình. Tuy nhiên, tôi thường phải nói “Không” bởi vì tôi không có thời gian hoặc nguồn lực. Tôi không thích đưa ra cùng một bài nói nhiều lần và việc chuẩn bị những bài nói mới mất rất nhiều thời gian và năng lượng.
A.K: Mặc dù bạn từ chối rất nhiều lời mời đó, bạn vẫn đưa ra một vài bài nói chuyện, và bạn cũng giảng dạy nữa! Bạn có thích làm việc với khán giả không?
T.V: Tôi thích chia sẻ kiến thức. Khi tôi biết điều gì đó mà người khác có thể không, tôi cảm thấy tuyệt vời khi nói với họ về điều đó. Nhưng các bài nói và bài giảng rất tốn thời gian, vì tôi phải chuẩn bị mọi thứ kỹ lưỡng và tập đi diễn lại nhiều lần. Đôi khi tôi cảm thấy muốn bỏ cuộc. Nhưng khi cuộc nói chuyện diễn ra suôn sẻ, nó sẽ rất phấn chấn. Mọi người háo hức học hỏi, họ lắng nghe và đặt câu hỏi, và bạn biết rằng mình đang có ích. Cuối cùng, họ đã học được điều gì đó và họ không nhìn vào đồng hồ của mình (hầu hết thời gian). Điều đó cho tôi biết rằng có lẽ tôi có thể làm cho một buổi nói chuyện trở nên thú vị.
A.K: Tôi đã nghe một số bài nói chuyện của bạn và tôi bị cuốn hút. Viết cũng là để chia sẻ kiến thức, nhưng bạn có vẻ thích nói chuyện hơn. Tại sao vậy?
T.V: Tôi đoán các định dạng hơi khác một chút. Tôi đã có bài nói chuyện đầu tiên của mình tại hội nghị Joker vào năm 2015. Đó là khi tôi bắt đầu quan tâm đến việc tìm hiểu cách Java biên dịch mã và tôi đã thấy một số tối ưu hóa đáng kinh ngạc ở đó. Tôi đã bắt đầu viết một bài báo cho Habr về vấn đề đó, nhưng nó không có gì hấp dẫn. Bạn thấy đấy, nó hơi giống một câu chuyện trinh thám: chúng tôi thử một cách tiếp cận này nhưng nó không hiệu quả, nhưng sau đó chúng tôi thử cách tiếp cận khác này, và bam, nó hoạt động… nhưng chúng tôi không biết tại sao! Tôi nghĩ rằng nếu tôi biến nội dung này thành một bài nói chuyện, nó sẽ thú vị hơn rất nhiều so với chỉ là một đoạn văn bản. Tôi có thể làm một chương trình, chèn một số tạm dừng kịch tính và những thứ, bạn biết đấy. Vì vậy, tôi đã làm, và tôi thích cách nó xuất hiện.
A.K: JetBrains cung cấp cơ hội chuyển địa điểm đến các văn phòng khác của mình ở Nga và các quốc gia khác. Điều gì đang giữ chân bạn ở Novosibirsk?
T.V: Tôi không thấy lợi ích lớn trong việc di chuyển. Tôi nghĩ ưu điểm và nhược điểm sẽ triệt tiêu lẫn nhau. Lấy ví dụ về khí hậu. Bạn không bao giờ biết về tương lai – đặc biệt là khi xét đến sự nóng lên toàn cầu, Novosibirsk có thể sẽ trở thành một nơi tốt hơn để ở.
Chuyển đến một đất nước khác cũng có những thách thức như rào cản ngôn ngữ, con cái bạn thích nghi với xã hội, không có bạn bè để ở bên, xa gia đình… rất nhiều điều cơ bản mà bạn phải làm lại từ đầu. Là một người thích ở nhà, tôi không muốn từ bỏ mọi thứ và chèo thuyền đến những bến bờ xa xôi.
Bên cạnh đó, bản chất công việc của chúng tôi cho phép chúng tôi làm việc từ mọi nơi. Dù bạn ở đâu, bạn đều nhìn vào cùng một màn hình điều khiển và viết cùng một mã. Novosibirsk cũng rẻ hơn Moscow hoặc St.Petersburg. Tôi có thể mua được chất lượng cuộc sống tốt hơn ở đây. Điều này đặc biệt đúng đối với những việc như đưa con bạn vào nhà trẻ tư nhân hoặc sử dụng các nhà cung cấp dịch vụ chăm sóc sức khỏe tư nhân.
Và sau đó là lòng yêu nước. Tôi đã sống ở Siberia cả đời và tôi cảm thấy mình có thể tạo ra sự khác biệt ở đây. Ví dụ, tôi có thể giúp thiết lập các cuộc hội thảo thú vị, có thể làm cho khu vực trở nên hấp dẫn hơn – biến nó thành một nơi mà mọi người muốn đến hơn là rời xa. Hành tinh của chúng ta rất lớn, vậy tại sao tất cả chúng ta lại phải sống ở một vài nơi giống nhau? Tại sao không lan rộng ra một chút, bạn biết không?
A.K: Nói về điều đó, bạn đang làm việc trong một đội rất phân tán: Novosibirsk đi trước Moscow và St.Petersburg 4 giờ và đi trước Munich từ 5 đến 6 giờ. Việc di chuyển đến từ xa có ảnh hưởng đến cách bạn và đồng đội của bạn làm việc cùng nhau không?
TV: Trước khi khóa máy, có ba thành viên nhóm Java chúng tôi làm việc trong cùng một phòng trong văn phòng Novosibirsk. Chúng tôi có thể nói về tất cả các vấn đề công việc phải đối mặt. Đôi khi chúng tôi giải quyết các vấn đề về mã hóa bằng cách ngồi lại với nhau và lập trình theo cặp. Tôi nhớ những lúc chúng tôi có thể bắt chuyện với một đồng nghiệp trong phòng bất cứ lúc nào. Tôi cảm thấy bây giờ chúng tôi đang bị cô lập hơn và ít nhận thức được những gì đang xảy ra. Nhưng một lần nữa, ngay cả trước khi bị khóa, nhiều đồng đội của tôi đã sống ở những nơi khác như St.Petersburg và Munich, vì vậy sự thay đổi không phải là quá lớn. Và tất nhiên, chúng tôi có các cuộc họp nhóm hàng tuần và các cuộc gọi riêng tư, ngoài ra tôi cố gắng tham dự các cuộc họp “dự phòng” ảo của chúng tôi hầu như mỗi ngày.
Ngoài ra còn có định dạng cuộc họp mới này được gọi là “virtual coffee”. Đó là khoảng thời gian ấn định hàng ngày khi cả nhóm của chúng tôi có thể cùng nhau trực tuyến và trò chuyện về những thứ không liên quan đến công việc. Mọi người nói về cuộc sống và bất cứ điều gì quan trọng đối với họ, và điều này đã giúp chúng tôi kết nối tốt hơn với một số đồng nghiệp làm việc tại các văn phòng khác.
A.K: JetBrains có một cái gì đó được gọi là “20% dự án”, nơi bạn có thể làm việc với một số thứ nằm ngoài mô tả công việc của bạn. Bạn có đang tận dụng điều này không?
TV: Bản chất tôi là người bốc đồng. Khi tôi có ý tưởng phát triển một tính năng mới, tôi bỏ mọi thứ và bắt đầu viết mã nó. Vì vậy, lên lịch 20% thời gian của tôi mỗi tuần để làm việc gì đó cụ thể có vẻ không phù hợp với phong cách làm việc của tôi. Đây cũng là lý do tại sao tôi chưa bao giờ tham gia hackathons – chúng không phải là “tách trà” của tôi. Nếu tôi có một ý tưởng sáng tạo, tôi muốn bắt tay vào thực hiện nó ngay lập tức. Và nếu tôi không có, nó sẽ không đến với tôi trong một cuộc thi hackathon.
Tôi dành một chút thời gian của mình cho những thứ không liên quan trực tiếp đến công việc của tôi, chẳng hạn như giúp định hình tương lai của Java. Tôi là thành viên của Nhóm chuyên gia Amber, nhóm sàng lọc tất cả các tính năng Java mới, như bản ghi, đối sánh mẫu, chuyển đổi biểu thức, v.v… Tôi cũng khá tích cực trong các cuộc thảo luận, chỉnh sửa các bản nháp thông số kỹ thuật và đôi khi cam kết các bản vá lỗi. Tôi chưa bao giờ theo dõi lượng thời gian làm việc của mình được dành cho việc này, nhưng có thể ít hơn 20%.
A.K: Bạn đã tham gia JetBrains với tư cách là nhà phát triển cấp cao và từ đó đã phát triển thành công ty dẫn đầu về công nghệ. Điều đó đã ảnh hưởng đến nhiệm vụ và khối lượng công việc của bạn như thế nào?
TV: Tôi hiện đang được mời tham gia nhiều cuộc họp liên chức năng hơn, cũng như các cuộc họp bắt buộc của trưởng nhóm. Tôi dành nhiều thời gian hơn để thảo luận về sự hợp tác giữa các nhóm và tôi cố vấn nhiều hơn. Điều này là tốt, nhưng quản lý không phải lĩnh vực dành cho tôi. Tôi tự cho mình là một nhà phát triển và theo lẽ tự nhiên, tôi đang cố gắng tiếp tục lập trình nhiều nhất có thể.
A.K: Nhóm của bạn thảo luận về các vấn đề công việc và đưa ra quyết định như thế nào? Bạn có cách tiếp cận của riêng bạn?
TV: Một số cuộc thảo luận không nhất thiết phải có sự tham gia của cả nhóm. Khi một người trong chúng ta giải quyết một vấn đề, họ thường đủ hiểu biết để quyết định cách tiếp cận và cách giải quyết vấn đề đó. Trưởng nhóm công nghệ cũng không chuyển các quyết định cho các thành viên khác trong nhóm. Mỗi người trong chúng ta đều có thể nói lên suy nghĩ của mình về cách tiếp cận vấn đề mà họ được giao nhiệm vụ và ý kiến của họ thường là yếu tố quyết định.
Tuy nhiên, một số quyết định không chỉ là viết mã, chẳng hạn như liệu chúng có ảnh hưởng đến trải nghiệm người dùng hay không. Giả sử ai đó đang yêu cầu chúng tôi tạo một cuộc kiểm tra hoặc cảnh báo mới. Đầu tiên, chúng tôi phải quyết định xem đó có phải là điều chúng tôi muốn làm hay không. Nếu tính năng được yêu cầu có tầm quan trọng hạn chế hoặc có thể chúng tôi không chắc mình có thể loại bỏ tất cả các kết quả dương tính giả và đảm bảo việc kiểm tra đủ chính xác, chúng tôi có thể không tiếp tục với nó. Hoặc nó có thể liên quan đến thư viện của bên thứ ba mà chúng tôi không muốn hỗ trợ trên toàn cầu. Chúng tôi đảm bảo sẽ thảo luận những điều này với tư cách một nhóm và cùng nhau đi đến quyết định.
Cách đây vài năm, chúng tôi đã viết một hướng dẫn mô tả các quy tắc xử lý các quyết định như vậy. Nó giúp chúng tôi trả lời các câu hỏi như “Chúng tôi có muốn thêm cảnh báo mới này hay không?” và, nếu chúng ta làm vậy, “Chúng ta nên thực hiện một cuộc thanh tra hoàn toàn mới hay kết hợp cảnh báo vào một cuộc thanh tra hiện có?”. Nếu chúng tôi tạo ra một cuộc kiểm tra mới mỗi lần, chẳng bao lâu nữa người dùng của chúng tôi sẽ bị ngập và mất phương hướng bởi rất nhiều cuộc kiểm tra khác nhau. Mặt khác, nếu chúng tôi đã thêm một cảnh báo mới vào quá trình kiểm tra hiện có, người dùng sẽ không thể tắt nó một cách riêng biệt khỏi tất cả các cảnh báo khác mà quá trình kiểm tra có thể tạo ra. Chúng tôi thảo luận về những câu hỏi như thế này trong cuộc trò chuyện Slack nội bộ của chúng tôi và đưa ra quyết định với tư cách là một nhóm.
Không phải lúc nào quan điểm của tôi cũng đúng. Nói chung, ai đó càng có nhiều kinh nghiệm trong lĩnh vực, họ càng có trình độ tốt hơn và chúng tôi càng có trọng lượng hơn đối với ý kiến của họ, bất kể chức danh hoặc vai trò của họ trong nhóm. Các đồng nghiệp có kinh nghiệm hơn có nhiều khả năng đã xử lý phần cụ thể đó của cơ sở mã. Nhưng nếu một thành viên mới trong nhóm đào sâu vào một hệ thống con và làm việc trên nó, chẳng hạn như một tháng hoặc lâu hơn, họ sẽ sớm trở thành chuyên gia thường trú trong đó, ngay cả khi họ ít kinh nghiệm hơn và chúng tôi sẽ đưa ra trọng số ý tưởng và đề xuất của họ.
A.K: Bạn làm gì để giải trí? Tôi nghe nói rằng bạn thông thạo tiếng Nhật.
TV: Tôi đang tập trung vào gia đình của mình, vì vậy tôi ngày càng có ít thời gian hơn cho bất cứ thứ gì bạn có thể gọi là “sở thích”. Những việc tôi làm để giải trí bây giờ thường xoay quanh công việc của tôi, như tham dự các hội nghị và giúp phát triển Java. Khi tôi dành cuối tuần để chuẩn bị một buổi nói chuyện hội nghị và con trai tôi hỏi tôi, “Bố ơi, bố đang làm việc à?” Tôi nói, “Không, thưa đại nhân, tôi đang rất vui.” Bởi vì bạn không phải làm việc vào cuối tuần, bạn biết không?
Cách đây rất lâu, tôi từng có những sở thích không liên quan gì đến lập trình. Tôi đã học tiếng Nhật trong sáu năm, và thậm chí tôi đã vượt qua Nihongo Nōryoku Shiken, Kỳ thi Năng lực Nhật ngữ. Tôi đã vượt qua cấp độ 2 của kỳ thi, với cấp độ 1 là cao nhất. Điều này đã trở lại vào năm 2006.
A.K: Tại sao lại là tiếng Nhật?
TV: Tôi là một fan hâm mộ của anime. Chà, tôi là một fan hâm mộ của Pokémon và sau đó tôi bị cuốn hút vào anime. Trước tiên, tôi sẽ xem một tập được lồng tiếng và sau đó xem bản gốc, chỉ cố gắng nắm được ý tưởng cơ bản về những gì họ đang nói.
Tôi luôn quan tâm và có năng khiếu về ngôn ngữ. Tôi có thể ghi nhớ các từ tốt. Vì vậy, đó là cách tôi yêu tiếng Nhật. Nó có cấu trúc đẹp, với ngữ pháp thú vị và ngữ âm rất đơn giản. Đẹp hơn nhiều so với tiếng Anh với những nguyên âm khó hiểu mà tôi không bao giờ có thể hiểu đúng!
A.K: Nhưng hệ thống chữ viết tiếng Nhật khó hơn, phải không? Nó có ba tập lệnh khác nhau và rất nhiều ký tự.
TV: Điều đó không bao giờ làm phiền tôi. Bạn chỉ cần ghi nhớ từng từ một cách trực quan. Mọi người ở mọi nơi trên thế giới hiện nói chuyện bằng biểu tượng cảm xúc, phải không? Xu hướng này đến từ Nhật Bản – “biểu tượng cảm xúc” là một từ tiếng Nhật. Người Nhật nghĩ bằng hình ảnh – các từ Kanji không là gì khác ngoài hình ảnh. Bạn ghi nhớ ý nghĩa của chúng, và thế là xong. Và nếu bạn bắt gặp một từ mà bạn chưa từng thấy trước đây, bạn có thể sẽ biết một trong hai ký tự mà từ đó bao gồm và bạn có thể sử dụng từ đó để suy ra ý nghĩa. Có nhiều nhân vật, nhưng không quá nhiều.
Tôi đã học được khoảng 1000, có thể là 1100 từ, cộng với hai hệ thống chữ viết, mỗi hệ thống có 50 ký tự. 1100 hoặc 1200 là một con số khá thực tế. Nhưng tiếng Anh không thực sự khác biệt như vậy. Tôi cũng nghĩ về các từ tiếng Anh như những chữ tượng hình. Khi bạn đang học tiếng Anh, bạn nhìn thấy một từ tiếng Anh và bạn không biết làm thế nào để nói nó một cách chính xác. Vì vậy, bạn phải học ba điều khác nhau: cách đánh vần của từ, cách phát âm và ý nghĩa của từ đó. Tiếng Nhật cũng vậy. Và sau đó, khi bạn có kinh nghiệm hơn, bạn bắt đầu nhìn thấy các mẫu và đôi khi bạn có thể đoán được nghĩa của những từ tiếng Nhật mà bạn chưa học.
Mặc dù tôi thích tiếng Nhật, nhưng tôi đã phải đặt nó vào ổ ghi phía sau. Nhưng gần đây, chúng tôi đang chạy một dự án bản địa hóa lớn cho IntelliJ IDEA và hiện tôi đang sử dụng phiên bản tiếng Nhật của nó. Nó làm chậm công việc của tôi, nhưng nó giúp tôi nâng cao kỹ năng tiếng Nhật của mình.
A.K: Vậy bạn thực sự đang viết mã trong phiên bản tiếng Nhật của IntelliJ IDEA?
TV: Đúng vậy, nó đã được bản địa hóa hoàn toàn và tôi đang sử dụng nó trong công việc hàng ngày của mình. Đôi khi tôi tìm kiếm một cái gì đó trong giao diện người dùng và tôi không thể tìm thấy nó. Trường hợp xấu nhất là khi tôi cần tìm một cuộc thanh tra mà tôi biết tên tiếng Anh của nó. Vì vậy, có danh sách 2000 cuộc kiểm tra này, tất nhiên tất cả đều bằng tiếng Nhật và tôi cần phải chọn đúng. Một bài toán hóc búa! Nhưng ngoài ra, nó vẫn hoạt động tốt. Tôi có một cảm giác hoài cổ đẹp đẽ khi nhìn lại tất cả những người Nhật mà tôi từng biết.
Tôi chủ yếu là thực hành cho quá trình biên tập của riêng tôi, nhưng thỉnh thoảng tôi nhận thấy lỗi dịch và tôi đã thông báo cho nhóm bản địa hóa của chúng tôi biết về những lỗi đó. Tôi đã tìm thấy một vài điều cần cải thiện, vì vậy đó là một hoạt động hữu ích.
Nguồn: blog.jetbrains
