Bagaimana cara menyarankan perubahan sebagai karyawan yang baru direkrut? [Tutup]

Baru-baru ini saya dipekerjakan di sebuah perusahaan besar (ribuan orang, untuk memberikan gambaran tentang besarnya). Mereka mengatakan bahwa mereka mempekerjakan saya karena kekakuan saya dan karena saya, meskipun masih muda (saya 25), berpengalaman sebagai programmer C / C ++.

Sekarang saya sudah masuk, saya bisa melihat bahwa seluruh sistem sudah tua dan sering menggunakan teknologi usang. Tidak ada konvensi penamaan (file, fungsi, variabel, ...), mereka tidak menggunakan Kontrol Versi, tidak menggunakan pengecualian atau polimorfisme dan sepertinya hampir semua orang kehilangan hasratnya (beberapa di antaranya baru berusia 30 tahun ).

Saya ingin menyarankan beberapa perubahan tetapi saya tidak ingin menjadi "orang baru yang ingin mengubah segalanya hanya karena dia tidak ingin cocok". Saya mencoba untuk "menyesuaikan diri", tetapi sebenarnya, saya butuh satu minggu untuk melakukan apa yang akan saya lakukan dalam satu sore, hanya karena alat-alat yang buruk yang terpaksa kami gunakan. Banyak kolega saya tidak pernah melihat "hal" baru dan teknik yang digunakan orang saat ini. Sepertinya mereka baru saja menyerah. Situasinya benar-benar membuat frustrasi.

Apakah Anda pernah berada dalam situasi yang sama dan, jika demikian, saran apa yang akan Anda berikan kepada saya? Apakah ada cara halus untuk mengubah sesuatu tanpa menjadi domba hitam di sini? Atau haruskah saya melepaskan gairah dan energi saya juga?

Terima kasih.

Pembaruan

Mengikuti saran berharga Anda, saya dapat menyarankan perubahan dan sekarang saya bertanggung jawab atas tim yang harus membuat dan menggunakan Subversion: D Terima kasih kepada Anda semua!

6 bulan kemudian

Saya berhenti dan menemukan lingkungan yang jauh lebih menarik, dengan gaji yang jauh lebih baik, dan tantangan yang lebih menarik. Saya tidak akan kembali untuk apa pun.

Saya berada dalam situasi yang sama di perusahaan saya sebelumnya, di mana saya berada selama 5 tahun. Ketika saya bergabung di tahun 2004, mereka adalah:

• masih menggunakan Microsoft Access untuk database mereka (bahkan yang penting untuk bisnis)
• menggunakan Visual Basic 6 atau Access / Excel VBA untuk pengembangan
• menggunakan banyak pihak ketiga alih-alih menggunakan sumber daya pengembangan di tempat (manajer bisnis memimpin proyek pengembangan mereka sendiri dan 90% dari waktu mengajukan kontrak untuk tender tanpa sepengetahuan IT)
• terkesiap tidak ada kontrol versi.

Ketika saya pergi tahun lalu, perusahaan itu adalah:

• menggunakan .NET dan C # secara eksklusif
• telah membuang semua pengembangan Akses
• menggunakan SVN untuk kontrol versi
• memiliki 2 kotak SQL Server gemuk dan sedang memigrasi database Access yang ada ke SQL
• semua pengembangan datang melalui tim in-house dan hanya keluar untuk tender jika sumber daya terbatas

Pada saat itu saya belum lama berusia 21, dan yang termuda berikutnya dalam tim pengembangan adalah 30. Saya tidak melakukan semuanya sendiri. Manajer TI telah bergabung dengan perusahaan pada saat yang sama, dan ingin membawa semua pengembangan melalui TI.

SVN adalah pencapaian pertama saya. Saya mengadakan pertemuan dengan manajer lini saya, dan menyoroti beberapa situasi di mana kode telah ditayangkan atau diubah yang menyebabkan masalah, dan menyoroti fakta bahwa tidak ada pertanggungjawaban - dia tidak bisa menyalahkan siapa pun, pada dasarnya - dan setelah ini dia mulai mendengarkan.

