Làm thế nào để tôi trở thành một lập trình viên tự chủ và tự chủ hơn? [đóng cửa]


13

Yếu tố lớn nhất trong những gì ngăn cản tôi trở thành một nhà phát triển xuất sắc là sự phụ thuộc của tôi vào người khác. Tôi cảm thấy như tôi hỏi quá nhiều câu hỏi vì tôi sợ hậu quả của việc phá vỡ mọi thứ và kìm hãm mọi người. Vì vậy, tôi quá thận trọng bằng cách hỏi rất nhiều câu hỏi mà về cơ bản tôi nhận được câu trả lời sau khi đủ câu hỏi. Tôi đã nhận ra điều đó là xấu nhưng tôi muốn ngăn chặn nó. Một phần của nó là có những lúc tôi chỉ đơn giản là không biết mã (có thể là một chi nhánh tôi chưa từng làm việc hoặc đó là một sản phẩm hoàn toàn mới), nhưng tôi muốn ít dựa vào người khác. Đối với lời nói đầu, những loại câu hỏi này không phải là câu hỏi về các mẫu hoặc ngôn ngữ chung: thông thường các câu hỏi của tôi xoay quanh cách chúng tôi làm mã tại công ty của chúng tôi và cách chúng tôi làm cho mọi thứ hoạt động trong hệ sinh thái của chúng tôi. Tôi muốn có thể lấy thông số kỹ thuật và lăn lộn với chúng mà không cần phải cảm thấy mình cần được giúp đỡ mỗi bước. Điều này có bình thường không? Bạn đã trải qua điều này, và nếu vậy, làm thế nào bạn vượt qua nó?


1
Có thể đây chỉ là một thứ văn hóa / ngôn ngữ ... nhưng điều gì khiến bạn nghĩ rằng mình sẽ trở thành một nhà phát triển xuất sắc? Điều gì làm cho bạn tốt hơn nhiều so với 99% các nhà phát triển mới khác?
Stephen C

5
Bây giờ tôi không phải là một, nhưng tôi muốn trở thành. Tôi luôn phấn đấu để học hỏi và cải thiện. Hầu hết mọi người sợ thậm chí thừa nhận họ có vấn đề. Tôi muốn tìm ra vấn đề của mình, thừa nhận và giải quyết chúng. Tốt nhất trong bất kỳ lĩnh vực nào phấn đấu để cải tiến liên tục, và tôi đặt mục tiêu làm như vậy.
acconrad

Câu trả lời:


24

Tôi thấy một số nhà phát triển mới đi vào công việc và ngay lập tức cảm thấy không thỏa đáng. Tôi đã làm như vậy sớm trong sự nghiệp của tôi. Tôi nghĩ có ít nhất hai vấn đề lớn mà hầu hết những người thông minh cần khắc phục: nhận thức về thời gian và khả năng tự nhiên của chính họ.

Nhận thức về thời gian
Những kẻ thông minh được sử dụng để giải quyết vấn đề tương đối nhanh chóng. Tôi nhớ là đã kinh ngạc khi tôi phải dành một giờ cho một vấn đề tính toán duy nhất. Dành 60 phút cho một vấn đề không còn gì nữa. Những ngày đó đã qua ... chôn vùi họ và nói lời tạm biệt. Sự phức tạp và kích thước của hầu hết các phần mềm ngày nay là thái quá. Mọi người không hiểu tất cả các công cụ họ phải sử dụng để hoàn thành công việc lâu hơn. Một trong những người chủ chốt của ngôn ngữ JavaScript, Douglas Crockford nói,

"Misapplication of standard tools...is the new standard."

Không có đủ thời gian trên thế giới để tìm hiểu tất cả các công cụ dev.

Khả năng tự nhiên
Trí thông minh, khả năng giải quyết vấn đề và kỹ năng tự nhiên của bạn đã đưa bạn vào toàn bộ buổi biểu diễn của nhà phát triển ngay từ đầu. Không có chỗ cho bất cứ điều gì ít hơn trong lĩnh vực này. Vậy bạn sẽ làm gì với 100.000 dòng mã, ngôn ngữ và khung mà bạn hầu như không biết, các mẫu thiết kế và mô hình mà mọi người đang thúc đẩy bạn, những người biết hầu hết về nó như bàn tay của họ, những khách hàng muốn nó ngày hôm qua và một ông chủ Ai mong thế giới của bạn? Freak out như khả năng tự nhiên của bạn thất bại.

