Apakah pengalaman magang negatif saya mewakili dunia nyata? [Tutup]


85

Saya ingin tahu apakah pengalaman saya saat ini sebagai magang mewakili industri yang sebenarnya.

Sebagai latar belakang, saya melalui bagian yang lebih baik dari dua jurusan komputer dan jurusan matematika di sebuah universitas besar; Saya telah mengakses setiap kelas dan mengagumi mereka semua, jadi saya ingin berpikir bahwa saya tidak buruk dalam pemrograman. Saya mendapat magang di salah satu perusahaan perangkat lunak utama, dan setengah jalan sekarang saya terkejut dengan kualitas kode yang sangat rendah. Komentar tidak ada, itu semua kode spageti, dan segala sesuatu yang bisa salah bahkan lebih buruk. Saya telah melakukan banyak pengajaran / TAing, jadi saya sangat terbiasa membaca kode yang buruk, tetapi produk-produk industri utama saya telah melihat semua itu. Saya bekerja 10-12 jam sehari dan tidak pernah merasa seperti berada di tempat lain, karena itu s jam tanpa henti mencoba untuk mencari tahu API tidak berdokumen atau menentukan perilaku beberapa bagian lain dari produk (benar-benar tidak berdokumen). Saya meninggalkan pekerjaan membenci pekerjaan setiap hari sejauh ini, dan saya sangat ingin tahu apakah ini yang ada di toko selama sisa hidup saya.

Apakah saya menggambar sedotan singkat di magang (gaji besar bukan kepalang menyiratkan bahwa itu bukan posisi berkualitas rendah), atau apakah ini seperti apa dunia nyata?


22
Lebih umum dari yang seharusnya. Banyak tempat yang sama sekali tidak tahu melakukan hal yang benar.
Wayne Molina

35
apa yang Anda lihat sebagai negatif sebenarnya positif, lebih baik untuk mendapatkan pengalaman dunia nyata lebih cepat daripada nanti, dan apa yang Anda alami adalah dunia yang lebih nyata daripada pengalaman akademis Anda atas perintah besarnya.

69
Ingatlah bahwa kebanyakan programmer membenci kode programmer lain. Peluang bahwa orang yang kemudian mengerjakan kode yang Anda tulis akan mengatakan hal yang sama. Saya tahu Anda berpikir Anda adalah programmer yang baik, dan Anda mungkin, tetapi kemungkinannya cukup tinggi bahwa siapa pun yang menulis kode yang Anda lihat juga berpikir demikian. Tapi tidak, itu tidak selalu seburuk yang Anda gambarkan. Sebagian mungkin karena Anda belum sepenuhnya belajar membaca dan mengevaluasi kode dunia nyata dengan benar, dan itu akan tampak sedikit lebih baik begitu Anda memilikinya.
psr

22
Jika kode yang Anda lihat di universitas bukan kode spageti berkualitas rendah, pengalaman Anda berbeda dengan kode saya ... Terlalu sering kode dalam proyek akademik keluar sebagai bukti konsep tanpa memperhatikan keberlanjutan apa pun.
Michael Borgwardt

10
@psr: Saya tidak setuju bahwa programmer membenci kode programmer lain secara umum. Jika Anda memiliki beberapa parameter kualitas seperti keterbacaan, dokumentasi yang baik, kesederhanaan, dll, Anda dapat menghargainya bahkan dalam kode orang lain, bahkan jika gaya pengkodeannya berbeda dari Anda. Di sisi lain, jika Anda melihat kode yang rumit, kacau, improvisasi, Anda tidak menyukainya, bukan karena itu adalah kode orang lain. BTW, saya juga benci kode saya sendiri ketika saya dipaksa untuk menulis sesuatu dengan tergesa-gesa dan hasilnya tidak memenuhi standar kualitas saya.
Giorgio

Jawaban:


128

Mereka menyebutnya Dunia Nyata ™ karena suatu alasan.

99% dari apa yang akan Anda temui di dunia korporat nyata akan dianggap omong kosong, dan untuk alasan yang baik saya akan jelaskan. 1% yang tidak dianggap omong kosong pada akhirnya akan menjadi omong kosong.

# 1 Tulis Kode, # 2 ????, # 3 Untung!

Bisnis pertama ada untuk menghasilkan untung, mereka tidak ada untuk menghasilkan gunung kode akademik yang dirancang dengan sempurna bersih dan murni disimpan dalam repositori emas kesempurnaan. Bahkan tidak dekat, bahkan yang dalam bisnis penjualan kode sumber yang mereka hasilkan.

Dalam dunia bisnis kode adalah sarana untuk mencapai tujuan . Jika beberapa kode memecahkan masalah bisnis dan menghasilkan lebih banyak uang daripada biaya untuk membuat dan memeliharanya, maka itu diinginkan untuk bisnis. Mempekerjakan Anda untuk menulis kode hanyalah satu cara bagi bisnis untuk mendapatkan kode.

Teori 0 - Praktek ∞

Idealnya pemeliharaan harus lebih menjadi perhatian tetapi biasanya tidak, karena dalam jangka pendek tidak menang secara finansial. Dalam jangka panjang, perangkat lunak biasanya memiliki siklus hidup yang relatif singkat, terutama aplikasi berbasis web, mereka menjadi usang dengan cepat dan lebih sering ditulis ulang.

In-house line aplikasi bisnis adalah yang terus berputar seperti yang dianggap sebagai proyek zombie tanpa akhir karena banyak alasan berbasis momentum. Proyek-proyek ini sebenarnya adalah kesuksesan yang terus mereka jalani karena mereka terus membuat bisnis ini untung.

Secara teori tidak ada perbedaan antara teori dan praktik. Dalam praktiknya ada. - Yogi Berra

Secara teori, arsitek yang benar-benar bersih, basis kode yang benar-benar bersih dengan cakupan kode 100% akan menghemat uang perusahaan, dalam praktiknya bahkan tidak mendekati memberikan sesuatu yang mendekati pengembalian investasi yang valid.

Fisika Siklus Hidup Perangkat Lunak

Ada juga kekuatan entropi yang sangat kuat yang bekerja di dunia perangkat lunak. Ini adalah lubang hitam keniscayaan yang mengutuk semua perangkat lunak untuk berubah menjadi Big Ball of Mud .

Semakin jauh Anda memulai dari BBM semakin baik, tetapi setiap sistem perangkat lunak pada akhirnya akan sampai di sana dengan waktu yang cukup. Seberapa cepat Anda mendekati 100% entropi ditentukan oleh di mana Anda memulai dan seberapa cepat Anda menimbun utang teknis dan seberapa tinggi bunganya.

Sistem perangkat lunak merosot dan membusuk karena pemeliharaan, bukan karena kekurangannya. Sebuah sistem yang sudah ada selama bertahun-tahun tanpa perubahan kode menurut definisi memenuhi semua persyaratan dan sasarannya dan sukses.