Saya kemudian menempatkan presentasi bersama ke tim dan menjelaskan konsep kontrol versi, dan mendemonstrasikan beberapa situasi di mana SVN dapat membantu kami pengembang. Yang lebih muda mengambilnya seperti bebek untuk air, yang lebih tua tidak begitu banyak tetapi mereka mencoba dan tidak mengeluh tentang mereka yang menggunakannya.

Prestasi besar lainnya adalah membawa sistem lengkap di dalam perusahaan - saya memimpin sebuah proyek yang menyelamatkan perusahaan sebesar £ 120rb setahun dalam perizinan. Saya menghabiskan sekitar 2 bulan waktu luang saya menulis sistem baru, dan mempresentasikannya kepada manajer TI, dan menjelaskan penghematan biaya. Dia kemudian mengizinkan saya untuk mempresentasikannya ke bisnis, dan menjelaskan bagaimana kami dapat menerapkan apa pun yang mereka suka ke dalam sistem - tidak lagi terbatas pada sistem "off-the-shelf".

4 minggu kemudian sistem saya dalam uji coba di 10 lokasi, dan 6 bulan kemudian ditayangkan. Setahun kemudian mereka membatalkan kontrak pihak ketiga, menghapus semua jejaknya dari jaringan, dan mendatangi kami untuk persyaratan peningkatan besar pada sistem internal kami.

Saran saya untuk Anda:

• jika Anda peduli dengan perusahaan, tetap bertahan. Jika orang lain tidak menyukai pendekatan Anda, biarkan mereka mengambilnya dengan Anda - ini semua tentang kompromi
• Menyesuaikan saran dengan orang yang Anda ajak bicara - manajer suka mendengar tentang bagaimana mereka dapat a) menghemat uang, b) secara akurat menyalahkan orang ketika ada sesuatu yang salah, tetapi pengembang suka mendengar bagaimana mereka dapat a) menghemat waktu, b) tetap setia untuk diri mereka sendiri, misalnya
• jika Anda bersemangat tentang perubahan (yang terlihat seperti Anda) maka tunjukkan antusiasme Anda kepada orang-orang dan jangan berkecil hati saat mereka kurang antusias
• Jangan bicara tentang membuat perubahan. Buat mereka. Ketika Anda mulai menghasilkan pekerjaan yang luar biasa dalam waktu kurang dari orang-orang yang lebih berpengalaman, orang-orang akan mulai bertanya "mengapa?"

Mereka mengatakan bahwa mereka mempekerjakan saya karena kekakuan saya dan karena saya, meskipun masih muda (saya 25), berpengalaman sebagai programmer C / C ++.

Lebih mungkin karena Anda lebih murah.

Apakah Anda pernah berada dalam situasi yang sama

Iya.

saran apa yang akan Anda berikan kepada saya

Meninggalkan.

Apakah ada cara halus untuk mengubah sesuatu tanpa menjadi domba hitam di sini?

Mungkin disana. Perkenalkan perubahan dan tunjukkan bagaimana mereka meningkatkan hal-hal untuk semua orang. Setelah Anda melakukannya beberapa kali, Anda mungkin mendapatkan penghargaan dari mereka yang tidak tersesat.

Atau haruskah saya melepaskan gairah dan energi saya juga?

Tidak mungkin. Anda masih muda dan Anda harus mengambil penuh dari peluang. Jangan buang tahun "di suatu tempat". Lihatlah posisi ini dan pahami apakah itu akan memberi Anda pengalaman berharga untuk mendorong karier Anda lebih jauh. Jika Anda melihat peluang, jelajahilah. Jika tidak ada dan itu hanya "pekerjaan", keluarlah. Praktek menunjukkan, mereka yang kehilangan gairah (atau tidak pernah memilikinya) tidak bisa mendapatkannya kembali. Carilah tim orang-orang yang bersemangat dan bergabunglah dengan mereka.

Pimpin dengan memberi contoh . Perubahan yang sangat kecil saat itu. Menepi seorang kolega dan mendemonstrasikan sesuatu kepada mereka. Jika mereka tidak mengerti, cobalah lagi lain kali.

Itu akan memakan waktu. Hanya saja, jangan menarik orang jauh dari zona nyaman mereka terlalu cepat.

