Harapan lulusan versus kenyataan [tertutup]

Ketika memilih apa yang ingin kita pelajari, dan lakukan dengan karier dan kehidupan kita, kita semua memiliki beberapa harapan tentang seperti apa jadinya nanti. Sekarang saya telah berada di industri ini selama hampir satu dekade, saya telah sedikit merenungkan apa yang saya pikirkan (ketika saya belajar Ilmu Komputer) pemrograman akan seperti apa kehidupan kerja, dan bagaimana itu sebenarnya berubah menjadi menjadi.

Sejauh ini, dua kejutan terbesar saya (atau harus saya katakan, harapan rusak) adalah banyaknya pekerjaan pemeliharaan yang terlibat dalam perangkat lunak, dan kurangnya profesionalisme:

1. Pemeliharaan : Di uni, kami semua diberitahu bahwa sebagian besar pekerjaan perangkat lunak adalah pemeliharaan sistem yang ada. Jadi saya tahu untuk mengharapkan ini secara abstrak. Tetapi saya tidak pernah membayangkan betapa luar biasanya hal ini nantinya. Mungkin itu adalah sesuatu yang secara mental saya sayu, dan berharap saya akan membangun lebih banyak barang baru yang keren dari awal. Tetapi sebenarnya adalah sebagian besar pekerjaan sangat pemeliharaan, perbaikan bug, dan berorientasi dukungan.

2. Kurangnya profesionalisme : Di uni, saya selalu mendapat kesan bahwa pekerjaan perangkat lunak komersial sangat berorientasi pada proses dan direkayasa secara ketat. Saya memiliki gambar proses ISO, rim dokumentasi teknis, setiap fitur dan bug yang didokumentasikan secara ketat, dan lingkungan yang umumnya profesional. Itu merupakan kejutan besar untuk menyadari bahwa sebagian besar perusahaan perangkat lunak beroperasi tidak berbeda dengan tim siswa yang bekerja pada proyek besar sepanjang semester. Dan saya telah bekerja di toko retas kecil, dan perusahaan menengah. Walaupun saya tidak akan mengatakan bahwa itu selalu "tidak profesional", rasanya industri perangkat lunak (secara keseluruhan) jauh dari disiplin teknik yang kuat seperti yang saya harapkan.

Adakah orang lain yang memiliki pengalaman serupa dengan ini? Apa cara di mana harapan Anda akan seperti apa profesi kita akan berbeda dengan kenyataan?

Saya merasa Anda laki-laki. Saya baru saja lulus sedikit lebih dari setahun yang lalu, melompat pada tawaran pekerjaan pertama yang datang kepada saya dan mendapat kejutan terbesar dalam hidup saya.

Hal-hal yang tidak saya harapkan:

Stres sekolah dan Stres kerja tidak sama - Stres bekerja pada proyek sekolah dengan teman-teman, atau bekerja sendiri, bahkan dengan tenggat waktu tesis yang menjulang atau pertahanan proyek khusus tidak sebanding dengan stres tenggat waktu kerja yang tampaknya tidak masuk akal, masalah komunikasi , (sedikit politik kantor) dan masa krisis.

Kurangnya Praktik Terbaik - Sama seperti pengalaman Anda tentang profesionalisme. Sebelum mengambil pekerjaan pertama saya dan selama periode pelatihan saya, saya bergegas meninjau dan membaca tentang praktik terbaik dalam pemrograman dan rekayasa perangkat lunak. Ini tidak diikuti sebagaimana mestinya karena tidak praktis dan, untuk alasan yang adil, praktis. Dan kadang-kadang, pengetahuan Anda tidak berarti banyak terhadap orang lain yang hanya takut pada yang tidak diketahui dan memperlakukan praktik ini dengan jijik.

