Apa saran Anda untuk mempelajari cara berpikir? [Tutup]

22

Pertama-tama, ini bukan generik 'membuat saya programer yang lebih baik' pertanyaan, meskipun hasil menanyakan pertanyaan ini mungkin tampak mirip dengan itu. Pada programmer.SE, saya telah membaca dan melihat ini ditutup di sini , di sini , di sini , di sini , dan di sini .

Kita semua tahu ada banyak saran umum untuk mengasah kemampuan pemrograman Anda (misalnya membaca SO, membaca buku yang direkomendasikan, mengikuti blog, terlibat dalam proyek sumber terbuka, dll.). Ini bukan yang saya cari.

Saya juga mengakui jumlah pembaca aktif di situs web ini dan saya berharap ini berfungsi untuk saya dengan memberikan beberapa jawaban yang bagus. Dari membaca korespondensi di sini, tampaknya ada sejumlah besar orang yang berpengalaman yang bekerja, atau telah bekerja, bidang yang berhubungan dengan pemrograman. Dan sebagian besar dari Anda dapat menyampaikan pikiran dengan cara yang fasih dan ringkas.

Baru-baru ini saya memperhatikan perbedaan antara seseorang yang mampu pemrograman dan seorang programmer yang benar - benar bisa berpikir . Saya menolak untuk percaya bahwa untuk menjadi hebat di programmer, kami hanya menyerahkan diri kita untuk seumur hidup seperti perilaku spons (yaitu menyerap semua yang berhubungan dengan bidang kita dengan membaca, mendengarkan, menonton, dll). Saya bahkan akan menyatakan bahwa hanya dengan mengetahui setiap konsep pemrograman tunggal yang memungkinkan Anda untuk menyelesaikan masalah X lebih cepat daripada semua orang di sekitar Anda, jika Anda tidak dapat berpikir , Anda sangat membatasi diri Anda sendiri - Anda hanya robot yang cepat.

Saya suka percaya bahwa ada wajah lain sebagai programmer hebat yang tidak terkait dengan seberapa banyak yang Anda ketahui tentang pemrograman, tetapi seberapa baik Anda bisa menjalin konsep baru dan menerapkannya pada profesi atau hobi pemrograman Anda. Saya belum pernah melihat orang menyelidiki, atau membahas, aspek pikiran dan pemrograman manusia ini. (Ya, itu juga mungkin bahwa saya belum terlihat cukup keras juga - maaf jika itu masalahnya.)

Jadi bagi siapa pun yang telah menghabiskan waktu memikirkan apa yang telah saya sebutkan di atas - atau mungkin semuanya ada di sini karena saya sedikit ketinggalan dalam pengembangan pribadi / profesional saya - apa saran Anda untuk belajar berpikir? Selain bacaan biasa, apa lagi yang Anda lakukan untuk menjadi lebih baik daripada orang lain di bidang Anda / kami?

JK
sumber
Anda harus berpikir seperti saya karena saya hebat.
ChaosPandion
Lakukan beberapa obat keras seperti yang dilakukan Steve Job.
Pekerjaan
Pemrograman fungsional mengajarkan untuk berpikir. Segala sesuatu yang lain diajarkan untuk diprogram;)
Dario

Jawaban:

13

Saran saya untuk belajar berpikir:

  • Pelajari bahasa baru . Bahasa alami dan pemrograman. Selalu punya bahasa baru untuk dipelajari di tangan Anda. Berpikir dilakukan lebih sedikit dalam suatu bahasa. Setiap bahasa memiliki "pandangan" berbeda dalam berpikir. Lebih banyak bahasa yang Anda tahu, lebih banyak "alat mental", konsep, sudut pandang, dan abstraksi tersedia untuk Anda.

"Bahasa membentuk cara kita berpikir, dan menentukan apa yang dapat kita pikirkan." - Benjamin Lee Whorf

