Điều gì có thể làm chậm một nhà phát triển? [đóng cửa]

Điều gì có xu hướng làm chậm một nhà phát triển?

Hãy cố gắng kiềm chế đăng câu trả lời rằng:

• bây giờ chậm nhưng hữu ích trong tính năng. (TDD, Tái cấu trúc, ...)
• liệt kê một sự phân tâm .

Ôi cái này dễ đấy:

1. Các cuộc họp
2. Cuộc họp khác
3. Các cuộc họp về cuộc họp cuối cùng
4. Các cuộc họp để chuẩn bị cho cuộc họp sắp tới
5. Phát triển một bài thuyết trình power point cho một cuộc họp
6. Phát triển một bài thuyết trình power point cho một cuộc họp thảo luận về các tính năng chưa được triển khai, không nên thực hiện và vì bất kỳ lý do gì mà anh chàng bán hàng sẽ nhảy qua. Tôi không thể dự đoán tài liệu nào bạn muốn hiển thị trong ứng dụng dựa trên vị trí hiện tại của bạn mà không có kết nối internet hoặc truy cập vào ổ cứng của bạn. Không thực sự, chỉ cần từ bỏ yêu cầu nó quá.

Máy tính chậm

Bất cứ điều gì gây ra chuyển đổi bối cảnh .

StackOverflow, lập trình viên.stackexchange.com, v.v. :)

Tôi sẽ nói kiệt sức.

Bất kỳ nỗ lực để làm theo một quy trình không phù hợp với nhiệm vụ trong tay.

Đây có thể là tất cả các loại, nhưng những thứ phổ biến tôi thấy bao gồm:

• phương pháp thử nghiệm không phù hợp với mã đang được thử nghiệm
• các quy trình nhanh nhẹn hoặc truyền thống hơn so với lệnh bảo đảm
• hướng dẫn dành cho bộ công cụ khác với bộ công cụ đã chọn
• hiệu trưởng thiết kế vượt quá quy mô với nhu cầu của dự án
• sử dụng bộ công cụ không phù hợp với nhiệm vụ

Tất cả những điều này có thể rất đáng giá đối với một số dự án hoặc trong một số tình huống, nhưng một số tổ chức cố gắng làm mọi thứ theo một cách và điều đó dẫn đến sự phù hợp kém với các dự án khác thường là cái chết về năng suất.

Chính trị

ví dụ: Khi có nhiều hơn một người sở hữu các yêu cầu (hoặc tệ hơn, hai lợi ích được giao khác nhau) và họ thực hiện các thay đổi cạnh tranh và xung đột với các yêu cầu trong khi đang phát triển.

Cuộc trò chuyện của người khác

và tiếng ồn nói chung

Nhiều câu trả lời nói về chuyển đổi ngữ cảnh và ra khỏi khu vực, và tiếng ồn, đặc biệt là cuộc trò chuyện, là một trong những điều dẫn đến những điều đó đối với tôi.

Ở thế giới của tôi, tôi bị bao vây bởi tiếng ồn và cuộc trò chuyện ở mọi phía. Một hàng kết thúc, nhóm máy tính lớn tổ chức các cuộc họp lập kế hoạch liên tục trong hàng khối. Đôi khi, họ sẽ gặp các chuyên gia tư vấn trong một văn phòng dọc theo bức tường, và điều đó có xu hướng dẫn đến tiếng cười lớn và tiếng cười 'và tôi phải đi qua và yêu cầu họ đóng cửa.

Ở phía bên kia, bàn hội nghị nhóm web ở phía bên kia của bức tường khối tây của tôi, vì vậy tôi là một phần của mọi cuộc họp, thích hay không. Ngoài ra còn có một máy in ở phía bên kia của bức tường khối phía nam, và điều đó luôn tốt cho trò chuyện từ những người đi chơi chờ đợi bản in của họ.

Câu trả lời ngay lập tức và rõ ràng của " Bạn không thể có tai nghe chống ồn" không giúp ích gì khi điều bạn muốn là im lặng.

Thỉnh thoảng để đánh giá mã, tôi mang chồng giấy của mình đến phòng ăn trưa (tất nhiên là vào giờ không ăn trưa), nhưng có một chiếc TV trong đó thường bị cháy. Tôi sẽ tắt nó đi nếu không có ai xem. Nếu không, tôi sẽ đi tìm một khối trống trong một bộ phận khác trong một phần khác của tòa nhà.

Nếu bạn muốn các lập trình viên của bạn thực hiện công việc họ cần làm, chủ yếu là suy nghĩ và cân nhắc và cân nhắc, họ cần một môi trường nơi họ có thể làm việc đó.

Viết quá nhiều dòng mã mà không có bài kiểm tra đầy đủ.

Thiếu cà phê chất lượng cao.

phải thực hiện các ước tính hoàn hảo mà không cần phải theo dõi từ khi bắt đầu phát triển, đó là một kịch bản trứng gà theo ý kiến ​​của tôi

Sửa lỗi xây dựng bị hỏng của người khác

Các cuộc họp không có chương trình nghị sự.

Một chiếc máy chậm chạp.

