Lập trình viên không nên đội mũ gì? [đóng cửa]

Theo kinh nghiệm của tôi, các nhà phát triển phần mềm có xu hướng đội nhiều mũ và đảm nhận nhiều vai trò với các trách nhiệm khác nhau. Từ không chỉ mã hóa, mà đôi khi còn viết SQL, thiết kế giao diện người dùng, thiết kế cơ sở dữ liệu, thao tác đồ họa, thậm chí kiểm tra QA.

Nếu vai trò chính là viết phần mềm / mã, nhà phát triển không nên đảm nhận vai trò nào? Có ai không

Ý định của câu hỏi này không phải vì nhà phát triển không có khả năng hoàn thành vai trò khác - mà có vai trò bổ sung thực sự hoạt động chống lại vai trò chính , hoặc thực sự phải là vai trò chuyên dụng của một người không chủ yếu lập trình.

Sysadmin. Phát triển phần mềm và xử lý cơ sở hạ tầng CNTT là hai kỹ năng khác nhau trông tương tự như người ngoài cuộc. (Tất cả chỉ đập vào máy tính, phải không?) Đối với một công ty nhỏ, sự cám dỗ sẽ rất mạnh mẽ để khiến The Computer Guy chịu trách nhiệm cho tất cả các máy móc trong văn phòng.

Nếu bạn có kỹ năng thực sự đội cả hai chiếc mũ, thật tuyệt vời; nhưng đó là một trong những điều có thể chìm trong thời gian lớn hơn nhiều so với mọi người nhận ra, và nếu bạn tự học khi bạn đi, rất có thể bạn đang làm rất tốt.

Bạn đội bất cứ chiếc mũ nào mà chủ nhân của bạn yêu cầu. Đó là những gì làm cho bạn một người chơi nhóm. Đó là những gì làm cho bạn một người giải quyết vấn đề .

Mọi người trở nên quá bị cuốn vào ý tưởng trở thành một "nhà phát triển" hoặc một "kiến trúc sư" hoặc một "nhà phân tích". Kệ đời nó. Bạn nên là một người giải quyết vấn đề. Mã chỉ là một công cụ trong vành đai của bạn.

Giải quyết vấn đề không bao giờ lỗi mốt.

Nếu chủ nhân của tôi muốn tôi làm hỗ trợ công nghệ hoặc xây dựng máy tính, thì hãy làm như vậy. Họ nghĩ rằng họ đang lãng phí tiền của họ, xem xét mức lương của nhà phát triển, nhưng đó là việc của họ. Tôi ở đây để giải quyết vấn đề. Tuy nhiên tôi có thể làm điều đó, tôi sẽ làm nó. Và nếu tôi cảm thấy, sau một khoảng thời gian nhất định, tài năng của tôi bị lãng phí hoặc sự hài lòng trong công việc của tôi không phải là nơi tôi muốn, thì tôi có nhiều quyền để chuyển sang một công việc khác.

Nhưng với câu hỏi cơ bản - không có chiếc mũ nào bạn không đội. Heck, nếu họ muốn bạn lấy cà phê, hãy làm điều đó. Giải quyết vấn đề của họ; chỉ cần biết rằng bạn có quyền tìm một công việc khác nếu bạn muốn thay đổi.

Người kiểm tra!

Xin vui lòng gửi cho chúng tôi người kiểm tra ra khỏi trường thử nghiệm nếu cần!

Không có người kiểm thử, mọi người mong đợi mọi thứ sẽ hoạt động tốt vì người lập trình là người kiểm thử và họ rất thông minh nên nó sẽ hoạt động.

Tôi không nói rằng dogfooding không phải là một ý tưởng tốt. Tôi chỉ nghĩ rằng người kiểm tra rất quan trọng bây giờ tôi là một lập trình viên.

Bạn nên cẩn thận về việc trở thành anh chàng cho các vấn đề phần cứng văn phòng . Điều này có thể bao gồm xử lý sự cố PC, quản trị viên máy chủ, sao lưu và thậm chí cả hệ thống điện thoại hoạt động. Tôi đã phạm sai lầm khi đề cập đến trải nghiệm phần cứng trước đây của tôi và cuối cùng, nhiệm vụ xử lý sự cố / phần cứng của tôi đã mâu thuẫn nghiêm trọng với nhiệm vụ lập trình của tôi.

Một lập trình viên không nên là người thử nghiệm duy nhất cho mã của riêng mình .

Các nhà phát triển viết mã với một loạt các giả định. Nếu người kiểm tra có bộ giả định giống hệt nhau, họ sẽ không thực hiện chức năng không mong muốn bên ngoài các giới hạn đó và nhiều vấn đề sẽ không bị phát hiện.