Dan yang lebih penting, bahasa menentukan apa yang tidak dapat kita pikirkan.

  • Baca dengan lahap . Baca secara luas. Bukan hanya tentang pemrograman, tetapi sejarah, sosiologi, biologi, seni, dll. Perluas perspektif Anda. Dapatkan wawasan segar. Anda tidak hanya apa yang Anda makan - Anda juga apa yang Anda baca. Ide-ide baru lebih tentang menggabungkan dua (tampaknya) ide yang berbeda, daripada kilasan kreativitas ilahi entah dari mana.

"Peluang berpihak pada pikiran yang siap." -- Louis Pasteur

  • Kerendahan hati . Anda harus tahu banyak, untuk memahami betapa sedikitnya yang Anda tahu. Kerendahan hati membantu membuat pikiran Anda terbuka untuk cara berpikir yang baru.
  • Tanya kenapa? Jangan puas dengan caranya.
  • Belajar matematika . Alat yang sangat kuat, semacam bahasa, untuk bekerja dengan logika dan abstraksi. Mempelajari matematika memperkuat otak Anda. Setara mental dengan "pergi ke gym".
Maglob
sumber
Saya tidak begitu yakin tentang bahasa alami. Mempelajari mereka memiliki nilai, tetapi untuk berpikir? Dalam konteks pemrograman? Nilai kata-kata untuk berpikir kadang-kadang terlalu berlebihan - kita dapat memiliki ide-ide yang tidak dapat kita ungkapkan dengan mudah dalam kata-kata, karena itu kita tidak sepenuhnya bergantung pada kata-kata untuk membentuk ide. Juga, kosakata yang paling relevan (jargon untuk matematika dan bidang teknis lainnya) sangat dibagi antara bahasa.
Steve314
6

Dari pengalaman saya, ada dua hal:

  1. Gairah, jika Anda tertarik pada kerajinan Anda akan belajar, beradaptasi, dan lebih cepat untuk berpikir di luar kotak daripada banyak programmer yang berada di lapangan seperti pekerjaan. (Beberapa di antaranya tidak memiliki komputer di rumah.)
  2. Beberapa orang baru saja lahir dengan kemampuan untuk memecahkan masalah teknis. Beberapa orang secara alami memiliki kemampuan untuk mengeluarkan solusi yang fleksibel.

Di luar ini, semua orang cukup berbeda dalam cara mereka berpikir tentang pemrograman atau belajar keterampilan pemrograman baru. Saya sarankan Anda terus mencoba hal-hal baru dan menjaga apa yang berfungsi baik untuk Anda.

jzd
sumber
Poin bagus, terutama poin kedua.
Orbling
5

Apa saran Anda untuk mempelajari cara berpikir?

Praktek. Praktek. Praktek.

Serius, aktivitas mental (yaitu berpikir) seperti aktivitas fisik. Semakin banyak Anda melakukannya, semakin baik Anda melakukannya. (Faktanya, aktivitas fisik melibatkan semacam aktivitas mental juga. Olahragawan top tidak hanya memiliki otot di tempat yang tepat ...)

Jadi, bagaimana Anda mempraktikkan pemikiran?

(Di sini saya menggeneralisasi dari sesuatu yang lain ...)

Saya pikir Anda akan mengidentifikasi masalah berpikir yang menurut Anda sulit (tetapi bukan tidak mungkin), dan mencoba menyelesaikannya (memikirkannya secara menyeluruh) dan lebih menyukainya.

