Đề xuất của bạn về việc học cách suy nghĩ là gì? [đóng cửa]


22

Trước hết, đây không phải là câu hỏi chung chung 'làm cho tôi trở thành một lập trình viên tốt hơn', mặc dù kết quả của việc hỏi câu hỏi này có vẻ giống như nó. Trên programmers.SE, tôi đã đọc và thấy những get đóng ở đây , ở đây , ở đây , ở đâyở đây .

Chúng ta đều biết có vô số lời đề nghị chung chung để trau dồi kỹ năng lập trình của bạn (ví dụ đọc SO, đọc sách được đề xuất, theo dõi blog, tham gia vào các dự án nguồn mở, v.v.). Đây không phải là những gì tôi sau.

Tôi cũng thừa nhận độc giả tích cực trên trang web này và hy vọng nó hoạt động có lợi cho tôi bằng cách đưa ra một số câu trả lời tuyệt vời. Từ việc đọc thư từ ở đây, dường như có một số lượng lớn những người có kinh nghiệm đang làm việc, hoặc đã làm việc, các lĩnh vực liên quan đến lập trình. Và hầu hết các bạn có thể truyền đạt suy nghĩ một cách hùng hồn, súc tích.

Gần đây tôi đã nhận thấy sự khác biệt giữa một người có khả năng lập trình và một lập trình viên thực sự có thể nghĩ . Tôi từ chối tin rằng để trở nên tuyệt vời với lập trình viên, chúng tôi chỉ đơn giản là tự phục tùng cả đời những hành vi giống như bọt biển (tức là tiếp thu mọi thứ liên quan đến lĩnh vực của chúng tôi bằng cách đọc, nghe, xem, v.v.). Tôi thậm chí sẽ nói rằng chỉ cần biết mọi khái niệm lập trình đơn lẻ cho phép bạn giải quyết vấn đề X nhanh hơn mọi người xung quanh, nếu bạn không thể nghĩ , bạn đang tự giới hạn bản thân mình - bạn chỉ là một robot nhanh.

Tôi muốn tin rằng có một khuôn mặt khác là một lập trình viên tuyệt vời không liên quan đến việc bạn biết nhiều về lập trình, nhưng đó là cách bạn có thể đan xen các khái niệm mới và áp dụng chúng vào nghề lập trình hoặc sở thích của bạn. Tôi chưa thấy ai đi sâu vào, hoặc giải quyết, khía cạnh này của tâm trí và lập trình của con người. (Vâng, cũng có thể là tôi đã không nhìn đủ cứng - xin lỗi nếu đó là trường hợp.)

Vì vậy, đối với bất kỳ ai đã dành thời gian suy nghĩ về những gì tôi đã đề cập ở trên - hoặc có thể tất cả mọi người ở đây vì tôi chậm một chút trong phát triển cá nhân / nghề nghiệp - những gợi ý của bạn về việc học cách suy nghĩ là gì? Ngoài cách đọc thông thường, bạn còn làm gì khác tốt hơn những người khác trong lĩnh vực của bạn?


Bạn nên nghĩ như tôi vì tôi tuyệt vời.
ChaosPandion

Làm một số loại thuốc cứng như Steve Job đã làm.
Công việc

Lập trình chức năng dạy để suy nghĩ. Mọi thứ khác dạy cho chương trình;)
Dario

Câu trả lời:


13

Gợi ý của tôi về việc học cách suy nghĩ:

  • Học ngôn ngữ mới . Cả ngôn ngữ tự nhiên và lập trình. Luôn luôn có một ngôn ngữ mới để học trên tay của bạn. Suy nghĩ được thực hiện nhiều hơn một ngôn ngữ. Mỗi ngôn ngữ có một "quan điểm" khác nhau về suy nghĩ. Nhiều ngôn ngữ bạn biết, nhiều "công cụ tinh thần" hơn, các khái niệm, quan điểm và trừu tượng có sẵn cho bạn.

"Ngôn ngữ định hình cách chúng ta suy nghĩ và xác định những gì chúng ta có thể nghĩ về." - Benjamin Lee Whorf