Ini adalah sistem yang membutuhkan perubahan konstan karena mereka mulai lebih dekat dengan entropi maksimum adalah sistem yang terus-menerus disodok dan didorong dan pemeliharaanlah yang mempercepat perubahan negatif.

Cukup Baik Cukup Baik

Sistem siklus hidup pendek seperti situs web yang berubah terus-menerus tidak mendapat manfaat dari desain awal yang sangat besar, cakupan kode 100% dalam pengujian unit, karena waktu amortisasi terlalu singkat untuk memperbesar biaya.

Sistem siklus hidup yang panjang seperti garis internal aplikasi bisnis yang disebutkan di atas, tidak benar-benar diuntungkan oleh investasi besar-besaran dari 100% tes cakupan unit, juga, karena tingkat perubahan selama masa proyek mendekati konstanta yang mendekati nol dalam mode non-linear.

Itulah sebabnya rencana akhir masa hidup lebih penting dan sistem penggantian harus direncanakan seperti sesuatu yang dirilis, bukan ketika telah melewati itu prima beberapa tahun dan tidak dapat didukung sehingga sistem baru harus dilarikan ke tempatnya.

Mereka tidak mengajarkan tentang BBM sejauh yang saya tahu, saya belum pernah menemukan lulusan CS baru-baru ini yang tahu apa itu, apalagi mengapa itu terjadi.

Itulah sebabnya Cukup Baik itu Cukup Baik , ada yang kurang lebih baik.

Perampasan Perangkat Lunak

Ada tuan tanah kumuh real estat karena suatu alasan, mereka membuat keuntungan pada bangunan kumuh yang mereka miliki. Menghasilkan lebih banyak keuntungan daripada yang mereka habiskan untuk pemeliharaan tambahan properti yang rusak. Jika tidak, mereka akan merobohkan bangunan dan menggantinya. Tetapi mereka tidak melakukannya, karena biaya tambahan jauh lebih sedikit daripada merombak atau mengganti seluruh bangunan. Ada juga pelanggan (penyewa) yang bersedia membayar untuk properti yang rusak.

Tidak ada pemilik gedung, penguasa kumuh atau tidak yang akan menghabiskan uang untuk sebuah properti hanya karena beberapa gagasan akademis tentang kesempurnaan yang tidak diterjemahkan ke dalam laba yang substansial atas biaya yang terkait.

Tidak ada pelanggan yang akan membayar untuk upgrade ke sistem perangkat lunak yang berfungsi diterima oleh mereka. Tidak ada bisnis yang akan menghabiskan uang hanya untuk menulis dan menulis ulang kode tanpa keuntungan besar yang nyata.

Microsoft adalah yang paling mendominasi dan slumlord perangkat lunak yang sukses ada. Windows tidak mulai mendapatkan dasar menulis ulang dasar sampai baru-baru ini. Dan mereka masih belum menjatuhkan semua kode lama dari kernel. Tidak masuk akal secara bisnis bagi mereka, orang lebih dari rela menerima bar harapan yang rendah yang telah mereka tetapkan selama dekade terakhir.

Prognosa

Ini telah menjadi pola selama 20 tahun lebih saya dalam pengembangan perangkat lunak. Itu tidak akan berubah dalam waktu dekat. Ini bukan cara orang ingin keluar dari suatu sistem kepercayaan, itu adalah kenyataan kekuatan eksternal pada bisnis. Bisnis mendorong pengambilan keputusan, laba bukanlah kejahatan, mereka membayar gaji Anda, visi jangka pendek atau jangka panjang tidak relevan, ini adalah industri jangka pendek dengan perubahan konstan menurut definisi. Siapa pun yang berpendapat cukup baik untuk mendapat untung tidak memahami bisnis.

Saya menghabiskan 15 tahun berkonsultasi dan belajar dengan sangat cepat bahwa cukup baik hanya itu, apa pun yang saya lakukan memerlukan biaya. Ya saya ingin semuanya menjadi sempurna, tetapi kecuali jika Anda menjual basis kode, yang 99,99999% dari waktu Anda menjual solusi , semua kode rapi bersih yang anggun dan rapi hilang dan Anda hanya membuang-buang waktu Anda, Anda tidak akan pernah mendapatkan penggantian untuk .

Kemajuan dan Harapan

Metodologi tangkas adalah langkah yang baik ke arah yang benar, setidaknya secara filosofis. Mereka mengatasi kekacauan dan perubahan konstan sebagai warga negara kelas satu dan menerimanya. Mereka menolak praktik dogmatis, mengakui bahwa metodologi dan praktik harus berubah serta persyaratan dan teknologi.

Mereka menerima entropi yang diperkenalkan oleh kurangnya waktu atau persyaratan yang berubah, staf yang berubah, dan semangat sistem perangkat lunak dengan konsep utang teknis.

Tapi Agile bukan obat mujarab, itu tidak akan mengubah hukum dasar fisika dan basis kode akan membusuk terlepas. Terserah manajemen untuk merencanakan berurusan dengan busuk sebelum benar-benar lepas kendali dan tidak dapat dikelola.

Agile ketika dilakukan dengan benar, membantu mengelola entropi, memperlambatnya, melacaknya, mengukurnya dan menghadapinya secara terencana. Itu tidak akan menghentikannya!

Keputusan Karier

Jika ini adalah masalah filosofis yang nyata bagi Anda, Anda mungkin harus mempertimbangkan pilihan karier lain, karena cara kerja memiliki kelebihan bisnis yang valid di belakangnya. Proyek Open Source tidak memiliki rekam jejak yang lebih baik, dan dalam banyak kasus kode ini bahkan lebih buruk daripada kebanyakan kode perusahaan yang saya lihat.


2
Saya tidak punya masalah filosofis dengan itu, itu hanya frustasi untuk mendapatkan tempat. Tapi, ini jelas masuk akal; banyak kode yang saya
tangani

8
"Mereka tidak ada untuk menghasilkan gunungan kode akademik yang dirancang secara teoritis bersih dan murni yang ditampung dalam repositori emas kesempurnaan.": Tetapi mereka tidak menyadari berapa banyak uang yang akan mereka hemat jika mereka memberi pengembang mereka lebih banyak waktu untuk membersihkan kode mereka sehingga bahwa nanti mereka tidak perlu menghabiskan berminggu-minggu mencari bug atau menulis ulang kode yang tidak ada yang mengerti lagi. Saya pikir pemikiran jangka pendek dari banyak perusahaan ini mengurangi keuntungan mereka dalam jangka panjang. Tapi ini IMO pertanda manajemen yang buruk.
Giorgio