Sedih tapi itu sebabnya Anda di sini dan mereka tidak.

Sebagai contoh. Siapkan kontrol versi secara lokal dan tunjukkan kepada mereka bagaimana hal itu dapat membantu. Kemudian beri mereka beberapa sumber (bacaan sederhana) yang dapat mendukung Anda.

Satu hal lagi tentang alat . Terkadang Anda harus menghabiskan uang Anda sendiri untuk membeli alat yang lebih baik. Saya tahu ini bukan 'hal yang dilakukan' tetapi ketika saya berbicara dengan perdagangan lain saya menemukan banyak insinyur 'nyata' membuat / membeli peralatan mereka sendiri untuk melakukan pekerjaan mereka dengan lebih baik. Saya selalu melakukan ini di mana saya dapat melihat bahwa saya menyelamatkan diri saya dari keterampilan atrofi.

Saya orang tua (51) dan saya punya masalah yang sama di setiap pekerjaan yang pernah saya miliki. Mungkin itu hanya berasal dari selalu menjadi pria paling cerdas di ruangan itu! :-) Serius, ketika Anda tahu cara melakukannya dengan benar dan tidak, Anda sering berpikir, "Hei, saya akan menunjukkan kepada semua orang teknik baru dan lebih baik ini dan mereka semua akan terkesan dan ingin terjun ke dalamnya untuk menggunakannya. " Namun dalam kehidupan nyata, 90% dari waktu, Anda menunjukkan kepada orang-orang cara yang lebih baik, dan mereka memberikan banyak alasan mengapa cara mereka melakukannya selama ini lebih baik. Ketika Anda menunjukkan bahwa alasan mereka tidak valid, mereka datang dengan alasan baru, bahkan lebih jelas. Saya sudah banyak kali saya

Bahkan jika Anda benar-benar jenius, Anda harus menerima bahwa tidak ada orang lain yang tahu Anda jenius sampai Anda membuktikannya. Saya teringat Kris, seorang teman saya yang memulai pekerjaan baru setelah menghabiskan 10 tahun di satu perusahaan. Tidak lama setelah memulai pekerjaan baru, dia menghadiri rapat di mana mereka mendiskusikan beberapa masalah teknis dan dia mulai menawarkan solusi yang disarankan. Kemudian seseorang menyela dan berkata, "Ya, terima kasih. Bob, bagaimana menurutmu?" Awalnya dia jengkel: Dia tahu jawaban yang benar, tetapi tidak ada yang peduli! Sebagai gantinya mereka pergi dengan pendapat seseorang yang kurang banyak tahu daripada dia. Tapi kemudian dia menyadari, hei, di pekerjaan lamaku, aku telah membangun reputasi sebagai seseorang yang tahu apa yang dia bicarakan, jadi ketika aku berbicara, orang-orang mendengarkan. Di sini, saya belum memiliki reputasi, jadi tidak ada yang peduli dengan apa yang saya pikirkan.

Saya sudah berada di pekerjaan saya sekarang 2 tahun dan hanya dalam beberapa bulan terakhir pendapat saya mulai memiliki bobot yang nyata. Kamu harus sabar.

Di sisi lain, orang-orang baru sering kali memiliki sejuta saran untuk perbaikan yang benar-benar tidak praktis, karena mereka belum cukup tahu tentang organisasi dan oleh karena itu mereka tidak tahu mengapa segala sesuatunya dilakukan sebagaimana adanya. Kadang-kadang orang terus melakukan sesuatu dengan cara yang sama selama 20 tahun karena itulah yang selalu dilakukan dan tidak ada yang pernah berpikir untuk mencari cara yang lebih baik; tetapi kadang-kadang orang terus melakukan sesuatu dengan cara yang sama selama 20 tahun karena pengalaman menunjukkan itu cara yang baik untuk melakukannya dan setiap kali mereka mencoba sesuatu yang berbeda itu adalah bencana. Jadi jangan terlalu cepat menyimpulkan bahwa orang-orang ini idiot. Cari tahu mengapa mereka melakukannya dengan cara lama sebelum Anda mengeluarkan saran baru yang cemerlang. Saya memiliki banyak waktu dalam hidup saya ketika saya