Apa yang mereka ajarkan di sekolah hanyalah puncak gunung es - Berpikir bahwa apa yang saya pelajari belajar sendiri dan dari kelas sudah cukup untuk membuat saya lulus, saya terkejut untuk sedikitnya ketika saya menatap tercengang pada potongan pertama kode saya. seharusnya mempertahankan. Banyak keterampilan yang saya gunakan sekarang dipelajari di pekerjaan atau selama pekerjaan saya yang saya terus bertanya-tanya apakah saya bisa membuatnya tanpa gelar sarjana sama sekali. XD

Pentingnya Komunikasi - Membuat saya sadar untuk apa semua kelas bahasa Inggris itu. Sebelum dunia nyata, saya tidak bisa melihat relevansi memiliki tiga hingga empat kelas bahasa Inggris yang berbeda di perguruan tinggi ketika sudah diajarkan sejak kami di kelas satu. Anda tidak berguna dalam pekerjaan Anda ketika Anda dapat berbicara dengan komputer tetapi gagal berbicara dengan orang lain.

Sebagian besar pekerjaan yang Anda lakukan tidak merusak

Ketika di Uni, saya bekerja pada rutinitas AI untuk mengendalikan robot yang bermain sepak bola, saya membuat kompiler dan meretas kernel sistem operasi.

Namun di dunia nyata, 99% ^* pengembangan perangkat lunak sebenarnya cukup membosankan. Saya selalu mengagumi arsitek atau pembangun yang, ketika ditanya "apa pekerjaan Anda?" dapat menunjuk ke sebuah bangunan atau apa pun dan mengatakan "Saya melakukan itu ". Tetapi kebanyakan pengembang perangkat lunak tidak dapat melakukan itu. Ketika ditanya "apa pekerjaanmu?" yang paling dekat dengan yang pernah saya dapat datang adalah ketika saya dulu bekerja untuk sebuah perusahaan yang membangun perangkat lunak yang memproses pesan SMS untuk stasiun radio dan sejenisnya ... Saya bisa mengatakan, "Anda tahu kapan Anda mengirim pesan teks ke sebuah stasiun radio untuk memilih lagu, yah saya menulis perangkat lunak yang memproses suara dan barang-barang itu. " Masih belum ada yang sedingin mungkin menunjuk ke sebuah bangunan dan berkata "Aku membangun itu."

Tentu saja, ada yang orang yang bisa mengatakan "Saya bekerja pada Windows" atau apa pun, tapi aku yakin mereka tidak benar-benar memberitahu siapa pun bahwa karena takut pertanyaan makhluk berikutnya "Saya tidak bisa mendapatkan printer saya untuk bekerja, bisakah kamu memperbaikinya untukku? "

^* dan 62% dari semua statistik dibuat di tempat

Jika Anda melihat perangkat lunak hari ini, melalui lensa sejarah teknik, itu pasti semacam rekayasa — tapi itu jenis rekayasa yang dilakukan orang tanpa konsep lengkungan. Sebagian besar perangkat lunak saat ini sangat mirip dengan piramida Mesir dengan jutaan batu bata bertumpuk satu sama lain, tanpa integritas struktural, tetapi hanya dilakukan dengan kekuatan kasar dan ribuan budak. -Alan Kay, 2004

wawancara lengkap: http://queue.acm.org/detail.cfm?id=1039523

Saya bukan dokter hewan industri; Justru sebaliknya, saya lulusan baru tetapi dari sekolah CS top di AS Tapi perasaan insting saya adalah bahwa cara kita membangun perangkat lunak salah. Alih-alih menekan tombol jeda dan memeriksa kembali dasar-dasar bagaimana kami memprogram kami baru saja bergegas maju menggunakan model tanggal dari 50-an, 60-an terus menambahkan sedikit gula di atas. Jika kita terus seperti ini, kita tidak akan pernah melewati di mana kita berada. Manusia tidak bisa mengelola kompleksitas hal-hal yang merupakan ukuran dari basis kode MS Windows. Kami membutuhkan cara baru. Saya tidak tahu apa itu.

