Ada pengembang, sebut saja dia John (saat ini dalam masa percobaan) di perusahaan (perusahaan yang cukup kecil sekitar 10 orang, 3 pengembang, salah satunya bekerja lama di perusahaan ini mengetahui proses bisnis sekitar dan dapat dianggap sebagai pemimpin tim) yang sama sekali tidak ingin menggunakan IDE (dia menggunakan editor teks).
Aplikasi yang dikerjakan tim ini adalah aplikasi Java ukuran sedang dengan tumpukan teknologi Spring Hibernate dan refactoring / menambahkan fitur baru untuk meluncurkan versi baru aplikasi itu dalam waktu dekat.
Kinerja John yang bekerja tanpa IDE pada aplikasi ini lebih rendah dari yang diinginkan, asumsi ketua tim (sebut saja dia Bill) adalah ini terjadi karena John tidak menggunakan IDE.
Bill mencoba membujuk John untuk menggunakan IDE, tetapi ide ini menemui banyak perlawanan dan alasan utamanya adalah "Saya ingin mengendalikan sepenuhnya apa yang saya lakukan, jadi saya perlu menulis semua kode sendiri".
Bagaimana Bill meyakinkan John untuk mencoba menggunakan IDE? (mengingat fakta bahwa Bill sudah melindungi John dari pemilik perusahaan beberapa keluhan tentang kinerja John)
Diperbarui: Bill memutuskan untuk mencoba dan meyakinkan John sekali lagi jika upaya itu tidak berhasil maka ia tidak akan mencoba memaksa John untuk menggunakan IDE dan lebih baik melihat apakah fitur yang dijanjikan oleh John dikirimkan tepat waktu atau tidak.
sumber
Jawaban:
Anda kurang lebih sudah menjawab pertanyaan:
Jadi, dia perlu dibuat sadar bahwa:
Kurangnya kemauan untuk beradaptasi dengan lingkungannya mungkin juga menjadi perhatian.
sumber
Bill harus memberi tahu John bahwa ia benar tentang memilih editor teks sederhana, tetapi sayangnya, dengan kerangka bahasa + seperti Java + Hibernate + Spring, ia perlu menggunakan IDE jika ia ingin menjadi efisien.
Saya agak seperti John. Saya tidak suka menggunakan IDE.
Ketika saya kode dalam ruby / python / bash / lisp, saya tidak menggunakan IDE.
Tetapi ketika saya berurusan dengan bahasa tingkat rendah / verbose seperti Java dan kerangka kerja yang membuat kode Anda sangat sulit untuk dijelajahi tanpa bantuan, saya menggunakan IDE. Itu juga benar jika saya tidak tahu bahasa / kerangka kerjanya dengan baik.
Katakan padanya bahwa jika ia ingin menjadi efisien dengan alat yang Anda gunakan, ia harus menggunakan IDE. Bill juga harus memasangkan program dengan John untuk menunjukkan kepadanya betapa efisiennya ia dengan IDE.
sumber
Saya pikir mendorong IDE, adalah ide yang buruk. Saya pikir memiliki daftar alat yang dapat digunakan orang, dan daripada membiarkan dia memilih apa yang dia gunakan, adalah solusi yang lebih terhormat.
Kemudian fokus pada kinerja masalah nyata dan produktivitas, berikan statistik nyata tentang bagaimana proyek tertentu telah mengambil terlalu banyak waktu.
Sama sekali tidak membiarkan fokus menjadi alat apa yang dia gunakan untuk kode, biarkan dia menemukan solusinya sendiri, selama tujuannya adalah produktivitas yang lebih baik.
Saya telah datang ke banyak perusahaan, 90% tidak peduli, selama mereka tidak harus membayar alat apa pun, 10% peduli, dan menuntut mereka menggunakan alat mereka.
Jika Anda menjadikan IDE sebagai fokus nyata dari diskusi Anda, Anda benar-benar tidak menghargai dia dan metodenya.
Alih-alih berfokus pada masalah kunci nyata yaitu produktivitas, kualitas, dan kinerja.
Saya sendiri, telah menggunakan editor teks selama lebih dari 6-7 tahun, dan tidak ada yang salah dengan kinerja saya.
Sebuah IDE dapat membantu, tetapi itu harus menjadi pilihan programmer untuk menggunakannya, selama itu tidak mempengaruhi kinerja.
Saya pribadi benci IDE tidak akan pernah menggunakan mereka, semakin banyak orang mendorong mereka ke saya, semakin saya merasa tidak dihargai. Saya tidak punya masalah dengan alat apa yang digunakan orang, tapi itu seperti agama dan penginjilan, mereka merasa perlu bahwa semua orang harus berpikir / melakukan segala sesuatu dengan cara yang mereka lakukan.
Dan itu adalah pendekatan yang sangat tidak profesional untuk apa masalah sebenarnya, produktivitasnya.
Jika dia memberikan pekerjaan berkualitas, dalam metodenya, siapa yang peduli alat apa yang dia gunakan? Selama itu bebas dari kesalahan, kualitas kerja, dan tepat waktu.
sumber
Saya tidak tahu bahwa kami telah mengkonfirmasi IDE adalah masalah John. Saya pikir Bill harus bekerja dengan John sebentar dan mengamatinya: Apa yang menurunkan produktivitasnya. Jika dia menghabiskan berjam-jam memformat kodenya dan mencoba untuk memindahkan atau mencari fungsi ... macam-macam yang disediakan IDE untuk Anda, maka Anda harus menunjukkan kepadanya seberapa cepat dia dapat menemukan fungsi yang diinginkannya dan memformat kodenya dengan IDE. Jika ini adalah frustrasi, saya yakin begitu dia melihat Anda memformat otomatis sebuah blok atau dengan cepat menemukan beberapa fungsi yang tidak jelas, dia akan melompat melalui atap dengan gembira.
Namun, jika efisiensi karena dia berselancar di google, atau kesulitan merumuskan idenya menjadi struktur pengkodean, sebuah IDE tidak akan membantunya. Dalam hal ini Anda perlu menindak disiplinnya, atau membantunya belajar memetakan ide-idenya menjadi aliran program sehingga ia dapat lebih efisien menyerang masalah
EDIT: Perwakilan saya terlalu rendah untuk berkomentar, jadi saya harus memposting di sini. Saya tidak setuju dengan orang-orang yang mengatakan "biarkan dia dipecat, maka dia akan belajar." Bagi sebagian orang ini berfungsi; kehilangan pekerjaan mengejutkan mereka dan mereka benar-benar bangun dan bugar. Yang lain akan berputar menjadi spiral penghancur diri yang biasanya berakhir dengan terapi atau kesejahteraan. Bill jelas peduli pada John atau dia tidak akan bertanya bagaimana membantunya, jadi saya pikir komentar dan jawaban tentang membiarkan dia dipecat jelas bukan yang dicari Bill.
sumber
Kegagalan adalah guru yang hebat. Bill dapat berhenti melindungi John dan membiarkannya berdiri dengan keputusannya sendiri. Jika John dipecat karena itu, mudah-mudahan itu akan membuatnya menjadi karyawan yang lebih baik untuk perusahaan berikutnya yang mempekerjakannya.
sumber
Anda dapat mencoba meyakinkannya bahwa jika dia memahami IDE dan apa fungsinya, dia tetap memegang kendali penuh.
Ini wortel.
Tongkatnya adalah bahwa dia dalam masa percobaan.
sumber
Saya harus mengatakan saya menggunakan dan IDE (aptana untuk javascript), dan saya benci itu, itu lambat dan melakukan hal-hal aneh dengan format. Saya beralih ke gvim dengan banyak alat baris perintah dan saya jauh lebih bahagia.
tentu saja aku tipe orang yang akan menulis generator kode di elisp untuk bersenang-senang.
sumber
Saya sulit percaya bahwa kinerja John ada hubungannya dengan editor yang ia gunakan. Di tempat kerja saya hampir semua orang menggunakan editor kode yang berbeda (Visual Studio, Source Insight, vim, SlickEdit ...) dan tidak ada korelasi yang terlihat antara editor / IDE dan kinerja kerja.
sumber
Jika ada IDE standar perusahaan, maka katakan saja kepadanya "IDE ini adalah standar perusahaan, GUNAKAN TI".
Jika tidak ada IDE standar perusahaan, dan keinginan baginya untuk menggunakan IDE semata-mata demi meningkatkan kinerja, maka itu adalah:
Jika Anda benar-benar ingin dia menggunakan IDE, saya pikir pendekatan terbaik adalah memberi tahu dia bahwa kinerjanya tidak normal, kemudian tunjukkan kepadanya bagaimana penggunaan IDE dapat membantu meningkatkan kinerja itu. Menunjukkan dengan contoh adalah motivator yang jauh lebih baik menurut saya.
Yang sedang berkata, saya pikir anggapan itu salah di sini. Kebanyakan pengembang yang layak dapat menjadi produktif di hampir semua lingkungan pengembangan. Jika ia tidak melakukan sesuai harapan, maka mungkin penyebab utama adalah pengembang, bukan IDE.
sumber
Jika Bill, meskipun posisinya sebagai pemimpin tim, tidak bisa membuat John menggunakan IDE ketika Bill ingin semua orang menggunakannya, ada sesuatu yang salah dengan perusahaan karena pemimpin tim tidak memiliki wewenang yang cukup.
Dan tidak, tergantung pada pekerjaan yang diberikan kepada seseorang, orang itu bisa sama produktifnya dengan tanpa IDE sama dengan satu, tergantung pada alat yang digunakan, pengalaman orang dengan alat-alat itu, dan kompetensi keseluruhannya (dan lingkungan keseluruhan, jika John harus menarik setiap sumber dari server aplikasi, memuatnya ke dalam IDE-nya, mengeditnya, mengunggahnya lagi, dll. dia jauh lebih cepat hanya mengedit langsung di server aplikasi menggunakan katakanlah VI (dengan asumsi dia tahu editor itu dengan baik) .
sumber
Tidak menggunakan IDE sangat baik karena dia akan belajar banyak. Tetapi seharusnya tidak pada biaya proyek. Dia harus menggunakannya ketika dia pikir dia bisa menyelesaikan pekerjaan tanpa memengaruhi timeline.
Saya menyarankan agar dia melakukan keduanya, sehingga dia dapat belajar dengan cepat dan pada saat yang sama tidak terlibat masalah.
Setelah semua yang Anda butuhkan roti untuk bertahan hidup maka hanya Anda yang bisa berpikir untuk menjadi pembangun tubuh.
sumber
Saya pikir nilai utama dari setiap IDE bukanlah bahwa itu adalah editor, tetapi itu adalah debugger. Ada beberapa yang tidak mendapatkan konsep debugger. Mereka melakukan debug dengan pernyataan cetak.
Jika fitur lain yang membuat IDE lebih produktif, seperti intellisense atau versi control hookup, saya bisa setuju dengan John, karena berbagai alasan kita bisa berdebat.
Tetapi debugging dengan pernyataan cetak saya merasa sulit untuk grok (meskipun saya terbiasa melakukannya).
sumber
Dengar, ada orang yang menggunakan barang, ada orang lain yang menggunakan barang lain. Saya suka IDE dan editor teks, mereka hanya 2 jenis aplikasi yang berbeda, tetapi pada akhirnya, tugas yang dilakukan benar-benar sama.
Itu hanya Jeruk dan Apel, akhir baris, jika Anda ingin memecatnya dengan alasan "dia menggunakan editor teks" atau "dia terlalu lambat, KARENA ia menggunakan editor teks", lanjutkan, tetapi apakah Anda benar-benar harus berkonspirasi untuk beberapa strategi tentang bagaimana Anda dapat meyakinkannya?
Anda tahu, kebebasan bukan tentang "hanya yang terbaik yang akan menang", ini tentang "Melakukan apa yang saya inginkan".
Bukan karena Anda hidup dalam demokrasi sehingga Anda harus memaksakan praktik mayoritas. Hampir terlihat seperti semacam penganiayaan
sumber