Hơn nữa, để tiến về phía trước, các nhà phát triển không có động lực cao để cố gắng phá vỡ mọi thứ, trong khi những người thử nghiệm là (có lẽ ở cấp độ tiềm thức).

Điều này không có nghĩa là thử nghiệm dev là vô ích. Hoàn toàn ngược lại - kiểm tra dev tốt cho phép người kiểm tra tập trung vào việc tìm kiếm các vấn đề sâu hơn. Tuy nhiên, thử nghiệm dev không phải là một thay thế cho một thử nghiệm chuyên dụng.

Hai tôi có thể nghĩ ra ngay con dơi.

1. Hô trợ ky thuật. Tôi không ở đây để giúp khách hàng làm việc thông qua trang web mới hoặc dạy họ cách sử dụng các tính năng.
2. Mặc dù có thể cần phải giao tiếp với khách hàng tại nhiều điểm khác nhau trong quy trình, trừ khi bạn là lập trình viên quản lý, bạn thực sự không nên trao đổi trực tiếp với họ về các tính năng và triển khai thiết kế.

Bạn có thể nói rằng phát triển CSS / UI sẽ nằm ngoài "lĩnh vực" lập trình nhưng theo kinh nghiệm của tôi thì đó là một kỹ năng cần thiết ngày nay. Bạn không thể thoát khỏi các bảng và phụ thuộc vào người khác để thực hiện nó một cách chính xác. Tôi có thể không thích thực hiện thiết kế hoặc thay đổi mã để xử lý một thiết kế mới, nhưng đó là một phần của công việc.

Viết các truy vấn là tốt, kiểm tra Q / A là tốt (và IMO nên là công việc của lập trình viên, có một bộ phận bên ngoài thực hiện nó, nhưng trước tiên bạn nên kiểm tra nó). Quản trị máy chủ là một chút của một khu vực màu xám. Tùy thuộc vào mức độ lớn của dự án hoặc nếu bạn có một quản trị viên máy chủ chuyên dụng, nó có thể hoặc không cần thiết.

Nói chung, theo kinh nghiệm của tôi, hầu hết các lập trình viên không nên phát triển giao diện người dùng - mặc dù tôi chắc chắn có khả năng phát triển UI (và thường tạo một giao diện khi xây dựng nguyên mẫu hoặc bằng chứng về khái niệm), đây là tốt hơn để lại cho một nhân tố con người (người trong công ty nhỏ của chúng tôi là một nghệ sĩ đồ họa, người cũng làm bố cục màn hình và tạo ra hầu hết các hướng dẫn và tài liệu quảng cáo).

Ngoài ra, các nhà phát triển không nên thực hiện kiểm tra QA - đó là công việc của bộ phận QA (công ty tôi làm việc sản xuất các thiết bị y tế nhúng, vì vậy đây là yêu cầu kiểm tra phải được thực hiện bởi một bộ phận riêng).

Mặt khác, tôi thấy không có lý do tại sao các nhà phát triển không thể thiết kế cơ sở dữ liệu và viết SQL, nếu họ có nền tảng để làm điều đó - tôi đã làm rất nhiều lần.

Hô trợ ky thuật

Quá nhiều thời gian trong ngày của tôi bị lãng phí khi thực hiện các cuộc gọi hỗ trợ công nghệ ...

Một số phổ biến là:

• "Tài khoản của tôi bị khóa" hoặc "Tôi quên mật khẩu"
• "[Điện thoại | bàn phím | chuột | máy tính] của tôi không hoạt động"
• "Máy tính của tôi chậm, bạn có thể kiểm tra xem có gì bất thường không?"
• "Tại sao X xảy ra khi tôi nhấp vào nút này? Nó nên làm Y"
• "Tôi tiếp tục nhận được các quảng cáo này ...." hoặc "Tôi nghĩ rằng tôi có vi-rút"
• "Người này không còn ở đây nữa, bạn có thể vô hiệu hóa tất cả những thứ của họ không?"
• "Chúng tôi có một nhân viên mới, bạn có thể thiết lập chúng với thông tin đăng nhập, thẻ bảo mật, điện thoại, email, v.v.?"

