0

Một ngày vào tháng 1 năm 2013, tôi thấy mình lãng phí thời gian trên internet.

Đây không phải là một ý tưởng hay: Tôi bận rộn như bất kỳ ai 2,5 năm học tiến sĩ. Tôi đã phải hoàn thành một bài thuyết trình về một số nghiên cứu di truyền nấm men, tôi đã chậm một tháng trên một bài báo với một cộng tác viên của NYU và thậm chí xa hơn về một số nghiên cứu đại học còn sót lại. Tôi cũng bận rộn với cuộc sống cá nhân của mình. Tôi đã trở về từ một chuyến đi đến Israel và vừa mới bắt gặp Jiu-Jitsu người Brazil và chạy bộ.

Nhưng một ngày này, tôi đã lãng phí thời gian bằng cách trả lời câu hỏi của người lạ về bản phân phối beta. Câu hỏi được đặt ra trên Cross Validated, trang web thống kê của nhà phát triển Q & A Stack Overflow. Tôi đã là một người trả lời tích cực trên Stack Overflow khoảng một năm tại thời điểm đó và là một người trả lời ít thường xuyên hơn về Xác thực chéo: đó chắc chắn là cách yêu thích của tôi để lãng phí thời gian.

Vào thời điểm đó, tôi có một ý tưởng dễ thương để giải thích về bản phân phối beta về mặt thống kê bóng chày. Một câu trả lời mà sau này sẽ chuyển sang bài nàyloạt bài này .

Tôi đã làm rất nhiều trong tiến sĩ mà tôi tự hào, và tôi đã làm nhiều hơn nữa là đáng quên hoặc không quan trọng. Nhưng về mặt ảnh hưởng đến sự nghiệp của tôi, câu trả lời đó là công việc mà tôi hạnh phúc nhất.

Một năm tại Stack Overflow

Thứ Năm tuần trước (16 tháng 6) đánh dấu kỷ niệm một năm làm việc của tôi tại Stack Overflow với tư cách là Nhà khoa học dữ liệu.

Tôi đã hoàn thành bằng tiến sĩ khoảng một tháng trước khi tôi tham gia và việc tôi chuyển sang một công ty công nghệ là một thay đổi khá lớn đối với tôi. Chỉ mới vài tháng trước, tôi đã có kế hoạch ở lại nghiên cứu học thuật, đặc biệt là trong lĩnh vực sinh học tính toán. Tôi đã bắt đầu đăng ký học bổng sau tiến sĩ, và thậm chí còn chưa xem xét việc nộp đơn vào các công việc của ngành công nghiệp.

Điều gì đã thay đổi tâm trí của tôi? Nó bắt đầu vào tháng 1 năm 2015, khi Jason Punyon tìm thấy bài đăng của tôi (lúc đó hai tuổi) về bản phân phối beta:

Tại sao tôi thích làm việc tại @StackExchange lý do # 14785: Chúng tôi nhận được câu trả lời tuyệt vời cho các câu hỏi như thế này: http://t.co/NkgvYHMEAy Cảm ơn @drob

- JSONP (@JasonPunyon) ngày 7 tháng 1 năm 2015

@drob PS Tôi biết chúng tôi không thú vị bằng việc hoàn thành bằng tiến sĩ nhưng nếu bạn muốn có một cuộc phỏng vấn ở đây tại Stack, bạn có thể có một :)

- JSONP (@JasonPunyon) ngày 7 tháng 1 năm 2015

Vào thời điểm đó, tôi khá chắc chắn rằng mình đã vào học viện, nhưng tôi không muốn bỏ qua cơ hội kiểm tra các văn phòng Stack Exchange và gặp một số người đứng sau sản phẩm. Về cơ bản phải mất một lần đến văn phòng để tôi thay đổi quyết định, và một vài tuần và các cuộc phỏng vấn sau đó tôi đã được mời vào vị trí và ký tên.

Một số điều tôi đã làm việc trên