Và quan trọng hơn là ngôn ngữ quyết định những gì chúng ta không thể nghĩ tới.

  • Đọc ngấu nghiến . Đọc rộng. Không chỉ về lập trình, mà lịch sử, xã hội học, sinh học, nghệ thuật, vv Mở rộng quan điểm của bạn. Nhận những hiểu biết mới. Bạn không chỉ là những gì bạn ăn - bạn cũng là những gì bạn đọc. Những ý tưởng mới liên quan nhiều hơn đến việc kết hợp hai ý tưởng (dường như) khác nhau, hơn là một tia sáng thần thánh từ hư không.

"Chance ủng hộ tâm chuẩn bị." - Louis Pasteur

  • Khiêm tốn . Bạn phải biết rất nhiều, để hiểu làm thế nào bạn biết ít. Khiêm tốn giúp giữ cho tâm trí của bạn mở cho những cách suy nghĩ mới.
  • Hỏi tại sao? Đừng hài lòng với cách làm.
  • Học toán . Một công cụ thực sự mạnh mẽ, một loại ngôn ngữ, để làm việc với logic và trừu tượng. Học toán tăng cường trí não của bạn. Tâm thần tương đương với "đi tập thể dục".

Tôi không chắc lắm về ngôn ngữ tự nhiên. Học chúng có giá trị, nhưng để suy nghĩ? Trong bối cảnh lập trình? Giá trị của các từ để suy nghĩ đôi khi được cường điệu hóa - chúng ta có thể có những ý tưởng mà chúng ta không thể diễn đạt dễ dàng bằng lời, do đó chúng ta không hoàn toàn phụ thuộc vào các từ để hình thành ý tưởng. Ngoài ra, từ vựng phù hợp nhất (biệt ngữ cho toán học và các lĩnh vực kỹ thuật khác) được chia sẻ nhiều giữa các ngôn ngữ.
Steve314

6

Từ kinh nghiệm của tôi, có hai điều:

  1. Đam mê, nếu bạn quan tâm đến nghề bạn sẽ học, thích nghi và nhanh chóng nghĩ ra bên ngoài hơn so với nhiều lập trình viên trong lĩnh vực này giống như công việc. (Một số trong đó không có máy tính ở nhà.)
  2. Một số người được sinh ra với khả năng giải quyết các vấn đề kỹ thuật. Một số người tự nhiên có khả năng trừu tượng hóa một giải pháp linh hoạt.

Ngoài ra, mọi người đều khác nhau về cách họ nghĩ về lập trình hoặc học các kỹ năng lập trình mới. Tôi đề nghị bạn tiếp tục thử những điều mới và giữ những gì tốt cho bạn.


Điểm tốt, đặc biệt là điểm thứ hai.
Orble

5

Đề xuất của bạn về việc học cách suy nghĩ là gì?

Thực hành. Thực hành. Thực hành.

Nghiêm túc mà nói, hoạt động tinh thần (tức là suy nghĩ) giống như hoạt động thể chất. Bạn càng làm điều đó, bạn càng làm tốt hơn. (Trên thực tế, hoạt động thể chất cũng bao gồm một loại hoạt động tinh thần. Các vận động viên hàng đầu không chỉ có cơ bắp đúng chỗ ...)

Vì vậy, làm thế nào bạn sẽ (có hiệu quả) thực hành suy nghĩ?

(Ở đây tôi đang khái quát từ một thứ khác ...)

Tôi nghĩ bạn sẽ xác định được những vấn đề suy nghĩ mà bạn cảm thấy khó khăn (nhưng không phải là không thể), và cố gắng giải quyết chúng (nghĩ về chúng) và giống như chúng hơn.


Tôi loại hỗ trợ này. Bất cứ khi nào tôi làm điều gì đó lặp đi lặp lại mà không cần phải suy nghĩ, tôi đang nghĩ về điều gì khác. Tôi cũng có xu hướng làm điều này khi làm những việc lặp đi lặp lại mà tôi nên nghĩ đến, chẳng hạn như lái xe, nhưng bằng cách nào đó tôi cảm thấy mình lái xe tốt hơn khi tôi không nghĩ về nó.
Earlz

1
@Earlz - Tôi không hiểu quan điểm của bạn. Nếu bạn đang làm một cái gì đó lặp đi lặp lại, bạn không cần phải suy nghĩ về nó. Tôi đang nói về việc thực hành giải quyết các vấn đề đòi hỏi phải suy nghĩ.
Stephen C

