Có sử dụng các kỹ thuật mới làm tổn thương năng suất? [đóng cửa]

Có vẻ như là kinh nghiệm với bộ công cụ cụ thể mà bạn phải làm việc cùng phát triển, sự khuyến khích để thử những thứ mới làm suy yếu.

Khi tôi mới làm công việc lập trình này, thử những điều mới, nghiên cứu trực tuyến, giúp tôi làm việc hiệu quả hơn , bởi vì tôi thường tìm ra một cách (hoặc thư viện) giúp cho công việc dễ dàng hơn mà khung mã đã có. Vì vậy, việc sử dụng một cái gì đó mới - đối với tôi cũng như trong bối cảnh của cơ sở mã đã cho - khiến tôi làm việc hiệu quả hơn.

Bây giờ tôi nhận thấy, rằng có ngày càng nhiều trường hợp, đối với một vấn đề nào đó, tôi biết rằng có lẽ là một giải pháp tốt hơn "ngoài kia", và việc tìm kiếm nó sẽ - có lẽ - cải thiện mã. Tuy nhiên, với kiến ​​thức gần gũi của tôi về cơ sở mã, việc sử dụng các công cụ dưới mức tối ưu mà chúng tôi có dễ dàng hơn rất nhiều và có được một giải pháp (bao gồm các thử nghiệm) đang chạy hơn là tìm kiếm một cơ sở mã mới và "tốt hơn" và "cải thiện".

Vì vậy, có sự căng thẳng này: "làm điều đó đúng" so với "hoàn thành công việc một cách dứt khoát ".

Đây có phải là một cái gì đó xảy ra với rất nhiều nhà phát triển? Đây có phải là một vấn đề cụ thể được biết đến? (Rốt cuộc nó có phải là một vấn đề thực sự không?) Nó có thực sự phải làm với mức độ kinh nghiệm ngày càng tăng không?

Ồ, và lưu ý: Tôi vẫn thích công việc của mình và thích giữ nó. Chỉ là nó có vẻ như - luôn luôn thú vị! - phần nghiên cứu trở nên nhỏ hơn khi tôi tìm hiểu cơ sở mã và các vấn đề chúng ta gặp phải với ứng dụng của mình.

Thường xuyên mạo hiểm để thử những điều mới. Đôi khi chúng ta gặp rắc rối vì chúng ta có xu hướng làm hai việc:

1. Đánh giá quá cao sự hữu ích của điều thú vị / mới / snazzy. Chúng tôi thấy một số ví dụ thú vị, một số mã ném trực tuyến. Chúng tôi nghĩ rất tuyệt Rất tuyệt! Trong XI có thể làm nhiệm vụ Y nhanh hơn mười lần. Nó rõ ràng vượt trội. Chúng tôi chưa thấy tất cả "ẩn số chưa biết". Chúng tôi đã không gặp phải những vấn đề mà nhân viên bán hàng của điều mới bỏ qua. Chúng tôi không có đủ chuyên môn về điều mới để thấy những quả mìn đang chờ trên đường.

2. Đánh giá thấp mức độ hữu ích của các công cụ / khung / phần mềm / thứ hiện có. Chúng tôi thường không ở đó khi hệ thống hiện tại được xây dựng ban đầu. Chúng tôi không đánh giá cao sự đánh đổi tinh tế đã được thực hiện. Thật dễ dàng để chơi trò chơi tiền vệ vào sáng thứ Hai trên một hệ thống hiện có, nhưng nó hoạt động . Có lẽ nó có rất nhiều điều kỳ lạ do sự đánh đổi rất cụ thể giữa việc giữ cho nó có thể duy trì, hoạt động và hoạt động tốt. Vâng chắc chắn nó kỳ lạ. Có lẽ quan trọng nhất, nhóm là một chuyên gia về sự kỳ lạ hiện tại và biết cách khắc phục sự kỳ lạ. Họ biết những quả mìn và những cái bẫy và những cạm bẫy cần tránh. Trên thực tế, chính xác là bởi vì chúng ta thấy tất cả các mụn cóc theo cách làm hiện tại mà chúng ta thậm chí quan tâm để chơi với những thứ mới.