Thiếu một màn hình thứ hai.

Một con chuột cũ có một quả bóng thay vì những con mới tốt đẹp.

Thiếu truy cập internet trên máy, khiến truy vấn MSDN / stackoverflow / etc hơi khó khăn.

Dành quá nhiều thời gian để lập trình

Ngay cả khi bạn thực sự thích lập trình, dành quá nhiều thời gian cho nó cuối cùng sẽ khiến bạn kiệt sức ...

Tránh mọi thứ khiến bạn ra khỏi "khu vực". Điều đó có nghĩa là hộp thư đến email của bạn, ứng dụng bật lên twitter của bạn, trò chuyện công ty của bạn, v.v.

Có một điều kiện làm việc yên tĩnh có nghĩa là tránh tiếng ồn máy tính để bàn quá.

Bất kỳ yêu cầu thay đổi nào sẽ dễ thực hiện hơn nếu bạn biết về nó trước khi thực hiện.

Mã kém.

Phải viết lại một phần của người khác có thể đã hoàn thành công việc ngay từ đầu là khoảng thời gian lớn nhất mà tôi có thể tưởng tượng.

Nhiều điều làm bạn chậm lại là một bài viết tốt cho việc này.

...

Nhiều dự án lặp đi lặp lại các tính năng cấp cơ sở hạ tầng cốt lõi, làm chậm việc kinh doanh đó trong việc cung cấp các tính năng phân biệt doanh nghiệp với các đối thủ cạnh tranh.

...

Không thể tránh khỏi việc các sản phẩm và đổi mới sẽ giúp giảm thời gian các nhà phát triển dành cho các nhiệm vụ không khác biệt. Câu hỏi đặt ra là những hình thức mà các dịch vụ và công cụ sẽ thực hiện.

...

Gần đây, sự chậm lại lớn nhất là bởi vì chúng tôi đang phát triển một số thứ mô phỏng đáng lẽ phải được thực hiện theo một thứ tự cụ thể. Vì vậy, tôi đang đợi cho đến khi (tên được thay đổi để bảo vệ người vô tội) John hoàn thành thành phần của mình mà tôi cần cho gói SSIS của mình và Harry bị chậm lại chờ tôi nhập hồ sơ vì anh ta cần một số dữ liệu để kiểm tra xuất khẩu của mình (hãy thử để viết báo cáo xuất phức tạp khi không có dữ liệu trong bất kỳ bảng nào?) và mọi người bị chậm lại vì thiết kế không được thực hiện và các bảng cơ sở dữ liệu chúng ta cần thực hiện các nhiệm vụ của mình chưa được tạo và thậm chí có thể không kết thúc trở thành những gì họ nói họ sẽ trở thành, v.v.

Trả lời câu hỏi trên stackexchange.com, như thế này.

Mặc dù bạn yêu cầu không liệt kê những phiền nhiễu, chúng có thể là một yếu tố lớn. Nhìn vào môi trường làm việc của họ, kiểm tra xem họ có bị gián đoạn thường xuyên hoặc được yêu cầu làm những việc khác không liên quan đến dự án không.

Đôi khi, một nhà phát triển có thể gặp khó khăn vì họ đang làm điều gì đó họ chưa từng làm trước đây và họ không biết tìm kiếm sự giúp đỡ ở đâu. Nếu đó là một nhóm nhỏ hoặc cá nhân, nó có thể còn khó khăn hơn. Chúng ta có xu hướng hơi kiêu ngạo và không muốn thừa nhận khi chúng ta không biết cách làm. Ngoài ra, chúng tôi không thích nhờ người khác giúp đỡ. Không có cách nào dễ dàng để khiến một nhà phát triển thừa nhận điều này, ngoại trừ có thể hỏi xem họ có thể đáp ứng thời hạn hay không, hoặc họ cần gì để đáp ứng thời hạn, và sau đó hy vọng họ sẽ thành thật. Bạn có thể cần đề nghị mang lại sự giúp đỡ khác, hoặc tìm ai đó có thể giúp đỡ họ.

Thiếu các yêu cầu được xác định rõ ràng, dẫn đến họ phải tìm ra mọi thứ hoặc đưa ra quyết định.

• Phải đợi khoảng 15 phút để PC khởi động vào trạng thái có thể sử dụng
• Chờ PC chuyển đổi ứng dụng
• Là người duy nhất trong văn phòng phải tự pha trà / cà phê.
• Bàn phím bị hỏng (đã sửa!)
• Làm việc bên ngoài văn phòng Giám đốc điều hành (CEO Hoa Kỳ) (và không phải trong một văn phòng), chỉ có một phân vùng ở giữa (đặc biệt là khi có một cuộc họp)
• Ông chủ chỉ có thể truy cập bằng email, nhưng mọi người khác đang ở trong tòa nhà
• Không được phép sử dụng VCS - rõ ràng nó phải ở trong não tôi
• Màn hình nhỏ
• Không cho phép thời gian để nghỉ ngơi ngoài bữa trưa
• Phải thực hiện sao lưu máy chủ từ xa mặc dù có một sysadmin trong tòa nhà
• Được bảo làm sao lưu bằng tay.
• Bị buộc phải sử dụng một hệ thống quản lý thời gian ngu ngốc phức tạp không cần thiết
• Chỉ nhận được một ý tưởng mơ hồ về các yêu cầu hai tháng vào công việc