Temukan sekutu yang juga ingin meningkatkan perusahaan.

Ada sesuatu yang bisa dikatakan untuk keluar sekarang dan membiarkan mereka membusuk. Namun akan terlihat luar biasa pada resume Anda jika Anda berhasil memperjuangkan kontrol versi dan peningkatan lainnya.

Gunakan Tes Joel selama wawancara mendatang. Ingat Anda juga sedang mewawancarai perusahaan.

Saran pertama saya adalah jangan mencoba untuk mengubah terlalu banyak terlalu cepat. Pertama, dapatkan reputasi sebagai pengembang andal yang baik yang bisa menyelesaikan sesuatu. Sekarang sebagai pemula, apa pun yang Anda sarankan mencurigakan; mereka belum tahu dan menghormati Anda. Dapatkan penghormatan itu sebagai langkah pertama Anda. Maka inilah saatnya untuk mulai memperkenalkan perubahan.

Pilih Anda dengan hati-hati. Mulai dengan kontrol versi, bukan teknologi baru. Karena memang itulah perubahan terpenting. Anda bahkan dapat melakukannya hanya dengan kode Anda dan kemudian memastikan bahwa ketika Anda harus kembali ke versi sebelumnya atau copmpare untuk mengetahui apa yang telah berubah, Anda memberi tahu orang-orang betapa mudahnya dalam percakapan biasa.

Gunakan pengetahuan Anda saat ini untuk menjadi orang yang bersinar dan kemudian orang akan mulai bertanya bagaimana Anda menyelesaikan ini. Ketika pcs pertama kali datang ke tempat kerja, saya bekerja untuk sebuah lembaga audit pemerintah. Para senior semua sangat menentang memiliki komputer sendiri (karena itu bekerja untuk sekretaris). Para junior mengambil komputer pertama dan mulai melakukan hal-hal yang tidak bisa dilakukan oleh para senior dengan Grafik 1-2-3 dan Harvard dan tiba-tiba, orang-orang tua tertarik karena mereka para pemuda mendapatkan perhatian dari manajemen yang sangat senior.

Perubahan ke budaya organisasi bukan masalah teknis, itu masalah politik. Apakah membaca tentang mengelola politik kantor. Anda akan membutuhkan dukungan politik di tingkat tinggi.

Saya mengalami situasi serupa di pekerjaan saya saat ini. Saya direkrut langsung dari sekolah pascasarjana untuk bekerja di tim yang sebagian besar adalah insinyur yang telah berada di sini lebih dari 15 tahun. Membuat perubahan itu tidak mudah (saya masih mendorong beberapa hal untuk dilakukan), tetapi itu mungkin.

Misalnya, tim saya mengelola, memperbarui, dan menggunakan utilitas uji DOS 16-bit. Utilitas itu sangat sulit untuk diperbarui, karena aplikasi mendorong batas penghubung 16-bit ke titik di mana jika Anda menambahkan kode, Anda harus menghapus sesuatu yang lain agar sesuai. Ketika ditanya mengapa kami menghabiskan begitu banyak waktu dan energi pada kode 16-bit, jawaban mereka adalah "karena kami membutuhkannya untuk dijalankan di DOS sehingga kami dapat menjalankannya dari flash drive yang dapat di-boot". Saya mencoba meyakinkan mereka untuk port utilitas ke Linux 32-bit, tetapi manajemen tidak ingin menginvestasikan waktu untuk melakukannya (kami sudah memiliki terlalu banyak pekerjaan untuk dilakukan seperti itu). Jadi, saya pergi ke depan dan porting utilitas di waktu istirahat (15 menit di sana-sini saat makan siang, pada akhir pekan, atau ketika saya sedang menunggu kode lain untuk dikompilasi). Selama beberapa bulan, Saya memiliki utilitas yang sepenuhnya porting, ditingkatkan dengan segala macam hal yang tidak bisa ditangani oleh aplikasi 16-bit asli, dan boot off dari drive flash Linux. Orang-orang memperhatikan ketika saya mulai menggunakannya, dan mengomentari bagaimana saya bisa menyelesaikan pekerjaan lebih cepat dan bagaimana utilitas saya menghasilkan hasil debug yang lebih baik. Segera, manajemen mendengar tentang itu. Begitu mereka melihat manfaatnya (dan yang paling penting, bahwa pekerjaan itu sudah dilakukan), mereka tidak lagi menentang gagasan itu.

