Apakah pesanan perusahaan untuk beralih ke IDE tertentu merupakan tanda bahaya? [Tutup]

Baru-baru ini saya bergabung dengan startup yang berkembang pesat. Dalam 3 bulan terakhir tim pengembangan telah berkembang dari 4 menjadi 12. Sampai sekarang mereka sangat laissez-faire tentang apa yang digunakan pengembang untuk melakukan pekerjaan mereka. Sebenarnya salah satu hal yang awalnya saya temukan menarik tentang perusahaan adalah bahwa kebanyakan programmer menggunakan Linux, atau OS apa pun yang mereka rasa paling sesuai dengan upaya mereka.

Sekarang pesanan, tanpa diskusi, telah turun bahwa setiap orang harus beralih ke Eclipse. Editor yang baik. Saya lebih suka SublimeText2, tapi itu hanya selera pribadi saya.

Untuk lebih jelasnya: kami adalah tim JS yang menggunakan Backbone dan Eclipse tidak pandai memahami kode Backbone. Ini berarti bahwa mereka yang ada di tim yang menggunakan / good / IDE (PHP Storm), harus kembali melakukan banyak pencarian-temukan-oh-tunggu-di mana-dulu-saya-tiga-langkah-lalu hal-hal yang lalu bukan hanya ctrl + mengklik dan menggunakan back / forward - mungkin mengurangi produktivitas dengan mengatakan 15% dan kenikmatan sebesar 50% ...

Apakah ini bendera merah? Tampaknya berubah-ubah dan mengendalikan secara tidak masuk akal untuk memberi tahu pengembang (non-MS) apa IDE atau perangkat-set untuk digunakan jika mereka sudah menetap dan produktif.

"Sekarang perintah, tanpa diskusi , telah turun bahwa setiap orang harus beralih ke Eclipse."

Saya pikir ini adalah bendera merah asli. Tim Anda adalah pakar dalam pengembangan perangkat lunak dan yang akan dipengaruhi oleh keputusan tersebut, namun Anda tidak dapat mengatakan sepatah kata pun dalam diskusi yang menghasilkan pesanan ini?

Kedengarannya seperti manajemen berlebihan oleh bos berambut runcing. Apakah orang / tim pembuat keputusan memiliki wawasan yang relevan untuk keputusan itu?

Mengingat bahwa para pembuat keputusan cukup memenuhi syarat untuk keputusan seperti itu, tidak meminta pendapat tim pengembang setidaknya memiliki dua kekurangan:

• Tim tidak merasa terlibat. Melibatkan tim harus menjadi prioritas bagi manajemen. Saya tidak ingin bekerja sebagai dev di suatu tempat di mana pendapat saya tentang masalah sentral seperti IDE tidak cukup dihargai bahkan untuk diminta. Memang, meminta pendapat seseorang dan kemudian memutuskan untuk menolaknya mungkin lebih buruk, tetapi dalam hal ini saya mengharapkan alasan yang kuat untuk keputusan itu.

• Manajemen, bagaimanapun berpengalamannya, tidak bekerja 100% dengan pengembangan kode khusus ini. Dengan asumsi bahwa orang-orang yang tidak memiliki wawasan yang menarik sama sekali naif. Tentu saja mungkin agar para manajer memikirkan segala hal yang diajukan para dev, tetapi satu-satunya cara untuk mengetahuinya adalah dengan bertanya.

Adalah masuk akal bahwa ketika Anda bekerja bersama pada proyek bersama, bahwa pada setiap workstation Anda memiliki semua alat yang tersedia untuk mengedit / membangun / men-debug perangkat lunak Anda, dan bahwa alat inti untuk melakukan sekitar 90% dari pengembangan diketahui oleh semua orang di tim. Tujuan itu lebih sulit untuk dicapai jika tim Anda berkembang dan semua orang menggunakan perangkat favorit pribadinya - semakin banyak orang, semakin banyak pendapat. Dan pekerjaan administrasi menjadi lebih mudah juga, jika Anda tidak membiarkan jumlah alat tumbuh lebih dari yang diperlukan.

Tentu saja, jika satu pengembang bersikeras untuk menggunakan editor favorit pribadinya, itu boleh saja asalkan dia dapat memastikan sumbernya tidak terlihat atau berperilaku berbeda di editor utama tim (dalam kasus Anda Eclipse), jadi jika dev B harus mengedit sumber dev A, dev B tidak boleh dipaksa untuk mempelajari editor favorit pribadi A untuk dapat mengubah sumber secara efektif. Namun waspadalah, jika keduanya harus bekerja sama dari waktu ke waktu di depan layar yang sama (atau melakukan pemrograman berpasangan), seringkali lebih mudah jika editor yang dipilih dikenal oleh keduanya.