Kinh nghiệm vấp ngã tất cả mọi thứ (loại tuyên bố chung, tôi biết) nhưng bạn học theo thời gian, ý tôi là bạn có thường xuyên gặp phải vấn đề khiến bạn phải giải quyết mãi mãi, chỉ để chạy lại và giải quyết nó trong vài phút. Ngoài ra, đó là cách bạn tiếp cận một vấn đề, đừng tập trung vào việc bị mắc kẹt, luôn tập trung vào những gì tôi chưa thử, từ đơn giản nhất đến phức tạp nhất
gian xa xôi

Cố ý thực hành. Bạn cần học một cái gì đó từ mỗi lần lặp.

4

Bạn có thể quan tâm bởi hai điều sau đây:

Dòng chảy

Mihály Csíkszentmihályi , một giáo sư tâm lý học người Hungary, đã giới thiệu khái niệm về dòng chảy .

Dòng chảy là trạng thái tinh thần của hoạt động trong đó một người trong một hoạt động hoàn toàn đắm chìm trong cảm giác tập trung năng lượng, tham gia đầy đủ và thành công trong quá trình hoạt động.

Tôi đủ may mắn để có thể tham gia vào dòng chảy hàng ngày bằng cách sử dụng một kỹ thuật cũ mà tôi học được từ ứng dụng GTD của mình , đó là hành động tiếp theo .

Tôi có thể nói với bạn rằng nó thực sự làm cho sự khác biệt. Khi tôi trong dòng chảy, tôi sản xuất chất lượng cao hơn và nhanh hơn so với khi tôi không ở trong trạng thái đó. Tôi hoàn toàn tập trung vào những gì tôi làm, và do đó tôi nghĩ hiệu quả hơn.

Chánh niệm

Tôi đã hỏi một câu hỏi về thiền cách đây một thời gian bởi vì tôi lo ngại bởi thực tế thiền có thể làm giảm khả năng lập trình (và sáng tạo) của tôi.

Tôi mới bắt đầu đào tạo phương pháp Jon Kabat-Zinn , vì vậy còn quá sớm để tôi chia sẻ với bạn những kinh nghiệm sâu rộng, nhưng từ vài lần tôi học được cho đến nay tôi có thể nói với bạn đây có lẽ là điều bạn sẽ muốn làm.


+1 Mặc dù tôi ghét rằng có một cuốn sách và toàn bộ "lý thuyết" về mức độ tiếp cận thông thường đối với một vấn đề, GTD chắc chắn có chân.
Orble

1
@ Tổ chức: oh tôi hoàn toàn đồng ý với bạn về điều đó. Nhưng giống như trong hầu hết các cuốn sách có tào lao và giá trị. Crap và giá trị là gì phụ thuộc vào người đang đọc cuốn sách. Vấn đề với GTD là nó rất mạnh, nó có thể nghiền nát bạn nếu bạn không dành thời gian để giảm đầu vào thay vì tập trung vào việc quản lý nó bất kể quy mô của nó. Đó là sai lầm của tôi;)

Vấn đề tôi gặp phải trong cuộc sống là có quá nhiều đầu vào, và rất nhiều việc phải làm, đến nỗi tôi sẽ không có thời gian để thực hiện bất kỳ thủ tục nào như vậy. Mặc dù tôi chắc chắn có thể thấy giá trị trong đó.
Orble

1
@ Tổ chức: Tôi nghĩ đó là chìa khóa. Lọc đầu vào của bạn là kỹ thuật năng suất cao nhất, trên Covey hoặc GTD. Nó đòi hỏi phải rất mạnh về tinh thần.

Tôi thấy nó cần thêm người để hoàn thành các nhiệm vụ bạn lọc ra, lol.
Orble

2

Tôi luôn tin rằng các kỹ sư giỏi được sinh ra, không được tạo ra.

Bạn cần có đầu óc cho nó, đầu óc logic, phân tích, suy luận, kết hợp với sự kiên trì và tò mò cần có để có cái nhìn tổng quan và cấu trúc của một vấn đề một cách hiệu quả và nhanh chóng đi từ A đến B, định hướng tâm trí của bạn giải pháp.