Bất kỳ vai trò nào làm cho anh ta tự quản lý. Trong các nhóm nhỏ, thường có xu hướng biến một trong những nhà phát triển cấp cao trở thành người quản lý dự án, nhưng cũng giữ anh ta trong nhóm với tư cách là một lập trình viên. Điều này dẫn đến tất cả các loại vấn đề, vì anh chàng này, với tư cách là một lập trình viên, về cơ bản là không được quản lý. Thay vì ủy thác tất cả các nhiệm vụ cho các thành viên khác trong nhóm, anh ta thường sẽ bị cám dỗ giao nhiều nhiệm vụ cho mình, đặc biệt là những nhiệm vụ khó khăn nhất. Vì vậy, các nhiệm vụ khó khăn nhất, những người có khả năng gây ra sự cố nhất, được giao cho một người chỉ có sẵn 50% với tư cách là một lập trình viên và báo cáo như vậy cho không ai biết. Khi các thành viên khác trong nhóm không thể giao hàng, thay vì đá vào mông họ, anh ta sẽ cố gắng thực hiện nhiệm vụ của mình, bởi vì là người quản lý dự án, anh ta chịu trách nhiệm cho sự thành công và cách an toàn nhất để thực hiện là tự làm , phải không?

Hỗ trợ kỹ thuật cho những thứ bạn không có trong việc phát triển, triển khai hoặc bảo trì và không được đào tạo và không cập nhật những thay đổi lớn. Một phần công việc của tôi đã trở thành trả lời điện thoại cho khách hàng gọi về lý do tại sao internet của họ không hoạt động. Tôi không đối phó với một nửa doanh nghiệp đó, vì vậy tôi không thể nói cho họ biết bất cứ điều gì sử dụng.

Không phải hỗ trợ kỹ thuật, không có vấn đề gì. Đó là một anh chàng thư ký / hỗ trợ công nghệ trong khi cố gắng phát triển mọi thứ.

Nó khá là đánh thuế khi phải nghe mọi người phàn nàn cả ngày và không thể nói với họ bất cứ điều gì. Tôi khuyên bạn nên tránh điều này bằng mọi giá.

Bán hàng .

Một số bugger nghèo phải làm điều đó, nhưng chắc chắn không nên là nhà phát triển.

Khi tôi già đi, tôi nhận ra rằng đó là điều tốt nhất nếu các nhà phát triển không tự triển khai (tôi đã chiến đấu với chiếc răng và móng này). Họ không nên có bất kỳ quyền nào đối với cơ sở dữ liệu sản xuất ngoại trừ các quyền được chọn. Mã của chúng tôi đã ít lỗi hơn rất nhiều (và điều tương tự đã không tăng lên nhiều lần vì sự thay đổi chỉ được thực hiện trong prod và một lần triển khai sau đó ghi đè lên nó một lần nữa sau đó chỉ sửa chữa nhanh chóng, rửa và lặp lại) khi chúng tôi đã phải bắt đầu đưa nó cho người khác triển khai và không được phép thực hiện các thay đổi sản xuất sửa chữa nhanh chóng vì việc triển khai không hoàn toàn đúng. Hơn nữa, chúng tôi đã ngừng có các bản cập nhật "vô tình mà không có mệnh đề where được tô sáng làm thay đổi mọi bản ghi trong bảng".

Nghệ sĩ và nhà thiết kế giao diện người dùng .

Hầu hết các lập trình viên rất kém về tác phẩm nghệ thuật, nhưng các công ty không bận tâm trả tiền cho một nghệ sĩ để vẽ hình ảnh và biểu tượng cho sản phẩm của họ, và chỉ sử dụng "nghệ thuật lập trình" - với kết quả ghê gớm. (Cho đến Windows Vista, đây là yếu tố khác biệt rõ ràng nhất ngay lập tức giữa máy Mac và PC - Máy Mac trông đẹp và thân thiện, PC là một đôi mắt)

Theo cách tương tự, rất nhiều lập trình viên không quan tâm đến giao diện người dùng - họ quan tâm chủ yếu đến mã của họ. Họ chỉ đơn giản đưa nội dung của các biến thành viên của mình trực tiếp vào một số trường có thể chỉnh sửa, thường không quan tâm đến việc họ đặt các nút và trường trên biểu mẫu của mình và cho rằng điều này là đủ, dẫn đến phần mềm không thể sử dụng được. (Toàn bộ ngành công nghiệp điện thoại di động đã rất có lỗi về điều này cho đến khi iPhone xuất hiện để cho họ thấy rằng bạn thực sự có thể tạo ra một giao diện người dùng điện thoại đẹp để sử dụng)

Lotus Notes là một ví dụ điển hình về việc cả hai điều này có thể tệ đến mức nào nếu bạn không nhờ một nhà thiết kế chuyên nghiệp giúp đỡ các lập trình viên.

