Meyakinkan pengembang untuk menggunakan IDE [tertutup]


8

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.


5
Lucu. Saya kira dia ingin merasakan sakit. Saya ingat saya menggunakan kode COBOL dalam editor teks. Ketika saya mengalami IDE pertama saya, saya pikir saya curang. Mungkin dia merasakan hal yang sama?
TehMinumGeek

53
Bagaimana Anda tahu produktivitasnya lebih rendah? Bagaimana Anda mengukur produktivitas. Juga. Saya merasa sulit untuk percaya ini adalah editor teks (seperti notepad). Apakah itu editor seperti vi atau emacs. Ini adalah kedua lingkungan untuk diri mereka sendiri di tangan pengguna yang terampil.
Martin York

23
"beberapa editor teks" mungkin jauh lebih kuat daripada yang Anda pikirkan.

6
Saya ingin tahu seberapa cepat seseorang menggunakan vi / emacs dapat melakukan ekstrak metode, mengganti nama metode, metode inline, memperkenalkan variabel lokal, bidang bergerak / metode, dll?
artjom

6
@artjomka: Jauh lebih cepat dari yang Anda kira. Itu semua bisa dituliskan. Anda pikir semua tugas otomatis ini diciptakan hanya setelah IDE diperkenalkan.
Martin York

Jawaban:


46

Anda kurang lebih sudah menjawab pertanyaan:

  1. Dia dalam masa percobaan
  2. Dia tidak cukup produktif

Jadi, dia perlu dibuat sadar bahwa:

  1. Dia harus lebih produktif atau dia tidak akan selamat dari masa percobaannya.
  2. Ia bertanggung jawab untuk menjadi lebih produktif dengan IDE yang tepat daripada dengan editor teks yang baik.
  3. IDE yang baik bukan tentang menyerahkan kontrol atas kode yang Anda tulis tentang memberikan Anda alat untuk memungkinkan Anda menghasilkan kode yang bekerja lebih cepat terlepas dari apakah Anda memilih untuk menggunakan pembuatan kode dan fasilitas templating yang mungkin tersedia dalam IDE .

Kurangnya kemauan untuk beradaptasi dengan lingkungannya mungkin juga menjadi perhatian.


25
"Kurangnya keinginan untuk beradaptasi dengan lingkungannya mungkin juga menjadi perhatian". Ini akan menjadi bendera merah bagi saya juga, dia tidak akan bertahan masa percobaan di sini sendirian ini.
Binary Worrier

9
Masalahnya adalah bahwa sebagian besar IDE yang disukai oleh perusahaan adalah yang buruk, karena mereka dipilih hanya berdasarkan biaya (artinya, gratis ...). Itu biasanya berarti Netbeans atau JDeveloper, atau beberapa rasa Eclipse. Dua yang pertama adalah bencana, yang terakhir sering terutama di tim yang lebih besar karena mengoordinasikan hal-hal seperti pengaturan dan plugin adalah hal yang buruk dengan Eclipse.
jwenting

4
@jwenting Saya tidak tahu seberapa besar maksud Anda, tetapi saya belum melihat tim yang Eclipse besar tidak akan memotongnya. Pengaturan dan plugin tentu saja harus distandarisasi, yang mudah.
biziclop

46
+1 Masalahnya adalah, "John tidak cukup produktif." Jangan fokus pada IDE sebagai masalah.
Andres Jaan Tack

1
"Kurangnya kemauan untuk beradaptasi dengan lingkungannya mungkin juga menjadi perhatian" - IMO sebagian besar kali manajemen memberlakukan aturan bodoh yang tidak dipikirkan oleh mentalitas kawanan normal yang diikuti oleh orang-orang yang berpikir kritis akan mempertanyakannya. Manajemen tidak suka orang-orang yang mempertanyakan pilihan mereka sehingga mereka mungkin mengibarkan bendera merah yang mengklaim Jhon tidak kooperatif.
Biksu Timur

22

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.

  • Semakin banyak abstraksi / pola / kerangka kerja yang Anda gunakan, semakin Anda membutuhkan IDE yang mampu membantu Anda menavigasi kode Anda.
  • Semakin rendah level / verbose / tidak Anda ketahui bahasa, semakin Anda membutuhkan IDE yang mampu membantu Anda menghasilkan / menemukan kode yang Anda butuhkan.

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.


2
++ untuk pemrograman berpasangan - hanya memiliki IDE yang terpampang di depan Anda tidak ada gunanya tanpa seseorang menunjukkan kepada Anda penekanan tombol yang berguna untuk menyelesaikan sesuatu
Gary Rowe

6
Sejak kapan Java menjadi bahasa tingkat rendah? ;-)
Craige

5
@Craige: 'levelness' adalah relatif. Dibandingkan dengan bahasa dinamis modern, Java adalah bahasa tingkat rendah dengan perpustakaan tingkat tinggi.
Javier

@Craige, Anda dapat menghapus "level rendah" jika mau, tetapi Anda tidak dapat menghapus "verbose";)
David

