Làm thế nào tôi có thể biết liệu tôi có phải là một lập trình viên giỏi không?

Giống như hầu hết mọi người, tôi nghĩ về bản thân mình là một chút trên trung bình trong lĩnh vực của tôi. Tôi được trả tiền tốt, tôi đã nhận được các chương trình khuyến mãi và tôi chưa bao giờ gặp vấn đề thực sự khi nhận được tài liệu tham khảo tốt hoặc nhận được một công việc.

Nhưng tôi đã có đủ để nhận thấy rằng nhiều lập trình viên tồi tệ nhất mà tôi từng làm việc nghĩ rằng họ là một trong những người giỏi nhất. Những lập trình viên tồi, những người bị bao vây bởi những lập trình viên tồi khác dường như là những người tự ảo tưởng nhất.

Tôi chắc chắn không hoàn hảo. Tôi đã phạm sai lầm. Tôi bỏ lỡ thời hạn. Nhưng tôi nghĩ rằng tôi thực hiện về cùng một số động tác xương mà "các lập trình viên giỏi" khác làm. Vấn đề là tôi định nghĩa "những lập trình viên giỏi khác" có nghĩa là "những người giống tôi".

Vì vậy, tôi tự hỏi, có cách nào một lập trình viên có thể thực hiện một số loại tự đánh giá hợp lý? Làm thế nào để chúng ta biết liệu chúng ta tốt hay xấu trong công việc của chúng ta?

Hoặc, nếu các thuật ngữ như tốt và xấu quá không rõ ràng, làm thế nào các lập trình viên có thể xác định trung thực điểm mạnh và điểm yếu của họ, để họ có thể tận dụng lợi thế trước và làm việc để cải thiện điều sau?

Một lập trình viên giỏi hiểu rằng họ phải tiếp tục học hỏi và phát triển. Họ cố gắng làm hết sức mình trong mọi nỗ lực, thừa nhận thất bại và học hỏi từ họ.

Họ là những người giao tiếp phi thường. Họ không chỉ có thể giải thích các thuật ngữ kỹ thuật phức tạp cho một giáo dân, mà họ còn cố gắng hành động như một người ủng hộ ma quỷ theo ý tưởng của riêng họ để đảm bảo rằng họ đưa ra những lựa chọn tốt nhất cho khách hàng của họ.

Các lập trình viên giỏi nhất biết và chấp nhận rằng có nhiều hơn một cách để làm mọi thứ, rằng không phải mọi vấn đề đều là vấn đề, và bởi vì luôn có cách tốt hơn để làm một việc gì đó hơn là cách họ dự định tiếp tục tìm hiểu các kỹ thuật mới , công nghệ và sự hiểu biết.

Một lập trình viên giỏi thích lập trình, và sẽ làm như vậy trong thời gian rảnh rỗi ngay cả khi họ đã dành hơn 80 giờ một tuần để lập trình.

Một lập trình viên giỏi biết rằng cô ấy / anh ấy không phải là một lập trình viên tuyệt vời. Những lập trình viên thực sự vĩ đại không tồn tại, chỉ có những người tự nhận là vĩ đại, và những người biết họ không vĩ đại.

Như Paul Graham chỉ ra một cách hùng hồn trong nhóm diễn viên này , bạn không thể. Chỉ đồng nghiệp của bạn có thể nói với bạn.

Tôi luôn thấy rằng dễ dàng nhất để đánh giá hiệu suất của bạn bằng cách thực hiện hai điều.

1. Bao quanh bạn với các lập trình viên giỏi khác
2. Xem họ phàn nàn bao nhiêu về mã bạn viết.

Vấn đề tất nhiên là tìm kiếm các lập trình viên giỏi, và sau đó trở thành một lập trình viên giỏi cũng không chỉ là về mã hóa. Bạn cần có khả năng làm việc tốt trong các nhóm, nhưng cũng có thể tự làm việc tốt.

Bây giờ vì mục đích lạc đề, tôi sẽ trích dẫn Robert A. Heinlein và quan điểm của ông về chủ đề này:

