Hindari menjadi programmer "Theoretician"

Saya telah menemukan artikel ini di beberapa posting di SO. Saya menemukan diri saya jatuh ke dalam arketipe ke-6; "Theoretician".

Ini mendefinisikan "Theoretician" sebagai:

Theoretician tahu semua yang perlu diketahui tentang pemrograman. Dia dapat menghabiskan empat jam mengajar tentang sejarah bahasa pemrograman yang tidak jelas atau memberikan bukti bagaimana kode yang Anda tulis kurang dari optimal sempurna dan mungkin membutuhkan tiga nanodetik tambahan untuk dijalankan. Masalahnya adalah, The Theoretician tidak tahu apa-apa tentang pengembangan perangkat lunak. Ketika Theoretician menulis kode, itu sangat "elegan" sehingga manusia biasa tidak bisa memahaminya. Teknik favoritnya adalah rekursi, dan setiap blok kode disesuaikan dengan maksimal, dengan mengorbankan ketepatan waktu dan keterbacaan.

Theoretician juga mudah terganggu. Tugas sederhana yang seharusnya memakan waktu satu jam akan memakan waktu tiga bulan bagi para teoretikus, karena mereka memutuskan bahwa alat yang ada tidak cukup dan mereka harus membangun alat baru untuk membangun perpustakaan baru untuk membangun sistem baru yang memenuhi standar tinggi mereka. Theoretician dapat diubah menjadi salah satu pemain terbaik Anda, jika Anda bisa membuatnya bermain dalam batas-batas proyek itu sendiri dan berhenti menghabiskan waktu bekerja di Algoritma Penyortiran Pamungkas.

Bahkan ketika mengerjakan apa yang seharusnya menjadi proyek sederhana, saya cenderung macet dan tidak bisa mencoba merekayasa semuanya dari awal (Ini mungkin menjelaskan mengapa saya membuang waktu sekitar 2 tahun mencoba membuat sistem operasi dari awal. Tetapi bahkan saya melihat itu akhirnya tidak ada gunanya).

Apa yang bisa membantu saya menghindari melakukan ini? Dan tetap berpegang pada prinsip KISS?

Terima kasih

Sebagai seorang ahli teori, saya sendiri dapat mengatakan kepada Anda bahwa bekerja di sebuah toko Agile akan dengan cepat dan pasti menyembuhkan semua kecenderungan semacam itu. Secara khusus, operasi Pemrograman eXtreme, dengan pemrograman berpasangan (sering berputar secara ideal), pengembangan yang digerakkan oleh tes, tinju waktu dan sprint terikat, segera menampilkan pekerjaan Anda untuk dilihat oleh semua kolega Anda, dan mengharuskan Anda untuk membuka dan berkolaborasi pada basis menit demi menit. Ini adalah perubahan besar dari tugas-tugas terpisah di lingkungan kantor yang terisolasi di mana gaya kerja Theoretician berkembang. Dibutuhkan kejujuran total dan integritas total, karena setiap orang secara aktif bergantung pada orang lain secara terus menerus.

Saya masih menghargai pusar-pandangan saya, tetapi saya harus memanjakannya di rumah, atau pada saat-saat langka ketika saya dapat bekerja pada proyek di sisi yang bukan bagian dari pengembangan jalur utama.

1. Memiliki tujuan untuk apa yang seharusnya Anda kembangkan.

2. Persempit tujuan itu untuk sesuatu yang dapat disampaikan dalam waktu dekat.

3. Kemudian fokus pada tujuan-tujuan itu, menghilangkan semua pertimbangan lainnya. Tidak ada latar belakang Tidak ada sejarah Tidak ada ekstensi. Tidak ada yang umum atau abstrak.

4. Kemudian mempersempit mereka lebih jauh ke dalam paling tidak Anda bisa melakukan itu akan dikirimkan. Tidak baik. Tidak fleksibel. Tidak bisa dirawat. Hanya Dapat Diterima.