Stephen C
sumber
Saya agak mendukung ini. Setiap kali saya melakukan sesuatu yang berulang yang tidak memerlukan pemikiran untuk dilakukan, saya memikirkan sesuatu yang lain. Saya juga cenderung melakukan ini ketika melakukan hal-hal berulang yang harus saya pikirkan, seperti mengemudi, tetapi entah bagaimana saya merasa seperti mengemudi lebih baik ketika saya tidak memikirkannya.
Earlz
1
@ Earlz - Saya tidak mengerti maksud Anda. Jika Anda melakukan sesuatu yang berulang, Anda tidak perlu memikirkannya. Saya berbicara tentang berlatih memecahkan masalah yang membutuhkan pemikiran.
Stephen C
pengalaman mengalahkan segalanya (semacam pernyataan umum, saya tahu) tetapi Anda belajar dengan waktu, maksud saya seberapa sering Anda mengalami masalah membuat Anda selamanya harus menyelesaikannya, hanya untuk menanganinya lagi dan mengurusnya dalam hitungan menit. Juga cara Anda mendekati masalah, jangan fokus pada macet, selalu fokus pada apa yang belum saya coba, dari yang paling sederhana hingga yang paling kompleks
farinspace
Latihan yang disengaja . Anda perlu belajar sesuatu dari setiap iterasi.
4

Anda mungkin tertarik dengan dua hal berikut:

Aliran

Mihály Csíkszentmihályi , seorang profesor psikologi Hongaria, memperkenalkan konsep aliran .

Flow adalah keadaan operasi mental di mana seseorang dalam suatu kegiatan sepenuhnya tenggelam dalam perasaan fokus penuh energi, keterlibatan penuh, dan keberhasilan dalam proses kegiatan.

Saya cukup beruntung bisa masuk dalam aliran setiap hari dengan menggunakan teknik lama yang saya pelajari dari aplikasi GTD yang merupakan tindakan selanjutnya .

Saya dapat memberitahu Anda itu benar-benar membuat perbedaan. Ketika saya dalam aliran, saya menghasilkan kualitas yang lebih tinggi dan lebih cepat daripada ketika saya tidak dalam keadaan itu. Saya benar-benar fokus pada apa yang saya lakukan, dan karena itu saya berpikir lebih efektif.

Perhatian penuh

Saya mengajukan pertanyaan tentang meditasi beberapa waktu yang lalu karena saya khawatir dengan fakta bahwa meditasi dapat menurunkan kemampuan pemrograman (dan kreatif) saya.

Saya baru saja memulai pelatihan metode Jon Kabat-Zinn , jadi masih terlalu dini bagi saya untuk berbagi dengan Anda pengalaman yang luas, tetapi dari beberapa yang saya pelajari sejauh ini saya bisa memberi tahu Anda ini mungkin sesuatu yang ingin Anda lakukan.

Komunitas
sumber
+1 Meskipun saya benci bahwa ada buku dan "teori" keseluruhan tentang jumlah yang masuk akal pada suatu masalah, GTD tentu saja memiliki kaki.
Orbling
1
@Orbling: oh saya setuju dengan Anda tentang hal itu. Tetapi seperti dalam kebanyakan buku ada omong kosong dan nilai. Apa itu omong kosong dan nilainya tergantung pada siapa yang membaca buku. Masalah dengan GTD adalah bahwa itu sangat kuat, dapat menghancurkan Anda jika Anda tidak meluangkan waktu untuk mengurangi input Anda alih-alih memfokuskan diri Anda dalam mengelola terlepas dari ukurannya. Itu kesalahan saya;)
Masalah yang saya miliki dalam hidup saya adalah bahwa ada begitu banyak masukan, dan banyak yang harus dilakukan, bahwa saya tidak akan punya waktu untuk menerapkan prosedur semacam itu. Padahal saya pasti bisa melihat nilai di dalamnya.
Orbling
1
@Orbling: Saya pikir itulah kuncinya. Memfilter input Anda adalah teknik produktivitas terbaik, di atas Covey atau GTD. Perlu mental yang sangat kuat.
Saya merasa perlu orang tambahan untuk menyelesaikan tugas yang Anda filter, lol.
Orbling
2

Saya selalu percaya insinyur yang baik dilahirkan, bukan dibuat.

Anda perlu pola pikir untuk itu, pikiran logis, analitis, deduktif, dikombinasikan dengan keuletan dan keingintahuan yang diperlukan untuk mendapatkan gambaran dan pandangan struktural dari masalah secara efisien dan cepat berjalan dari A ke B, mengarahkan pikiran Anda melalui solusinya.