"[Một lập trình viên kick-ass] sẽ có thể thay tã, lên kế hoạch xâm lược, bán thịt lợn, đóng tàu, thiết kế một tòa nhà, viết sonnet, cân bằng tài khoản, xây tường, đặt xương, an ủi người sắp chết , ra lệnh, ra lệnh, hợp tác, hành động một mình, giải phương trình, phân tích một vấn đề mới, phân bón, lập trình máy tính, nấu một bữa ăn ngon, chiến đấu hiệu quả và chết một cách dũng cảm. Chuyên môn hóa là dành cho côn trùng. "
- từ Sổ tay của Lazarus Long.

Đây là Ma trận năng lực lập trình viên chỉ dành cho bạn: http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htmlm

Jeff có một trong những bài đăng blog yêu thích của tôi về chủ đề này ... Tại sao tôi là lập trình viên giỏi nhất thế giới

"... đó không phải là công việc của chúng tôi tốt hơn bất kỳ ai khác; chúng tôi chỉ cần giỏi hơn chúng tôi một năm trước."

Tôi nghĩ rằng việc bạn đang đặt câu hỏi chứng tỏ bạn không phải là một lập trình viên tồi, vì vậy, theo tôi, bạn đang đi được một nửa. :)

Những lập trình viên tồi luôn nghĩ rằng họ là những lập trình viên tuyệt vời, theo kinh nghiệm của tôi.

Câu nói của @ Nick "Những lập trình viên tồi luôn nghĩ rằng họ là những lập trình viên tuyệt vời ..." được giải thích bởi Hiệu ứng Dunning Kruger , nói chung rằng những người biết một chút về một chủ đề thường vượt quá mức ước tính họ thực sự biết.

Là một người ít nói ... bạn càng ít nghĩ rằng bạn càng biết nhiều về bạn, trừ khi tất nhiên bạn là một thằng ngốc thực sự tự nhận thức.

Trả lời câu hỏi ban đầu, mặc dù tôi có xu hướng nghĩ rằng ảnh hưởng nhiều hơn (không kiểm soát) mà bạn có thường là một chỉ số tốt. Nếu bạn thấy người khác đi theo sự dẫn dắt của bạn, hoặc chọn cách thực hành thì bạn đang đi đúng hướng.

Câu trả lời nhận được nhiều phiếu bầu nhất là thực sự đau khổ. Về cơ bản nó nói rằng bạn không có cuộc sống ngoài lập trình. Gia đình thì sao? Cộng đồng? Sở thích? Chúng ta thuộc loại nghề nghiệp nào trong đó bạn phải bận tâm đến mức ám ảnh chỉ để được coi là "tốt"? Tôi thực sự nghĩ rằng chúng ta cần có được một số quan điểm ở đây.

Bạn có thể thử cạnh tranh trong các cuộc thi thuật toán TopCoder .

Tôi không hoàn hảo. Tôi mắc lỗi. Tôi nhớ thời hạn. Nhưng tôi nghĩ rằng tôi thực hiện về cùng một số động tác xương mà "các lập trình viên giỏi" khác làm.

Nhận thức đó một mình làm cho bạn trở thành một lập trình viên tốt hơn so với hầu hết các lập trình viên xấu ngoài kia.

Rất nhiều lập trình viên tồi tệ nhất có xu hướng nghĩ rằng họ đã biết tất cả mọi thứ cần biết và không nhận thức được những hạn chế của họ. Kết quả là, họ không bao giờ cải thiện kỹ năng của họ.

Nếu bạn nhìn vào mã của bạn từ giả sử một năm trước, và nghĩ, trời ạ, tôi có thể đã làm điều đó tốt hơn rất nhiều, có lẽ bạn tốt :).

Dưới đây là một số ví dụ thực tế về lập trình xấu. Tất nhiên, mã tương tự đã được sao chép / dán ở 100 nơi. Guy đã bị sa thải, nhưng tôi nghe nói rằng anh ta đã có một công việc tốt một lần nữa. Thưởng thức:

a)

