Tránh làm phiền một lập trình viên Theoretician

Tôi đã tìm thấy này viết trong vài bài viết trên SO. Tôi thấy mình rơi vào nguyên mẫu thứ 6; "Nhà lý luận".

Nó định nghĩa "Nhà lý luận" là:

Nhà lý luận biết tất cả mọi thứ cần biết về lập trình. Anh ấy hoặc cô ấy có thể dành bốn giờ để giảng về lịch sử của ngôn ngữ lập trình tối nghĩa hoặc cung cấp bằng chứng về cách mã bạn viết không tối ưu hoàn hảo và có thể mất thêm ba nano giây để chạy. Vấn đề là, Theoretician không biết gì về phát triển phần mềm. Khi Theoretician viết mã, thật là tao nhã, mà những người phàm trần không thể hiểu được điều đó. Kỹ thuật yêu thích của anh ấy hoặc cô ấy là đệ quy, và mọi khối mã được điều chỉnh đến mức tối đa, với chi phí về tính kịp thời và dễ đọc.

Nhà lý luận cũng dễ bị phân tâm. Một nhiệm vụ đơn giản phải mất một giờ phải mất ba tháng cho các nhà lý thuyết, vì họ quyết định rằng các công cụ hiện có là không đủ và họ phải xây dựng các công cụ mới để xây dựng thư viện mới để xây dựng một hệ thống hoàn toàn mới đáp ứng các tiêu chuẩn cao của họ. Theoretician có thể được biến thành một trong những người chơi giỏi nhất của bạn, nếu bạn có thể khiến anh ấy hoặc cô ấy chơi trong ranh giới của chính dự án và ngừng dành thời gian làm việc với Thuật toán sắp xếp cuối cùng.

Ngay cả khi làm việc với dự án đơn giản, tôi vẫn có xu hướng bị sa lầy khi cố gắng vượt qua mọi thứ từ đầu (Điều này có thể giải thích tại sao tôi lãng phí khoảng 2 năm để cố gắng tạo ra một hệ điều hành từ đầu. Nhưng thậm chí tôi còn thấy rằng cuối cùng là vô nghĩa).

Điều gì có thể giúp tôi tránh làm điều này? Và tuân thủ nguyên tắc KISS?

Cảm ơn

Bản thân tôi là một nhà lý luận, tôi có thể nói với bạn rằng làm việc trong một cửa hàng Agile sẽ nhanh chóng và dứt khoát chữa tất cả các xu hướng như vậy. Đặc biệt, một hoạt động Lập trình eXtreme, với lập trình cặp (lý tưởng là xoay vòng thường xuyên), phát triển dựa trên thử nghiệm, đấm bốc thời gian và chạy nước rút, ngay lập tức đưa công việc của bạn cho tất cả các đồng nghiệp của bạn xem, và yêu cầu bạn phải mở và cộng tác một cơ sở từng phút. Đây là một sự thay đổi lớn từ các nhiệm vụ riêng biệt trong môi trường văn phòng biệt lập, trong đó công việc theo phong cách Theoretician phát triển mạnh mẽ. Nó đòi hỏi sự trung thực hoàn toàn và toàn vẹn, vì mọi người đều chủ động phụ thuộc vào những người khác liên tục.

Tôi vẫn trân trọng cái nhìn của mình, nhưng tôi phải thưởng thức nó ở nhà, hoặc trong những dịp hiếm hoi khi tôi có thể làm việc trong một dự án bên lề không phải là một phần của sự phát triển chính.

1. Có mục tiêu cho những gì bạn cần phát triển.

2. Thu hẹp những mục tiêu đó thành một cái gì đó có thể giao được trong tương lai gần.

3. Sau đó tập trung vào những mục tiêu đó, loại bỏ tất cả những cân nhắc khác. Không có nền. Không có lịch sử. Không có phần mở rộng. Không có gì chung chung hay trừu tượng.

4. Sau đó thu hẹp chúng hơn nữa vào mức tối thiểu bạn có thể làm điều đó sẽ có thể giao được. Không tốt. Không linh hoạt. Không thể bảo trì. Chỉ chấp nhận được.