Viết bài kiểm tra tổng thể và kế hoạch kiểm tra. Nghiêm túc đấy các bạn ạ, tôi có thể viết kế hoạch kiểm tra của riêng mình, nhưng điều đó có nghĩa là nướng vào sản phẩm bất cứ sự hiểu lầm, giả định sai lầm và sai lầm nhận thức nào tôi đã làm trong khi viết nội dung. Đó là điều duy nhất tôi ghét về một công ty tôi làm việc; Tôi đang ở đâu, ít nhất chúng tôi có các bài đánh giá mã có khả năng sẽ nắm bắt được nội dung này.

Không bao giờ đội nhiều "mũ" hơn bạn có thể xử lý một cách hợp lý và thoải mái, cố gắng làm cho các nhà phát triển lỗ chim bồ câu bằng cách nói rằng họ không nên làm A hoặc B có nghĩa là một nhà thiết kế UI tuyệt vời có thể không được chú ý vì ai đó nghĩ rằng các lập trình viên nên tránh xa giao diện người dùng.

Vào cuối ngày, mọi người sẽ có những điểm mạnh và điểm yếu khác nhau và một người quản lý / giám sát / trưởng nhóm tốt nên biết cách tốt nhất để hướng dẫn những người làm việc cho họ để đảm bảo rằng tài năng được sử dụng một cách thích hợp. Tương tự như vậy, nếu bạn không thoải mái với việc thiết kế UI hoặc giao dịch với người dùng cuối, thì hãy cho nhóm bạn biết để bạn có thể giảm thiểu vai trò của mình trong lĩnh vực đó. Tuy nhiên, bạn nên chuẩn bị để nhận một số công việc bổ sung trong một khu vực khác.

Ngoài ra, nếu bạn đội quá nhiều mũ (ví dụ: lập trình viên, nhà thiết kế giao diện người dùng, người thử nghiệm, nhà phân tích kinh doanh, v.v.) thì bạn sẽ làm việc kém với một số người trong số họ, hoặc bạn sẽ tự thiêu. Hãy chắc chắn rằng bạn biết có bao nhiêu chiếc mũ bạn có thể xử lý và cố gắng giữ khối lượng công việc quanh mức đó.

Ngoài ra, thực sự không có "chiếc mũ" nào mà nhà phát triển không nên đội nếu họ có kỹ năng vượt trội trong vai trò đó.

Tôi có xu hướng nhận bất kỳ công việc nào được ném vào tôi khi và chỉ khi:

• Tôi cảnh báo trước về mức độ kỹ năng của tôi và những tác động có thể xảy ra và ông chủ của tôi quyết định rằng nó có thể chấp nhận được
• Có một người ở cấp độ guru có thể (và có thể sẽ ở một giai đoạn nào đó) giúp tôi đối phó với những điều bất ngờ
• Đọc qua một số tài liệu, câu hỏi trực tuyến, vv

Bằng cách này, tôi chủ yếu được bảo hiểm chống lại ông chủ của mình và nếu ai đó sai, ít nhất là có thể sửa được.

Các nhà phát triển là các bên liên quan trong tình huống (như khách hàng, chủ sở hữu, v.v.), vì vậy họ có quyền mong đợi một công việc có ý nghĩa. Theo tôi, điều đó có nghĩa là cơ hội để làm việc với những điểm mạnh của bạn .

Vì vậy, nhà phát triển không nên đội mũ không mang lại sinh lực, đóng góp cho sự phát triển cá nhân và dẫn đến hiệu suất cao nhất - và đánh cắp thời gian từ "những chiếc mũ" làm những việc này cho họ.

Khác với việc không phải là người duy nhất thử nghiệm mã riêng của họ, tôi nghĩ rằng bất kỳ "chiếc mũ" nào cũng được nếu nó là công việc có ý nghĩa đối với nhà phát triển đội mũ.

"Nhà thiết kế" hay "anh chàng sáng tạo". Bạn sẽ vô tình kết hợp một giao diện của ứng dụng để viết văn bản tiếp thị cho chiến dịch quảng cáo trực tuyến tiếp theo hoặc các cuộc thảo luận bất tận về màu xanh "đúng" trước khi bạn biết nó x_x.

cái mũ đó với lon bia ở bên cạnh bằng ống hút. ý tưởng tồi nếu bạn bị bắt.

chỉnh sửa:

Đây là chiếc mũ tôi ghét nhưng nó có phần thưởng lớn - đó là một dấu hiệu lớn đối với tôi nói rằng nếu điều này phá vỡ tất cả là lỗi của bạn .... à, nhưng nếu nó tốt, thì con trai tôi là cậu bé tốt, chúng tôi đều biết bạn là - bây giờ quay trở lại tầng hầm ... cậu bé tốt ... đó là nó.

Chiếc mũ đổ lỗi.