Kecuali bahwa, dengan editor yang cukup kuat, Anda mungkin salah, dan dia mungkin lebih produktif dengan editornya daripada di IDE. Bersikeras pada poin-poin kepercayaan (mis., IDE acak lebih produktif daripada vi atau emacs) hanya akan memperburuk masalah, karena pengembang yang tidak produktif akan melihat bahwa Anda membuat keributan tentang hal-hal yang salah.
David Thornley

12

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.


11

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.


1
Saya setuju. Kasing belum terbukti bahwa John kurang produktif karena dia tidak menggunakan IDE. Pindah ke lingkungan yang tidak dikenal kemungkinan besar akan membuatnya bahkan KURANG produktif, dan frustrasi untuk boot. Fokus pada penampilannya. Buat dia memasangkan program dengan seseorang yang menggunakan IDE (atau pasangkan dengannya dalam editor teks, mungkin Anda akan belajar sesuatu juga.) Temukan akar penyebab kurangnya produktivitas, jangan langsung menyimpulkan bahwa toolchainnya adalah salah.
karmajunkie

3
Sangat mungkin juga bahwa majikan memiliki harapan yang tidak realistis untuk John, dan bahwa kinerjanya masuk akal.
Joe Internet

Dengan hanya 3 pengembang, jika dua lainnya dari kaliber premium keluaran tinggi bahan bakar, itu sepenuhnya mungkin juga
Avatar_Squadron

8

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.


3
Kegagalan mungkin menjadi guru yang hebat, tetapi jelas merupakan strategi bisnis yang buruk - mengapa perusahaan ini harus membayar untuk pendidikan karyawan perusahaan berikutnya?
Ekkehard.Horner

5
@ Ekkehard.Horner: Bagaimana strategi bisnis yang buruk dihilangkan dari seseorang yang (a) kurang produktif dan (b) tidak kooperatif?
S.Lott

2
@ S.Lott: pertanyaan artjomka menyiratkan bahwa John dapat dibuat produktif (keuntungan untuk perusahaan); Usulan Paul Butcher untuk tidak melakukan apa pun selain membiarkan John melanjutkan sampai dipecat adalah cara yang pasti untuk kehilangan uang.
Ekkehard.Horner

4
@ S. Lott: Karena melatih orang (John) membutuhkan uang. Karena menemukan orang baru memerlukan biaya. Karena melatih orang baru untuk melakukan pekerjaannya membutuhkan biaya. Memecat orang itu mahal.
pyvi

2
Saya pikir Bill harus melangkah lebih jauh, dan memecat John sendiri. Jangan menunggu sampai itu terjadi dengan sendirinya ... Juga, saya ingin tahu bagaimana ini tidak ditemukan selama wawancara?
AviD

6

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.


6

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.


4

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.


4

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:

  1. Asumsi yang salah untuk membuat pilihan lingkungan pengembangan akan banyak menjadi faktor dalam kinerja
  2. Pendekatan yang salah mengatakan padanya untuk menggunakan IDE

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.


3

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) .


4
Setiap jenis refactoring lebih lambat (belum lagi rawan kesalahan) oleh beberapa urutan besarnya dalam editor teks biasa daripada IDE yang dirancang untuk melakukan refactoring.
biziclop

3
@biziclop IDE hanyalah kumpulan alat. Tidak ada alasan mengapa koleksi alat harus lebih kuat daripada alat sendiri. Alat refactoring juga ada di luar IDE. Mengetahui alat membuat Anda produktif, jika Anda bisa memilih sendiri, Anda lebih cenderung produktif daripada memasukkan beberapa alat ke tenggorokan Anda.
daramarak

1
@ Daramarak Saya pikir kita semua dapat dengan aman setuju bahwa editor teks bukan alat refactoring, sementara IDE.
biziclop

3
@biziclop yakin hanya texteditor saja yang bukan alat refactoring. Maksud saya adalah bahwa seorang texteditor sederhana bukanlah halangan untuk refactoring. Ini membuat Anda bebas untuk memilih alat yang Anda suka.
daramarak

@biziclop: Sejak kapan refactoring (dan mendapatkan bantuan untuk melakukannya) hal utama dalam produktivitas? Saya akui itu sangat membantu ketika saya ingin mengganti nama sesuatu, sebulan sekali, tetapi produktivitas saya bukan karena itu.
Mike Dunlavey

2

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.


Mencoba mempelajari IDE secara efektif adalah latihan dalam frustrasi juga, dan membutuhkan banyak waktu dan usaha. Dia mungkin menjadi SLOWER selama beberapa minggu menggunakan IDE daripada sekarang menggunakan editor teks (tergantung pada kompetensi intinya dengan bahasa yang dia tulis), dan tidak lebih cepat selama beberapa minggu setelah itu (jika pernah).
jwenting

0

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).


1
Ada pengadu yang berdiri sendiri yang bekerja sangat baik untuk setidaknya beberapa tujuan. Saya tidak cukup tahu tentang alat Java untuk mengatakan apakah itu yang terjadi di sini.
David Thornley

ada beberapa pengembang terkenal yang men-debug hal-hal dengan printf. Bahkan jika itu sedikit rewel, mengapa repot-repot seseorang meyakinkan dia untuk menggunakan sesuatu yang lain?
jokoon

0

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

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.