if (! TableObject.loadList("sql condition").isEmpty()) {  
    List<TableObject> myList = TableObject.loadList("sql condition");  
    ...  
}

b)

public static Type getInstance() {  
    if (instance == null) {  
        return new Type();  
    }  
    return instance;  
}

c)

getForeignKeyObjectProperty1() {  
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getProperty1();  
}  

getForeignKeyObjectProperty2() {  
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getProperty2();  
}  

...

getForeignKeyObjectPropertyN() {
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getPropertyN();
}

Cười mở miệng)

public boolean isHasImage() throws SQLException {
    StringBuilder query = new StringBuilder();
    query.append("select user_name");
    query.append(" from user");
    query.append(" where has_image = 1");
    query.append(" and user_name ='"+getUserName()+"' and user_image is not null");
    Connection c = Database.getInstance().getConnection();
    Statement st = c.createStatement();

    try {
        ResultSet rs = st.executeQuery(query.toString());
        if (rs.hasNext()) {
            return true;
        } else {
            return false;
        }
    } finally {
        st.close();
    }
}

Nếu bạn thực hiện loại mã này, dừng lập trình. Nếu bạn không thấy bất cứ điều gì lạ trong mã này, hãy ngừng lập trình. Nếu không thì bạn không tệ, vì vậy bạn thậm chí có thể tốt :)

EDIT: Để trả lời các bình luận: Tôi đã có việc làm trước khi tốt nghiệp, và anh chàng này đã có vài năm kinh nghiệm lập trình. Anh ta bị đuổi việc vài tháng sau khi tôi đi làm nên tôi không ở vị trí gia sư cho bất cứ ai. Các ví dụ ở trên chỉ nằm trên đỉnh đầu của tôi - mọi sự an tâm về mã mà anh ấy chạm vào đều bị thiếu sót theo nhiều cách khác nhau và giàu trí tưởng tượng. Hầu hết mọi thứ bắt đầu bò ra sau khi anh ta đi từ công ty, bởi vì chỉ sau đó những người khác nhìn thấy một số phần của mã. Anh ấy nói chung là một chàng trai tốt, dễ nói chuyện, v.v. nhưng anh ấy sẽ KHÔNG BAO GIỜ là một lập trình viên giỏi, giống như tôi sẽ không bao giờ là một họa sĩ giỏi hay một nhà văn hay bất cứ điều gì.

Để đối chiếu điều này với một ví dụ khác, anh chàng đến thay thế anh ta cũng đang học đại học vào thời điểm đó. Anh học đại học nổi tiếng hơn về quản lý rồi lập trình. Anh ấy không quá táo tợn theo nghĩa là anh ấy đã lập trình bất cứ điều gì cho vui hoặc sẽ ngồi nhà và đọc về java hoặc lập trình, nhưng anh ấy vẫn làm tốt. Ông điều chỉnh nhanh chóng và bắt đầu sản xuất mã hữu ích và có thể bảo trì. Một số người có thể làm điều đó, những người khác thì không thể - chỉ cần hỏi Dailywtf.

Có một vài điều bạn có thể thử, để có được một thước đo tốt hơn về cách bạn xếp chồng lên nhau.

• So sánh đánh giá mã. Xem đánh giá của ai tiết lộ nhiều vấn đề hơn.
• Hỏi lần cuối cùng họ đọc những cuốn sách ngoại vi với quá trình học tập bình thường của họ là khi nào. Sau đó tự hỏi mình điều tương tự.
• Hãy tự hỏi ai là người đưa ra ý tưởng mới cho công ty (và họ làm việc tốt như thế nào).
• Cuối cùng (và ít nhất), có một số hình thức công nhận công ty?

(Tôi đặt rằng người cuối cùng vì tại công ty cuối cùng của tôi, một lập trình viên nhận "nhà phát triển của năm" hai lần trong ba năm. Sau khi ông rời đi, chúng tôi thấy ít nhất 20 đoạn mã TDWTF-xứng đáng. Ông phát triển mã nhanh , nhưng không nhất thiết phải tốt Quản lý chỉ không biết sự khác biệt.)