5. Sau đó, ưu tiên vào mức tối thiểu tuyệt đối cần thiết để đạt được điều tối thiểu bạn có thể làm. Vấn đề là chọn một ngày trong khoảng một tuần và xây dựng cho đến ngày đó. Nếu bạn không thể cung cấp một cái gì đó trong một tuần. Hẹp. Tiêu điểm. Cắt tỉa. Giảm.

6. Sau đó loại bỏ lông tơ. Bạn chỉ có một tuần. Tiếp tục cắt.

7. Sau đó, tập trung vào việc thực hiện giảm sẽ được thực hiện càng sớm càng tốt. Lý tưởng nhất là ít hơn một tuần, vì vậy bạn có thời gian để viết tài liệu.

Tôi đã làm việc với các nhà lý thuyết. Tôi coi "phần bổ sung" là một cái cớ để tránh thực sự làm điều gì đó có thể bị coi là thất bại.

Làm - và thất bại - là khó. Nói về việc làm một cái gì đó dễ dàng hơn làm một cái gì đó. Rất nhiều nghiên cứu và suy nghĩ là một cách để tránh làm sai và sau đó làm lại sau khi biết rằng người dùng đã nói dối.

Chỉ cần đặt mã trước mặt họ. Họ sẽ gọi mã là một thất bại. Nó xảy ra. Nhưng trong quá trình thất bại, bạn sẽ học được những yêu cầu thực sự là gì. Và bạn sẽ biết rằng họ đã nói dối.

Tôi không chắc đây là một điều tồi tệ như vậy. Rõ ràng bạn cần phải làm việc hiệu quả hoặc bạn sẽ không làm việc của mình, nhưng có hứng thú với lĩnh vực này, là một sinh viên của nghệ thuật, vì vậy để nói không phải là một điều xấu.

Tôi sẽ chơi theo sở trường của bạn, tìm kiếm cơ hội trong đó phong cách và sở thích của bạn là một lợi thế.

Để đảm bảo bạn vẫn làm việc hiệu quả trong khi đam mê viết một khung MVC trong Erlang (hoặc bất cứ điều gì bạn thấy thú vị), có lẽ bạn nên dành thời gian cho công việc tinh túy hơn của mình, giả sử, một giờ mỗi ngày. Trong phần còn lại của ngày, chỉ cần tập trung vào công việc lẩm cẩm và hoàn thành công việc. Khi bạn thấy một cái gì đó thú vị sẽ làm bạn mất tập trung đánh dấu nó hoặc ghi chú nhưng tiếp tục, sau đó quay lại với nó trong khoảng thời gian được phân bổ của bạn.

Cá nhân tôi có rất nhiều URL trông chúng rất thú vị và một đống sách thư viện cũng vậy. Cuối cùng tôi có thể nhận được khoảng 10% số URL đó và cuối cùng có thể đọc 50% số sách, nhưng tôi vẫn hoàn thành công việc hàng ngày.

Tôi đã có vấn đề này bản thân mình. Hai kỹ thuật đã giúp:

1. Sử dụng kỹ thuật Pomodoro hoặc một số kỹ thuật quản lý thời gian khác trong đó bạn đặt một chuỗi các mục tiêu rất ngắn hạn. Khi bạn phải tìm ra những gì bạn có thể hoàn thành trong 25 phút tiếp theo, nó sẽ giúp bạn tập trung vào công việc hữu ích.
2. Hướng phát triển thử nghiệm. Nếu bạn phải viết một bài kiểm tra cụ thể trước khi bạn viết bất kỳ mã nào, nó sẽ giảm thiểu việc mơ mộng. (Không có cách nào để viết một bài kiểm tra cho "thanh lịch".) Sau khi bạn làm việc gì đó, bạn có thể dành nhiều thời gian hơn bạn nên tái cấu trúc nó, nhưng ít nhất bạn sẽ làm việc với mã thực chứ không phải là một lý tưởng tưởng tượng.

Đừng đánh đập bản thân quá nhiều. Thật dễ dàng để khiến một nhà lý thuyết tập trung và làm những công việc hữu ích hơn là để những người không quan tâm mở rộng tầm nhìn của họ.