Nhưng không thử những điều mới và hành động quá bảo thủ có lẽ còn nguy hiểm hơn. Chắc chắn chúng ta cần phải cẩn thận, nhưng nếu chúng ta không tìm ra cách chế tạo bẫy chuột tốt nhất, các đối thủ của chúng ta sẵn sàng thử một thứ gì đó mới sẽ xuất hiện và loại bỏ tàn thuốc! Hành động để bảo thủ và không phát triển có thể dẫn đến kết cục không thể tránh khỏi, đặc biệt là trong một thị trường cạnh tranh.

Vì vậy, có, chúng ta cần cân bằng việc duy trì và vận chuyển thứ hiện tại với một số mức độ thử nghiệm vui chơi / giáo dục với những cách mới để giải quyết vấn đề lưu ý rằng nhiều cách mới đó là ngõ cụt trong khi những cách khác có thể phải trả giá. IMO Đây là một lý do tốt để nhiều công ty có 20% thời gian để chơi với những điều mới. Họ biết rất nhiều lần họ không làm việc, nhưng nhiều ý tưởng xuất hiện trong 20% ​​thời gian đã trở thành băng đảng. Không có thời gian để chơi và thử nghiệm, bạn có thể dễ dàng trì trệ như một công ty và thực sự tự làm phiền mình.

Nó xảy ra tất cả các thời gian . Tôi đã nói điều này trong các bài đăng khác, nhưng nhiều lần hơn là không, bạn không kinh doanh trong việc phát triển mã thanh lịch, bạn đang kinh doanh vận chuyển một sản phẩm. Do đó, bạn sẽ khó tìm được bất kỳ người quản lý nào sẵn sàng phân bổ nhàng giờ cho bạn để khắc phục điều gì đó không bị hỏng và thực sự (vào cuối ngày) không cải thiện đáng kể trải nghiệm người dùng cuối. Bạn sẽ khó lòng tìm được người quản lý sẵn sàng phân bổ nhàng giờ để nghiên cứu (không có mục tiêu rõ ràng) ngoài "có lẽ có gì đó tốt hơn" so với những gì đang được thực hiện.

Phải nói rằng, nếu có những tắc nghẽn trong ứng dụng của bạn mà bạn đã phát hiện ra bằng cách sử dụng các công cụ định hình và như vậy và bạn có thể định lượng rõ ràng việc nâng cao trải nghiệm người dùng dự kiến ​​sẽ khắc phục chúng, thì bạn nên (khá dễ dàng) có thời gian để thực hiện R & D làm việc để tối ưu hóa chúng bằng các kỹ thuật mà bạn có thể tìm thấy từ nhiều nguồn khác nhau.

Tôi nghĩ rằng một số trong đó có được sự có kinh nghiệm và kiến ​​thức chuyên sâu hơn về cách giải quyết thành công một số vấn đề.

Khi bạn là người mới, tất cả các vấn đề cũng mới và bạn cần nghiên cứu cách thực hiện chúng. Nhưng khi bạn đã giải quyết cùng một loại vấn đề, nhu cầu nghiên cứu sẽ giảm xuống khi bạn biết một giải pháp thành công cho vấn đề đó.

Sau đó, bạn chỉ có xu hướng nghiên cứu các vấn đề mới hoặc những vấn đề mà cái cũ đã thử và đúng hoặc không còn hoạt động (đã bị phản đối) hoặc gây ra vấn đề về hiệu suất hoặc lỗi. Khi bạn bắt đầu hiểu một hệ thống phức tạp sâu hơn, bạn biết rằng bạn không có thời gian thực sự sử dụng các kỹ thuật mới mỗi khi chúng xuất hiện và bạn đã phát hiện ra qua kinh nghiệm rằng rất nhiều thời gian kỹ thuật mới không tồn tại lên đến mức cường điệu và tạo ra nhiều vấn đề hơn nó đã giải quyết. Vì vậy, bạn trở nên ít có xu hướng sử dụng các công cụ và công nghệ mới khi bạn không thực sự cần chúng để giải quyết vấn đề.