Ada banyak penelitian yang menunjukkan keterampilan ini sangat didorong oleh paparan awal yang baik untuk hal-hal seperti itu, musik juga membantu. Setelah titik waktu tertentu, peta mental Anda sangat sulit. Bukan dalam hal apa yang Anda pikirkan, tetapi bagaimana Anda berpikir.

Bisakah Anda belajar berpikir sebagai orang dewasa? Yah Anda tentu bisa diajari teknik untuk memecahkan masalah, tetapi kemudian Anda memiliki algoritma untuk diikuti, Anda bisa menjadi "robot yang sangat cepat" seperti yang Anda katakan dengan fasih. Pemahaman intuitif mungkin bawaan.

Ini tidak terbatas pada profesi kita, banyak wajan didominasi oleh keterampilan bawaan, bukan respons yang diperoleh. Orang mungkin tidak ingin itu benar, tetapi kemungkinan besar memang demikian.

Orbling
sumber
2

Temukan forum online untuk sesuatu yang Anda sukai. Sesuatu yang memiliki semacam komunitas. Lebih disukai tidak pemrograman - forum pemrograman biasanya lebih berorientasi pada solusi daripada berorientasi pada diskusi. Mengambil sikap. Pertahankan. Gunakan argumen. Anda juga dapat membuat blog, tetapi memiliki lawan lebih baik. Intinya adalah memiliki komunikasi yang bermakna dan tertulis tentang sesuatu dengan seseorang. Tempat Anda bertukar potongan teks yang agak lebih besar.

Anda akan belajar mengomunikasikan ide-ide Anda dan membantahnya. Karena Anda harus mempertahankan pandangan Anda, Anda harus mendukung mereka dengan fakta. Anda harus memikirkan sesuatu, mengartikulasikan posisi Anda, dan mendukungnya; bahkan mungkin mengubahnya.

Setelah itu, ambil kemampuan itu untuk menganalisis masalah dan mensintesis opini dan menerapkannya pada apa pun. Bahkan pemrograman.

Domchi
sumber
Saya harus mengatakan, itu salah satu cara untuk berlatih berpikir. Bukan satu-satunya.
Domchi
2

Satu hal yang saya pikirkan adalah bahwa seseorang perlu melihat sesuatu sebagai sistem, dan semua sistem saling terkait. Setiap orang di alam semesta. Manusia, planet-planet, galaksi, tanaman, sinar matahari, fotosintesis, serangga, batu, lautan, semua sistem yang saling berinteraksi. Demikian juga, dalam waktu, siklus: kelahiran, pertumbuhan, pembusukan, kematian, serangga, orang, peradaban, pegunungan, sistem bintang. Perjuangan tanpa akhir untuk energi. Semua sistem.

Ini adalah Studi Kehidupan dan Alam dalam pengertian utama Studi. Lihat semua hal terkait, lihat semua hal berinteraksi. Berkonsentrasi pada ini ketika Anda menyaksikan matahari terbenam dan merasakan kedalaman kekuatan gravitasi yang memutar kita di sekitar Matahari, menarik kita ke permukaan planet, dan sinar matahari yang surut yang memerah sebelum memasuki retina Anda pada 300.000.000 meter per detik dan membuat gambar di otak primata Anda.

Ketika Anda mulai memikirkan hal itu, tentang bagaimana semuanya terkait, tentang bagaimana harga emas dan tenaga kerja budak dan badai di seluruh Pasifik dan kompleks industri di Jepang semuanya terkait, dan Anda meluangkan waktu, benar-benar meluangkan waktu untuk duduk dan pikirkan semua ini, maka "otot" berpikir Anda akan benar-benar lentur dan tumbuh.