22
Lucunya, perusahaan tempat saya bekerja memang mendapatkan ROI karena memiliki cakupan kode yang sangat tinggi, ulasan kode yang ketat, sesi desain 30 menit setiap hari, dll. Pada awalnya pengembangan mungkin berjalan sedikit lebih lambat, tetapi dikembalikan sepuluh kali lipat pada tahap selanjutnya ketika basis kode sebaliknya akan menjadi berat.
Maks

4
Saya telah melihat cukup kegagalan proyek untuk mengetahui bahwa jawaban Anda tidak akurat. Anda menggambarkan apa yang dipercaya kebanyakan orang di industri ini. Iman bukanlah kualitas yang baik di dunia teknik, terutama ketika sains telah membuktikan kepercayaan semacam itu sejak lama.
deadalnix

27
-1 Meskipun beberapa poin valid, ada banyak kesalahan. Misalnya, hal tentang "dirancang secara teoritis bersih" adalah manusia jerami yang jelas; merencanakan untuk menulis ulang daripada refactor bukanlah ide yang baik, dan bahkan banyak orang di industri memahami hal ini. Dan basis kode tidak membusuk, mereka membusuk karena kurangnya perawatan.
sleske

44

Saya ingin tahu apakah pengalaman saya saat ini sebagai magang mewakili industri yang sebenarnya.

Tidak, bukan. Ini mewakili tingkat karir dan pengalaman Anda. Ini semua adalah bagian dari pembelajaran tentang bagaimana bisnis bekerja dari perspektif kontrol kualitas internal.

Sebagai latar belakang, saya melalui bagian yang lebih baik dari dua jurusan komputer dan jurusan matematika di sebuah universitas besar; Saya telah mengakses setiap kelas dan mengagumi mereka semua, jadi saya ingin berpikir bahwa saya tidak buruk dalam pemrograman. Saya mendapat magang di salah satu perusahaan perangkat lunak utama, dan setengah jalan sekarang saya terkejut dengan kualitas kode yang sangat rendah.

Keterampilan Anda, pengalaman Anda, pendidikan Anda tidak berdampak pada kualitas pekerjaan yang dilakukan oleh orang lain. Hanya karena Anda tidak memiliki wewenang untuk mengubah praktik-praktik itu. Tidak masalah apakah Anda baik atau buruk di universitas. Itu tidak mengubah cara perusahaan tempat Anda bekerja saat ini beroperasi. Jadi sementara ini bagus, Anda memiliki semua latar belakang ini. Ini benar-benar untuk keuntungan Anda sendiri dan bukan untuk mereka. Itulah mengapa penting untuk mempelajari apa yang Anda sukai.

Saya mendapat magang di salah satu perusahaan perangkat lunak utama, dan setengah jalan sekarang saya terkejut dengan kualitas kode yang sangat rendah. Komentar tidak ada, itu semua kode spageti, dan segala sesuatu yang bisa salah bahkan lebih buruk. Saya telah melakukan banyak pengajaran / TAing, jadi saya sangat terbiasa membaca kode yang buruk, tetapi produk-produk industri utama saya telah melihat semua itu.

Apa yang saya pelajari selama bertahun-tahun pemrograman adalah bahwa ada perbedaan antara "kualitas kode" dan "kode yang dapat diterima". Yang benar adalah bahwa seseorang dengan otoritas menemukan kode sumber dalam kondisi yang dapat diterima, atau mereka merasa tidak dapat diterima tetapi perlu. Meskipun alangkah baiknya jika kita semua bisa membersihkan proyek yang melibatkan kita. Sering kali bukan kepentingan bisnis atau anggaran untuk mengalokasikan sumber daya untuk melakukan pekerjaan itu. Argumen logis dapat dibuat sampai matahari terbit pada hari berikutnya mengapa ini akan menjadi hal yang baik untuk diperbaiki, tetapi ketika manajemen telah memutuskan keadaan saat ini "dapat diterima" maka sedikit yang bisa dilakukan. Itu semua terkait langsung dengan siapa yang menjalankan sesuatu. Entah mereka menghargai kualitas internal yang baik atau tidak. Anda dengan jelas menghargainya dan karena itu keadaan saat ini mengganggu Anda.

Anda akan menemukan contoh jenis masalah ini di industri apa pun yang bergantung pada kontrol kualitas internal. Mulai dari pengembangan perangkat lunak hingga manufaktur. Anda perlu belajar untuk melihat ini bukan sebagai masalah, tetapi hanya sebagai kondisi saat ini dari kode sumber mereka. Ini adalah bagaimana, dibutuhkan X jumlah menit untuk menemukan sesuatu, dibutuhkan X jumlah menit untuk memperbaiki sesuatu.

Bisnis itu tidak peduli dengan waktu tambahan ini, atau bisnis itu dapat diterima.

Saya bekerja 10-12 jam sehari dan tidak pernah merasa seperti berada di tempat lain, karena ini adalah waktu tanpa henti untuk mencoba mencari tahu API yang tidak berdokumen atau menentukan perilaku beberapa bagian lain dari produk (yang sepenuhnya tidak berdokumen). Saya meninggalkan pekerjaan membenci pekerjaan setiap hari sejauh ini, dan saya sangat ingin tahu apakah ini yang ada di toko selama sisa hidup saya.

Mengapa Anda bisa menghabiskan waktu berjam-jam di universitas untuk mempelajari subjek, tetapi sekarang tidak dapat diterima untuk menghabiskan waktu berjam-jam untuk mempelajari kode sumber? Saya yakin alasan majikan mempekerjakan Anda adalah karena mereka pikir Anda bisa mengatasinya.

Biarkan saya memberi Anda beberapa saran. Pengembang yang baik tahu kapan harus meminta bantuan dari rekan setimnya. Jangan berpikir jawabannya selalu ada dalam kode. Saya telah menghemat banyak waktu dengan mengajukan beberapa pertanyaan kepada orang-orang. Sepertinya Anda perlu bantuan untuk mempercepat.

Kedua, kita tidak tahu kondisi kerjanya. Bekerja berjam-jam adalah fakta kehidupan di banyak industri. Anda perlu menyelesaikannya sendiri, tetapi saya dapat memberi tahu Anda. Membenci pekerjaan Anda bukanlah pertanda baik. Anda harus berurusan dengan perasaan itu dan sampai ke akarnya. Maaf, Anda mendapati pengalaman ini negatif.

Apakah saya menggambar sedotan singkat di magang (gaji besar bukan kepalang menyiratkan bahwa itu bukan posisi berkualitas rendah), atau apakah ini seperti apa dunia nyata?

Anda melakukannya dengan sangat baik di sekolah, tetapi sekarang Anda memiliki magang dan Anda tidak melakukannya dengan baik. Sepertinya Anda sudah berada di dunia nyata. Itu bagian dari kehidupan. Pertanyaannya adalah, apa yang akan Anda lakukan? Itu temanku, adalah satu-satunya hal yang penting. Kami tidak dapat memberi tahu Anda apa yang harus dilakukan. Anda harus mengambil keputusan sendiri.