Pelajaran yang saya pelajari dari cerita ini adalah ini: Jika Anda pikir Anda dapat meningkatkan sesuatu, bicarakan dengan manajer Anda tentang hal itu. Jika mereka tidak ingin menghabiskan sumber daya untuk itu, lakukan sendiri dan buktikan kepada mereka bahwa ide Anda valid dan bermanfaat. Adalah jauh lebih mudah untuk mengatakan tidak pada suatu gagasan yang seseorang usulkan daripada sesuatu yang Anda lihat di depan Anda yang nilainya jelas.

Setelah tim / manajer Anda mengimplementasikan ide Anda dan mulai melihat manfaatnya, mereka akan lebih mungkin mendengarkan ide-ide Anda di masa depan. Saya menggunakan "kredibilitas jalanan" yang saya peroleh dari alat tes saya untuk menulis ulang untuk meyakinkan tim saya bahwa kami perlu membuang sistem kontrol versi kami yang kuno (yang akan tetap anonim untuk menghindari rasa malu) dan bermigrasi ke Subversion. Saya mengajukan diri untuk memimpin upaya pengaturan / migrasi untuk membantu memastikan bahwa manajemen akan menyetujuinya.

Itu semacam "selangkah demi selangkah". Mungkin ada banyak hal yang ingin Anda ubah, tetapi mulailah memilih sesuatu yang kecil. Tunjukkan kualitas ide-ide Anda sehingga tim dan manajer Anda tidak bisa mengatakan 'tidak'. Seperti halnya akun stackoverflow Anda, semakin banyak ide bagus yang Anda miliki, semakin baik reputasi Anda dan semakin mudah pula ide Anda diterima.

Pasti mulai menggunakan alat yang Anda inginkan secara lokal (di mana Anda bisa - beberapa perusahaan juga tampaknya mengontrol apa yang dapat Anda instal pada kotak Anda dengan kepalan yang sangat ketat). Atur sistem kontrol versi favorit Anda dan mulailah menggunakannya. Dalam kode apa pun yang Anda sentuh, buat perubahan kecil yang membuat kode lebih bersih, terutama saat Anda bisa menulis kode baru. Jika mereka mempekerjakan Anda untuk ketelitian dan pengalaman Anda, itu berarti mereka sudah menghormati Anda.

Saya baru-baru ini membaca Hiring Ren dan Stimpy , dan menemukan contoh Stimpy adalah tantangan besar. Jika Anda mengikuti jejaknya, Anda pada akhirnya akan meminta (dengan baik) segala macam perspektif dari rekan kerja Anda, membuat Anda memiliki pengetahuan yang tidak dimiliki pengembang yang tidak bersemangat. Anda akan menghabiskan waktu luang Anda telah bermimpi cara untuk melakukan perbaikan. Jika perusahaan melihat pekerjaan Anda sebagai barang berharga, Anda akan menjadi sangat berharga. Jika tidak, Anda mungkin ingin mencari pekerjaan.

Banyak orang menjawab dengan saran untuk fokus pada satu hal kecil pada satu waktu, dan beberapa menyarankan kontrol versi. Saya akan melangkah lebih jauh: membuat repositori di mesin desktop Anda, dan bekerja dari repositori itu. Perbarui secara teratur dari repositori utama apa pun yang digunakan perusahaan. Ketika (tidak jika) ada krisis karena seseorang merusak master, beri tahu mereka bahwa Anda dapat memotong salinan baru dari repositori pribadi Anda.

Namun, jangan dalam kondisi apa pun meletakkan kode perusahaan pada mesin yang Anda miliki atau bawa sendiri secara pribadi . Karena dengan begitu Anda mungkin menemukan bahwa, alih-alih menjadi pahlawan, Anda berada di sisi yang salah dari seorang pengacara (paling banter) atau penegak hukum (paling buruk).