5. Kemudian memprioritaskan ke dalam minimum absolut yang diperlukan untuk mencapai paling tidak yang dapat Anda lakukan. Intinya adalah memilih tanggal dalam waktu sekitar satu minggu dan membangun menuju tanggal itu. Jika Anda tidak dapat mengirimkan sesuatu dalam seminggu. Sempit. Fokus. Memangkas. Mengurangi.

6. Lalu hilangkan bulu. Anda hanya punya satu minggu. Terus potong.

7. Kemudian fokus hanya pada implementasi yang dikurangi yang akan dilakukan sedini mungkin. Idealnya, kurang dari seminggu, sehingga Anda punya waktu untuk menulis dokumentasi.

Saya telah bekerja dengan para ahli teori. Saya menganggap "figuran" sebagai alasan untuk benar-benar melakukan sesuatu yang mungkin dicap gagal.

Melakukan - dan gagal - itu sulit. Berbicara tentang melakukan sesuatu lebih mudah daripada melakukan sesuatu. Banyak penelitian dan pemikiran adalah cara untuk menghindari melakukan hal yang salah dan kemudian mengerjakannya kembali setelah mengetahui bahwa pengguna berbohong.

Letakkan kode di depan mereka. Mereka akan menyebut kode itu gagal. Itu terjadi. Tetapi dalam proses gagal Anda akan belajar apa persyaratan sebenarnya. Dan Anda akan belajar bahwa mereka berbohong.

Saya tidak yakin ini hal yang buruk. Jelas Anda harus produktif atau Anda tidak akan melakukan pekerjaan Anda, tetapi memiliki minat di bidangnya, menjadi mahasiswa seni, sehingga untuk berbicara bukanlah hal yang buruk.

Saya akan bermain untuk kekuatan Anda, mencari peluang di mana gaya dan preferensi Anda adalah keuntungan.

Untuk memastikan Anda tetap produktif saat terlibat dalam penulisan kerangka kerja MVC di Erlang (atau apa pun yang menurut Anda menarik), Anda mungkin harus mengatur waktu pekerjaan Anda yang lebih esoteris, misalnya, satu jam sehari. Untuk sisa hari itu hanya fokus pada pekerjaan kasar dan menyelesaikan pekerjaan. Ketika Anda melihat sesuatu yang menarik yang akan mengalihkan perhatian Anda atau membuat catatan tetapi melanjutkan, kemudian kembali ke sana di slot waktu yang ditentukan.

Secara pribadi saya punya rim URL yang terlihat menarik, dan setumpuk buku perpustakaan juga. Saya mungkin mendapatkan sekitar 10% dari URL itu pada akhirnya, dan mungkin membaca 50% dari buku pada akhirnya, tetapi saya masih menyelesaikan pekerjaan harian juga.

Saya sendiri pernah mengalami masalah ini. Dua teknik telah membantu:

1. Gunakan teknik Pomodoro, atau teknik manajemen waktu lainnya di mana Anda menetapkan urutan tujuan jangka pendek. Ketika Anda harus mencari tahu apa yang dapat Anda capai dalam 25 menit berikutnya, itu membuat Anda fokus pada pekerjaan yang bermanfaat.
2. Pengembangan berbasis tes. Jika Anda harus menulis tes konkret sebelum Anda menulis kode apa pun, itu meminimalkan lamunan. (Tidak ada cara untuk menulis tes untuk "elegan".) Setelah Anda mendapatkan sesuatu yang berfungsi, Anda mungkin menghabiskan lebih banyak waktu daripada yang seharusnya Anda refactoring itu, tetapi setidaknya Anda akan bekerja pada kode nyata daripada ideal imajiner.

Jangan terlalu banyak menyalahkan diri sendiri. Lebih mudah untuk mendapatkan teoretikus untuk fokus dan melakukan pekerjaan yang bermanfaat daripada membuat orang-orang yang tidak peduli memperluas wawasan mereka.