Saya pikir ini adalah alasan yang mendasari perasaan bahwa toko-toko perangkat lunak besar dan kecil tampaknya membuat perangkat lunak dengan meretasnya bersama tanpa pemahaman mendalam tentang prinsip-prinsip dasar.

Saya tidak mendapatkan gelar, tetapi saya mengambil sedikit di perpustakaan dan laboratorium perguruan tinggi dan universitas.

• Big Iron - Teknologi yang mereka ajarkan terutama mainframe dan minicomputer. Dekan satu perguruan tinggi memberi tahu saya bahwa saya tidak akan bisa mendapatkan pekerjaan karena saya bahkan tidak tahu apa itu masterfile. Saya tidak punya niat untuk mengerjakan mainframe karena saya tidak mampu membelinya, tapi saya tidak akan sebodoh itu untuk tidak sedikit dipersiapkan. VAXen keren, dan saya berharap mendapat bayaran untuk kode Micro VAX saya sendiri di bilik saya. Sayang sekali pasar itu benar-benar meledak. (Ternyata saya memiliki dua posisi bekerja dengan mainframe ... sebagai kontraktor untuk IBM.)

• Rekayasa Perangkat Lunak - Setelah Pemrograman Terstruktur, SASD, dan metodologi desain lainnya, Anda mungkin berpikir kami akan menjadi insinyur nyata. Aku melakukannya. Tetapi para guru hanya memberikan sedikit panduan tentang teknik desain yang saya baca di perpustakaan. Siswa dibiarkan berjuang sendiri dan micros membuatnya terlalu mudah untuk men-flail kode sampai mereka mendapatkan jawaban yang mereka sukai. Saya tidak menyadari betapa buruknya itu di pasar kerja. Entah bagaimana saya harus melakukan sedikit kode baru, jadi itu tidak terlalu membosankan. Tetapi saya juga mengambil banyak, dan mereka cukup buruk itu seperti proyek baru karena saya harus memperbaiki banyak kode. Itu adalah kombinasi meneliti fungsi yang ada dan membuat kode baru (penggantinya); alat tulis untuk menyederhanakan proses dan melembagakan manajemen proyek yang lebih baik.

• Karir teknologi tinggi - Ini adalah satu hal ketika sekolah memiliki bangunan dan peralatan lama (peralatan punch card diganti semester sebelum saya mulai ... pada tahun 1984), tetapi ketika Anda bekerja di gudang yang kurang terang atau untuk bos yang menutup telepon pada pelanggan yang menghubungi saluran dukungan, Anda mulai menyadari bahwa deskripsi pekerjaan Anda tidak mungkin mencakup memasak popcorn dengan laser 5-megawatt.

• Pengembangan terutama kerja tim. Itu berarti bahwa komunikasi (lisan dan membaca), membaca kode orang lain dan menggunakan kembali modul sebelumnya (baik internal dan eksternal) adalah sesuatu yang harus dihadapi hampir setiap hari. Di kampus saya, paling tidak saya harus membuat kode dengan lebih banyak orang dalam beberapa kesempatan, jadi saya pikir bagian utama dari pekerjaan itu adalah untuk membuat kode sendiri, di hutan belantara. Bukan itu.
• Menjelaskan hal-hal kepada non-pengembang itu sulit (juga dibahas untuk poin pertama), dan merupakan tanggung jawab Anda untuk menyampaikan poin Anda (bukan dari 99% lainnya di dunia).
• Tes yang baik adalah tes yang gagal. (pertama kali, setidaknya) Dan, tentu saja, tidak ada kode bebas bug. Anda bukan programmer yang buruk jika Anda memiliki bug. Bug hanyalah bagian (sangat penting dan menghabiskan waktu) dari pekerjaan Anda.
• Tidak ada peluru perak. Setiap teknologi memiliki kelebihan dan kekurangan.
• Perguruan tinggi tidak mengajarkan Anda teknologi tercanggih. Tetapi juga, 90% karya menggunakan teknologi yang cukup tua. Ngomong-ngomong, kadang-kadang itulah yang dibutuhkan.
• Orang-orang non-teknis membuat keputusan tentang solusi teknis , sebagian besar untuk alasan esoteris seperti pemeliharaan, kemitraan, ketersediaan pekerja ...
• Anda baru mulai , padawan muda .