Tránh stackoverflow.com . Đừng hiểu sai ý tôi - Tôi là một fan hâm mộ lớn - nhưng SO và các diễn đàn định hướng lập trình khác làm cho hoàn hảo kẻ thù tốt . Sau một thời gian, bạn có thể bắt đầu cảm thấy như hàng ngàn người thông minh đang nhìn qua vai bạn và không có gì bạn viết là đủ tốt. Chỉ cần có được một cái gì đó làm việc và cố gắng làm cho nó dễ hiểu. Bạn luôn có thể xem lại nếu nó cần cải thiện.

Ngoài ra, tránh các bài viết như những gì bạn liên kết. Bạn có thực sự tin rằng có mười loại lập trình viên? Hoặc bất cứ ai bạn biết hoàn toàn phù hợp với chính xác một trong các loại được mô tả? Các bài viết như thế này có một sức hấp dẫn nhất định bởi vì chúng chứa một chút sự thật - bạn có thể thấy chính mình và / hoặc một số đồng nghiệp của bạn trong một số khuôn mẫu. Nhưng các loại giữ nhiều nước như các dấu hiệu chiêm tinh. Hãy thử điều này vào lần tới khi bạn tham gia vào bộ trộn sau hội nghị: "Xin chào, tôi là một Cowboy Cowboy! Bạn thuộc kiểu gì?"

Điều đó không có nghĩa là câu hỏi của bạn không hợp lệ - nếu bạn suy nghĩ quá nhiều, thật tốt khi biết cách tránh xu hướng đó. Nhưng đừng để punditry này nói chuyện với bạn về chính mình.

Có một hướng dẫn đơn giản, khi được giải nén hoàn toàn, sẽ giải thích đầy đủ cách tránh kịch bản này.

Làm điều đơn giản nhất có thể có thể làm việc.

- Kent Beck

Tôi nghĩ một cách để tránh đầu bạn khỏi đám mây là buộc bản thân phải viết các ứng dụng thực tế từ đầu đến cuối, ngoài việc viết các API hoặc khung lý thuyết của bạn. Cố gắng đặt một hộp thời gian xung quanh một cái gì đó, và cố gắng "hoàn thành" nó trong khoảng thời gian đó. Viết khung công tác đòi hỏi sự hiểu biết tốt về các mẫu thiết kế và kiến ​​trúc, nhưng tôi thấy rằng viết một ứng dụng hoàn chỉnh trong một hộp thời gian cố định đòi hỏi các kỹ năng khác với viết một khung được thiết kế siêu tốt.

Nếu bạn muốn hoàn thành một ứng dụng, đến một lúc nào đó bạn phải tự đưa mình xuống trái đất và hoàn thành nó. Điều này có thể yêu cầu hy sinh cho các thiết kế hoặc bị buộc phải triển khai một tính năng theo cách mà bạn không hài lòng, do một số loại ràng buộc. Tôi giống như bạn - có xu hướng viết và viết lại mọi thứ một triệu lần, nhưng nếu tôi phải đối mặt với các nhiệm vụ phải hoàn thành trong một khoảng thời gian nhất định, tôi thấy rằng tôi chọn các trận chiến của mình và chỉ thực hiện các thao tác điều quan trọng nhất

Đơn giản :

1. Hãy thực dụng .

Mặt đối lập của Nhà lý luận (có lợi thế về mặt thông tin / kiến ​​thức của lĩnh vực lập trình) là Chủ nghĩa thực dụng.

Áp dụng KISS, DRY, SOC và cách suy nghĩ khác, như được mô tả trong câu trả lời này , có nghĩa là nuôi ong thực dụng.

Bạn cũng có thể học cách thực dụng bằng cách đọc cuốn sách này:

http://www.amazon.com/Pigateatic-Programmer-JTHERman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

Đừng quên rằng lý thuyết và thực hành làm việc cùng nhau, không phải một mình. Không có nhiều thực hành, kiến ​​thức của bạn không là gì cả. Không có nhiều kiến ​​thức, bạn không thể cải thiện việc luyện tập của mình một cách nhanh chóng.

Vì vậy, hãy luyện tập thật nhiều. Và học hỏi được nhiều điều. Nhưng đừng để người này vượt qua người kia.