Saya dapat memberitahu Anda bahwa sepertinya pengalaman Anda di usia Anda jauh lebih baik daripada peluang yang saya miliki. Kehidupan bagi saya di tahun 90-an adalah perjuangan untuk membayar sewa dan menemukan kontrak berikutnya. Anggap diri Anda beruntung.


3
Terima kasih atas wawasan Anda! Maafkan saya jika saya terdengar cengeng atau sok, saya sadar bahwa saya sangat beruntung dan masih harus banyak belajar. Dan saya kira saya sudah melakukan cukup baik (saya mungkin mendapatkan tawaran penuh waktu), saya hanya tidak tahu apakah pengalaman ini harus meyakinkan saya untuk mencari di tempat lain. Saya menghargai lebih memahami industri!
tryAtAnonimity

9
Seperti kata ayah saya ketika saya mulai. "Kamu tidak pernah berhenti mencari di tempat lain". Anda harus selalu berjejaring dengan orang lain di industri ini. Selalu perbarui resume Anda, dan selalu pelajari bahasa pemrograman baru. Jalani hidup Anda seolah-olah Anda menganggur dan Anda akan selalu bekerja dengan baik.
Reactgular

Saya tidak bisa melihat diri saya tidak terus belajar, mengingat betapa saya menikmati itu sekarang. Senang mendengar bahwa itu akan membantu saya!
tryAtAnonimity

5
+1 untuk "Pengembang yang baik tahu kapan harus meminta bantuan dari rekan setimnya." Saya bekerja di sebuah perusahaan kecil dan hanya memiliki 1 rekan satu tim yang cukup junior untuk saya dalam pengalaman pemrograman, tetapi dia sering memiliki kejelasan tentang masalah di mana saya terjebak. MEMINTA!
TecBrat

2
@Jodrell mengubah kode "bekerja" adalah risiko besar, "membersihkan" adalah perubahan dengan niat baik, tetapi jalan menuju neraka ditaburi dengan niat baik. Beberapa pemilik produk / manajer proyek akan menyetujui perubahan hanya demi perubahan, terlalu banyak risiko.

25

Setelah 25 tahun dan berbagai perusahaan dan industri saya dapat mengatakan:
Ya, itu cukup umum.
Inilah sebabnya mengapa insinyur dibayar dengan cukup baik biasanya, mereka harus pandai menghadapi berantakan hodge-podges dan masih dapat melakukan perubahan sambil menolak keinginan mendesak untuk refactor seluruh barang sialan dan mencari tahu apa yang sebenarnya seharusnya perbuatan. Saya melemparkan emosi untuk Anda di sana - itu normal untuk merasa seperti itu tentang kode yang Anda temui!

Kode yang Anda lihat akan sering mengalami iterasi tanpa akhir oleh programmer yang berbeda dengan pendekatan dan standar yang berbeda dan konvensi penamaan yang berbeda, dll. Dll.

Yang terjadi adalah tekanan $ selalu menyala. Itu selalu tergoda untuk menggambarkan bagaimana dan mengapa kode yang lebih baik adalah satu-satunya cara dalam jangka panjang tetapi dalam banyak pekerjaan jam terus berdetak untuk solusi perbaikan cepat jangka pendek. Hanya perlu 1 insinyur waktu singkat untuk menghancurkan standar dalam suatu proyek. Dibutuhkan manajer yang sangat baik yang tahu bagaimana mencegahnya dan mempertahankan pendekatan yang tepat (jika memungkinkan) untuk benar-benar mengatasinya.

Satu hal yang pasti, istilah 'kode yang baik' terlalu subjektif untuk berguna. Ini tidak subyektif bagi Anda tentu saja, Anda dapat membuat daftar alasan / item tertentu. Namun orang lain membuat daftar item dan prioritas yang berbeda, beberapa bahkan tidak teknis, yang mereka anggap penting, dan karenanya subyektif.

Seperti Drekka, ini mulai terdengar menyedihkan, jadi izinkan saya mencoba untuk sedikit lebih positif, karena memang benar bahwa: -

  • Ada organisasi, sering dengan komponen teknis terbesar yang sedang melakukan hal yang benar.
  • Semakin baru perusahaan ... dan kodenya ... cenderung bersih . spaghetti tumbuh karena waktu dan manusia.
  • Beberapa orang melakukan TDD dan BDD, yang lain tidak. Kisarannya sangat besar.
  • Setelah sekitar 10 tahun, saat ini, seluruh basis teknologi berubah sehingga mereka yang tinggal di industri dapat memiliki waktu yang sulit seperti halnya pemula.

Akhirnya, seperti yang ditunjukkan Anthony Blake, selalu ada 3 faktor - waktu, biaya dan kualitas.
Saya suka ungkapan terkait: "pick 2" !


Saya senang orang lain merasa seperti itu, haha. Memahami bahwa ini normal, saya pasti akan berusaha memiliki lebih banyak toleransi untuk ini. Terima kasih!
tryAtAnonimity

6
Anda beruntung jika Anda mendapatkan "Pilih 2" karena "Pilih 1" lebih sering menjadi norma.

Saya tidak berpikir "kode yang baik" itu subjektif sama sekali. Jatuhkan pengembang biasa dalam proyek dan minta mereka untuk membuat fitur yang umum diminta. Jika butuh berjam-jam, kode Anda baik. Jika butuh berhari-hari (atau berminggu-minggu) kode Anda buruk.
kubi

kubi, saya pikir itu bukan aturan yang baik. Kita harus memperhitungkan apa yang dihasilkan. Kode yang lebih lambat mungkin memiliki lebih banyak tes sebagai salah satu contoh. Kode cepat dapat (meskipun tidak selalu) menjadi sakit kepala pemeliharaan yang sangat besar.
Michael Durrant

Juga 'rata-rata dev' agak subyektif ...;)
Michael Durrant

16

Ada banyak pendapat tentang ini karena pengalaman setiap orang berbeda.

Milik saya adalah bahwa sekitar setengah dari pengembang yang saya temui bermaksud baik, tetapi kemampuan rata-rata. Ada sekelompok kecil orang-orang cerdas di atas, dan sekelompok kecil di bagian bawah yang berusaha tetapi pada dasarnya harus melakukan sesuatu yang lain karena mereka tidak benar-benar mendapatkannya. Sayangnya ada juga kelompok kecil lain dari orang-orang bodoh yang tidak kompeten yang berpikir bahwa mereka jauh lebih pintar daripada orang lain dan biasanya cukup di hadapan Anda tentang bagaimana Anda harus mengikuti mereka.