Datang dari pengembang junior lain ... apakah Anda memiliki keterampilan orang-orang hebat? Apakah Anda memiliki perasaan menahan diri dan pemahaman yang sangat baik tentang kapan ide itu tepat dan tidak sesuai, dan bagaimana cara terbaik menjual ide itu? Bahkan jika Anda melakukannya, Anda mungkin masih akan menjadi "pria itu" karena memberi tahu orang lain bagaimana melakukan pekerjaan mereka tanpa membuktikan nilai Anda.

Inilah bagaimana saya MASIH membangun kredibilitas saya sebagai pengembang junior: Saya mengidentifikasi pembuang kink / kludge / waktu. Lalu saya memperbaikinya dengan mengotomatiskannya (file batch, skrip PowerShell, program sederhana, freeware baru, apa pun di akhir pekan) tanpa mengganggu orang lain. Saya memastikan untuk menjadikannya bagian dari pendidikan mandiri teknis saya yang sedang berlangsung sehingga saya dapat menganggapnya sebagai "meluangkan waktu ekstra untuk mengajar diri saya hal baru DAN membantu perusahaan".

Jika perbaikan saya sangat bagus saya membagikannya, dan berkata, "Hai teman-teman, saya membuat alat keren ini, itu mengotomatisasi XY dan Z dan melakukan hal lain ini dengan cepat." Simpan namamu di sana. Ulangi. Masalah kredibilitas diselesaikan dalam beberapa bulan jika Anda berada dalam persentase yang berkinerja tinggi untuk level Anda, dan orang-orang di atas Anda akan lebih terbuka terhadap saran Anda jika Anda siap menjelaskan mengapa ide Anda bagus dan bagaimana hal itu dapat menyelesaikan masalah mereka.

Baru-baru ini saya dapat mengusulkan ide-ide baru kepada manajemen tingkat atas yang diterima, sebagian besar karena saya meluangkan waktu untuk menjelaskan alasan saya, mendengarkan umpan balik mereka, dan memiliki kredibilitas dari pekerjaan saya yang lalu.

TAMBAHKAN: Jika manajer Anda mempertanyakan perilaku Anda ... jangan lakukan hal ini kecuali dia merasa kinerja Anda tetap setidaknya "25% teratas", yaitu pastikan bos Anda senang dengan Anda sebelum Anda mulai mencoba untuk membuat segala macam perbaikan pintar yang mendorong Anda lebih tinggi ke% teratas itu atau dia akan berpikir Anda membuang-buang waktu. Jika Anda membuang utilitas dan solusi baru sambil memunculkan umpan balik kinerja positif namun dia tetap bersikeras untuk mengelola mikro Anda, Anda mungkin memiliki masalah yang berada di luar cakupan topik ini.

Berbaur.

Seperti yang Anda katakan, Anda tidak ingin menjadi domba hitam. Namun, karena Anda (seperti saya) ingin menambahkan beberapa perubahan yang bermanfaat:

Tambahkan nilai di latar belakang.

Atur cronjobs untuk memeriksa kode orang di svn / hg / git .. Buat alat Anda sendiri, pada waktu Anda sendiri, yang secara nyata dapat meningkatkan upaya pengembangan. Secara khusus, Anda ingin melakukan perbaikan pada perusahaan yang dapat Anda tunjukkan kepada senior Anda di bilik Anda sendiri. Dan inilah alasannya:

Faktor wow

Jika Anda dapat mengatakan "Hai Alice, Anda tahu bagaimana Bob merusak bangunan? Saya dapat mengembalikan hasil editnya, dan bangunan itu berfungsi lagi". Dan ketika senior Anda mengatakan sial, mungkin Anda akan membangunkan cukup gairah di dalamnya sehingga mereka akan mendorong, atau setidaknya mendorong, praktik baru Anda.

Ini saran saya.

Saya berada dalam situasi yang sama, pertama saya harus mengatakan, perusahaan saya cukup kecil sekitar 6 pengembang, saya adalah jenis programmer yang suka menggunakan teknologi baru, alat-alat baru dan apa pun yang akan membuat pekerjaan saya lebih mudah dan menghasilkan perangkat lunak berkualitas lebih baik .