Saya mulai menyadari sejak saat itu tentang fakta bahwa pengkodean adalah pekerjaan yang Anda lakukan bersama dengan lebih banyak orang, khususnya sekarang bahwa open-source lebih menonjol. Tetapi ketika saya masih kuliah (akhir tahun sembilan puluhan), saya yakin bahwa saya akan melakukan sesuatu dari awal dan tidak pernah melihat ke kode orang lain atau harus berkoordinasi dengan orang lain ...

Melihat ke belakang, bagi saya salah satu bagian terbaik adalah belajar dan mengajar orang lain .

• Pemrograman komputer adalah non-fisik dan non-intuitif.
  • Ketika seorang pembangun rumah menyelesaikan pekerjaannya, ia dapat berjalan-jalan dan segera melihat / merasakan jika ada sesuatu yang salah. Bug pemrograman komputer tidak dapat ditemukan dengan cara yang sama, dan dapat mengintai di sistem selama berbulan-bulan, atau bahkan puluhan tahun.
  • Sementara seorang programmer dapat melihat / merasakan sepotong kode sumber melalui tinjauan kode, itu tidak dijamin untuk menemukan setiap kesalahan yang terkandung dalam kode. Komputer, bagaimanapun, akan mampu mereproduksi kesalahan dengan tepat setiap kali dengan menjalankan program dengan input tertentu. Dengan demikian, pemahaman manusia tentang sepotong kode sumber selalu merupakan model esensi yang tidak sempurna yang menjadi petunjuk bagi komputer.
• Sangat mudah untuk membuat kode program yang menangani kasus yang paling umum, tetapi sepenuhnya gagal menangani kasus tepi.
  • Dalam disiplin lain, relatif mudah untuk menerapkan tindakan perbaikan setelah fakta. Bahkan mungkin ada badan pengetahuan khusus yang dikhususkan untuk tindakan perbaikan. Tidak ada hal seperti itu dalam Pengembangan Perangkat Lunak.
  • Untungnya, pengembangan yang digerakkan oleh tes membantu mengkodifikasi kasus tepi yang seharusnya ditangani oleh kode.
  • Ditambahkan Di sisi lain, metodologi pengembangan perangkat lunak tertentu tampaknya menunjukkan bahwa kita dapat mengekstraksi nilai bisnis (waktu lebih cepat ke pasar, dll.) Dengan secara sadar memilih untuk tidak menangani kasus tepi, dan untuk mengomunikasikan keputusan tersebut kepada pelanggan.
• Pelanggan dapat menemukan nilai bisnis dalam perangkat lunak yang hanya menangani kasus yang paling umum, oleh karena itu penyedia perangkat lunak tidak terlalu khawatir tentang penanganan kasus yang jarang terjadi.
  • Pelanggan hanya belajar untuk menghindari sisi yang kasar.

Ditambahkan

• Keanggunan kode sumber tidak dihargai.
  • Pelanggan tidak melihat keanggunan kode sumber. Mereka hanya melihat keanggunan antarmuka pengguna dan interaksi.
  • Programmer, di sisi lain, biasanya tidak menghargai keanggunan antarmuka pengguna, dan mereka biasanya tidak tinggal dalam satu proyek untuk waktu yang cukup lama untuk mulai menghargai desain perangkat lunak yang elegan.
  • Karena baik pelanggan maupun pemrogram tidak menghargai keanggunan kode sumber, tidak akan dinilai oleh bisnis.