Có rất nhiều nghiên cứu cho thấy kỹ năng này được tăng cường mạnh mẽ bằng cách tiếp xúc sớm với những thứ như vậy, âm nhạc cũng giúp ích. Sau một thời điểm nhất định, bản đồ tinh thần của bạn có dây khá cứng. Không phải về những gì bạn nghĩ, mà là cách bạn nghĩ.

Bạn có thể học cách suy nghĩ như một người trưởng thành? Chà, bạn chắc chắn có thể được dạy các kỹ thuật để phá vỡ các vấn đề, nhưng sau đó bạn có các thuật toán để làm theo, bạn có thể trở thành một "robot rất nhanh" như bạn đã hùng hồn đặt ra. Sự hiểu biết trực quan có lẽ là bẩm sinh.

Điều này không có nghĩa là giới hạn trong nghề nghiệp của chúng tôi, rất nhiều kỹ năng bị chi phối bởi kỹ năng bẩm sinh, thay vì phản ứng có được. Mọi người có thể không muốn điều đó là đúng, nhưng rất có thể là như vậy.


2

Tìm một diễn đàn trực tuyến về một cái gì đó bạn đam mê. Một cái gì đó có một số loại cộng đồng. Tốt nhất là không lập trình - diễn đàn lập trình thường thiên về giải pháp hơn là hướng thảo luận. Hãy đứng dậy. Bảo vệ nó. Sử dụng đối số. Bạn cũng có thể viết blog, nhưng có một đối thủ thì tốt hơn. Vấn đề là có sự giao tiếp có ý nghĩa và bằng văn bản về điều gì đó với ai đó. Nơi bạn trao đổi một phần lớn hơn của văn bản.

Bạn sẽ học cách truyền đạt ý tưởng của mình và tranh luận chúng. Vì bạn sẽ phải bảo vệ quan điểm của mình, bạn sẽ phải hỗ trợ họ bằng sự thật. Bạn sẽ phải suy nghĩ về một cái gì đó, nói rõ vị trí của bạn và hỗ trợ nó; thậm chí có thể thay đổi nó

Sau đó, lấy khả năng đó để phân tích vấn đề và tổng hợp ý kiến ​​và áp dụng nó vào bất cứ điều gì. Ngay cả lập trình.


Tôi nên nói, đó là một cách để thực hành suy nghĩ. Đó không phải là người duy nhất.
Domchi

2

Một điều tôi nghĩ là người ta cần phải xem mọi thứ là hệ thống, và tất cả các hệ thống đều liên quan. Mỗi một người trong vũ trụ. Loài người, các hành tinh, thiên hà, thực vật, ánh sáng mặt trời, quang hợp, côn trùng, đá, đại dương, tất cả các hệ thống tương tác. Tương tự như vậy, trong thời gian, chu kỳ: sinh, tăng trưởng, suy tàn, chết, của bọ, con người, nền văn minh, dãy núi, hệ sao. Cuộc đấu tranh bất tận cho năng lượng. Tất cả các hệ thống.

Đây là Nghiên cứu về Cuộc sống và Tự nhiên theo nghĩa lớn của Nghiên cứu. Xem tất cả những thứ liên quan, xem tất cả những thứ tương tác. Tập trung vào điều này khi bạn ngắm hoàng hôn và cảm nhận độ sâu của lực hấp dẫn xoay quanh Mặt trời, kéo chúng ta xuống bề mặt hành tinh và ánh sáng mặt trời đỏ rực trước khi vào võng mạc của bạn ở tốc độ 300.000.000 mét mỗi giây và tạo ra hình ảnh trong bộ não linh trưởng của bạn.

Khi bạn bắt đầu nghĩ về điều đó, về mọi thứ có liên quan như thế nào, giá vàng và lao động nô lệ và bão tố trên Thái Bình Dương và các khu công nghiệp ở Nhật Bản có liên quan như thế nào, và bạn dành thời gian, thực sự dành thời gian để ngồi và nghĩ về tất cả những điều này, thì suy nghĩ "cơ bắp" của bạn sẽ thực sự uốn cong và phát triển.

Bây giờ, rất nhiều thứ sẽ ở dưới ngưỡng biểu cảm, nhưng đừng để điều đó cản trở bạn. Bộ não của bạn mạnh hơn máy tính mạnh nhất. Đẩy nó. Tôi không nghĩ rằng nó có thể ép xung nó.