Dari segi proyek, saya telah pergi ke banyak pekerjaan dan segera diminta untuk "merawat" beberapa proyek yang sudah mapan, biasanya yang baru saja ditemukan oleh bisnis yang sangat dibutuhkan setelah kehilangan pengembang terakhir. Saya biasanya menemukan persis apa yang telah Anda sebutkan di atas - spaghetti tidak berdokumen, over-engineered, buggy. Kadang saya bisa memperbaikinya, kadang saya baru mulai lagi. Bahkan tidak perlu kode lama, saya telah menemukan ini di proyek baru saya juga diminta untuk "membantu".

Anda harus mengambil hati dari kenyataan bahwa sebagian besar perusahaan akan memberikan pekerja magang pekerjaan buruk. Yang menyenangkan datang setelah Anda melakukan dua hal: 1 - membuktikan diri Anda dan 2 - meluangkan waktu untuk mengerjakan hal-hal selain memperbaiki kesalahan orang lain. Dengan kata lain Anda harus menunjukkan kemampuan dan inisiatif.

Trik nyata untuk menangani kode buruk adalah mencari tahu apa yang bisa diselamatkan dan apa yang tidak. Ini berasal dari pengalaman dan penelitian.

Pilihan karier lain yang Anda miliki adalah berhenti bekerja untuk perusahaan yang sudah mapan dan mencari pekerjaan di perusahaan pemula. Maka tidak akan ada kode warisan omong kosong untuk dipelihara sehingga Anda akan memiliki kesempatan untuk membantu membangun sesuatu yang lebih baik. Kelemahannya adalah bahwa tekanan untuk memberikan ditempatkan pada proyek-proyek startup sering berarti bahwa jalan pintas dan peretasan digunakan ketika mereka seharusnya tidak.

Pemrogram terlalu sering bersedia untuk mengambil utang teknologi untuk memberikan lebih awal atau tepat waktu. Sayangnya dampak dari utang teknologi ini sering ditutup-tutupi, diminimalkan, diabaikan atau diberhentikan oleh pengembang dan manajemen sampai semuanya terlambat dan mereka dalam masalah.

Maaf jika ini terdengar menyedihkan. Saya yakin orang lain dapat melakukan hal yang lebih positif. :-)


Sama sekali tidak menekan, ada baiknya untuk mengetahui bahwa pengalaman ini tidak bisa dihindari dan permanen!
tryAtAnonimity

8
startup hanya menciptakan kode yang tidak dianggap omong kosong belum ...

Benar :-) dan saya juga pernah bekerja di startup yang diisi oleh beberapa orang bodoh yang tidak kompeten yang saya buat yang awalnya membuat banyak kode omong kosong.
drekka

12

Ada beberapa jawaban bagus di sini, tetapi izinkan saya menambahkan bagian saya;

Selamat datang di dunia nyata - sayangnya ini sangat umum.

Lihat diagram di bawah ini;

masukkan deskripsi gambar di sini

Dengan perangkat lunak perusahaan, Anda hanya dapat memilih 2 atau yang di atas, dan Anda harus mengorbankan satu.

Seperti yang tampaknya sudah Anda temukan, sebagian besar dunia korporat berjalan dengan kecepatan dan harga.


17
Sebenarnya Anda akan beruntung untuk memilih bahkan 2, sebagian besar tempat hanya memilih 1
softveda

1
Faktanya, ada lebih dari ketiganya - ada juga ruang lingkup (alias fitur), kompatibilitas, keamanan, kegunaan hanya untuk beberapa nama. Seperti biasa, mendapatkan hasil yang baik adalah tentang memilih kompromi terbaik (seperti biasa dalam hidup ...).
sleske

Saya setuju dengan kedua komentar, tetapi ini adalah contoh tingkat yang sangat tinggi. Dalam contoh ini Anda mungkin hanya ingin meletakkan ruang lingkup (alias fitur), kompatibilitas, keamanan, kegunaan di bawah judul "kualitas".
AnthonyBlake

1
@AnthonyBlake: Ya, saya tahu. Saya tidak ingin merusak contoh yang bagus, maaf :-).
sleske

+1 untuk jawaban yang bersaing ini untuk saya. Waktu, Biaya, dan Kualitas adalah segitiga penting untuk diingat. Menggunakan tiga kata membuatnya lebih mudah untuk mempromosikan dan berbagi dan berdiskusi dengan orang lain.
Michael Durrant

6

Tidak sepenuhnya menunjukkan industri, tetapi dari pengalaman saya yang terbatas 5+ tahun. Saya akan bekerja melalui magang Anda dan mengambil sebanyak mungkin pelajaran dari pengalaman. Cari tanda dan indikator. Misalnya untuk posisi Anda berikutnya, Anda tanpa ragu harus melalui serangkaian wawancara. Proses ini adalah jalan dua arah, dan memberi Anda kesempatan untuk merasakan perusahaan. Ini sangat penting dan kemungkinan akan mengarah pada kebahagiaan dan kesejahteraan Anda sendiri.

Singkatnya, temukan tanda-tanda dongeng;

  • Siapa yang menjalankan perusahaan? Apakah itu manajer tunggal, tim pemasaran (jika demikian, menjauhlah), tim pengembangan, dll. Sudut ini berarti Anda mungkin mendapatkan lebih banyak atau lebih sedikit pengaruh untuk proyek, waktu yang dihabiskan untuk proyek, dll.
  • Apakah ada penghargaan teknis? Lihatlah bagaimana manajemen, penyelia, dan anggota tim memperlakukan satu sama lain. Saya telah dalam sebuah wawancara di mana para manajer telah melakukan semua jenis gerakan alis begitu pemimpin teknis mulai berbicara. Setelah itu dan belajar mereka tidak menggunakan kontrol sumber - Anda tidak bisa menunjukkan pintu cukup cepat.
  • Tujuan bisnis? Apakah perusahaan hidup hari demi hari, seperti dalam target keuangan harian, atau apakah ia memiliki rencana jangka panjang yang menjadi bagian Anda. Pengembangan perangkat lunak umumnya dilakukan selama berbulan-bulan sehingga memiliki perusahaan dengan sifat skizofrenik biasanya mengarah pada perangkat lunak yang berantakan.
  • Gali sekitar - ketika mengajukan pertanyaan teknis dan lihat apakah orang-orang mengocok. Kontrol sumber, kontrol dokumen, proses rilis, laporan bug, gaya manajemen, T&C, dll.

Jadi hiduplah dan pelajari, dan pikirkan tentang peran Anda selanjutnya. Memiliki pengalaman buruk tidak terlalu buruk, karena Anda akan lebih terdidik tentang dunia kerja & bisnis.


4

Yah, saya menjalankan pada dekade kedua saya dalam bisnis, dan saya dapat memberitahu Anda bahwa kode bersih sempurna sangat jarang terjadi, dan ketika itu terjadi, itu tidak lama tetap seperti itu. Pada umumnya Anda akan menemukan diri Anda terus-menerus berusaha memperbaiki kesalahan masa lalu, sementara (sedih) dipaksa oleh kendala waktu dan kepemimpinan yang buruk untuk melakukan kesalahan saat ini.