Ditambahkan

Dua sen saya: biasakan saja.

Gambar proses ISO, rim dokumentasi teknis, setiap fitur dan bug yang didokumentasikan secara ketat, dan lingkungan yang umumnya profesional menggambarkan perusahaan saya dengan cukup baik. Kami melakukan produk infrastruktur software / hardware penting, jadi, baik, tekanan pada kualitas (kita ISO 9001, misalnya).

Saya pikir setelah lulus bahwa orang-orang yang bertanggung jawab akan dapat mengenali pekerjaan yang baik dari pekerjaan yang buruk. Setelah menyerahkan salinan sejuta "kode hebat yang disatukan oleh pembuat kode teratas kami" dan membuatnya terlihat seperti ini:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Aku hampir menyerah berusaha memahami apa yang terjadi di antara telinga bos berambut runcing. "Hebat" berarti mimpi buruk pemeliharaan, "baik" berarti crash dalam angin sepoi-sepoi, dan "kekacauan mengerikan" berarti entah itu atau basis kode yang terstruktur dengan baik yang para insinyurnya menolak untuk memenuhi tenggat waktu yang tidak senonoh hanya untuk menjaga kewarasan mereka.

Saya telah mendengarnya berpendapat bahwa semua rekayasa perangkat lunak setelah baris pertama kode adalah pemeliharaan. Dan itu sepertinya cocok dengan pengalaman saya. Satu-satunya kode yang saya tulis yang tidak memiliki sebagian besar biaya pemeliharaan adalah kode yang tidak berhasil sehingga tidak pernah atau hanya digunakan secara singkat.

Saya pikir Anda dapat menemukan tim teknik yang disiplin yang mengembangkan dan mengikuti proses yang kuat yang mengarah pada pelepasan kode yang kuat dimana tim dapat memiliki tingkat kepercayaan yang tinggi (walaupun saya tidak akan berbelit-belit dengan dokumentasi dalam jumlah besar). Saya percaya bahwa saya bekerja di tim seperti itu saat ini. Meskipun saya sudah pasti mengalami jenis perkembangan lainnya.

Namun hal yang saya hargai adalah, tantangannya tidak selalu menemukan algoritma yang sempurna atau solusi terbersih untuk masalah tersebut. Tetapi seringkali menukar semua jenis kendala (sumber daya, pengetahuan, uang, waktu, keterampilan, risiko, pelatihan pengguna yang sudah ada, dll., Dll) untuk mencapai pengembalian tertinggi untuk investasi yang tersedia. Yaitu membangun sistem yang paling cocok untuk semua faktor itu dan bukan hanya pengaruh teknis.

Banyak perangkat lunak yang tidak membuatnya cukup sampai digunakan / dibeli cukup. Ketika seseorang berhasil, ia cenderung bertahan dan hanya "kacau" dalam pemeliharaan.

Harapan pengguna meningkat setiap hari untuk fitur, tetapi di banyak bidang, mereka lebih rendah di bidang teknik. Mari kita asumsikan perangkat lunak transaksi perbankan sekokoh dan direkayasa secara profesional seperti mobil modern. Penanganan volume adalah keajaiban modern, tetapi apa tentang keandalan setiap transaksi? Tidak terlalu banyak. Posting Anda tentang omong kosong pertama anak anjing Anda di karpet dijatuhkan, jadi apa. Ini lebih seperti kantong plastik kecil di toko kelontong. Mereka menghasilkan miliaran dari mereka, mereka merobek-robek dan dibuang. Kebanyakan orang tidak cukup peduli untuk meminta tas yang lebih baik.

Saya pikir perangkat lunak berkualitas akhirnya dibuat. Beberapa di antaranya mencapai pasar lebih cepat daripada kebanyakan produk komersial. Siapa yang bisa mengendarai mobil dalam Beta?