Phải, đó là bình thường. Tôi vẫn còn bối rối với một số thứ bị ném theo cách của tôi.

Những gì có thể được thực hiện?

Đã đến lúc phải cải thiện những khả năng tự nhiên đó bằng công việc khó khăn kiểu cũ. Làm việc để phá vỡ các vấn đề thành các phần nhỏ hơn. Và nhận ra rằng không giống như rất nhiều điều bạn có thể đã làm trong quá khứ, những vấn đề này cần rất nhiều thời gian để giải quyết. Vì vậy, đừng bỏ cuộc chỉ sau 15 phút kiểm tra một vấn đề phức tạp. Thay vào đó, phá vỡ các vấn đề và ngừng xem đồng hồ. Sau một thời gian, 30 phút làm việc với một vấn đề thực sự không giống như trước đây.

Sự tự tin đóng một vai trò lớn trong khả năng tự quản trị. Đội ngũ, đặc biệt là những người cao niên có kinh nghiệm hơn. Thật tốt khi cẩn thận về việc không phá vỡ mọi thứ, nhưng điều này không có nghĩa là bạn cần phải hỏi một dòng câu hỏi liên tục.

Thay vào đó, hãy sử dụng kiểm soát nguồn. Miễn là bạn không kiểm tra thay đổi, bạn không thể phá vỡ sản phẩm chính và khiến các nhà phát triển khác tức giận. Ngoài ra, thực hiện các thay đổi mà bạn có thể hiểu và kiểm tra và chắc chắn kiểm tra chúng trước khi đăng ký.

Tôi thậm chí có một dự án thử nghiệm nhỏ mà tôi sử dụng để viết một lần, các chương trình đơn giản vì vậy tôi không phải lo lắng về tất cả các hoạt động trong ứng dụng chính.

Cuối cùng, hãy nhớ rằng mọi quyết định đều đi kèm với một số mức độ cho và nhận. Không có tiến lên mà không thực hiện một số loại hy sinh ở một mức độ nào đó. Đừng phấn đấu cho sự hoàn hảo, phấn đấu cho sự tuyệt vời và lưu tâm đến hành động của bạn. Bởi vì bạn luôn cần chuẩn bị sẵn sàng để đưa ra lời phê bình và giải thích ý tưởng của bạn và lý do tại sao bạn thực hiện chúng. Hãy tự hào về những quyết định bạn đưa ra. Ngay cả khi họ sai cũng có nhiều điều phải học.


2
+1 làm việc tại đó cho đến khi bạn từ bỏ. Đôi khi tôi đã dành 2-3 ngày để giải quyết một vấn đề. Đối với phá vỡ: thử TDD, hoặc ít nhất là viết bài kiểm tra đơn vị.
tro999

12

Điều đầu tiên là đừng ngại đặt câu hỏi. Tôi đã từng thấy các kiến ​​trúc sư cao cấp đặt câu hỏi về mã. Họ không mong đợi để biết tất cả mọi thứ; họ dự kiến ​​sẽ biết đủ để hoàn thành công việc và có thể tìm ra phần còn lại.

Có lẽ chiến thuật tốt nhất sẽ là:

  • Tìm hiểu cách nghiên cứu trên Google. Bạn có thể tìm thấy câu trả lời cho hầu hết mọi thứ với một công việc điều tra nhỏ. Stack Overflow hoạt động kỳ diệu cho những vấn đề khó giải quyết.
  • Tìm hiểu làm thế nào để gỡ lỗi. Tôi đã dành hàng giờ để bước vào mã doanh nghiệp sâu sắc, kỳ quặc, chỉ để tìm biến X là 3 thay vì 7. Có thể đọc mã và gỡ lỗi có lẽ là cách tốt nhất để trở nên tự chủ.

Không phải tôi là một bông hoa đặc biệt, nhưng vấn đề của tôi không nằm ở ngôn ngữ. Đó không phải là cách làm mọi thứ trong ngôn ngữ của tôi. Hầu hết các câu hỏi của tôi đều rất tập trung vào công ty: đó là về cách thực hiện mọi thứ trong miền cụ thể cho môi trường tại nơi làm việc của chúng tôi. Chúng là những thứ bạn không thể Google, nếu bạn muốn.
acconrad

3
Tôi hiểu hoàn toàn; Tôi đã ở trong tình trạng tương tự trong ba năm. Bullet point # 2 là câu trả lời: Học cách gỡ lỗi. Mọi người không nhớ chi tiết thường xuyên; gỡ lỗi là chìa khóa.
tro999