Kecuali jika Anda berada dalam jenis bisnis perangkat lunak yang sangat spesifik, tekanan untuk mengeluarkan produk fungsional keluar dari pintu mengesampingkan semua masalah lain, dan pengoptimalan di luar titik tertentu dianggap tidak ada gunanya. Jika program berjalan dalam 5 menit, dan kami hanya perlu menjalankannya dalam 5 menit, tidak ada yang akan memberi Anda beberapa minggu untuk menjalankan runtime menjadi 2 menit.

Jika, dengan suatu keajaiban, Anda memiliki pertemuan sempurna dari manajemen yang kompeten, tujuan yang jelas, uang, bakat, dan waktu, dan Anda menghasilkan produk yang bersih dan unggul ... Satu-satunya cara itu akan tetap seperti itu adalah jika Anda tidak pernah menyentuh lagi . Pemeliharaan dan ekstensi hampir selalu diberikan prioritas yang sangat rendah, perubahan selalu diperlukan pada pemberitahuan nol secara efektif, dan akhirnya dikurung secara tidak teratur.

Saya sedang memikirkan proyek yang satu ini kemarin. Bagiku itu adalah mimpi pipa yang sangat jelas, sehingga aku memantulkan sedikit omong kosong yang sangat fungsional keluar dari pintu. Saya melihatnya sebagai pemborosan waktu dan sumber daya.

Nah, kejutan, kejutan, semua orang menyukainya dan itu berhasil dengan baik. Jadi saya melompat kembali ke papan gambar dan melakukannya dengan benar. Dan versi baru itu luar biasa! Tapi kemudian ada pergantian dalam manajemen dan semuanya dibatalkan demi "arah bisnis baru."

Iterasi kedua memiliki penyebaran yang benar-benar setengah-setengah dalam perusahaan, dan saya tidak pernah mendengar hal lain tentang itu, yang lucu karena saya tahu setidaknya ~ 10 unit bisnis masih menggunakannya (perangkat lunak yang kami siapkan untuk melakukan pekerjaan itu) hampir 2 tahun terlambat dari jadwal) dan tampaknya tidak pernah putus.

Ini membawa kita ke titik akhir saya. Bahkan jika Anda menghasilkan sesuatu yang ajaib, fakta bahwa itu bekerja dengan sangat baik berarti bahwa TIDAK seorang pun akan mengenalnya, dan ketika itu rusak (biasanya karena mereka melakukan sesuatu yang bodoh) maka mereka akan mengutuk nama Anda lebih buruk daripada mereka pernah mengutuk si idiot yang menulis hal yang merusak setiap Selasa ketiga.


2

Sulit untuk mengatakan apa yang Anda anggap kode kualitas sangat buruk, tapi ya beberapa programmer sangat baik (menurut definisi). Sebagai perangkat lunak berkembang, orang membuat kesalahan. Seiring berjalannya waktu ini, dan tekanan bisnis (dan kemalasan / kebodohan programmer) membuat refactoring ... Jarang.


Yah, untuk referensi, saya biasanya kode cukup cepat, tetapi dalam 6 minggu terakhir saya telah menghasilkan sekitar satu halaman kode, karena butuh waktu lama untuk menguraikan apa arti dari basis kode. Kurangnya komentar dilengkapi dengan nama acak untuk variabel dan fungsi (variabel anggota dinamai lokasi Asia adalah favorit saya ...).
tryAtAnonimity

1
Juga, apakah 50-60 jam minggu standar dalam pengembangan perangkat lunak?
tryAtAnonimity

2
Hanya di perusahaan yang buruk.
Wayne Molina

2
Tidak sama sekali dan itu sebabnya ini adalah pertanyaan "itu tergantung". Di startup dan sejenisnya? Tentu. Ditambah banyak lagi! Di Pendidikan Tinggi atau Governmnet, no. Dalam konsultasi, ya. Ditambah lagi. Mereka semua berbeda dalam bidang dan manfaat lain dan tentu saja $
Michael Durrant

1
ya, Anda akan menemukan bahwa Anda akan memerlukan keterampilan kompensasi gaya hidup yang berbeda di tempat kerja. Jam tetap, jam makan siang, dan larut malam sangat berbeda. Temukan hal-hal kecil dalam batasan yang dapat membantu dan mengingat waktu yang diberikan dan sikap yang baik, Anda akan menyesuaikan diri, dan Anda akan mendapatkan lebih banyak rasa hormat seiring berjalannya waktu dan akan memiliki lebih banyak kekuatan dan wewenang untuk melakukan sesuatu dengan cara Anda sendiri dan / atau dapatkan perubahan.
Michael Durrant

2

Tidak bisa bicara untuk semua orang, tapi ini yang bisa saya katakan.

Saya belum bekerja 30+ tahun di domain, tetapi saya melihat cukup untuk mengatakan beberapa hal. Sebuah proyek memiliki masa hidup yang sangat mirip manusia. Desain awal mungkin tidak sesuai dengan kebutuhan saat ini untuk katakanlah satu proyek setelah 20 tahun pembangunan. Yang mengatakan dalam jumlah waktu itu, banyak orang mengubah kode yang berantakan dengannya dan menambahkan hal-hal yang pada awalnya tidak mungkin dilakukan.

Tidak terlalu sulit membayangkan kode jelek pada proyek lawas atau proyek yang cukup lama. Kami tidak dapat mengharapkan semua orang untuk sepenuhnya memahami desain awal. Sedih, tapi memang begitu.

Yang mengatakan, Anda harus ingat bahwa refactoring proyek warisan tidak selalu mungkin dan kadang-kadang bahkan tidak diinginkan. Saya bekerja di perusahaan tempat mereka mengembangkan pengganti untuk proyek yang sedang saya kerjakan. Saya tidak diizinkan untuk terlalu banyak memperbaiki proyek saya karena takut itu akan bekerja lebih baik daripada proyek baru. Saya cukup yakin tidak ada cara proyek ini bisa bekerja lebih baik daripada yang baru. frasa itu agak seperti "Jangan membuatnya lebih baik, hanya membuatnya bekerja".

Akhirnya Anda tidak akan sering memiliki proyek semacam itu, karena saya sering membaca dan mendengarkan. Anda harus mencoba mencari pekerjaan dengan perusahaan rintisan alih-alih perusahaan besar. Startup cukup menarik dan pada akhirnya Anda bisa bergerak cepat jika Anda melihat itu tidak berjalan seperti yang Anda inginkan juga.