Hindari stackoverflow.com . Jangan salah paham - Saya adalah penggemar besar - tapi begitu dan forum pemrograman berorientasi lain membuat sempurna musuh yang baik . Setelah beberapa saat, Anda mungkin mulai merasa seperti ribuan orang pintar melihat dari balik bahu Anda dan tidak ada yang Anda tulis cukup baik. Dapatkan saja sesuatu yang berfungsi dan cobalah membuatnya dapat dimengerti. Anda selalu dapat mengunjungi kembali jika perlu diperbaiki.

Selain itu, hindari artikel seperti yang Anda tautkan. Apakah Anda benar-benar percaya bahwa ada sepuluh jenis programmer? Atau siapa pun yang Anda kenal cocok sepenuhnya ke dalam salah satu kategori yang dijelaskan? Artikel seperti ini memiliki daya tarik tertentu karena mengandung sedikit kebenaran - Anda dapat melihat diri Anda sendiri dan / atau beberapa rekan kerja Anda dalam beberapa stereotip. Tetapi kategori-kategori tersebut menampung air sebanyak tanda astrologi. Coba ini lain kali saat Anda berada di mixer pasca-konferensi: "Hai, saya seorang Koboi Code! Apa tipemu?"

Itu bukan untuk mengatakan bahwa pertanyaan Anda tidak valid - jika Anda terlalu banyak berpikir, ada baiknya untuk belajar bagaimana menghindari kecenderungan itu. Tetapi jangan biarkan punditry ini membujuk Anda untuk menjadi pigeonholing sendiri.

Ada satu pedoman sederhana yang, ketika sepenuhnya dibongkar, menjelaskan secara penuh bagaimana menghindari skenario ini.

Lakukan hal paling sederhana yang mungkin bisa berhasil.

- Kent Beck

Saya pikir salah satu cara untuk menjaga kepala Anda keluar dari awan adalah dengan memaksa diri Anda untuk menulis aplikasi yang sebenarnya dari awal hingga akhir, selain menulis API atau kerangka kerja teoritis Anda. Coba letakkan kotak waktu di sekitar sesuatu, dan coba "selesaikan" dalam waktu itu. Kerangka penulisan membutuhkan pemahaman yang baik tentang pola desain dan arsitektur, tetapi saya telah menemukan bahwa menulis aplikasi lengkap dalam kotak waktu yang tetap membutuhkan keterampilan yang berbeda dari menulis kerangka kerja yang dirancang dengan sangat baik.

Jika Anda ingin menyelesaikan aplikasi, pada titik tertentu Anda harus turun ke bumi dan menyelesaikannya. Ini mungkin memerlukan pengorbanan pada desain, atau dipaksa untuk mengimplementasikan fitur dengan cara yang tidak Anda sukai, karena beberapa jenis kendala. Aku seperti dirimu - cenderung menulis dan menulis ulang jutaan kali, tetapi jika aku dihadapkan dengan tugas-tugas yang harus dilakukan dalam jangka waktu tertentu, aku menemukan bahwa aku memilih pertempuran, dan hanya memperbaiki hal terpenting.

Sederhana:

1. Bersikap pragmatis .

Sisi berlawanan dari Theorician (yang memiliki kelebihan pada sisi informasi / pengetahuan dari domain pemrograman) adalah Pragmatis.

Untuk menerapkan KISS, KERING, SOC dan cara berpikir lain, seperti yang dijelaskan dalam jawaban ini , berarti menjadi pragmatis.

Anda juga bisa belajar pragmatis dengan membaca buku ini:

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

Jangan lupa bahwa teori dan praktik bekerja bersama, tidak sendirian. Tanpa banyak latihan, pengetahuan Anda bukanlah apa-apa. Tanpa banyak pengetahuan Anda tidak dapat meningkatkan latihan Anda dengan cepat.