Tôi có thể tiếp tục, nhưng đó là thứ Sáu và tôi muốn quên đi công việc.

• Thiếu tài liệu (Hệ thống, Công ty, v.v.)
• Thiếu mã nhận xét
• Một sự hiểu biết không đầy đủ về hệ thống
• Chính trị (tức là các cuộc họp không cần thiết, giấy tờ, trở ngại của quản lý ...)
• Tài liệu yêu cầu không đầy đủ
• Facebook!
• Ngủ nhiều quá?

Quá nhiều người trong dự án.

Nhìn thấy nó nhiều lần trong đó ban quản lý quyết định dựa trên không có dữ liệu thực mà họ cần thêm nhiều người vào dự án. Điều đó kết thúc trong ppl người biết những gì đang xảy ra cần phải dừng mọi thứ để nắm trong tay những người ít biết về những gì đang xảy ra. Tôi đã thấy nhiều hơn một dự án nấm có kích thước và sau đó đi vào nhà vệ sinh một cách nhanh chóng trong khi trước khi nó diễn ra tốt đẹp, mặc dù có thể hơi chậm.

Vì vậy, bạn đi từ trễ một tháng vì không đủ vận tốc / quá nhiều việc phải làm để không cung cấp gì cả vì bạn hoàn toàn thổi ngân sách cho tất cả những người thừa đó.

Ngoài những điều được đề cập bởi những người khác, chặng đường dài giữa việc quyết định biên dịch & chạy mã của bạn và nhận được kết quả tích cực / tiêu cực . Lý tưởng nhất, RTT này sẽ chỉ là một giây, nhưng tôi đã thấy một ví dụ về giờ. BTW, thử nghiệm đơn vị cố gắng đối phó với vấn đề này.

Một điều khác liên quan đây là độ trễ chung của môi trường làm việc của bạn. Hãy tưởng tượng bạn cần làm việc qua kết nối máy tính để bàn từ xa với máy tính ở phía bên kia thế giới, qua một kết nối đáng sợ. Tôi đã từng ở đó. Tôi đã ghét điều này.

• Thủ tục giấy tờ quá mức

• Có sự phụ thuộc vào một người không bao giờ ở bên cạnh (chẳng hạn như sếp của bạn - nếu bạn cần đặt câu hỏi nhưng anh ấy luôn trong các cuộc họp)

• Công cụ & thiết bị không đầy đủ.

• Mọi người đẩy mái chèo của họ không vì lý do gì (bất kỳ thay đổi có thể nhìn thấy UI nào cũng phải tuân theo điều này) hoặc chỉ tranh luận về việc ném những thứ tầm thường.

• Máy pha cà phê hỏng

• Được giao nhiệm vụ sai

Máy lạnh không hoạt động.

Vì vậy, nhiệt độ trong văn phòng lên tới 40 độ vào mùa hè -5 vào mùa đông.

-5 không tốt cho việc gõ, vì tôi không thể đeo găng tay và gõ. 40, chỉ làm chậm suy nghĩ của tôi xuống.

Đây là một ý kiến ​​rất cá nhân và có lẽ gây tranh cãi, nhưng lập kế hoạch và suy nghĩ quá nhiều về việc thiết kế trước hoặc viết mã "chất lượng" mọi lúc. Có một câu nói rằng "tuần mã hóa có thể giúp bạn tiết kiệm hàng giờ lập kế hoạch" có thể đúng trong một số trường hợp.

Tuy nhiên tôi thường thấy các lập trình viên cố gắng phác thảo một thiết kế tốt trước khi bắt đầu viết mã. Tôi thấy bản thân mình dễ dàng hơn khi "bắt đầu", khi bạn lập trình, bạn sẽ tìm hiểu thêm về vấn đề và giải pháp của mình, điều này sẽ cho phép bạn cấu trúc lại giải pháp của mình một cách nhanh chóng thành một thiết kế tốt. Hầu hết các vấn đề phát sinh là khá nhiều không thể biết được khi bắt đầu viết mã (ít nhất là với suy nghĩ yếu ớt của tôi) vì vậy lãng phí rất nhiều thời gian để thiết kế trước chỉ là một sự lãng phí thời gian.

Đây cũng là lý do tại sao tôi không thích TDD, bạn lãng phí quá nhiều thời gian để viết bài kiểm tra khiến bạn ít có khả năng tái cấu trúc hoặc mất nhiều thời gian để viết lại bài kiểm tra. Các bài kiểm tra đơn vị rất tốt cho một số trường hợp và một số giai đoạn của một dự án, nhưng sự khởi đầu của một trong số đó không phải là một trong số đó IMHO :)

Nhận một cái gì đó làm việc nhanh chóng và cải thiện nó.

Khối lập trình viên : Không giống như các sự chậm lại khác, điều này khó giải quyết hơn.