Tôi nhớ về một bức tranh đen trắng cho thấy albert Einstein đang ngồi trên một chiếc ghế cỏ trên bãi biển nhìn ra biển. Chú thích cho biết: "Đây là Albert Einstein. Với bộ não của anh ấy."

Thách thức tiếp theo là có thể truyền đạt sự phức tạp và phụ thuộc lẫn nhau của tất cả mọi thứ một cách đơn giản. Điều này sẽ cung cấp cho bạn một cái gì đó để làm cho đến khi bạn rất già.


2

Một cách tiếp cận là Thực hành có chủ ý .

Sự lặp lại đơn giản không dẫn đến bất kỳ kỹ năng nào - bạn cần phải hướng nội, đánh giá hiệu suất của bạn, để xác định các cách để làm mọi thứ tốt hơn.

Một minh họa: Một người họ hàng gần gũi của tôi thi đấu trong môn thể thao bắn súng lục. Trong quá trình đào tạo, rất nhiều sự tập trung vào việc xem xét từng phát bắn, tập trung vào các bước đi chính xác. Phản trực giác, không tập trung nhiều vào các cảnh quay kém, bởi vì phát lại (diễn tập) sai lầm củng cố nó.

Đơn giản chỉ cần bắn 100 phát xuống tầm bắn là không có gì. Thực hành có chủ ý bắn 20 phát sẽ củng cố thói quen tốt và dẫn đến hiệu suất tốt hơn.

Điều tương tự cũng áp dụng cho lập trình - hãy nghĩ về những gì bạn làm. Đừng làm điều đó hàng tháng, hàng tuần hoặc hàng ngày - hãy làm từng khoảnh khắc, hành động bằng hành động.

  • Tại sao lỗi đó xảy ra trong mã của tôi?
  • Làm thế nào tôi có thể tránh được việc tạo ra khuyết điểm đó?
  • Làm thế nào tôi có thể tìm thấy giải pháp nhanh hơn?
  • Giả định nào của tôi là sai?
  • Tôi đã yêu cầu giúp đỡ đủ nhanh? quá nhanh?
  • Tôi đã phạm sai lầm đó trước đây?
  • Là khiếm khuyết này bị cô lập, hoặc một phần của một mô hình?
  • Có một khiếm khuyết thiết kế cơ bản?
  • Nếu vậy, tôi có thể làm bất cứ điều gì về nó?

Và cứ thế ...


điểm tuyệt vời, một lần nữa tất cả điều này đi kèm với thời gian / kinh nghiệm
gian xa xôi

1
@farinspace, chỉ khi bạn dành thời gian để đánh giá và tìm hiểu sau mỗi lần lặp.

1

Đi chọc vào một cái gì đó bạn yêu thích cho đến khi bạn tìm thấy một cạnh.

Thở sâu,

Bước qua...

...

... Nói cho người khác biết những gì bạn đã tìm thấy.


1

Vì vậy bạn muốn nghĩ

Rất nhiều lời đề nghị tuyệt vời từ các áp phích khác về cách suy nghĩ hoặc cách học cách suy nghĩ: dòng chảy, chánh niệm, toán học, niềm đam mê, thực hành ... vì vậy tôi sẽ không đến đó, được bảo vệ.

Nhưng không có lý do tại sao. Mục đích gì?

Cá nhân tôi đã hiểu rằng trước khi bạn có thể nghĩ rằng bạn cần phải biết tại sao.
Điều tốt nhất để làm là lắng nghe và nhìn. (Tôi lấy cả hai làm đơn vị, bạn không thể tách chúng ra)

Cách duy nhất để cải thiện lập trình, cho dù đó là thu thập các yêu cầu, chuyển đổi các yêu cầu đó thành thông số kỹ thuật hệ thống chi tiết, khớp với tài liệu thiết kế, thực thi mã, gỡ lỗi cho cuộc sống thân yêu của bạn, cho dù bạn bỏ qua bất kỳ hoặc tất cả các giai đoạn đó, cho dù bạn có năm phút để tìm giải pháp hay 20 năm, bạn cần lắng nghe và xem xét.