Cho phép các nhà phát triển khác mà bạn tôn trọng làm việc với hoặc xem mã của bạn.

Có người thực sự sử dụng những gì bạn thích và xem những gì họ nghĩ.

- Kevin Fairchild

Bạn có hiểu cái này không?

if(rp->p_flag&SSWAP) {
	rp->p_flag =& ~SSWAP;
	aretu(u.u_ssav);
}

:-)

Chỉ cần suy nghĩ rằng bạn cần phải tự đánh giá sẽ khiến bạn bị cắt giảm so với phần còn lại.

Một cách tôi luôn đánh giá bản thân mình là lắng nghe những gì đồng nghiệp nói về tôi. Thủ thuật là tìm đúng người.

Nó luôn luôn chủ quan ai là một lập trình viên giỏi. Tôi đồng ý với Nick rằng chỉ cần đặt câu hỏi là một bước đi đúng hướng. Tôi nghĩ rằng mong muốn không ngừng học hỏi và cải thiện là điều làm nên một lập trình viên giỏi.

Đối với tôi, những lập trình viên giỏi nhất không bao giờ tìm việc. Họ đã cung cấp thường trực cho các vị trí mới chỉ dựa trên danh tiếng của họ. Vì vậy, một lập trình viên giỏi có thể có lời đề nghị từ các nhà tuyển dụng trước để trả lại, nếu họ muốn. Hoặc một lập trình viên giỏi sẽ có những câu hỏi từ các đồng nghiệp cũ về việc đến làm việc cho họ tại một công ty mới.

Về điểm mạnh / điểm yếu, có lẽ bạn đã biết chúng. Nếu không, hãy hỏi một người cao cấp hơn trong nhóm của bạn. Nó thậm chí không phải là một nhà phát triển. Một người quản lý dự án tốt biết điểm mạnh / điểm yếu của lập trình viên. Bên cạnh đó, những đặc điểm xác định một lập trình viên giỏi không chỉ giới hạn ở mã. Hiểu về kinh doanh, kỹ năng giao tiếp, phán đoán, v.v ... đều được thực hiện bên ngoài IDE của bạn.

Tôi nghĩ điều này giống như tự hỏi làm thế nào bạn có thể biết nếu bạn là một người tốt.

Tôi nghĩ, thật không may, câu trả lời là chỉ những người đáng tin cậy khác có thể nói với bạn điều đó. Tôi không nghĩ đó là thứ bạn có thể tự xác định chính xác (ít nhất là rất khó - nhưng tôi nghĩ nó có thể là không thể).

tôi chỉ đơn giản nói: nếu bạn đam mê (ý tôi là THỰC SỰ đam mê) về những gì bạn làm, nếu bạn linh hoạt (ngôn ngữ khác, công nghệ mới, làm lại hoàn toàn một dự án cũ - hãy làm đi!), nếu bạn tiếp tục học và cải thiện kỹ năng của bạn và không bao giờ, không bao giờ nghĩ rằng bạn đủ tốt để dừng lại - thì bạn là một lập trình viên giỏi!

95% tất cả các lập trình viên nghĩ rằng họ nằm trong số 5% lập trình viên hàng đầu, 5% còn lại là các nhà quản lý. Vì vậy, nếu bạn là một người quản lý, có lẽ bạn không phải là một lập trình viên giỏi, nếu không thì có lẽ bạn là như vậy.

Tôi nghĩ đó là vấn đề của những gì bạn làm với kỹ năng lập trình của mình. Trở thành một lập trình viên tuyệt vời là tốt, nhưng có vấn đề gì nếu bạn mã hóa phần mềm ngân hàng cả ngày (không vi phạm). Nó chỉ không thêm.

Để thực sự chứng minh với bản thân rằng bạn là một lập trình viên giỏi, hãy tham gia một dự án phụ thú vị. Điều này cho thấy một vài điều: bạn quan tâm đến việc lập trình vào thời gian rảnh của mình và thực sự thích môn này - đây là điều cần thiết để trở thành một lập trình viên giỏi. Nó cho thấy sự linh hoạt ở chỗ bạn có thể mở rộng các kỹ năng của mình ngoài những gì bạn làm trong môi trường làm việc. Nó cũng cho thấy động lực và sự sáng tạo: bạn đã tự mình xác định một vấn đề và đang thực hiện các bước để giải quyết nó.