Trong các dự án của bạn, đặt thời hạn. Dính vào nó. Sau đó suy nghĩ thực tế về cách hoàn thành dự án của bạn trước thời hạn đó. (đọc cuốn sách, thực sự) Sau đó bắt đầu viết mã, bắt đầu đọc những gì bạn sẽ cần biết, chuyển từ đọc sang mã hóa và giới hạn hoặc thời gian đọc của bạn.

Hrm ... Có lẽ có thể thử nhận một công việc trong một doanh nghiệp yêu cầu bạn viết đơn theo dòng thời gian. Tôi sẽ nói với bản thân mình, rằng tôi có lẽ là một nhà lý thuyết xa như bạn có thể, ít nhất là trong công việc. Làm loại công việc đó có vị trí và thời gian của nó và rất quan trọng để phát triển bản thân. Tuy nhiên, trong khi tôi đánh giá cao khả năng đó thì nó không có chỗ đứng trong thế giới kinh doanh, đặc biệt là nơi tôi làm việc. Một môi trường phát triển nhanh, đôi khi bạn viết ứng dụng trong vài tuần và khách hàng muốn chúng ngày hôm qua! Tôi đã được ban phước với các nhà phát triển tuyệt vời và phải mất thời gian để mọi người làm việc như một nhóm.

Tôi đã có một anh chàng xuất sắc nhất có thể, nhưng cũng giống như bạn, luôn phải vắt kiệt chút ít mã cuối cùng ngay cả khi nó hoạt động tốt, thậm chí đến mức anh ta bắt đầu viết các điều khiển tùy chỉnh về cơ bản là giống như những người được cung cấp bởi môi trường. Tất cả đều rất tuyệt nhưng thật lãng phí thời gian khi chúng tôi phải ra ngoài đúng giờ. Thường thì những dự án phụ này ủng hộ đội ngũ và cuối cùng anh bắt đầu cảm thấy áp lực từ những người khác và anh đã thành hình. Tôi sẽ đề nghị bắt đầu làm việc trong môi trường nhóm với một số nhà phát triển giỏi khác phải đẩy sản phẩm ra. Luôn luôn có thời gian sau đó để cấu trúc lại và làm lại mọi thứ hoặc viết MergeSort mạnh nhất từ ​​trước đến nay; nhưng đôi khi bạn phải đưa sản phẩm đến điểm mà nó hoạt động và đưa nó ra cho khách hàng.

Không có gì sai khi là một "nhà lý luận" theo nghĩa thông thường của từ này. Có kiến ​​thức nền tảng và có thể hiểu được nghiên cứu CS mới nhất là một khả năng tuyệt vời, vì nó là một mỏ vàng của những ý tưởng hay và độc đáo.

"Câu hỏi thực sự" ở đây rõ ràng hơn ở nửa sau của bài viết. Biết mục tiêu dự án cụ thể và làm việc hướng tới mục tiêu đó, không phải bất kỳ mục đích nào khác. Đó thực sự chỉ là vấn đề kỷ luật tự giác trong trường hợp này. Xem câu trả lời của S. Lott để biết thêm về điều này :).

Tập trung tâm trí của bạn từ lập trình và thậm chí hoàn thành mọi thứ để cung cấp phần mềm làm việc. Nó đặt đúng các ưu tiên của bạn.

Làm thế nào để đạt được điều này là một câu chuyện khác. Cách tốt nhất là hình dung một số dự án và trải qua tất cả các bước để đưa nó vào sản xuất. Sau đó, bạn sẽ có một suy nghĩ khác so với trước đây.

Thanx cho bài này. Nó làm cho công việc của tôi thậm chí còn có giá trị hơn trong khi. Tôi cảm thấy giống như có một nền giáo dục về Kiến trúc thông tin làm việc như một Nhà phát triển phần mềm. Thường thì tôi thấy mình phải vật lộn với "nơi thay đổi mọi thứ" hơn là "thay đổi điều gì". Có quá nhiều mối quan hệ, quá nhiều thứ thông minh và chung chung xung quanh mà phải mất quá nhiều thời gian để tìm hiểu cách thức hoạt động của công cụ.