Demi pemrograman berpasangan, alangkah baiknya jika kedua pihak di depan layar memiliki keterampilan yang sama saat menggunakan keyboard. Sangat menyenangkan mengetahui bahwa, jika proyek Anda memiliki kebutuhan konfigurasi khusus dalam IDE, maka itu dikonfigurasi dengan cara yang sama untuk semua orang. Memulai pengembang baru lebih mudah bila alatnya sama untuk semua orang.

Tetapi jika Anda membandingkannya dengan hanya berusaha menjadi yang paling efektif, maka itu tidak terlalu sepadan

Ya, itu sedikit tanda bahaya yang manajemen anggap sebagai penilaian yang lebih baik untuk alat mana yang lebih efisien daripada Anda.

Itu bukan bendera merah itu sendiri.

Terkadang manajemen perlu mengambil keputusan . Setiap masalah yang memerlukan standardisasi pada sesuatu cenderung masuk dalam kategori itu. Saya pernah bekerja di klien yang membiarkan standar melayang selama beberapa tahun dan mereka memiliki 20+ alat SCM yang berbeda. Apa yang dimulai sebagai pilihan independen oleh tim pengembangan yang berbeda berubah menjadi mimpi buruk logistik yang sangat menghambat berbagi keterampilan dan kolaborasi pada kode di seluruh organisasi. Bangunan terintegrasi adalah ..... eh ..... tidak terlalu terintegrasi .....

Selain itu, tidak praktis atau perlu berkonsultasi dengan semua orang untuk setiap keputusan . Sejauh mana hal ini perlu dilakukan tergantung pada budaya organisasi dan pentingnya / kompleksitas keputusan. Biasanya Anda akan mengambil salah satu dari opsi yang kurang konsultasi ini:

1. Buat keputusan sendiri, jika Anda memiliki pengetahuan yang cukup tentang pro / kontra dan itu bukan keputusan yang cukup penting untuk memerlukan konsultasi luas.
2. Konsultasikan dengan beberapa individu kunci (yang mungkin akan menjadi pengembang senior yang paling memenuhi syarat untuk mengambil keputusan).
3. Angkat fakta bahwa Anda membuat keputusan untuk semua orang yang mungkin terpengaruh (email, rapat balai kota, rapat tim). Katakan apa yang menurut Anda keputusan yang tepat tetapi Anda bersedia mengubahnya jika bukti baru muncul sebaliknya. Undang orang untuk tampil secara individu jika mereka memiliki beberapa pandangan penting
4. Undang orang untuk membentuk sub-tim untuk meninjau opsi dan merekomendasikan keputusan. Pilihan yang bagus jika itu benar-benar panggilan dekat, Anda tidak tahu jawabannya dan Anda ingin orang-orang yang terlibat ikut serta dalam keputusan tersebut.

Untuk sesuatu seperti pengembang perangkat (yang merupakan masalah yang berpotensi diperdebatkan) saya mungkin akan melakukan 2 diikuti oleh 3 atau 4. yaitu pasti akan ada beberapa individu yang saya tidak akan berbicara secara pribadi tentang masalah ini, tetapi di sisi lain sebagian besar dari orang-orang kunci akan mendapatkan kesempatan untuk berkontribusi dalam pengambilan keputusan.

Bagi saya bendera merah yang sebenarnya akan ada jika Anda merasa sangat kuat bahwa keputusan yang salah telah diambil (salah == itu merugikan perusahaan daripada hanya alat favorit Anda yang tidak akan dipilih). Bagaimana manajemen bereaksi ketika Anda mengangkat masalah ini:

• Manajemen yang baik akan mendengarkan argumen Anda, terima kasih dengan tulus atas umpan balik dan mempertimbangkan kembali posisi mereka jika Anda telah meningkatkan wawasan baru . Mereka mungkin masih tidak setuju dengan Anda dan mungkin berpegang teguh pada keputusan mereka, tetapi mereka akan menghargai bahwa Anda telah mengangkatnya dengan mereka dan apakah Anda dengan sopan mengatakan mengapa mereka tetap dengan keputusan mereka. Mereka bahkan mungkin mengubah cara mereka membuat keputusan seperti itu di masa depan, dan jika Anda membuat poin yang baik dapat memasukkan Anda dalam daftar "orang pintar untuk bertanya".
• Manajemen yang buruk akan menjadi defensif, mengatakan bahwa "keputusan telah dibuat" dan taktik lainnya untuk menghindari menghadapi kenyataan bahwa mereka mungkin telah membuat keputusan yang salah. Mereka mungkin melihat Anda sebagai "pembuat onar". Perusahaan menderita, seperti halnya iman Anda dalam manajemen. Ini adalah bendera merah asli! Keluarlah selagi bisa!