Jadi, banyak berlatih. Dan belajar banyak. Tapi jangan biarkan yang satu mengalahkan yang lain.

Dalam proyek Anda, tetapkan tenggat waktu. Tetap pada itu. Kemudian pikirkan secara pragmatis tentang cara menyelesaikan proyek Anda sebelum batas waktu itu. (baca buku, sungguh) Lalu mulai coding, mulailah membaca apa yang perlu Anda ketahui, beralih dari membaca ke coding dan membatasi atau waktu membaca Anda.

Hrm ... Mungkin mungkin mencoba mendapatkan pekerjaan di bisnis yang mengharuskan Anda untuk menulis aplikasi di bawah timeline. Saya akan mengatakan untuk diri saya sendiri, bahwa saya mungkin akan menjadi seorang teoretikus sejauh mungkin, setidaknya di tempat kerja. Melakukan jenis pekerjaan itu memiliki tempat dan waktu dan penting untuk mengembangkan diri Anda. Namun, sementara saya menghargai kemampuan semacam itu ia tidak memiliki tempat di dunia bisnis, terutama di mana saya bekerja. Lingkungan pengembangan yang serba cepat di mana Anda kadang-kadang menulis aplikasi dalam beberapa minggu dan klien menginginkannya kemarin! Saya telah diberkati dengan pengembang yang luar biasa dan butuh waktu untuk membuat semua orang bekerja sebagai sebuah tim.

Saya memiliki seorang pria yang secemerlang mungkin, tetapi seperti Anda, selalu harus memeras sedikit terakhir dari kode-nya bahkan ketika itu berfungsi dengan baik, bahkan ke titik di mana ia mulai menulis kontrol kustom yang pada dasarnya adalah sama seperti yang disediakan oleh lingkungan. Itu semua sangat keren tetapi buang-buang waktu ketika kami harus menyelesaikan masalah tepat waktu. Sering kali proyek sampingan ini mendukung tim dan akhirnya dia mulai merasakan tekanan dari yang lain dan dia berhasil. Saya akan menyarankan untuk mulai bekerja dalam lingkungan tim dengan beberapa pengembang bagus lainnya yang harus mendorong produk keluar. Selalu ada waktu kemudian untuk memperbaiki dan mengulang hal-hal atau menulis MergeSort yang paling keren; tetapi kadang-kadang Anda harus membawa produk ke titik di mana ia bekerja dan membawanya ke klien.

Tidak ada yang salah dengan menjadi 'ahli teori' dalam arti kata yang biasa. Memiliki latar belakang pengetahuan dan mampu memahami penelitian CS terbaru adalah kemampuan hebat untuk dimiliki, karena merupakan tambang emas dari ide-ide bagus dan orisinal.

'Pertanyaan sebenarnya' di sini lebih jelas di bagian akhir posting. Ketahuilah tujuan proyek tertentu dan bekerjalah untuk mencapai tujuan itu, bukan tujuan lain. Ini benar-benar hanya masalah disiplin diri dalam kasus ini. Lihat jawaban S. Lott untuk lebih lanjut tentang ini :).

Fokuskan kembali pikiran Anda dari pemrograman dan bahkan mencapai hal-hal hingga memberikan perangkat lunak yang berfungsi. Ini menetapkan prioritas Anda.

Cara mencapai ini adalah cerita lain. Cara terbaik adalah menyusun beberapa proyek dan menjalani semua langkah untuk meluncurkannya ke dalam produksi. Setelah itu Anda akan memiliki pola pikir yang berbeda dari sebelumnya.

Terima kasih untuk posting ini. Itu membuat pekerjaan saya lebih bernilai saat ini. Saya merasakan hal yang sama memiliki pendidikan dalam Arsitektur Informasi yang bekerja sebagai Pengembang Perangkat Lunak. Seringkali saya menemukan diri saya berjuang dengan "tempat untuk mengubah sesuatu" daripada "apa yang harus diubah". Ada terlalu banyak hubungan, terlalu banyak hal pintar dan generik di sekitar sehingga butuh waktu terlalu lama untuk mengetahui bagaimana hal itu bekerja.