1
Tôi đồng ý. Tiếp tục đặt câu hỏi, cho đến khi bạn biết nhiều câu trả lời hơn những người xung quanh bạn. Đi xuống và nói chuyện với nhóm QA cho đến khi bạn có thể phát hiện ra lỗi cũng như sửa chúng. Google là bạn chuyên gia của bạn; sử dụng anh ta rộng rãi. Một ngày nào đó bạn sẽ thấy rằng bạn gửi e-mail đặt câu hỏi và tự tìm câu trả lời trước khi trả lời lại.
Andy Canfield

5

Đừng ngại đặt câu hỏi "bức tranh lớn"

Tôi đã từng cố gắng tìm câu hỏi nhỏ nhất mà tôi có thể hỏi và vẫn có thể tiếp tục công việc của mình, vì sợ tôi sẽ bị coi là bất tài nếu tôi hỏi những câu hỏi rộng mà mọi người khác dường như biết câu trả lời. Tôi không hiểu sự khác biệt giữa thiếu hiểu biết và bất tài. Vô minh chỉ có nghĩa là bạn chưa học được điều gì, và hoàn toàn chấp nhận được miễn là nó không tồn tại. Giả vờ không biết gì là tồi tệ hơn nhiều.

Nếu bạn thấy rằng câu trả lời của mọi người chỉ đưa bạn đến nay, bạn cần yêu cầu họ dạy bạn câu cá thay vì trao cho bạn một con cá khác. Hỏi làm thế nào phần của bạn phù hợp với toàn bộ. Nếu câu hỏi của bạn có vẻ cơ bản như "SQL là gì" thì hãy hỏi nó sớm hơn là sau này. Bây giờ bạn có thể trông hơi ngốc nghếch, nhưng sau này sẽ trông ngốc nghếch hơn rất nhiều.

Cho mình một khoảng thời gian chờ đợi

Đừng đặt câu hỏi ngay khi bạn có chúng. Tùy thuộc vào sự phức tạp, hãy dành cho bản thân bất cứ nơi nào từ nửa giờ đến một ngày để cố gắng tự mình tìm ra nó. Rất nhiều lần bạn sẽ tự giải quyết nó. Nếu không, bạn sẽ có thể nói với đồng nghiệp của mình những gì không hiệu quả, điều này có thể giúp anh ấy trả lời tốt hơn.

Ngoài ra, nếu đồng nghiệp của bạn không biết câu trả lời trên đỉnh đầu, hãy chú ý đến cách anh ta đến đó. Rất nhiều lần bạn không cần nhiều sự giúp đỡ như bạn nghĩ. Nếu tôi không có thời gian cho một câu hỏi, tôi sẽ thường chỉ cho ai đó một hướng mơ hồ và nói với họ rằng tôi sẽ đến theo dõi khi tôi nhận được một phút, và họ thường giải quyết nó khi tôi đến đó.

Vứt bỏ một số dự thảo

Ngồi xuống và đặt mọi thứ vào đầu bạn và sau đó bạn là một nhà văn. Nhưng một tác giả là một người có thể đánh giá giá trị của chính mình, mà không thương hại và phá hủy hầu hết.
Mầm non

Đừng ngại viết mã sẽ không bao giờ biến nó thành một bản phát hành. Bạn càng có nhiều kinh nghiệm, bạn càng sớm có thể nói rằng bạn đang đi sai đường, nhưng đi sai đường vẫn xảy ra. Rất nhiều lần giá trị của một giải pháp không rõ ràng cho đến khi bạn thấy nó làm sai cách trước.


1

Tự túc sẽ đi kèm với

  • Tăng kinh nghiệm và tiếp xúc trong miền.
  • Tăng kỹ năng quan sát và kỹ năng phân tích để hiểu các hệ thống hiện có và hành vi, sự phụ thuộc của chúng.

Đặt câu hỏi thường xuyên sẽ có nguy cơ cho thấy bạn thiếu cả hai điều này.

Nếu bạn thay đổi tên miền, công nghệ, nền tảng, ngôn ngữ của mình, bạn sẽ quay lại hình vuông (Gần như, không tính khả năng tăng của bạn để giải quyết các vấn đề tương tự và kiến ​​thức có thể chuyển nhượng)

Không đặt câu hỏi khi thực sự cần thiết sẽ lãng phí rất nhiều thời gian sản xuất có giá trị.