Jika Anda menggunakan pakar atau sesuatu yang serupa, tidak masalah dengan IDE mana yang Anda gunakan. Mungkin ada kasus di mana seseorang terikat pada IDE tertentu seperti gerhana, jika ada plugin yang Anda andalkan.

Saya pikir Anda harus dapat memilih IDE Anda sendiri, IDE yang paling produktif bagi Anda. Namun, seperti yang sudah saya katakan ada beberapa kasus di mana masuk akal untuk menggunakan IDE standar.

Saya telah menginstal "mandat perusahaan" IDE, tetapi masih akan melakukan sebagian besar pekerjaan saya di IDE apa pun yang saya inginkan - tidak seperti orang dapat mengetahui apa yang digunakan IDE untuk mengedit file sumber.

Di IDE vs Editor depan ... untuk hampir semua bahasa, saya sangat lebih memilih IDE (IntelliJ) karena ada begitu banyak lagi yang bisa lakukan untuk Anda daripada editor kaleng. Ada beberapa hal yang saya kembalikan ke ST2 atau Emacs, tetapi untuk pengkodean sehari-hari, meskipun saya sangat menyukai kedua ST2 / Emacs, IDE hampir selalu menang.

Setiap tim yang pernah saya kunjungi memiliki beragam IDE dan editor: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - ini tidak pernah menjadi masalah. Tidak pernah.

Bagi saya ini berbicara dengan kesalahpahaman di tingkat tinggi organisasi, tentang apa yang benar-benar penting. Yang penting adalah membiarkan pembuat kode yang baik melakukan apa yang perlu mereka lakukan dan menggunakan alat yang membuat mereka paling nyaman. Keseragaman IDE sangat sedikit hubungannya dengan komunikasi nyata yang terjadi tentang pertanyaan-pertanyaan penting arsitektur objek, pengujian unit, algoritma, dll.

Memiliki IDE yang sama dengan orang berikutnya hanya berarti bahwa kita berdua tahu cara menelusuri kode dengan cara pintas yang sama, dan bagaimana kompilasi / konfigurasi kita diatur. Tidak ada yang akan menjadi masalah ketika berbicara tentang masalah kode nyata.

Lihat, itu layak huni, tergantung pada faktor-faktor lain di perusahaan. Anda selalu dapat menggunakan editor pilihan Anda sendiri untuk hal-hal sehari-hari. Dan mungkin grup Anda melakukan hal-hal hebat lainnya yang menciptakan budaya hebat. Namun, mandat IDE adalah kesalahan langkah IMO yang sangat besar. Bagi saya, jika saya mewawancarai sebuah perusahaan dan mereka memberi tahu saya IDE mana yang diizinkan untuk digunakan, saya akan berterima kasih dengan sopan atas waktu mereka.

Di toko Ruby kami ada rekomendasi yang kuat untuk menggunakan IDE yang dinikmati sebagian besar tim (RubyMine), karena kami tahu itu berfungsi dan kami bisa saling mengajarkan cara pintas dll.

Pengembang bebas menggunakan IDE yang berbeda, tetapi kami mengharuskan mereka untuk memiliki keterampilan yang solid dalam editor itu jika mereka memilihnya. Jika kami melihat seseorang yang berjuang untuk menavigasi proyek mereka atau mengedit teks di FooEdit kustom mereka, RubyMine untuk mereka adalah.

Jika seorang programmer adalah pakar di IDE yang diberikan, maka mereka harus menggunakannya. Jika mereka bukan ahli di IDE mana pun, mungkin ada satu atau dua yang sangat umum untuk bahasa pemrograman Anda, atau dalam tim Anda, dan mungkin masuk akal bagi mereka untuk mempelajarinya.

Terpaksa melakukan standardisasi pada IDE terdengar seperti ide yang buruk.