Mọi người biết những gì các nhà phát triển web làm, nhưng một nhà khoa học dữ liệu làm gì? (Tôi không phải là người duy nhất được hỏi điều đó).

Đây không phải là những dự án duy nhất tôi đang thực hiện, nhưng chúng có thể mang lại cảm giác về những gì tôi đã làm.

Thiết kế, phát triển và kiểm tra các tính năng học máy

Ví dụ nổi bật nhất về nơi sử dụng máy học trong sản phẩm của chúng tôi là Providence; hệ thống của chúng tôi để kết hợp người dùng với các công việc mà họ sẽ quan tâm. (Ví dụ: nếu bạn truy cập hầu hết các câu hỏi về Python và Javascript trên Stack Overflow, cuối cùng bạn sẽ nhận được các công việc phát triển web Python dưới dạng quảng cáo). Tôi làm việc với các kỹ sư trong nhóm Dữ liệu ( Kevin Montrose , Jason PunyonNick Larsen ) để thiết kế, cải thiện và thực hiện các thuật toán học máy này. (Đây là một số chi tiếtvề kiến ​​trúc của hệ thống, được xây dựng trước khi tôi tham gia). Ví dụ: chúng tôi đã làm việc để có được sự cân bằng giữa các công việc gần với người dùng về mặt địa lý và các công việc phù hợp về mặt công nghệ và đảm bảo rằng người dùng có được nhiều công việc hơn là nhìn thấy cùng một công việc và kết thúc.

Rất nhiều quá trình này bao gồm thiết kế và phân tích các thử nghiệm A / B, đặc biệt là về việc thay đổi thuật toán nhắm mục tiêu, thiết kế quảng cáo và các yếu tố khác để cải thiện tỷ lệ nhấp (TLB). Quá trình này thú vị hơn về mặt thống kê so với tôi dự kiến, trong một số trường hợp, cho phép tôi tìm ra cách sử dụng mới cho các phương pháp tôi đã sử dụng để phân tích các thí nghiệm sinh học và trong các trường hợp khác khuyến khích tôi tìm hiểu các công cụ thống kê mới. Trên thực tế, phần lớn loạt bài của tôi về việc áp dụng các phương pháp Bayes cho thống kê bóng chày thực sự là một phiên bản mỏng của các phương pháp mà tôi đã sử dụng để phân tích TLB trên các chiến dịch quảng cáo.

Học những điều hay

Tôi không còn là nhà khoa học hàn lâm nữa, nhưng điều đó không có nghĩa là tôi không quan tâm đến việc rút ra kết luận từ dữ liệu. Stack Overflow có cái nhìn toàn cảnh về hệ sinh thái phát triển phần mềm, hàng triệu câu hỏi, người dùng và khách truy cập hàng ngày. Chúng ta có thể học được gì từ tất cả dữ liệu đó?

Để bắt đầu, bằng cách xem xét cách các thẻ được sử dụng cùng nhau, chúng ta có thể tìm thấy các cụm công nghệ tự nhiên:

Điều này cho phép chúng tôi tự động phân loại các khung và gói thành các ngôn ngữ và cụm cấp cao hơn mà chúng thuộc về, tất cả không có chú thích thủ công.