Sekarang, banyak dari itu akan berada di bawah ambang ekspresi, tetapi jangan biarkan itu menghentikan Anda. Otak Anda lebih kuat daripada komputer paling kuat. Mendorongnya. Saya pikir tidak mungkin untuk melakukan overclock.

Saya teringat akan gambar hitam putih yang menunjukkan albert Einstein duduk di kursi taman di pantai sambil memandangi lautan. Tulisan itu berbunyi, "Di sini duduk Albert Einstein. Dengan otaknya."

Tantangan berikutnya adalah untuk dapat mengomunikasikan kompleksitas dan saling ketergantungan semua hal dengan cara yang sederhana. Ini akan memberi Anda sesuatu untuk dilakukan sampai Anda sangat tua.

Christopher Mahan
sumber
2

Salah satu pendekatan adalah Praktek yang Disengaja .

Pengulangan sederhana tidak mengarah pada perolehan keterampilan - Anda harus mawas diri, mengevaluasi kinerja Anda, mengidentifikasi cara untuk melakukan hal-hal yang lebih baik.

Sebuah ilustrasi: Seorang kerabat dekat saya berkompetisi dalam olahraga menembak pistol. Selama pelatihan, banyak konsentrasi terus meninjau setiap tembakan, fokus pada langkah-langkah yang berjalan dengan benar. Counter secara intuitif, tidak banyak fokus masuk ke bidikan buruk, karena memutar ulang (berlatih) kesalahan memperkuatnya.

Cukup menembakkan 100 tembakan ke bawah jangkauan tidak menghasilkan apa-apa. Praktek yang disengaja menembakkan 20 tembakan akan memperkuat kebiasaan baik dan menghasilkan kinerja yang lebih baik.

Hal yang sama berlaku untuk pemrograman - pikirkan apa yang Anda lakukan. Jangan lakukan itu secara bulanan, mingguan, atau harian - lakukan momen demi momen, aksi demi aksi.

  • Mengapa cacat itu terjadi pada kode saya?
  • Bagaimana saya bisa menghindari membuat cacat itu?
  • Bagaimana saya bisa menemukan solusinya lebih cepat?
  • Asumsi saya yang mana yang salah?
  • Apakah saya meminta bantuan dengan cukup cepat? terlalu cepat?
  • Pernahkah saya melakukan kesalahan itu sebelumnya?
  • Apakah cacat ini terisolasi, atau bagian dari suatu pola?
  • Apakah ada cacat desain yang mendasarinya?
  • Jika demikian, dapatkah saya melakukan sesuatu tentang itu?

Dan seterusnya ...

Bevan
sumber
Poin hebat, lagi-lagi semua ini datang dengan waktu / pengalaman
farinspace
1
@farinspace, hanya jika Anda meluangkan waktu untuk mengevaluasi dan belajar setelah setiap iterasi.
1

Pergi menyodok sesuatu yang Anda cintai sampai Anda menemukan keunggulan.

Napas dalam,

Langkah selesai...

...

... Ceritakan kepada orang lain apa yang Anda temukan.

Paddy3118
sumber
1

Jadi kamu mau berpikir

Banyak dari sebagian besar saran bagus dari poster lain tentang cara berpikir atau cara belajar berpikir: aliran, perhatian, matematika, gairah, latihan ... jadi saya tidak akan pergi ke sana, tertutupi tanah.

Tapi tidak ada yang tahu mengapa. Apa tujuannya?

Secara pribadi saya telah memahami bahwa sebelum Anda dapat berpikir Anda perlu tahu mengapa.
Satu-satunya hal terbaik untuk dilakukan adalah mendengarkan dan melihat. (Saya menganggap keduanya sebagai satu unit, Anda tidak dapat memisahkannya)

Satu-satunya cara untuk menjadi lebih baik dalam pemrograman, apakah itu mengumpulkan persyaratan, mengubah persyaratan itu menjadi spesifikasi sistem yang terperinci, mencocokkannya dengan dokumen desain, menerapkan kode, men-debug untuk kehidupan Anda, apakah Anda melewati salah satu atau semua tahapan itu, apakah Anda memiliki lima menit untuk menemukan solusi atau 20 tahun, Anda perlu mendengarkan dan mencari.