Alasan perusahaan memaksa editor atau perangkat lunak tertentu secara umum pada pengembangnya harus diperiksa. Bagian paranoid (mungkin bukan kata yang saya cari) dari saya berpikir mungkin ada semacam pelacakan produktivitas yang ditambahkan ke gerhana yang mereka minta agar dipasang oleh pengembang. Pemikiran yang jauh lebih paranoid (lagi) adalah bahwa mereka telah menghabiskan waktu menambahkan alat pembuatan produk ke IDE ini yang akan membuat segalanya lebih mudah jika semua orang menekan tombol yang sama untuk menguji dan membangun cabang kode mereka.

Pokoknya yang ingin saya katakan adalah mungkin lebih dari sekadar birokrasi, atau metode mengacaukan kepala pengembang.

Ini adalah bendera merah besar. Setiap perusahaan memiliki beberapa ide bodoh seperti itu, tetapi jika bendera merah lainnya terus berdatangan, pergilah.

Sangat mudah untuk motivasi di balik beberapa keputusan untuk hilang - terutama dengan tim yang berkembang pesat. Motivasi untuk pindah ke Eclipse mungkin hanya fakta bahwa sebagian besar pengembang tampaknya menghabiskan banyak waktu hanya mengkonfigurasi IDE dan bahwa hanya ada keahlian terbatas dengan perusahaan Anda.

Saya hanya akan mengambil perintah untuk pindah ke Eclipse untuk berarti bahwa Anda harus memiliki pengaturan Eclipse jika diperlukan, tetapi lanjutkan pekerjaan Anda di editor favorit Anda. (Anda mungkin harus pindah ke Eclipse secara bertahap jika perusahaan Anda mulai menggunakan alat keren dalam Eclipse.)

Bendera Merah: Saya akan menunggu jika ada beberapa pesanan irasional seperti itu sebelum khawatir.

Startup umumnya mencoba untuk tetap gesit cukup lama untuk mengetahui model bisnis yang berkelanjutan. Setelah mengetahui bagian uang, manajemen bergerak untuk meningkatkan bisnis. Itu umumnya ketika semua karyawan teknologi awal mulai pergi, karena proses rekayasa diperketat.

Seperti yang Anda ketahui, Anda tidak tahu kode apa yang sebenarnya akan dilakukan sampai Anda menjalankannya. Turing membuktikan hal itu di awal-awal komputasi. Ini berarti bahwa tidak ada yang namanya ukuran produktivitas yang berarti dalam hal menulis perangkat lunak. Namun, bagi manajemen untuk melakukan tugasnya, produktivitas harus dapat dibaca. Karena Anda tidak dapat mengukur kode (dan orang-orang telah mencoba - baris kode, misalnya), mereka akan mengukur apa yang dapat mereka lihat. Pemrogram lebih terbaca daripada perangkat lunak yang mereka kembangkan. Tim manajemen tipikal berupaya mengendalikan programmer untuk membuat hal-hal ini dapat dibaca oleh mereka (alih-alih melakukan pekerjaan nyata mereka: menyingkir). Dan karena mereka mengukur hal-hal yang salah, itu tidak berfungsi dengan baik.

Karena itu, Anda masih bisa pergi jauh dengan tim yang longgar. Tim pengembangan Github memiliki sekitar 50 orang dan mereka melanggar setiap aturan dalam buku teks manajemen bisnis. Mereka tampaknya baik-baik saja. Bug diperbaiki (akhirnya). Fitur ditambahkan. Api bisa padam.

Apa yang dimaksud dengan bendera merah besar adalah jika mereka mencoba meningkatkan skala tanpa mengetahui cara menghasilkan uang. Pada titik itu, Anda harus bertanya-tanya berapa banyak opsi dan hibah yang tidak Anda investasikan benar-benar bernilai.

Tentunya ini adalah ide yang buruk. Tidak dapat dihindari bahwa tim akan menjadi kurang produktif karena mereka harus belajar menggunakan alat baru. Dan bahkan saat itu mereka tidak akan seefektif dengan alat yang sudah mereka grok .

Karena saya sudah mencoba berbagai alat sendiri, saya selalu merasa bahwa "ya ampun, editor ini mengganggu saya dengan <memasukkan beberapa bug / perbedaan dari alat yang disukai>". Jadi itu akan menjadi kelemahan moral juga.

Tapi tentu saja ada juga pro untuk membuat seluruh tim menggunakan alat yang sama. Berbagi konfigurasi, skrip, plugin, dan semua hal semacam itu. Yang tidak mungkin dilakukan dengan beragam toolset.

Di sisi lain ... bit terakhir tidak akan diperlukan jika semua orang menggunakan perangkat lunak pilihannya. ;)