Nhưng nó thực sự chỉ cho chúng ta thấy các thẻ xuất hiện như thế nào trong các câu hỏi lập trình cụ thể, chứ không phải cách chúng được sử dụng trong cùng một dự án (ví dụ: C # và SQL Server có thể không luôn xuất hiện trên cùng một câu hỏi, nhưng chúng thường được sử dụng như một phần của ngăn xếp công nghệ tương tự). Vì thế, tôi có thể xem xét một nguồn dữ liệu khác, hồ sơ Stack Overflow Careerers và xem những công nghệ nào có xu hướng được sử dụng bởi cùng các nhà phát triển:

Tôi thích cách điều này phân chia các thẻ không chỉ theo các danh mục nghiêm ngặt, mà còn bởi các hệ sinh thái công nghệ của Google. Sự hiểu biết này không giới hạn trong các công nghệ lập trình. Mạng Stack Exchange chứa một loạt các trang web hỏi đáp. Bằng cách xem xét các cộng đồng nào có xu hướng có cùng các thành viên tích cực, chúng tôi có thể tạo ra một mạng lưới tương tự như thế nào các trang web của chúng tôi có liên quan với nhau:

(Không phải tất cả mọi thứ tôi làm là mạng, chỉ là một số ví dụ thú vị hơn trong nháy mắt.)

Tại sao phải dành thời gian cho các phân tích như thế này? Đôi khi họ có thể đóng góp trực tiếp vào các tính năng sản phẩm. Ví dụ: việc hiểu các cụm công nghệ một cách định lượng cho phép chúng tôi cải thiện mô hình các loại nhà phát triển hướng mục tiêu Providence. Những hiểu biết khác có thể có giá trị từ góc độ kinh doanh. Tôi đã làm việc một chút với các nhóm bán hàng, tiếp thị và cộng đồng để giải thích dữ liệu của họ và giúp đưa ra quyết định.

Nhưng về bản chất tôi cũng khá thích tìm hiểu và hình dung loại thông tin này; đó là một trong những điều làm cho công việc này trở nên thú vị Một kế hoạch cho năm thứ hai của tôi ở đây là chia sẻ công khai hơn những phân tích này. Trong một bài viết trước , tôi đã xem xét công nghệ nào phân cực nhất và tôi mong sớm được chia sẻ nhiều bài đăng như thế.

Phát triển kiến ​​trúc khoa học dữ liệu (Gói R nội bộ)

Tôi thích sử dụng R để tìm hiểu những điều thú vị về dữ liệu của chúng tôi, nhưng mục tiêu dài hạn của tôi là giúp mọi kỹ sư của chúng tôi dễ dàng làm điều đó. Khi tôi tham gia, tôi là người đầu tiên ở công ty sử dụng R, nhưng nó đã lan rộng trong năm kể từ đó. R chỉ là một cách thực sự tuyệt vời để tham gia trực tiếp với dữ liệu và trả lời các câu hỏi thú vị. (Điều này làm tôi buồn khi các kỹ sư phần mềm xuất sắc mở Excel để tạo biểu đồ đường!)

Hướng tới mục tiêu này, tôi đã tập trung vào việc xây dựng các công cụ và khung công tác đáng tin cậy mà mọi người có thể áp dụng cho nhiều vấn đề khác nhau, thay vì các kịch bản phân tích một lần của Nghịch lý. (Có một bài viết tuyệt vời của Jeff Magnusson tại StitchFix về một số trong những thách thức chung này). Cách tiếp cận của tôi là xây dựng các gói R nội bộ , tương tự như chiến lược của AirBnb (mặc dù nhóm dữ liệu của chúng tôi khá trẻ và nhỏ hơn so với họ). Các gói nội bộ này có thể truy vấn cơ sở dữ liệu và phân tích API nội bộ của chúng tôi, bao gồm làm cho các vấn đề bảo mật và cơ sở hạ tầng khác nhau trở nên vô hình đối với người dùng.

Điều này cũng có liên quan đến việc xây dựng các hướng dẫn R và viết các tài liệu trên tàu. Ví dụ, tôi đã công khai một hướng dẫn giới thiệu gói sqlstackr nội bộ để truy vấn cơ sở dữ liệu của chúng tôi. Điều này tăng gấp đôi khi giới thiệu chung về dplyr / tidyr / ggplot2, điều mà tôi thấy hữu ích hơn là liên kết nhà phát triển với hướng dẫn chung về dplyr (vì đây là dữ liệu mà các đồng nghiệp của tôi chắc chắn sẽ quan tâm!) Tôi hy vọng rằng khi nhóm dữ liệu phát triển và khi nhiều kỹ sư học R, hệ sinh thái các gói và hướng dẫn này có thể phát triển thành một nền tảng khoa học dữ liệu nội bộ thực sự.

Học thuật và Công nghiệp

Có một định nghĩa phổ biến của các nhà khoa học dữ liệu:

Nhà khoa học dữ liệu (n.): Người giỏi thống kê hơn bất kỳ kỹ sư phần mềm nào và giỏi về công nghệ phần mềm hơn bất kỳ nhà thống kê nào.

- (((Josh Wills))) (@josh_wills) ngày 3 tháng 5 năm 2012

Phiên bản này được đóng khung tích cực, nhưng đáng chú ý là điều ngược lại cũng đúng: Ở trường học, tôi biết ít về thống kê hơn những người khác trong phòng thí nghiệm của tôi, và trong công việc mới, tôi biết ít về công nghệ phần mềm hơn các đồng nghiệp. Vậy quá trình chuyển đổi đã diễn ra như thế nào?

Biết thêm về thống kê

Có rất nhiều bài viết ấn tượng về cách các lập trình viên người Viking cần học thống kê. "Đúng là tôi có nhiều kinh nghiệm thống kê và đào tạo hơn các đồng nghiệp của mình (cũng là người đầu tiên có bằng tiến sĩ trong bất kỳ chủ đề nào). Nhưng nó không cảm thấy như một trở ngại trong công việc của tôi.

Đối với một điều, tôi đã nhận thấy khoảng cách này đang đóng lại trong nhiều lĩnh vực quan trọng. Các nhà phát triển mà tôi đã gặp, người diễn giải thử nghiệm A / B đã nhận thức được sự nguy hiểm của việc hack p và thử nghiệm nhiều giả thuyết, cũng như tầm quan trọng của kích thước hiệu ứng và khoảng tin cậy. Nhóm dữ liệu nói riêng đã làm việc để truyền bá các thông lệ tốt. Các lỗ hổng đã trở nên quen thuộc hơn dọc theo các dòng của sử dụng Poisson thay vì hồi quy tuyến tính, hay biết khi nào nên sử dụng thang đo log. "

Quan trọng hơn, tôi đã thấy rằng các nhà phát triển đã sẵn sàng lắng nghe và học hỏi hơn khi tôi đưa ra các vấn đề thống kê và tôi cảm thấy như các mối quan hệ công việc của tôi cho đến nay đã tạo dựng được sự tin tưởng lẫn nhau. Đây là một trường hợp trong đó kinh nghiệm của tôi thực sự đã không được phản ánh trong “Lập trình viên cần phải học Thống kê” bài viết , mà sơn nhà phát triển cuồng tín như quá tự tin. Có thể chúng tôi là một bộ phận kỹ thuật chức năng khác thường về vấn đề này (tôi đã nghe những câu chuyện tồi tệ hơn từ các công ty khác!), Nhưng cũng có thể thái độ của ngành phát triển phần mềm đã thay đổi trong sáu năm qua, với tầm quan trọng của số liệu thống kê được công nhận rộng rãi hơn.

Một khía cạnh của trường đại học tôi bỏ lỡ là học về thống kê từ những người khác. Tôi được bao quanh bởi những người hiểu biết hơn mình rất nhiều, và trong các cuộc họp và hội thảo trong phòng thí nghiệm, tôi đã tiếp xúc với rất nhiều lý thuyết và phương pháp thống kê hữu ích. Tôi cũng có thể tin tưởng vào những người khác để bắt nếu tôi mắc lỗi. Hầu hết giáo dục thống kê hiện tại của tôi phải tự điều khiển và tôi cần phải rất thận trọng với công việc của mình: Nếu tôi sử dụng một giả định thống kê không phù hợp trong báo cáo, không ai có thể chỉ ra điều đó.

Biết ít về kỹ thuật phần mềm

Từ lâu tôi đã quan tâm đến các thực tiễn lập trình và tôi đã sử dụng GitHub và đóng góp cho các dự án Python và R nguồn mở trong nhiều năm, nhưng làm việc cho một công ty công nghệ đã đại diện cho một sự thay đổi. Tôi là người dùng Mac trọn đời và trong vài năm qua đã hoạt động hoàn toàn trong R. Stack Overflow được xây dựng trên các công nghệ của Microsoft, đặc biệt là C #, ASP.NET và SQL Server và trước khi tôi tham gia không ai trong công ty đã từng sử dụng R. Tôi không gắn bó với một khía cạnh cụ thể của cuộc chiến ngôn ngữ , nhưng tôi chắc chắn lo lắng về sự thay đổi có ý nghĩa gì đối với tôi.

Điều này cũng hóa ra không phải là một trở ngại lớn, đặc biệt là tôi đã thấy rằng tôi có thể đóng góp rất nhiều cho công ty hoàn toàn từ bên trong R trên máy Mac. Tôi nợ rất nhiều nhà phát triển RSQLServertrình điều khiển jTDS ; nhờ có chúng tôi có thể dễ dàng truy vấn cơ sở dữ liệu của chúng tôi từ RStudio. Tôi có một cửa sổ Parallels với Visual Studio luôn mở, nhưng tôi thấy hầu hết các ngày tôi thậm chí không cần sử dụng nó. Đôi khi tôi đẩy mã để sản xuất (thường liên quan đến các thử nghiệm nhắm mục tiêu quảng cáo), nhưng nó không phải là một nguồn ma sát. Có nhiều lĩnh vực công nghệ phần mềm mà tôi biết nhiều ít về hơn đồng nghiệp của tôi, bao gồm thiết kế web front-end và kỹ thuật trang web đáng tin cậy, nhưng cũng giống như trong bất kỳ công ty tôi kết thúc khá cách ly khỏi những mối quan tâm.

Những thay đổi khác

Rời khỏi nghiên cứu sinh học . Đây có lẽ là sự thay đổi mà tôi lo lắng nhất. Trong tám năm (bao gồm hầu hết bằng đại học của tôi), nghiên cứu của tôi đã tập trung vào sinh học. Phải mất vài tháng làm việc cho các vấn đề khác để nhận ra rằng, thành thật mà nói, tôi chưa bao giờ đam mê các câu hỏi sinh học.

@ daattali @ JennyBryan @ noamross @ hspter

Tôi: Tôi có một giấc mơ kỳ lạ nhất, dài nhất tôi quan tâm đến

Vợ RNA : Đó không phải là một giấc mơ, đó là một tiến sĩ

- David Robinson (@drob) ngày 16 tháng 4 năm 2016

Sinh học trình bày rất nhiều vấn đề tính toán và thống kê thú vị, và có rất nhiều công việc thú vị đang diễn ra trong tin sinh học. Nhưng khi tôi hoàn thành một phân tích sinh học, tôi đã kết thúc với kết quả (giả sử, một trăm gen thay đổi biểu hiện để đáp ứng với một kích thích) mà tôi không có kiến ​​thức hoặc quan tâm để tự giải thích. (Ngay cả sau nhiều năm làm việc với toàn bộ bộ gen nấm men, tôi chỉ có thể nhận ra một số ít gen theo tên). Ngược lại, tôi là người dùng Stack Overflow lâu năm và tôi có mối quan tâm chung về trạng thái của hệ sinh thái nhà phát triển phần mềm, vì vậy tôi thấy một kết quả như các mạng ở trên, tôi có thể biết liệu nó có ý nghĩa ngay lập tức hay không. Cảm giác khác nhau khi làm việc trên dữ liệu mà tôi thực sự quan tâm.

Viết : Đây là một lợi thế tôi đánh giá thấp. Tôi đã viết rất nhiều bằng cấp của mình, chủ yếu cho các bài báo và luận văn của tôi, và sự thật là việc viết loại ngôn ngữ chính thức đó có thể cảm thấy khá khó khăn . Trong năm ngoái, hầu hết các bài viết của tôi là dành cho các báo cáo nội bộ, cho tài liệu hoặc cho các bài đăng trên blog, nơi tôi có thể viết không chính thức và đàm thoại (thử so sánh ngôn ngữ của luận án của tôi với bất kỳ bài đăng nào trên blog này). Tôi đã có một số nghiên cứu còn sót lại Tôi đang cố gắng để được xuất bản, và vì lý do này, rất khó để trở lại với suy nghĩ viết cho một bài báo.

Những người tôi làm việc cùng

Tôi có khiếu hài hước kỳ lạ, và nhiều bài tweet của tôi liên quan đến một tiểu thuyết giả tưởng Dev Dev phục vụ như một lá hài, hoặc để chế giễu văn hóa kỹ thuật hoặc để chế giễu sự thiếu kinh nghiệm của tôi trong đó.

Tôi: Bạn không thể chỉ thêm hai giá trị p với nhau.

Dev: Địa ngục tôi không thể:

newPval = pval1 + pval2;

Tôi: But-

Dev: Có phải tất cả các số liệu thống kê đều dễ dàng

- David Robinson (@drob) ngày 29 tháng 3 năm 2016

Tôi [smugly]: Vì vậy, bạn thấy, khi bạn sử dụng hiệu chỉnh đúng, giá trị p là 0,23 chứ không phải 0,02

Dev: Bạn có phải là người đã phá vỡ bản dựng ngày hôm qua

- David Robinson (@drob) ngày 11 tháng 4 năm 2016

Trong trường hợp không rõ ràng, mỗi một trong số các tweet này là một lời nói dối trắng trợn. Đầu tiên, không một trong những trao đổi này xảy ra. Nhưng quan trọng hơn, họ không phải là đại diện từ xa của các nhà phát triển mà tôi đã làm việc cùng. Những người thông minh, có năng lực, chu đáo tại công ty này là một trong những phần yêu thích của tôi khi làm việc ở đây.

Có nhiều danh sách đáng giá (chắc chắn là tất cả các thành viên của nhóm Dữ liệu và Máy chủ quảng cáo), nhưng tôi sẽ chỉ nêu một vài ví dụ. Jason Punyon là nhà phát triển ban đầu phát hiện ra bài đăng của tôi trên bản phân phối beta. Jason là một kỹ sư xuất sắc, và sau sáu năm ở đây, anh đã xây dựng được một lượng kiến ​​thức sản phẩm hữu ích khổng lồ. Một khía cạnh thực sự gây ấn tượng với tôi là cách anh ấy kết hợp việc quan tâm đến dữ liệu với việc quan tâm đến người dùng của chúng tôi.

Vài tháng trước tôi đã thực hiện một thử nghiệm cho thấy có một lợi ích đáng kể khi hiển thị mức lương trên quảng cáo việc làm (thêm về điều đó trong các bài đăng trong tương lai) và chia sẻ kết quả trong công ty. Tôi rất vui khi chia sẻ một số kết luận mà tôi đã học được. Nhưng Jason đã lấy kết quả và biến chúng thành hành động, bắt đầu thúc đẩy tất cả các nhà tuyển dụng (bao gồm cả chúng tôi) cung cấp thông tin về lương trong danh sách. Anh ấy đã làm điều đó bởi vì anh ấy coi trọng dữ liệu, như một thứ gì đó hướng dẫn sự lựa chọn của anh ấy và điều đó sẽ hướng dẫn các quyết định của công ty. Ông cũng quan tâm đến các nhà phát triển, với tư cách là người dùng sản phẩm của chúng tôi và mọi người, và nghĩ rằng họ xứng đáng được biết thông tin về tiền lương. Tôi tự hào được làm việc với anh ấy.

Có rất nhiều người bên ngoài bộ phận kỹ thuật mà tôi rất ấn tượng và tôi đặc biệt vui mừng khi được làm việc với Nhóm cộng đồng . Chẳng hạn, Taryn Pratt đã gia nhập đội một vài tháng trước khi tôi bắt đầu. Tôi đã đóng góp cho cộng đồng Stack Overflow trước khi tôi làm việc ở đây, nhưng không có gì so với những đóng góp của Taryn. Cô đã là người trả lời và điều hành tích cực trong nhiều năm, bao gồm trả lời> 3500 câu hỏi và truyền> 22.000 cờ hữu ích (!!).

Mặc dù Taryn không phải là nhà phát triển ở đây, nhưng cô ấy có kinh nghiệm và kỹ năng tuyệt vời (đúng với hầu hết các Nhà quản lý cộng đồng). Và cô ấy cam kết những kỹ năng này (đặc biệt là SQL) để giúp cộng đồng Stack Overflow. Trong bối cảnh đó, gần đây cô đã bắt đầu học R, vì vậy cô có thể áp dụng các phương pháp thống kê, dựa trên dữ liệu để phân tích và hiểu các mẫu trong hoạt động Hỏi và Đáp. Với sự giúp đỡ của cô ấy và những người khác trong nhóm, tôi thực sự rất phấn khích khi thấy những gì khoa học dữ liệu có thể đóng góp cho cộng đồng.

Lời khuyên của tôi cho sinh viên tốt nghiệp: Tạo các tạo tác công cộng

Một thời gian sau khi tôi được thuê, tôi đã biết thêm một chút về câu chuyện đằng sau dòng tweet của Jason, và cuộc trò chuyện nội bộ về việc tiếp cận với tôi đã bắt đầu một cách bất chợt.

Tôi cảm thấy thực sự may mắn khi có công việc hiện tại và thấy điều đó khiến tôi cảm thấy may mắn hơn nữa. Hoàn cảnh tuyển dụng của tôi có lẽ là quá nhiều tai nạn kỳ quặc để rút ra bất kỳ lời khuyên nào. Nhưng nếu tôi cố gắng đưa ra lời khuyên cho những người vẫn còn học cao học, thì đây là điều tôi nghĩ ra: Công việc không phải là một sự lãng phí thời gian.

Khi tôi học cao học, tôi quan tâm nhất đến việc xuất bản các bài báo; theo hiểu biết của tôi đó là dấu hiệu của một mức độ thành công, và điều duy nhất quan trọng cho sự nghiệp của tôi. Cuối cùng tôi đã xuất bản khoảng số trung vị cho một tiến sĩ trong lĩnh vực của tôi. Tôi rất vui vì tôi đã làm như vậy, nhưng thành thật mà nói, thật khó để chỉ ra một cách mà cuộc sống của tôi sẽ khác đi nếu tôi xuất bản ít hơn hoặc thậm chí không ai trong số họ. Nhưng tôi biết chắc chắn cuộc sống của tôi sẽ khác nếu tôi không đăng về bản phân phối beta, và thậm chí còn khác hơn nếu tôi chưa bắt đầu trả lời trên Stack Overflow.

Các bài báo trên tạp chí là một cách để tạo ra công việc công cộng, nhưng khác xa với cách duy nhất: Họ chậm xem xét và họ cần phải là người hoàn hảo trước khi được gửi. Tôi nghĩ rằng có một thái độ nguy hiểm rằng họ là cách duy nhất để công khai công việc, và do đó rất nhiều công việc tốt trong học viện mòn mỏi trong nhiều năm hoặc biến mất hoàn toàn vì nó không hoàn toàn là một bài báo (chắc chắn không có bài đăng nào trên blog của tôi đủ điều kiện trình như một bài báo). Vì vậy, tôi muốn nói rằng nếu bạn có một cái gì đó thú vị nhưng nó không hoàn toàn là một bài báo, hãy viết nó dưới dạng một bài đăng trên blog hoặc câu trả lời Stack Overflow hoặc một dự án nguồn mở trên GitHub. Chỉ cần nhận được một cái gì đó ra khỏi đó!

Như tôi đã nói lúc đầu, tôi rất vui vì đã trả lời câu hỏi đó về bản phân phối beta. Nó đã cho tôi cơ hội để làm việc trên một sản phẩm đã làm rất nhiều cho kiến ​​thức và năng suất lập trình của tôi. Tôi được làm việc với những người xây dựng nó, những người cho đến ngày nay luôn gây ấn tượng với tôi. Và một năm sau, đó là công việc tốt nhất tôi có thể yêu cầu.

Vâng, gần như là tốt nhất.

|