Lắng nghe những gì người dùng muốn, lắng nghe những gì người dùng nói với bạn đã xảy ra, lắng nghe người hỗ trợ nói với bạn rằng họ đã thấy. Nghe. Lắng nghe ngay cả khi nó không có ý nghĩa. Hãy lắng nghe ngay cả khi bạn tin rằng họ đã sai. Lắng nghe và không phán xét.

Tìm kiếm manh mối, không phải bằng cách tìm kiếm mà bằng cách mở mắt ra. Nhìn vào thực tế. Bạn không thể bắt đầu tìm kiếm câu trả lời trước khi bạn nhìn vào hiện trường vụ án. Bạn không thể tìm ra giải pháp cho đến khi bạn đã chứng minh được lỗ hổng.

Một ví dụ duy nhất từ ​​kinh nghiệm của tôi(về độ phân giải lỗi, nhưng nó có thể thích nghi với mọi thứ thực sự). Vì lý do rõ ràng (hợp pháp và mặt khác) tôi sẽ giữ các chi tiết ngon ngọt ra khỏi điều này. Trên một hệ thống quan trọng an toàn, một nhà điều hành đã báo cáo một lỗ hổng nghiêm trọng. Một số thiết bị theo dõi địa lý thực sự bị mất theo dõi khi 'không nên', với tác động tiềm tàng đối với cuộc sống (điều này 'nên' là sai lầm thực sự và khiến quá trình điều tra của chúng tôi bị đình trệ quá lâu). May mắn thay, mặc dù điều này đã được tìm thấy nhiều tuần sau đó gần như tình cờ, vì có một hệ thống khác đang hoạt động tại một địa điểm từ xa mà một nhà điều hành khác đến để chứng minh việc theo dõi đã không bị mất trên hệ thống đó. Điều này khiến chúng tôi suy nghĩ lại. Nhà cung cấp phần mềm chính của chúng tôi đã không tin chúng tôi một giây, vì vậy chúng tôi phải ra ngoài và chứng minh vấn đề. Cách duy nhất là thông qua ghép: xây dựng một mô phỏng để nhân rộng tình hình hoạt động chính xác. Chúng tôi đã phải thực sự quay video bằng chứng để nhà cung cấp tin chúng tôi. Cuối cùng, mô phỏng mang lại thông tin vượt quá hy vọng của chúng tôi và khiến chúng tôi hiểu toàn bộ vấn đề. Sau đó không mất nhiều thời gian để sửa chữa.

Cách duy nhất chúng tôi có được cho đến cuối cùng là kết nối một cách hợp lý một hệ thống từ xa với một hệ thống khác làm một công việc tương tự nhưng không hoàn toàn giống nhau. Đó là tìm kiếm manh mối (Nhìn). Điều này chỉ có thể bằng cách tin vào báo cáo một lần và không loại bỏ nó như một trục trặc ngẫu nhiên trong hệ thống (Nghe), và sau đó nghe lại báo cáo thứ hai mâu thuẫn với báo cáo đầu tiên (Nghe).

Vì vậy, khi bạn có manh mối đúng (đã lắng nghe và xem xét), xác định khu vực vấn đề, hiểu nguyên nhân gốc hoặc nguyên tắc chính, thì bạn có thể nghĩ đến các giải pháp để hiểu thêm trước (thử và sai, mô phỏng, trình diễn, chứng minh khái niệm, phiên bản mock-up, alpha, beta) và cuối cùng cung cấp một giải pháp vững chắc (đôi khi có thể được cải thiện hơn nữa sau một số hoạt động thực tế trong cuộc sống).

Để có thể thực hiện việc lắng nghe và tìm kiếm như vậy cần một tâm trí cởi mở, tin tưởng và cống hiến tuyệt đối cho mục tiêu của bạn. Đây là nhiên liệu bạn cần suy nghĩ, hoặc nhiều hơn đến mức để suy nghĩ của bạn tập trung vào đúng mục tiêu (thường thì vấn đề không phải là không có khả năng suy nghĩ mà là thiếu mục tiêu được xác định rõ để thực hiện tâm trí của bạn).


+1 cho câu trả lời của bạn, nghiên cứu miền vấn đề của bạn và lắng nghe người dùng là điều cần thiết. Mặc dù -1 cho nhận xét "yeah right", vì vậy không có thay đổi.
Orble