Jadi saya mulai bertanya, dan bahkan lebih banyak pertanyaan sampai saya tahu BAGAIMANA dan DI MANA ini benar-benar dibangun. Dan saya beri tahu Anda - itu berhasil. Semakin banyak pertanyaan kebakaran, semakin tidak penting untuk menjaga arsitektur asli, dan akhirnya kembali ke dasar

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!");
}

Minta atasan Anda untuk mendapatkan mentor, dan lakukan seperti yang dikatakan mentor.

Bagian yang sulit adalah menjaga fokus, dan mengakui bahwa "hei, mari kita tulis ulang sistem operasi" tidak akan mendapat manfaat besar untuk menyelesaikan tugas yang telah diberikan kepada Anda (itulah sebabnya manajer proyek tidak akan melakukan).

Juga minta mentor untuk meninjau SEMUA desain Anda sebelum pengkodean, dan kode aktual setelah pengkodean. Ini akan membantu Anda tetap fokus pada apa yang perlu dilakukan.

Saya memiliki godaan yang sama untuk merekayasa hal-hal berlebihan, dan diperlukan disiplin diri dan organisasi untuk melewatinya. Saat menulis kode untuk orang lain, inilah cara saya melakukannya:

1. Saat memulai tugas yang terpisah, luangkan beberapa menit untuk memikirkan apa yang benar-benar diperlukan sejauh fungsionalitas, kualitas, tanggal pengiriman, dll.
2. Luangkan lebih banyak waktu untuk merencanakan bagaimana melakukannya , memecahnya menjadi sub-tugas, sub-tugas, dll., Dengan mengingat tujuan pelanggan kode.
3. Perkirakan waktu untuk setiap item , tambahkan hingga 50% untuk yang tidak diketahui. Jika suatu barang akan memakan waktu lebih dari empat jam, pilah lagi. (Jika saya melakukan proyek kuliah, saya akan menggunakan spreadsheet, tetapi sebagai konsultan dengan banyak klien, saya menggunakan sistem pelacakan masalah yang disebut Redmine.)
4. Yang paling penting: lakukan hanya barang-barang yang saya buat .

Tentu saja, banyak hal terjadi. Kadang-kadang saya merasa perlu melakukan lebih banyak hal - jadi saya memulai dari # 1. Kadang-kadang saya menemukan tugas akan memakan waktu lebih lama dari yang saya kira - mulai dari # 1. Kadang-kadang saya tahu sebelumnya bahwa desain saya akan membutuhkan lebih banyak rincian nanti - jadi saya merencanakan subtugas estimasi ulang di mana saya memulai kembali di # 1.

Semakin saya melakukan ini, semakin baik saya melakukannya. Disiplin diri adalah otot mental yang menguat dengan olahraga, dan saya juga meningkatkan dalam memperkirakan berapa lama hal akan terjadi dan membuat pertukaran teknis. Dan saya merasa terbantu untuk mengingat kutipan dari Jenderal Patton: "Rencana bagus yang dieksekusi dengan keras sekarang lebih baik daripada rencana sempurna yang dilaksanakan minggu depan."

Sebagai pengembang mandiri, alur kerja saya menggabungkan ini dengan aspek Agile, termasuk papan Kanban. Terkadang saya bersinggungan dengan garis singgung, tetapi saya mencoba membatasi penyimpangan menjadi beberapa jam seminggu, dan itu bekerja dengan cukup baik.

Jika Anda berencana untuk bekerja di industri swasta, sangat penting untuk mengendalikan dorongan "teoritikus". Programmer paling brilian yang saya kenal hidup di Silicon Valley, tetapi tidak memiliki pekerjaan selama bertahun-tahun karena dia memiliki reputasi untuk memberikan kode sempurna terlalu terlambat.