Ketika saya mulai, kami menggunakan Visual Studio 2005, ketika VS2008 telah keluar cukup lama, tetapi meminta bos saya untuk mengeluarkan uang, upgrade semua pengembang kami tidak mudah, saya harus perlahan-lahan memunculkan ide, karena lebih dari a "alangkah baiknya jika kita bisa melakukan ini", tetapi sebelum saya membawanya ke bos saya, akan memastikan pengembang lain akan baik pada gagasan itu, karena mereka akan menjadi orang yang menggunakannya dan memiliki sekelompok orang di nikmat akan terlihat kurang seperti keputusan satu orang.

Saya pikir, alih-alih hanya melontarkan ide itu kepada bos Anda, mungkin secara perlahan memunculkan kemungkinan perubahan, karena saya merasa jika Anda menyarankan ide yang akan mengubah perusahaan dengan cara yang lebih baik, juga menunjukkan bahwa Anda peduli dengan pekerjaan Anda dan menunjukkan bahwa Anda berencana untuk membuat rumah di sana.

Ini juga akan tergantung pada lingkungan kerja Anda dan kepribadian bos Anda, jika mereka santai dan memperlakukan Anda seperti keluarga dan mengambil saran, maka sarankan, tetapi jika mereka memperlakukan Anda seperti angka, saya akan sangat berhati-hati bagaimana Anda mendekatinya.

Bisa jadi peluang seumur hidup - mengubah cara perusahaan bekerja pada usia 25. Jika mereka menolak dan menunjukkan permusuhan sepanjang waktu, itu bukan tempat untuk Anda.

Ingat, wawancara Anda adalah proses dua arah. Anda bisa merasakan betapa kuno dan tahan terhadap perubahan mereka.

Ps, saya juga 25 dan tahu bagaimana perasaan Anda. Anda mungkin jauh lebih bersemangat untuk belajar dan mencoba hal-hal baru daripada rekan kerja Anda. Bagaimanapun, harus kembali ke pekerjaan .NET4 yang saya perkenalkan;)

Baca Mendapatkan Berbagai Hal Dilakukan Saat Anda Hanya Mendengus oleh Joel Spolsky.

... terkadang Anda tidak memiliki kekuatan untuk membuat perubahan di organisasi Anda oleh eksekutif fiat. Tentunya, jika Anda hanya seorang programmer kasar di bagian bawah tiang totem, Anda tidak bisa memerintahkan orang untuk mulai membuat jadwal atau database bug. Dan bahkan jika Anda seorang manajer, Anda mungkin menemukan bahwa mengelola pengembang sama seperti menggembalakan kucing, hanya saja tidak menyenangkan. Hanya mengatakan "buat begitu" tidak membuatnya begitu.

Ini bisa membuat frustrasi ketika Anda bekerja di sebuah organisasi yang mendapat skor rendah di The Joel Test . Tidak peduli seberapa bagus kode Anda, rekan kerja Anda menulis kode buruk sedemikian rupa sehingga Anda merasa malu untuk dikaitkan dengan proyek tersebut. Atau manajemen membuat keputusan buruk tentang kode apa yang akan ditulis, jadi Anda terpaksa menyia-nyiakan bakat Anda dengan debug versi AS / 400 dari game perencanaan pensiun untuk anak-anak.

... berurusan dengan kehidupan di tim yang buruk bisa menyebalkan. Tetapi ada strategi untuk meningkatkan tim Anda dari bawah, dan saya ingin membagikan beberapa di antaranya ...

Bekerja dengan manajemen; jangan "nakal". Bekerja di dalam proses, dan memasukkan hal-hal ke dalam istilah yang orang akan mengerti, seperti "menerapkan svn akan membawa kita ruang pada server, dua hari untuk setup, dan kita perlu mencadangkannya, tetapi kita akan mendapatkan x, y, z , Yang dapat menyelamatkan kita banyak uang. "

Berhenti. Ada banyak pekerjaan di luar sana. Bukan tugas Anda untuk memperbaiki beberapa perusahaan acak yang kebetulan mempekerjakan Anda. Mereka suka apa adanya, kalau tidak mereka akan menyewa CTO baru atau apalah.