Dengarkan apa yang diinginkan pengguna, dengarkan apa yang pengguna katakan telah terjadi, dengarkan orang yang memberi tahu Anda bahwa mereka melihat. Mendengarkan. Dengarkan bahkan jika itu tidak masuk akal. Dengarkan bahkan jika Anda yakin mereka sangat salah. Dengarkan dan jangan menilai.

Cari petunjuk, bukan dengan mencari tetapi dengan membuka mata Anda. Lihatlah kenyataan. Anda tidak dapat mulai mencari jawaban sebelum melihat tempat kejadian perkara. Anda tidak dapat menemukan solusi sampai Anda membuktikan cacatnya.

Satu contoh dari pengalaman saya(pada resolusi bug, tetapi bisa disesuaikan dengan apa pun juga). Untuk alasan yang jelas (legal dan sebaliknya) saya akan menyimpan detail menarik dari ini. Pada sistem yang kritis terhadap keselamatan, seorang operator melaporkan cacat serius. Beberapa perangkat pelacakan geografis benar-benar kehilangan pelacakan ketika 'seharusnya' tidak memiliki, dengan dampak potensial pada kehidupan (ini 'seharusnya' adalah kesalahan nyata dan menghentikan penyelidikan kami terlalu lama). Untungnya, walaupun ini ditemukan berminggu-minggu kemudian hampir secara kebetulan, karena ada sistem lain yang beroperasi di lokasi yang jauh di mana operator lain datang untuk membuktikan pelacakan tidak hilang pada sistem itu. Ini membuat kami berpikir lagi. Pemasok perangkat lunak utama kami tidak mempercayai kami sedetik pun, jadi kami harus keluar dan membuktikan masalahnya. Satu-satunya cara adalah melalui korupsi: membangun simulasi untuk mereplikasi situasi operasional yang tepat. Kami harus benar-benar merekam bukti agar pemasok mempercayai kami. Akhirnya simulasi menghasilkan informasi di luar harapan kami dan menuntun kami untuk memahami seluruh masalah. Tidak butuh waktu lama untuk memperbaikinya.

Satu-satunya cara yang kami lalui sampai akhir adalah dengan menghubungkan secara logis satu sistem jarak jauh dengan yang lain melakukan pekerjaan yang serupa tetapi tidak dengan pekerjaan yang sama. Itulah yang mencari petunjuk (Lihat). Ini hanya mungkin dengan memercayai laporan satu kali dan tidak mengabaikannya sebagai kesalahan acak dalam sistem (Dengar), dan kemudian mendengar lagi laporan kedua yang bertentangan dengan yang pertama (Dengar).

Jadi, ketika Anda memiliki petunjuk yang tepat (setelah mendengarkan dan melihat), menentukan area masalah, memahami akar permasalahan atau prinsip-prinsip kunci, maka Anda dapat memikirkan solusi menuju pemahaman lebih lanjut terlebih dahulu (coba-coba, simulasi, demonstrasi, bukti konsep, mock-up, alpha, versi beta), dan akhirnya menawarkan solusi yang solid (yang terkadang dapat lebih ditingkatkan setelah beberapa operasi kehidupan nyata).

Untuk dapat mendengarkan dan berpenampilan seperti itu dibutuhkan pikiran terbuka, kepercayaan, dan pengabdian mutlak pada tujuan Anda. Ini adalah bahan bakar yang perlu Anda pikirkan, atau lebih tepatnya untuk berpikir Anda untuk fokus pada target yang tepat (seringkali masalahnya bukan ketidakmampuan untuk berpikir tetapi kurangnya target yang didefinisikan dengan baik untuk melatih pikiran Anda).