Tất cả các khía cạnh này xác định một lập trình viên tốt với tôi.

Câu trả lời của tôi sẽ không chính trị. Tuy nhiên, tôi thực sự là một người sáng lập của một start up và công việc của tôi là thuê những lập trình viên giỏi nhất.

Làm thế nào để tôi biết người nào sẽ là lập trình viên giỏi hoặc có thể là lập trình viên giỏi?

1 từ: IQ.

IQ dành cho lập trình vì chiều cao dành cho người chơi bóng rổ.

Tôi sẽ đặt các kỹ năng toán học như là một chỉ số chính xác hơn. Các giáo viên khoa học máy tính của tôi nói với tôi rằng có một tiêu chí dự đoán chính xác ai sẽ thành công trong các khóa học lập trình. Điểm trung học môn Toán. Đó là những IQ có hiệu quả.

Điều này có thể đến như một bất ngờ. Chúng tôi được nói rằng lập trình là một công việc bằng đại học. Đoán xem, tôi không quan tâm đến bằng cấp. Tôi chỉ quan tâm đến 3 điều.

1. Kỹ năng lập trình (có thể được kiểm tra).
2. Năng khiếu.
3. Kỹ năng thông thường (không quá thấp) của mọi người.

Thật không may IQ chỉ đo lường một điều. Vì vậy, tôi làm một số bài kiểm tra.

Tôi hỏi mọi người câu hỏi. Câu hỏi đơn giản tôi mong đợi học sinh tiểu học sẽ có thể trả lời.

Tôi hỏi những câu như:

1. Khoảng cách giữa kim ngắn và dài của đồng hồ lúc 7:35
2. Nếu tôi đi từ Jakarta đến Semarang và muốn duy trì tốc độ 60km / giờ. Sau đó vào 2 giờ đầu tiên tôi lái xe 100km / giờ. Tôi nên đi nhanh như thế nào trong phần còn lại của chuyến đi để tốc độ AVERAGE của tôi là 60km / giờ?

Nếu bạn xem xét cẩn thận những câu hỏi đó không đòi hỏi sự sáng tạo. Chỉ có lẽ thường. Bất kỳ học sinh tiểu học có IQ đều có thể trả lời điều đó.

Tốt nghiệp đại học MOST không thể. Bây giờ hãy tưởng tượng nếu ai đó không thể trả lời điều đó? Anh ấy có thể lập trình không? Hãy suy nghĩ về nó. Bao lâu bạn sẽ phải xác định những gì anh ấy nên làm?

Bạn cũng có thể đặt câu hỏi như Microsoft yêu cầu sự sáng tạo. Bạn có thể đặt câu hỏi về cách cân 8 quả bóng theo thang cân bằng để biết quả nào nặng nhất. Vấn đề với những câu hỏi như vậy là nó liên quan đến may mắn. Tuy nhiên, một số khá dễ dàng nên là một yêu cầu tối thiểu.

Có được một lập trình viên tuyệt vời có thể cải thiện tinh thần của các lập trình viên khác. Có được một lập trình viên luật có thể hạ thấp tinh thần của mọi người khác.

Sau khi mọi người có thể trả lời những câu hỏi như vậy, rất dễ, tôi sẽ khiến họ viết một số mã mứt google.

Các lập trình viên giỏi có thể giải quyết mã kẹt google và có thể dự đoán vấn đề nào dễ hơn.

imho bạn là một lập trình viên tốt nếu

-bạn có một nền tảng lý thuyết âm thanh. phát minh lại bánh xe cũng như thuật toán hoặc khung là một sự lãng phí thời gian, hầu hết thời gian.

-bạn đôi khi có thể nhìn thấy mọi thứ và vấn đề từ một quan điểm sai lệch. điều này có thể mang lại cho bạn để tìm giải pháp sáng tạo.