Nhưng ít nghiêng hơn không có nghĩa là bạn ngừng học hỏi hoặc không bao giờ sử dụng một kỹ thuật mới, chỉ là bạn thận trọng hơn khi chúng phù hợp.

Dưới đây là một số chi tiết:

1. Có thời hạn : Trước đó, lập trình viên nên có tất cả các chi tiết cần thiết có sẵn của các công cụ anh ta đang sử dụng. Đọc một số trang web, tìm thấy một số điều thú vị mới, và sau đó sử dụng nó trong môi trường sản xuất là một điều không nên. Bạn không có đủ kinh nghiệm với công cụ này và thậm chí quan trọng hơn, bạn không có thời gian cần thiết để bắt đầu học một cái gì đó mới. Nếu bạn muốn một số công cụ mới thú vị, hãy tìm hiểu nó nửa năm hoặc năm trước khi sử dụng nó.
2. Hãy chắc chắn rằng bạn biết đúng về nó trước khi sử dụng nó : Một số công cụ mới tuyệt vời có thể thú vị để sử dụng, nhưng việc tìm kiếm các giải pháp và sau đó sử dụng chúng mà không học chúng đúng cách có thể rất tệ. Bạn không có đủ kinh nghiệm với nó. Nếu bạn cần google nó để tìm ra nó có nghĩa là bạn không biết nó đủ tốt để sửa nó khi nó phá vỡ một nửa hệ thống.
3. Sử dụng công cụ mới nhất không thực hiện đúng cách : công cụ mới không được chứng minh là công nghệ. Năm tới công nghệ có lẽ đã hoàn toàn biến mất, bạn là người duy nhất trên thế giới sử dụng nó nữa. Mọi người khác nhận thấy nó không hoạt động. Phải mất nhiều công sức để tránh viên đạn bạc mới nhất, nhưng nó đáng giá.
4. Tập trung vào các kỹ thuật là kiến ​​thức cốt lõi của bạn : Mọi lập trình viên chỉ biết một phần nhỏ trong toàn bộ kiến ​​thức lập trình có sẵn trên thế giới. Phần mà lập trình viên đủ thoải mái khi sử dụng nó thậm chí còn nhỏ hơn. Phần thực sự hoạt động thậm chí còn nhỏ hơn. Chỉ sử dụng kiến ​​thức mà bạn đã học đúng cách và bạn biết rằng nó hoạt động. Điều này làm cho bạn lập trình nhanh hơn và kết quả là mã tốt hơn.
5. Đừng tinh chỉnh nó vô tận : Mã hoàn hảo là một mục tiêu tốt, nhưng điều này không có nghĩa là bạn viết một số thứ nhảm nhí trước, và sau đó tinh chỉnh nó để làm cho nó tăng dần tốt hơn. Viết nó hoàn hảo ngay lần đầu tiên sử dụng tất cả những kiến ​​thức tốt mà bạn có. Hãy tin tưởng chính mình. Đừng tin vào thế giới. Không ai khác biết chính xác những gì bạn làm. Ý kiến ​​của họ không quan trọng. Bạn là lập trình viên, bạn cần làm cho nó hoạt động. Thế giới không thể làm điều đó cho bạn. Khi đã xong, Dừng lại. Đừng chạm vào nó cho đến khi ai đó phàn nàn về nó.
6. Dành thời gian để học những điều mới : Mọi người cần liên tục học những điều mới. Tương lai của chúng ta phụ thuộc vào nó. Chỉ cần từ chối sử dụng nó! Tìm hiểu công cụ mới, nhưng không sử dụng nó cho đến khi bạn chắc chắn rằng nó thực sự hoạt động. Bạn sẽ có cơ hội sử dụng nó vào năm tới, một khi nó đã được chứng minh công nghệ. Hoặc bạn đã quên nó, giống như mọi người khác - chỉ những thứ tốt còn lại ...
7. Đừng để mất những thứ tốt : Một khi bạn đã xây dựng thành công các hệ thống lớn và khắc phục tất cả các vấn đề trong đó, và học được một số kỹ thuật hay, điều tồi tệ nhất bạn có thể làm là bỏ đi kiến ​​thức đó và tìm kiếm thứ gì đó mới. Bạn đã biết nó hoạt động như thế nào, có vấn đề gì và làm thế nào để giải quyết những vấn đề đó. Ném nó đi chỉ là lãng phí thời gian.
8. Theo kịp công nghệ mới : một trong những hệ thống mới sẽ thành công. Nó có một cái gì đó về cơ bản tốt hơn bất cứ thứ gì khác trên thị trường. Bạn không biết cái nào là viên đạn bạc. Nếu bạn không tìm thấy nó kịp thời, kiến ​​thức của bạn sẽ bị lỗi thời. Thế giới có thể khiến bạn mất tất cả những thứ tốt bằng cách loại bỏ quyền truy cập vào các hệ thống cũ.