pindahkan
sumber
Memberi +1 untuk jawaban Anda, mempelajari domain masalah Anda, dan mendengarkan pengguna adalah penting. Meskipun -1 untuk komentar "Ya benar", jadi tidak ada perubahan.
Orbling
@Orbling: Ok, Anda benar, itu sedikit berlebihan. Komentar dihapus. Saya tidak berpikir bakat bawaan itu benar, tetapi tidak perlu menyebutkannya.
asoundmove
Baiklah jika Anda memiliki -1 jawaban saya sebagai gantinya, saya akan menandai semua jawaban Anda sama saja, tetapi itu mencegahnya, diperbaiki sekarang. Baik untuk mengatakan itu salah jika Anda tidak setuju dengan apa yang saya katakan.
Orbling
@Orbling, nah saya tidak suka memilih -1 untuk siapa pun, saya lebih suka melanjutkan ... Hanya skenario ekstrem yang menjamin -1, hanya tidak setuju tidak.
asoundmove
Saya setuju dengan Anda di situs lain, karena mereka benar / salah di utama. Programmer.SE berbeda dari yang lain karena bersifat subyektif, sehingga pemungutan suara pada dasarnya adalah kesepakatan, ketidaksepakatan. Apakah Anda pikir itu bermanfaat atau tidak membantu. Saya hanya memberikan suara negatif jika saya sangat tidak setuju dengan seseorang. Pada saat penulisan, 2,6% suara saya adalah downvotes. Pendapat setelah semua harus ditantang.
Orbling
1

Saya pikir Anda perlu membuat perbedaan antara berbagai jenis pemikiran.

Berpikir kreatif - bagaimana memunculkan ide-ide baru, solusi inovatif dan hasil yang tidak terduga. Ada seluruh ilmu di balik ini, lihat Edward de Bono, teknik kreativitas dll. Tidak banyak programmer melihat ke daerah ini.

Pemikiran analitis - maksud saya proses ilmiah ini. Lihatlah input, output, ukur apa yang penting, sampai pada kesimpulan logis. Sebagian besar pengembang akrab dengan teknik ilmiah tetapi kemudian tidak pernah benar-benar menggunakannya. Lakukan itu!

Berpikir kritis - saya pikir ini lebih filosofi. Mundur dan lihat gambaran yang lebih besar, tinjau asumsi Anda, apakah Anda benar-benar melakukan apa yang Anda nilai-nilai Anda? Mempelajari filsafat ada banyak penulis dan gagasan hebat di luar sana.

Richard
sumber
0

Matematika mengajarkan seseorang bagaimana cara berpikir. Aplikasi membutuhkan kreativitas dan pengalaman.

Saya menolak untuk percaya bahwa untuk menjadi hebat di programer, kami hanya menyerahkan diri kita pada perilaku seperti spons seumur hidup

Wawasan yang bagus. Secara kasar dinyatakan, persyaratan untuk "kebesaran" tergantung pada definisi pribadi Anda tentang "kebesaran" ... dan telah berubah seiring waktu. Hari ini, keberhasilan proyek adalah tentang dapat menyatukan konsep dengan cepat dan tanpa mempelajari semua detail yang rumit. Keberhasilan pribadi dapat didefinisikan sebagai menguasai C # seperti Jon Skeet.

Baca kode di tempat kerja . Coders jauh lebih berpengalaman daripada saya membahas ini secara rinci.

P.Brian.Mackey
sumber
0

Berusahalah menerapkan gagasan dan konsep dari bidang yang tampaknya tidak terkait. Bagi saya, kecemerlangan iPod bukanlah teknik di balik pembuatan pemutar MP3 yang hebat, tetapi membantu memecahkan masalah besar yang dialami industri hiburan musik dengan musik bajakan dan model CD / Album dalam menjual musik. Jobs mungkin menerapkan lebih banyak dari apa yang dia pelajari di Pixar dalam berurusan dengan industri film. Dia tahu apa masalah sebenarnya.

JeffO
sumber