-bạn dành thời gian và công sức để có các công cụ tốt nhất và các kỹ năng tốt nhất được cập nhật.

mã của bạn rất dễ sửa đổi. Nếu bạn thiết kế mã sạch, thanh lịch và dễ hiểu, việc sửa đổi nó sẽ không gây đau đớn.

-Nếu tỷ lệ mã / lỗi của bạn là hợp lý cao. Tôi biết điều này có vẻ tầm thường, nhưng tôi biết nhiều nhà phát triển sáng tạo và có kỹ năng mà dù sao cũng rất dễ mắc phải những lỗi nhỏ. điều này làm suy yếu rất nhiều hiệu quả và tính hữu dụng của chúng.

những người xung quanh bạn biết rằng bạn có thể giúp quyết định lựa chọn nào để làm

-bạn có thể giải quyết vấn đề bằng các công cụ khác nhau. lập trình viên xấu tiếp tục sử dụng cùng một công cụ (có thể là ngôn ngữ hoặc công nghệ hoặc kiến ​​trúc, v.v.) cho bất kỳ vấn đề nào họ gặp phải

-bạn tiếp tục học, bạn tò mò.

-bạn có chương trình thú vị, sau ngần ấy năm

"Thưa ông, tôi đã trải qua điều đó từ Alpha đến Omaha và tôi nói với bạn rằng một người đàn ông càng ít biết tiếng ồn anh ta tạo ra càng lớn và mức lương anh ta ra lệnh càng cao." Đánh dấu

... kết luận của tôi là các lập trình viên giỏi chỉ huy mức lương thấp và ít gây ồn ào ... :)

Lập trình viên tốt nhất: Hoàn thành nhiệm vụ với số lượng báo cáo mã thấp nhất đúng hạn.

Mã của bạn có bao nhiêu lỗi trên một số liệu? (tức là lỗi trên mỗi dòng) Bao nhiêu mã của bạn phải được mã hóa lại khi các tính năng mới cần được thêm vào? Do đồng nghiệp của bạn có vấn đề sửa đổi mã của bạn?

Cuối cùng, câu hỏi bên cạnh không thể trả lời được cho rằng câu hỏi "mã chất lượng là gì" vẫn là một chủ đề tranh luận sôi nổi sau ngần ấy năm.

Tôi thực sự thích những gì Adam V đã nói ở trên.

Ngoài những gì người khác đã nói, hãy nhìn vào lịch sử duy trì và hỗ trợ công việc của bạn. Nếu mã của bạn có các yêu cầu bảo trì nặng và liên tục được sửa chữa, hoặc khó thay đổi, thì đó có thể là các chỉ số về chất lượng của nó. Nhưng đây cũng có thể là chỉ số của các yêu cầu kém.

Thật khó để tự đánh giá. Những người không đủ năng lực có xu hướng đánh giá quá mức về khả năng của chính họ.

Một số liệu tốt là liệu những người khác mà bạn tôn trọng như chính các lập trình viên có muốn làm việc trên / với mã mà bạn đã viết hay không. Có cơ hội làm việc trực tiếp với bạn hoặc kế thừa mã mà bạn đã viết, sau đó sẽ từ chối? Đồng ý miễn cưỡng? Hoặc nhảy vào cơ hội để học hỏi từ công việc của bạn? Kỹ thuật này hoạt động thậm chí còn tốt hơn nếu đó là một người ngang hàng, không phải là người dưới quyền hoặc ai đó nghĩ rằng có thể có bất kỳ lợi ích nào cho họ từ việc khiến bạn cảm thấy tốt.

Nếu bạn thực sự muốn tìm hiểu, hãy gửi một số mã cho các đồng nghiệp của bạn và yêu cầu xem xét mã (mang tính xây dựng). Trong trường hợp xấu nhất, bạn học được điều gì đó. Thực tế là bạn đang ở đây trên trang web này để tìm kiếm sự giác ngộ đã khiến bạn khác biệt với số đông không được rửa sạch. (trừ khi bạn chỉ ở đây để vuốt ve bản ngã. :-)