@ Tổ chức: Ok, bạn nói đúng, đó là một chút quá mức. Bình luận bị xóa. Tôi không nghĩ tài năng bẩm sinh là đúng, nhưng không cần phải đề cập đến nó.
asoundmove

Chà, nếu bạn có -1 câu trả lời của tôi thay vào đó, tôi sẽ đánh dấu tất cả của bạn giống nhau, nhưng nó đã ngăn nó trong điều này, đã được sửa ngay bây giờ. Tốt để đề cập đến nó là sai nếu bạn không đồng ý với những gì tôi nói.
Orble

@ Đơn giản, tôi không thích bỏ phiếu -1 cho bất kỳ ai, tôi chỉ muốn tiếp tục ... Chỉ những kịch bản cực đoan bảo đảm -1, chỉ không đồng ý thì không.
asoundmove

Tôi đồng ý với bạn trên các trang web khác, vì họ đúng / sai trong chính. Lập trình viên.SE khác với phần còn lại vì nó chủ quan, nên việc bỏ phiếu về cơ bản là thỏa thuận, không đồng ý. Cho dù bạn nghĩ rằng nó hữu ích hay không có ích. Tôi bỏ phiếu chỉ tiêu cực nếu tôi mạnh mẽ không đồng ý với một ai đó. Tại thời điểm viết, 2,6% phiếu bầu của tôi là downvote. Ý kiến ​​sau tất cả nên được thử thách.
Orble

1

Tôi nghĩ bạn cần phân biệt giữa các loại suy nghĩ khác nhau.

Tư duy sáng tạo - làm thế nào để đưa ra những ý tưởng mới, giải pháp sáng tạo và kết quả bất ngờ. Có cả một khoa học đằng sau điều này, hãy tìm Edward de Bono, các kỹ thuật sáng tạo, v.v. Không nhiều lập trình viên nhìn vào lĩnh vực này.

Tư duy phân tích - bởi điều này tôi có nghĩa là quá trình khoa học. Nhìn vào đầu vào, đầu ra, đo lường những gì quan trọng, đưa ra kết luận hợp lý. Hầu hết các nhà phát triển đều quen thuộc với kỹ thuật khoa học nhưng sau đó không bao giờ thực sự sử dụng nó. Làm như vậy!

Tư duy phê phán - Tôi nghĩ rằng đây là triết lý nhiều hơn. Đứng lại và nhìn vào bức tranh lớn hơn, xem xét các giả định của bạn, bạn có thực sự làm những gì bạn nói giá trị của bạn? Nghiên cứu triết học có một loạt các tác giả và ý tưởng tuyệt vời ngoài kia.


0

Toán học dạy người ta cách suy nghĩ. Ứng dụng đòi hỏi sự sáng tạo và kinh nghiệm.

Tôi từ chối tin rằng để trở nên tuyệt vời với lập trình viên, chúng tôi chỉ đơn giản là tự phục tùng cả đời những hành vi giống như bọt biển

Cái nhìn sâu sắc Nói một cách rõ ràng, các yêu cầu về "sự vĩ đại" phụ thuộc vào định nghĩa cá nhân của bạn về "sự vĩ đại" ... và đã thay đổi theo thời gian. Ngày nay, thành công của dự án là về việc có thể ghép các khái niệm lại với nhau một cách nhanh chóng và không đi sâu vào tất cả các chi tiết nghiệt ngã của nitty. Thành công cá nhân có thể được định nghĩa là thành thạo C # như Jon Skeet.

Đọc coder tại nơi làm việc . Các lập trình viên nhiều kinh nghiệm hơn tôi thảo luận chi tiết về điều này.


0

Làm việc về việc áp dụng các ý tưởng và khái niệm từ các lĩnh vực dường như không liên quan. Đối với tôi, sự sáng chói của iPod không phải là kỹ thuật tạo ra một máy nghe nhạc MP3 tuyệt vời, nhưng giúp giải quyết một vấn đề lớn mà ngành công nghiệp giải trí âm nhạc gặp phải với nhạc lậu và mô hình CD / Album bán nhạc. Jobs có lẽ đã áp dụng nhiều hơn những gì ông học được ở Pixar trong việc đối phó với ngành công nghiệp điện ảnh. Anh biết vấn đề thực sự là gì.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.