Vâng, tôi đã có điều đó xảy ra. Thông thường, bạn phải phân tích rủi ro về thời gian cần thiết để học kỹ thuật mới, và bạn có thể phục hồi và sử dụng một kỹ thuật cũ hơn trong trường hợp kỹ thuật mới không đáp ứng được kỳ vọng. Tôi thích học các kỹ thuật mới khi tôi có thể nhưng khi áp lực tăng lên và tôi không đủ khả năng dành thời gian để thử những thứ mới có thể thất bại, tôi gắn bó với các phương pháp thử và đúng.

Nói chung, tôi thấy thời điểm tốt nhất để học các kỹ thuật mới là lúc bắt đầu một dự án mới. Thường không có quá nhiều áp lực và nếu bạn tìm thấy một cái gì đó mới hoạt động tốt, bạn có thể dễ dàng tích hợp nó với phần còn lại của dự án, trong tương lai. Thời gian tồi tệ nhất để thử và học những điều mới là vài tuần cuối cùng điên cuồng trước khi triển khai lớn.

Vâng, những điều mới làm giảm năng suất

Phải, tất nhiên. Ngay cả đối với trường hợp tốt nhất, những điều mới cũng cần thêm thời gian vì chúng không quen thuộc. Nó thường có thể tốn nhiều thời gian hơn.

Không, các kỹ thuật mới có thể cải thiện năng suất

Bất kỳ kỹ thuật mới nào cho phép bạn thể hiện giải pháp dễ dàng hơn sẽ cải thiện năng suất của bạn. Điều này có thể đơn giản như chuyển từ if-elseifđiều kiện lớn sang bảng điều phối.

Có nó có thể làm giảm năng suất. Người yêu cũ của tôi đã được yêu cầu thực hiện một số công việc xử lý dữ liệu nhàm chán một lần, vì vậy cô ấy đã quyết định rằng sẽ tốt hơn nếu viết một chương trình dài để xử lý dữ liệu và sau đó chạy nó - sẽ khắc phục sự cố trong vài giây.

Tất nhiên, cô ấy đã mất một tuần để viết nó, nhưng vấn đề đã được giải quyết trong vài giây sau đó.

Tôi nghĩ điều tương tự cũng áp dụng cho câu hỏi của bạn: có, bạn có thể tăng năng suất bằng cách học những điều mới, nhưng bạn vẫn nên áp dụng kiến ​​thức hiện có của mình vào nhiệm vụ và hoàn thành công việc nhanh hơn. Ai quan tâm đến việc tìm và học một thư viện mới, nếu bạn có thể tự viết trong thời gian ngắn hơn.

Đừng quên, thường thì việc hoàn thành công cụ hiện có là một giải pháp tốt hơn so với đưa công cụ mới vào. Mỗi khi bạn thêm mới, bạn tăng bề mặt bảo trì cần thiết, điều này sẽ làm chậm mọi người khác (và có thể làm cho mã của bạn khá lộn xộn - Tôi nghĩ về các lớp công nghệ 'mới' đã được truyền lại theo thời gian nhưng vẫn còn trong mã của chúng ta làm cho mọi thứ trở nên khủng khiếp. Nhìn lại, tốt hơn là chỉ sử dụng các cách C cũ thay vì thêm tất cả COM đó và tất cả VB và tất cả .NET đó và giờ cũng chuyển HTML vào đó)