Juga satu hal yang dapat Anda lakukan, saya benar-benar tidak menjanjikan apa pun, tetapi jika Anda merasa kode itu benar-benar buruk dan perlu refactoring. Bagikan dengan tim. Ingatlah bahwa orang-orang yang menulis kode jelek itu mungkin bekerja dengan Anda. Ini bukan tentang menyakiti perasaan orang, tetapi jika Anda melihat bahwa proyek yang sedang Anda kerjakan akan runtuh setelah beberapa waktu dan orang akan menghabiskan lebih banyak waktu untuk memahami apa yang dilakukannya daripada meningkatkannya. Lebih baik berbicara dan mengomunikasikan masalah daripada menyimpannya sendiri. Jika Anda cukup beruntung, Anda mungkin akhirnya akan refactoring proyek.

Jika Anda akhirnya refactoring proyek, Anda mungkin menjadi orang yang ditunjuk untuk pilihan desain yang buruk! Dan Anda mungkin mengerti mengapa refactoring tidak sering terjadi. Mudah-mudahan jika seluruh tim harus refactor, maka tidak ada yang bisa menunjuk. Mereka hanya akan memecat semua orang =)


2

Saya akan mencoba meringkas jawaban untuk pertanyaan ini dengan kutipan sederhana:

All code turns to crap given enough time and hands.

Sisanya hanya cerita ...


Dan kode yang berfungsi, betapapun jeleknya, akan tetap dalam produksi JAUH lebih lama dari yang dipercayai para pembuat kode.
Jennifer S

2

Kualitas Kode terutama tergantung pada dua faktor.

Pertama selalu uang. Perusahaan yang memiliki tekanan selamat tinggi biasanya membayar upah rendah, melibatkan pengembang yang kurang berpengalaman, memiliki jadwal yang ketat dan tidak punya waktu atau uang untuk memanfaatkan pengembang mereka.

Kedua adalah manusia. Pertama-tama mereka yang memutuskan anggaran harus memilih pengeluaran dalam kualitas kode, maka mereka harus melibatkan orang-orang yang ingin "menjalaninya". Seperti yang dapat Anda bayangkan, Mungkin akan sulit untuk mengubah seorang programmer Delphi top-down-Delphi berusia lima puluh tahun yang dibayar (tidak berniat membuat stereotip, maaf) menjadi Pengembang Java Terkini yang melakukan CI Builds dan memproduksi kode yang digabungkan secara longgar. Banyak pengembang tidak menyukai pelajaran oleh orang-orang (mungkin yang lebih muda), mereka tidak suka seseorang memancing di kolam mereka - atau menggetarkan takhta mereka.

Jadi dengan mengatakan itu, dan juga mempertimbangkan fakta bahwa Anda memiliki kode warisan di sebelah setiap perusahaan, saya akan mengatakan Anda mendapatkan banyak dari itu di kehidupan nyata. Yang bisa Anda lakukan adalah berperilaku seperti pemboikot: Pergi ke hutan, ambil sampah dan bersihkan. Lain kali Anda akan memiliki sedikit kekacauan untuk melangkah.


2

Selamat datang di kode dengan anggaran! Ada perbedaan besar ketika pengembangan didorong oleh manajemen untuk dilakukan terlalu cepat, tanpa perencanaan, dan dengan memotong sudut. Saya memiliki pengalaman yang sama dengan kejutan dunia nyata ketika saya mendapatkan pekerjaan pemrograman pertama saya keluar dari perguruan tinggi. Tidak ada dokumentasi! Seiring waktu saya belajar banyak dari waktu ke waktu, menulis dan menjaga dokumentasi formal tetap terkini hanyalah buang-buang waktu. Beruntung bagi saya, itu adalah tim yang luar biasa. Itu dipimpin oleh seorang pria yang tahu apa yang dia lakukan dan anggota tim lainnya benar-benar peduli tentang menulis kode dengan cara yang benar. Sejak itu, pengalaman saya mirip dengan Anda. Banyak kode mengerikan, banyak kode buruk, banyak "pengembang" yang tidak mengerti. Untuk setiap pengembang yang baik, tampaknya ada 100 yang buruk.

Anda tidak ditakdirkan untuk membenci pekerjaan Anda selamanya. Anda hanya perlu menemukan perusahaan yang cukup pintar untuk mengenali manfaat jangka panjang yang bersedia berinvestasi sedikit di muka. Saya telah berhasil membuktikan melakukan hal-hal dengan cara yang benar alih-alih yang tercepat bermanfaat dan menjadi sangat dihormati dan dipercaya untuk itu di perusahaan tempat saya bekerja. Seiring waktu, kode spageti diperbaiki atau menjadi usang dan kode Anda mengambil alih. Bersiaplah untuk berkompromi. Terkadang cara paling keren atau paling kuat untuk pemrograman sesuatu hanya berlebihan dan tidak apa-apa untuk melakukannya dengan cara cepat dan kotor.


1

Saya mendapat magang di salah satu perusahaan perangkat lunak utama

Tidak semua perusahaan sama. Anda akan menemukan tim jelek dan basis kode perangkat lunak jelek di sebagian besar perusahaan. Tetapi Anda juga dapat menemukan tim yang hebat dan basis kode yang hebat.

Saya pikir orang-orang di Solaris melakukan deskripsi yang sangat baik dan jujur ​​tentang jenis basis kode yang akan Anda temukan di perusahaan besar: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

Saya meninggalkan pekerjaan membenci pekerjaan setiap hari sejauh ini, dan saya sangat ingin tahu apakah ini yang ada di toko selama sisa hidup saya.

Tidak, saya telah mengkode selama lebih dari 15 tahun dan saya masih menyukainya.

Itu tidak berarti bahwa semuanya telah sempurna. Saya telah melihat beberapa basis kode yang mengerikan dan juga beberapa yang hebat. Kuncinya adalah menemukan tempat yang tepat untuk Anda.

Perusahaan besar sangat berbeda dengan yang kecil. Dalam tim perusahaan yang sama, A kadang-kadang sangat berbeda dengan tim B. Temukan yang memiliki keseimbangan yang tepat untuk Anda (misalnya proyek yang menantang, budaya yang Anda nikmati, bayaran baik, dan lain-lain)

Semoga berhasil!


Tidak hanya semua perusahaan tidak sama, tetapi di perusahaan besar tidak semua kelompok adalah sama. Terkadang, kelompok yang berbeda terikat oleh proses peninjauan yang sama sekali berbeda. Perhatikan bahwa tidak apa-apa untuk terus-menerus bertanya kepada manajer wawancara (dan jika Anda memiliki akses ke mereka, programer wawancara) seperti apa praktik terbaik yang mereka ikuti. (Perhatikan bahwa jawaban programmer tidak akan berguna jika bos berada di ruangan bersama mereka.)
Novak

1