Nó có thể có ích cho bạn trong việc bỏ một từ về giả định của bạn về mức độ thiệt hại có thể xảy ra nếu bạn làm sai. hoặc những gì bạn nghĩ có thể phá vỡ để có được đánh giá thực tế về các giả định của bạn. Rất nhiều lần nó có thể cho phép bạn phát hiện ra các điểm và góc bạn đã bỏ lỡ.

Thận trọng là tốt. Nhưng tốt nhất bạn nên bắt đầu xác định Bản chất của câu hỏi của mình. Tốt nhất nếu bạn viết nó ra giấy và kiểm tra độ khó / giá trị của nó.

  1. Đây có phải là thứ bạn có thể tìm ra với google / forum hay bằng cách làm việc với nó lâu hơn
  2. Đây có phải là thứ bạn có thể lấy đi hoặc sửa chữa mà không tốn nhiều chi phí nếu bạn làm hỏng?

0

Tôi sẽ nói để xem xét những điều bạn đang làm việc và bắt đầu tự mình đưa ra quyết định (tất nhiên là giữ trong thông số kỹ thuật của ứng dụng). Bây giờ, bạn nên có một cảm giác tốt cho những gì là một thay đổi sâu rộng và một thay đổi đơn giản. Bắt đầu với những cái đơn giản. Nếu bạn nghĩ những gì bạn đang làm là đúng, hãy làm nó.

Bạn S make mắc sai lầm và những điều đó là vô giá. Học mọi thứ bạn có thể từ họ khi chúng xảy ra vì chúng là thứ sẽ khiến bạn làm tốt hơn vào lần tới.

Một khi bạn cảm thấy thoải mái với những quyết định nhỏ hơn, hãy bắt đầu thực hiện những quyết định lớn hơn. Bạn sẽ cần phải quyết định sẽ đi bao xa với điều này dựa trên dự án / môi trường / nhóm của bạn.

Đó là khía cạnh ra quyết định. Một điều khác bạn cần làm là tiếp tục nuôi dưỡng não của bạn để nó có thể giúp định hướng các quyết định của bạn. Theo dõi các trang web bao gồm công nghệ của bạn. Có những hướng dẫn trực tuyến về hầu hết mọi thứ ngoài kia bao gồm mọi thứ, từ đơn giản đến phức tạp đến kỳ lạ. Đừng ngại hỏi mọi người tại sao họ đưa ra quyết định nhất định - với tư cách là người tìm kiếm thông tin, không phải là người đối đầu. Hầu hết mọi người đều rất vui khi giải thích mọi thứ và bạn có thể học được khá nhiều từ họ.

Một khi bạn có kiến ​​thức kỹ thuật, phần còn lại là sự khôn ngoan và tự tin và những người đi kèm với kinh nghiệm.


0

Khi tôi là một người mới đặt câu hỏi, tôi sẽ luôn cố gắng tự mình trả lời một phần cho vấn đề đó, sử dụng các công cụ có sẵn; và khi tôi đã đi xa hết mức có thể, tôi sẽ tìm ra chính xác cách diễn đạt câu hỏi của mình sao cho rõ ràng và súc tích nhất có thể, theo giả định rằng người mà tôi sẽ giúp đỡ đang bận rộn. Với một chút chuẩn bị này, tôi không nghĩ có ai từng để tôi hỏi họ câu hỏi và thực tế tôi có ấn tượng rằng họ rất thích nó. Sau này, khi tôi trở thành chuyên gia về miền, tôi cũng thích giúp đỡ những người nói rõ rằng họ tôn trọng thời gian của tôi.

Một điều khác tôi đã làm là, mỗi ngày, chọn qua kiến ​​trúc của hệ thống. Các áp phích khác đã bình luận về những gì một hệ thống hiện đại khổng lồ đang thực hiện, khó đến mức nào. Vì vậy, tôi sẽ thực hiện các chuyến tham quan về mã: bắt đầu tại một số điểm nhập cảnh hợp lý, sau đó lần theo dấu vết của nó, ghi chú cho bản thân về cách nó hoạt động, hỏi những câu hỏi mà đôi khi tôi sẽ tự trả lời, đôi khi hỏi người khác. Kiểu này bao quát sự quen thuộc và năng lực miền cần có thời gian, nhưng bạn có thể tăng tốc nó; và bạn càng làm, bạn sẽ càng sớm tự lập theo những cách bạn muốn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.