Anda dapat "menggunakan" Eclipse sambil mengetik di SublimeText2.

Ini berarti memiliki Eclipse diinstal dan dikonfigurasi untuk proyek Anda dan mempercepat dengan itu sehingga Anda sama-sama nyaman menggunakannya jika, katakanlah, memasangkan pemrograman. Tidak ada yang akan (atau paling tidak seharusnya) peduli editor apa yang sebenarnya Anda gunakan untuk mengetikkan kode yang Anda komit selama mempertahankan pengaturan paralel Anda tidak memakan waktu yang tidak semestinya dan Anda tidak memotong diri dari lingkungan pengembangan standar.

Jika Anda menggunakan Git dan percabangan Anda sedang down, Anda tidak perlu menggunakan editor satu sama lain. Anda bisa mendorong cabang dan dev lain menariknya untuk membuatnya bekerja jika dia benar-benar tidak bisa mengetahui toolset Anda. Memaksa semua orang untuk menggunakan editor yang sama terdengar seperti perintah oleh beberapa kepala bisnis yang ingin terlihat pintar tetapi tidak benar-benar mengerti cara kalian beroperasi.

Jika Anda memikirkan hal ini dari sudut pandang manajemen, alasan mereka melakukan hal ini adalah untuk kepatuhan hukum. Perusahaan bertanggung jawab untuk memastikan bahwa setiap alat yang digunakan digunakan secara legal dan juga tidak akan membebani produk yang sedang dikembangkan. (Beberapa editor gratis untuk penggunaan pribadi, tetapi tidak gratis untuk tujuan lain, dll.) Untuk mengaudit setiap alat yang mungkin ingin digunakan setiap pengembang bisa mahal. Saya telah melihat bahwa pada proyek-proyek di mana garis waktu sangat ketat, manajemen akan berhati-hati tentang alat / perpustakaan / dll mana yang digunakan untuk meminimalkan perubahan nanti dalam proyek yang diarahkan oleh orang-orang hukum.

Pada proyek keamanan yang lebih tinggi ada juga kekhawatiran di mana IDE menyimpan file sementara, dan informasi apa yang disimpan di antara sesi.

Itu semua tergantung pada alasan mereka harus merekomendasikan Eclipse. Jika pengembang mengalami kesulitan mengatur lingkungan mereka karena semua orang mengatur berbagai hal secara berbeda, mungkin ada alasan untuk merekomendasikan straightjacket. Namun, jika semua orang bahagia dan produktif menggunakan apa pun yang mereka inginkan, ada sedikit alasan untuk memaksakan perubahan pada sesuatu yang begitu terlibat dalam proses kreatif.

Eclipse jauh lebih dari sekadar editor - Anda dapat tetap menggunakan editor favorit Anda untuk mengedit kode Anda dan mengandalkan Eclipse untuk kontrol sumber, debugging, dan apa pun yang ingin digunakan oleh alur kerja yang diamanatkan oleh perusahaan.

Satu hal terakhir - proses penegakan di tingkat ini dapat menunjukkan perusahaan bermaksud untuk memperluas tim pengembangan dan ingin memiliki sedikit struktur tertentu di tempat sehingga rekan tim baru bisa menjadi produktif lebih cepat. Jika Anda menganggap Rails (atau Django) sebagai kerangka kerja "pendapat", Anda akan menyadari memiliki struktur membantu untuk memahami aplikasi baru dengan lebih mudah.

Bendera merah tidak begitu banyak bahwa IDE / editor tunggal dipaksakan pada setiap pengembang, tetapi bahwa keputusan ini, dan terutama keputusan di mana IDE / editor akan digunakan tidak dibuat oleh semua pengembang, dan mungkin tidak ada mereka!?!

Tentu akan lebih baik bagi para pengembang untuk mencapai konsensus, terutama karena mereka jelas-jelas memenuhi syarat untuk keputusan (setidaknya pada editor / IDE mana). Mungkin ada alasan yang baik untuk menyesuaikan dan bahwa keputusan harus mempertimbangkan preferensi manajemen, tetapi editor / IDE mana yang seharusnya menjadi keputusan semua pengembang.

Mendapatkan 12 pengembang untuk memberikan suara akan mudah. Tentu saja ada cukup waktu untuk melakukan itu! Kesimpulannya mungkin akan menyakitkan untuk beberapa hal dan itu mungkin bahkan akhirnya menjadi Eclipse pada akhirnya, tetapi label persyaratan sebagai "bendera merah" dalam kasus itu akan jauh lebih bisa diperdebatkan.