Saya telah melihat hal yang sama seperti Anda. Saya memiliki dua pengalaman kasus ketika itu terjadi.

  1. Ketika pengembangan terlalu didorong oleh proyek. Satu-satunya hal yang penting adalah memberikan fungsionalitas tepat waktu, lalu keluar. Perubahan selanjutnya akan dilakukan oleh orang lain, oleh beberapa manajer tim / proyek lain dengan anggaran baru.
  2. Ketika sebuah perangkat lunak dikelola oleh hanya beberapa orang dalam waktu yang lama, pengembang cenderung menjadi malas, karena mereka tahu perangkat lunak mereka. Prinsip akademis jauh sekali.

Sedih, tapi begitulah di beberapa tempat.

Lihat apakah Anda dapat membuat perubahan kecil menjadi lebih baik, membiasakan diri atau mengubahnya ke perusahaan lain dan meminta untuk menyaring beberapa kode saat wawancara :-)


1

Ini akan menjadi jawaban singkat.

Pendidikan sangat berguna untuk membuat Anda merasa berkualitas dan idealis. Ini adalah hal yang baik, dan Anda harus berusaha mempertahankan idealisme.

Jika Anda benar-benar objektif, dan Anda dapat melihat kembali pekerjaan Anda sendiri di masa depan, itu tidak akan menjadi pengalaman yang sangat memuaskan. Kecuali Anda membohongi diri sendiri atau tidak belajar apa pun, Anda akan melihat banyak cara untuk meningkatkan apa yang telah Anda lakukan.

Secara umum, seluruh dunia melakukan ini di sekitar Anda. Jadi, ketika Anda melihat pekerjaan dari masa lalu, kecuali pengecualian, itu akan tampak lebih rendah dan membutuhkan perbaikan. Jika Anda tidak merasa seperti ini, itu berarti Anda melakukan pekerjaan yang salah, atau membayarnya terlalu baik.

Berita baiknya adalah, Anda dapat mengambil manfaat dari kesalahan orang lain dan dari perbandingan dengan masa lalu. Jika semua aplikasi bekerja dengan baik dan mudah untuk mempertahankan pengembang baru tidak akan diperlukan. Menurut pendapat saya, mempertahankan beberapa pengembang lain merupakan pengalaman belajar yang berguna dan harus menjadi elemen pelatihan wajib untuk semua pengembang langit biru.


1

Pengalaman negatif Anda terlalu khas dari perusahaan merek-merek besar terkenal yang banyak pengembang pelajari untuk mendekati dengan lebih hati-hati dan gentar daripada yang mereka lakukan saat pertama kali mereka memiliki kesempatan untuk bekerja di satu. Pada dasarnya, semakin banyak lapisan manajemen yang Anda miliki, semakin biasa-biasa saja diperjuangkan. Manajer menengah tidak melaporkan kepada manajer atas tentang kualitas kode. Mereka melaporkan fitur-fitur yang dikirimkan dalam jumlah waktu X dan memberikan presentasi powerpoint pada fitur UI neato yang mereka harapkan berfungsi cukup lama untuk menyelesaikannya. Jika semuanya runtuh satu bulan kemudian, itu biasanya masalah orang lain dan mereka tahu itu.

Jadi ya, para devs yang hidup di tempat-tempat seperti itu cenderung tidak terlalu peduli. Mereka tidak bisa bertahan di sana jika mereka melakukannya. Saya pernah mendengar tentang Lembah Silikon, bahwa jika Anda ingin malas, bekerjalah untuk salah satu nama besar. Jika Anda ingin pekerjaan yang menarik, cari startup yang lebih baru yang belum menjadi nama rumah tangga. Saya bekerja di Chicago dan dapat menjamin fenomena serupa di sini.

Sebagai aturan umum (dengan banyak pengecualian saya yakin), Anda akan menemukan apresiasi yang lebih tinggi untuk kode kualitas di perusahaan yang lebih kecil dan dikelola atau dimiliki oleh orang-orang yang juga terus menulis kode. Kompensasi sering kurang, tetapi pekerjaan sering jauh lebih bermanfaat menurut saya.

Sebagai pengembang tingkat pemula, Anda tidak mungkin memiliki banyak kendali atas siapa Anda bekerja pada awalnya, tetapi saya akan mengatakan bahwa memiliki nama besar di resume Anda selama setahun atau lebih pasti menggairahkan perekrut dan SDM. Juga, Anda dapat belajar sedikit yang tidak akan Anda pelajari jika tidak bekerja untuk seseorang yang benar-benar mengerikan dalam enam bulan pertama atau lebih dan itu juga membantu Anda mendapatkan pegangan yang lebih baik mengenai praktik terbaik mana yang benar-benar penting dan mengapa dan mana yang hanya merupakan teknologi. mode.

Dan tentu saja ketika bekerja dengan alat korporat populer yang lebih utama, Anda akan cenderung menemukan bahwa tingkat bakat rata-rata akan sangat payah. Jika keterampilan utama Anda adalah kombinasi dari Java dan C #, perluas wawasan Anda sedikit. Anda mungkin menemukan ceruk yang lebih bahagia di tulisan tingkat menengah Erlang atau Python atau: o JavaScript.

Dan jangan biarkan orang lain memberi tahu Anda perbedaan. Anda mungkin tidak punya pilihan dalam hal bagaimana melanjutkan tetapi kode omong kosong! @ # $ Ing mahal.


-2

Pertanyaan Anda terfokus pada magang. Saya tidak pernah punya pemrograman, tetapi magang di stasiun radio, tidak benar-benar berlaku di sini.

Pertanyaan Anda juga menyebutkan pengalaman Anda selama magang. Pengalaman magang Anda dan jawaban yang telah Anda terima sejauh ini semuanya meringkas pengalaman saya, setelah apa yang sekarang menjadi perangkat lunak penulisan selama dua puluh tujuh tahun (mulai pertengahan Juni 1985).

Saya tidak pernah percaya saat sekolah ketika instruktur kami mengatakan ada lebih banyak pemikiran daripada menulis kode. Mereka benar. Dan, jika Anda mencoba mencari tahu kode orang lain, itu lebih buruk tanpa komentar, dan hampir sama buruknya dengan komentar. Cobalah mempertahankan sistem pengumpulan pajak kota-rumah tanpa komentar, tanpa dokumentasi, tidak ada bangunan formal, dan tanpa kontrol kode sumber.

Kapan pun Anda bisa melakukannya dengan baik tanpa langsung melanggar perintah standar, maka lakukan dengan baik. Selalu ingat, lebih mudah untuk meminta maaf karena melakukan sesuatu yang Anda tidak minta izin untuk dilakukan daripada memiliki izin tidak diberikan dan bertentangan dengan perintah langsung.

Jangan lupa standar yang Anda pelajari di sekolah. Mereka tidak sia-sia, tetapi kemungkinan besar standar-standar itu adalah asimtot dalam batas Kalkulus. Anda selalu dapat mencoba mendekati mereka, tetapi Anda mungkin tidak pernah mencapai nilai mereka.

Semoga berhasil.

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.