Vì vậy, tôi bắt đầu đặt câu hỏi, và thậm chí nhiều câu hỏi hơn cho đến khi tôi biết CÁCH và nơi này thực sự được xây dựng. Và để tôi nói với bạn - nó hoạt động. Càng có nhiều câu hỏi, đám cháy càng ít quan trọng để theo kịp kiến ​​trúc ban đầu, và cuối cùng là nơi trở lại những điều cơ bản

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Yêu cầu sếp của bạn để có được một người cố vấn, và sau đó làm như người cố vấn nói.

Phần khó là giữ tập trung và nhận ra rằng "này, hãy viết lại hệ điều hành" sẽ không mang lại lợi ích đáng kể cho việc hoàn thành nhiệm vụ bạn đã giao (đó là lý do tại sao người quản lý dự án sẽ không làm).

Cũng có người cố vấn xem xét TẤT CẢ các thiết kế của bạn trước khi mã hóa và mã thực tế sau khi mã hóa. Điều này sẽ giúp bạn tiếp tục tập trung vào những gì cần phải làm.

Tôi có cùng cám dỗ với những thứ kỹ sư quá mức, và nó đòi hỏi sự tự giác và tổ chức để vượt qua nó. Khi mã hóa cho người khác, đây là cách tôi thực hiện:

1. Khi bắt đầu một nhiệm vụ riêng biệt, hãy dành vài phút suy nghĩ về những gì thực sự cần thiết về chức năng, chất lượng, ngày giao hàng, v.v.
2. Dành thêm một chút thời gian để lên kế hoạch làm thế nào để làm điều đó , chia nó thành các nhiệm vụ phụ, nhiệm vụ phụ, v.v., giữ cho mục tiêu của khách hàng trong mã.
3. Ước tính thời gian cho mỗi mục , thêm tối đa 50% cho ẩn số. Nếu một mục sẽ mất hơn bốn giờ, hãy chia nhỏ nó thêm. (Nếu tôi đang làm các dự án đại học, tôi sẽ sử dụng bảng tính, nhưng là một nhà tư vấn có nhiều khách hàng, tôi sử dụng một hệ thống theo dõi vấn đề được gọi là Redmine.)
4. Quan trọng nhất: chỉ làm những mục tôi nghĩ ra .

Tất nhiên, công cụ xảy ra. Đôi khi tôi thấy tôi cần phải làm nhiều thứ hơn - vì vậy tôi bắt đầu lại ở # 1. Đôi khi tôi thấy một nhiệm vụ sẽ mất nhiều thời gian hơn tôi nghĩ - bắt đầu lại ở # 1. Đôi khi tôi biết trước thiết kế của mình sẽ cần thêm chi tiết sau - vì vậy tôi lên kế hoạch cho một bảng con ước tính lại, nơi tôi bắt đầu lại ở # 1.

Tôi càng làm điều này, tôi càng nhận được nó tốt hơn. Kỷ luật tự giác là một cơ bắp tinh thần tăng cường với tập thể dục, và tôi cũng cải thiện việc ước tính thời gian mọi thứ sẽ mất và thực hiện đánh đổi kỹ thuật. Và tôi thấy thật hữu ích khi nhớ một câu trích dẫn từ Tướng Patton: "Một kế hoạch tốt được thực hiện một cách thô bạo bây giờ tốt hơn một kế hoạch hoàn hảo được thực hiện vào tuần tới."

Là một nhà phát triển đơn độc, quy trình làm việc của tôi kết hợp điều này với các khía cạnh của Agile, bao gồm cả bảng Kanban. Đôi khi tôi đi trên tiếp tuyến, nhưng tôi cố gắng hạn chế độ lệch trong một vài giờ một tuần, và nó hoạt động khá tốt.

Nếu bạn có kế hoạch làm việc trong ngành công nghiệp tư nhân, việc kiểm soát xung lực của "nhà lý luận" thực sự rất quan trọng. Lập trình viên xuất sắc nhất mà tôi biết sống ở Thung lũng Silicon, nhưng đã không có việc làm trong nhiều năm vì anh ta có tiếng như vậy vì đã cung cấp mã hoàn hảo quá muộn.