Saya baru saja memulai karir saya sebagai pengembang web untuk perusahaan menengah. Segera setelah saya mulai, saya mendapat tugas untuk memperluas aplikasi yang sudah ada (kode buruk, dikembangkan oleh banyak programmer selama bertahun-tahun, menangani tugas yang sama dengan cara yang berbeda, struktur nol).

Jadi setelah saya berhasil memperpanjang aplikasi ini dengan fungsionalitas yang diminta, mereka memberi saya tugas untuk sepenuhnya memelihara aplikasi tersebut. Ini tentu saja bukan masalah, atau jadi saya pikir. Tetapi kemudian saya mendengar bahwa saya tidak diizinkan untuk memperbaiki kode yang ada dan hanya fokus pada perbaikan bug ketika bug dilaporkan.

Sejak saat itu saya memiliki tiga proyek lagi seperti di atas, yang sekarang harus saya pertahankan. Dan saya punya empat proyek di mana saya diizinkan membuat aplikasi dari awal, dan saya harus memelihara itu juga.

Pada saat ini saya sedikit mulai menjadi gila dari surat harian pengguna (baca pengelola) untuk setiap aplikasi yang harus saya pertahankan. Mereka mengharapkan saya untuk menangani surat-surat ini secara langsung sambil juga mengerjakan dua proyek baru lainnya (dan sudah ada lima proyek lagi setelah itu). Yang menyedihkan adalah saya belum menerima laporan bug tentang apa pun yang saya kodekan sendiri. Untuk itu saya hanya menerima permintaan perubahan 180 derajat yang berbeda-beda.

Lagi pula, apakah ini normal? Menurut pendapat saya, saya melakukan pekerjaan yang setara dengan seluruh tim pengembang.

Apakah saya idiot ketika awalnya saya mengharapkan hal-hal menjadi berbeda?

Saya kira posting ini telah berubah menjadi kata-kata kasar, tapi tolong katakan padaku bahwa ini tidak sama untuk setiap pengembang.

PS Gaji saya hampir sama jika tidak lebih rendah dari kasir di supermarket.

Selama salah satu magang saya, saya menemukan saya menghabiskan banyak waktu melakukan perbaikan bug. Anda harus menyadari bahwa sebagai karyawan entry level Anda tidak akan mendapatkan pekerjaan terseksi, Anda akan mendapatkan pekerjaan kasar yang tidak diinginkan orang lain. Sangat disayangkan, tapi begitulah pada setiap pekerjaan.

Selain itu, Anda harus menyadari bahwa bagi perusahaan, memiliki kode yang berfungsi lebih penting daripada memiliki kode yang bersih. Dari perspektif perusahaan Anda, Anda mengubah struktur yang ada adalah uang yang terbuang untuk mengulang sesuatu yang sudah dilakukan dan berpotensi menyebabkan lebih banyak kesalahan. Biasanya jenis perusahaan ini bukan perusahaan komputer / perangkat lunak sehingga tidak ada manajer yang cukup tinggi yang memiliki latar belakang teknis untuk mengetahui bahwa kadang-kadang Anda perlu melakukan perombakan besar ini. Yang mengatakan, jika perusahaan Anda dijalankan oleh orang-orang yang secara teknis kompeten dan mereka memahami nilai kode yang baik, Anda mungkin mendapatkan lebih banyak waktu luang, meskipun kadang-kadang Anda perlu memilih pertempuran Anda (tujuan utama bisnis masih menghasilkan uang, setelah semua ).

Yang mengatakan, Anda tidak masuk akal ingin dapat meninggalkan jejak Anda pada perangkat lunak dan menginginkan pekerjaan yang lebih bermakna. Sangat disayangkan bahwa Anda harus berurusan dengan begitu banyak proyek sekaligus sambil menerima permintaan dari begitu banyak manajer yang berbeda.

Sebagai seorang programmer, itu adalah fakta kehidupan bahwa Anda akan menghabiskan lebih banyak waktu untuk memelihara dan memodifikasi kode orang lain daripada Anda akan menulis sendiri dari awal. Jika ini merupakan masalah bagi Anda maka mungkin Anda harus tetap berkembang sebagai hobi dan mengejar karier yang berbeda. Jika Anda baik-baik saja dengan menjaga kode, tetapi Anda merasa tidak digunakan secara efektif atau kewalahan, maka itu adalah masalah yang perlu Anda diskusikan dengan manajer Anda. Jika masalah Anda lebih serius dari itu atau jika Anda merasa manajer Anda tidak tahu cara mengelola set keterampilan Anda secara efektif, maka akan lebih baik untuk mempertimbangkan mencari posisi di perusahaan lain. Mengingat gaji Anda yang rendah, ini mungkin tindakan terbaik Anda.

Sepertinya manajemen memiliki masalah mengelola beban kerja Anda dan memprioritaskan tugas. Anda harus berbicara dengan manajer Anda dan membuat mereka mengerti bahwa Anda kelebihan beban dan Anda tidak dapat melakukan pekerjaan yang efektif jika semua orang terus membombardir Anda dengan permintaan yang mereka inginkan segera dipenuhi.

Itu membuat Anda melompat dari satu tugas dan proyek ke yang lain, membuang banyak waktu untuk berpindah gigi di pikiran Anda. Untuk pekerjaan pengembangan perangkat lunak yang efektif, seseorang harus dapat membenamkan diri ke dalam tugas dan fokus sepenuhnya padanya. Semakin banyak gangguan yang didapatkan, semakin banyak waktu terbuang oleh pengalihan konteks. Penelitian menunjukkan bahwa dibutuhkan sekitar 15 menit untuk merendam dan mencapai tingkat aliran di mana pikiran kita bekerja paling efisien. Jika Anda mendapat gangguan setiap 15 menit, Anda tidak akan pernah bisa mengalir, yang merupakan pemborosan yang luar biasa bagi Anda dan perusahaan.

Jadi, Anda harus mencoba menegosiasikan mode kerja yang lebih masuk akal dengan manajer Anda . Ini harus mencakup memprioritaskan permintaan yang masuk dan perencanaan ke depan sampai batas tertentu . Semua permintaan pengguna harus disimpan dalam daftar, diurutkan berdasarkan prioritas. Dan prioritas tidak boleh diputuskan oleh pemohon (karena semua orang berpikir permintaannya adalah yang paling penting di dunia), bukan oleh Anda, tetapi oleh seseorang dengan pengetahuan bisnis yang cukup dan tinjauan umum dari berbagai macam produk yang Anda pertahankan ( yang pemilik produk ).

Idealnya, semua permintaan yang masuk harus dimasukkan ke pelacak masalah seperti JIRA atau Mantis . Atau setidaknya dikirimkan ke pemilik produk, bukan Anda. Dan dia harus menangani semua keluhan dari pengguna terlalu banyak "mengapa permintaan saya belum siap ?!", memungkinkan Anda untuk fokus pada pekerjaan pengembangan. Jika ini tidak dapat dicapai, Anda setidaknya harus menegosiasikan beberapa jendela waktu ketika Anda melihat permintaan yang masuk dan menanganinya, memesan sebagian waktu Anda tanpa gangguan hanya untuk pengembangan.

Jika ini memungkinkan, langkah selanjutnya adalah merencanakan ke depan sampai batas tertentu. Artinya, perkirakan waktu yang dibutuhkan untuk mengimplementasikan permintaan prioritas utama, kemudian jadwalkan waktu Anda ke dalam sprint , yang masing-masing mungkin satu atau lebih minggu, dan alokasikan tugas yang cukup ke sprint berikutnya untuk menutupi waktu Anda.

Anda mungkin ingin menyimpan sebagian dari waktu Anda untuk permintaan darurat yang masuk, tetapi sisanya dapat direncanakan sebelumnya. Dan Anda juga dapat memilih untuk mengorganisasikan pekerjaan pada proyek yang berbeda menjadi "coretan" yang terpisah, yaitu untuk bekerja pada proyek A pada hari Senin, proyek B pada Tueday-Rabu, proyek C pada Kamis pagi dan D pada sore hari, dll., Untuk lebih lanjut mengurangi pengalihan konteks.

Dengan cara ini Anda memiliki gambaran kasar tentang apa yang harus Anda lakukan dalam satu atau beberapa minggu ke depan. Selain itu, ini juga memberikan peta jalan kepada klien Anda: mereka dapat melihat kapan mereka menerapkan permintaan mana yang diterapkan. Anda mungkin atau mungkin tidak ingin menyebutkan kata "gesit" kepada manajer Anda di sini - ini pada dasarnya pengembangan tangkas , tetapi beberapa orang menentang tangkas tanpa benar-benar tahu apa itu :-)

Perhatikan bahwa meskipun posisi Anda saat ini nampaknya dinilai rendah oleh perusahaan Anda, semakin banyak proyek yang Anda pertahankan, semakin banyak kekuatan negosiasi yang Anda miliki .

Mencari dan melatih karyawan baru untuk mempertahankan semua proyek ini membutuhkan waktu (= uang) yang besar untuk perusahaan. Dan Anda dapat dengan tepat menunjukkan bahwa kode Anda jauh lebih baik daripada bagian sebelumnya dari aplikasi ini, jadi bukan karena mereka dapat dengan mudah menemukan kandidat dengan kemampuan yang sama untuk jumlah uang yang sama. Belum lagi jika mereka tidak meningkatkan kondisi kerja, mereka akan membuat orang berikutnya bosan dan berhenti secepat Anda ... Cobalah untuk membuat mereka mengerti bahwa demi kepentingan Anda sendiri adalah untuk menjaga Anda, dan untuk membuat Anda bahagia di mana Anda berada :-) Ini dapat memberi Anda kekuatan untuk menegosiasikan kondisi di atas, dan / atau meminta kenaikan gaji.

Seberapa besar kekuatan negosiasi yang Anda miliki - itu adalah pertanyaan besar. Manajemen Anda mungkin terbuka atau tidak terbuka terhadap ide-ide ini, dan mungkin atau mungkin tidak cukup menghormati Anda untuk menanggapi permohonan Anda dengan serius. Tetapi jika Anda memainkan kartu dengan baik, Anda memiliki peluang. Dan jika mereka menolak ... Anda selalu dapat mencari tempat kerja yang lebih baik. Situasi ini tidak sama untuk setiap pemula, walaupun (sayangnya) pengalaman Anda cukup khas. Tapi benar-benar ada tempat kerja yang lebih baik di luar sana . Kualitas tempat kerja hanya berkorelasi longgar dengan lokasi geografis, tetapi perasaan saya adalah bahwa di Eropa Utara Anda memiliki peluang lebih tinggi daripada rata-rata. Jadi, jika Anda tidak dapat memperbaiki kondisi Anda saat ini, Anda harus segera mulai mencari , sebelum Anda benar-benar bosan, dan kelelahan.

Jauh lebih baik mencari pekerjaan selagi Anda masih memiliki pekerjaan, jadi Anda tidak perlu menerima tawaran pertama hanya karena Anda butuh uang segera. Akhirnya Anda akan menemukan tempat yang lebih baik :-)

PS Gaji saya hampir sama jika tidak lebih rendah dari kasir di supermarket.

Heh saya ingin menulis sesuatu tentang cara bernegosiasi sampai saya membacanya. Sekarang yang bisa saya katakan adalah pergi! Dengan asumsi itu setengah dari apa yang biasanya didapatkan oleh pengembang dengan gelar. Dan dengan asumsi bahwa segala sesuatunya membaik dan mereka segera memberi Anda kenaikan 10%, Anda dapat menentukan sendiri berapa lama untuk sampai ke sana. Sepertinya Anda tidak belajar apa pun di tempat kerja dan sepertinya Anda tidak dikelilingi oleh insinyur-insinyur hebat di sana, jadi itu membuang-buang waktu.

Saya juga dalam situasi yang sama, dan saya dapat memberi tahu Anda bahwa jika Anda tetap berada di jalur itu tidak pernah berakhir. Manajemen akan terus memberikannya kepada Anda, karena ... mereka bisa.

Ada beberapa pemikiran tambahan yang saya miliki tentang topik ini.

1. Lakukan apa yang kamu sukai. Jika Anda tidak menyukainya, siapkan diri Anda untuk berusaha menemukan apa yang mungkin Anda sukai.

2. Komunikasi. Komunikasikan dengan jelas ketidakmampuan Anda untuk memenuhi harapan yang tidak realistis. Dalam pengalaman saya yang serupa, arsitek (yang melakukan paling menyekop) berkata, "Anda harus mengatur harapan orang lain terhadap Anda."

3. Terbakar habis. Jika Anda belum mengalami kelelahan, jangan menggoda nasib. Itu menyedot hidup dan jiwa Anda dari pikiran Anda. Terlepas dari upaya terbaik Anda, tujuan kerja Anda menjadi abu-abu, suram dan tidak berarti. Saya memberikan saran ini karena Anda harus, bagaimanapun caranya, menghindari kejenuhan.

4. Latihan. Inilah garis peraknya. Pelatihan dan pengalaman Anda, meski membuat frustrasi, dan mungkin di bawah bayaran, sebenarnya, sangat berharga bagi karier Anda. Ini adalah anugrah menyelamatkan Anda untuk mewujudkan ini karena Anda dapat menyerap sebanyak mungkin pembelajaran dan menunda langit-langit kaca yang tak terhindarkan.

Fokus pada bakat dan keterampilan apa yang Anda kembangkan ... Ini akan membawa Anda melalui peluang karier Anda selanjutnya.

Anda sedang berhadapan dengan banyak masalah di sini ... Mari kita mulai dengan yang jelas ...

Apakah ini normal?

Tidak. Tapi ... apakah itu biasa? Sayangnya ya.

Mengenai Frekuensi Memperbaiki Bug

Meskipun itu tidak memaafkan sisa kekacauan yang harus Anda hadapi dan beberapa proyek yang membebani Anda, saya hanya ingin membuat catatan cepat bahwa "perbaikan bug" hanya pendekatan, sementara membuat Anda frustrasi sebagai pengembang , dapat menjadi pendekatan yang masuk akal untuk perusahaan dan manajemennya.

Permukaan untuk Lebih Banyak Bug dan Biaya

Semakin banyak kode yang Anda sentuh, semakin besar kemungkinan Anda untuk memperkenalkan bug, bahkan jika niat Anda adalah untuk memperbaikinya. Itu berarti perpanjangan waktu dev, waktu pengujian, dan biaya. Dan jika itu lolos ke rilis layanan dengan cacat sedang hingga tinggi, itu kekacauan besar bagi mereka.

Kebisingan / Kabut di Log Anda

Dari perspektif SCM, juga masuk akal jika Anda bekerja langsung dari cabang rilis layanan, karena Anda ingin memiliki pandangan yang bersih tentang perubahan terkait dengan perbaikan bug. Jika ada 15 komit dengan ribuan perubahan di sekitar perbaikan bug yang sebenarnya diperlukan mungkin perubahan kode 1 baris, ini sedikit mengganggu.

Jadi, sebagai karyawan baru, akan lebih masuk akal untuk meminta Anda untuk tidak melakukan refactoring dan / atau meningkatkan perangkat lunak, dan menurut saya cukup baik untuk "bedah" mungkin dengan perbaikan bug Anda. Itu hanya membuat sakit kepala di teluk.

Bisakah Anda melakukan sesuatu tentang itu?

Sekarang, itu TIDAK berarti bahwa akan ada cara untuk mencapai kewarasan kode dan kewarasan dari pikiran orang-orang yang terlibat. Menjadi junior, mereka harus meminta seseorang meninjau perubahan Anda, terutama perbaikan bug, dan memastikan mereka disetujui sebelum sampai ke build rilis layanan. Itu akan mencegah atau membatasi perubahan radikal, dan lebih aman.

Proyek Dari Neraka

Kode Crap, Kawanan Pemrogram, Duplikasi, Arsitektur Crap

Sekali lagi, advokat iblis di sini, tetapi hanya menunjukkan bahwa permintaan awal Anda berisi beberapa bit non-konsekuensial.

Maksud saya adalah ini: Saya benar-benar sangat jarang mengambil alih basis kode yang tidak dalam kondisi ini. Dan jika saya melakukannya, mereka baru saja memulai proyek atau prototipe yang telah dimulai oleh programmer yang sangat baik. Tetapi mayoritas yang menakjubkan dari mereka tampak seperti omong kosong, dan jumlah yang menakutkan dari ini adalah omong kosong yang sebenarnya. Bahkan yang dimulai oleh programmer yang baik atau hebat dapat berakhir menjadi omong kosong, tenggat waktu dan keterlibatan lainnya membantu ...

Selamat datang di rekayasa perangkat lunak industri kehidupan nyata!

Dan tahukah Anda apa yang menyenangkan? Ini seringkali jauh lebih buruk di dunia pengembangan web. Nikmati! :)

Terlalu Banyak Proyek & Permintaan, Tidak Cukup Tangan & Waktu

Masalahnya terletak di sini mungkin di:

• manajemen Anda (mungkin secara tidak sadar) melecehkan Anda ,
• kolega Anda (mungkin secara tidak sadar) melecehkan Anda ,
• Anda (mungkin tanpa sadar) tidak menutupi pantat Anda dan cukup berjuang melawan Anda .

Manajer Anda harus menyadari bahwa Anda mengerjakan terlalu banyak proyek untuk dikelola. Jika tidak, pastikan mereka ASAP. Pastikan juga mereka tahu itu bukan pick-nick di taman dan Anda merasa tertekan, dan itu harus dihentikan.

Cobalah untuk melihat-lihat dan pastikan kolega Anda tidak membelokkan lebih banyak tugas dan proyek pada Anda, secara langsung (dengan benar-benar mengatakan "X akan dapat mengatasinya") atau secara tidak langsung ("Saya bukan orang yang tepat untuk ini, cari orang lain "-> akhirnya menjadi Anda).

Anekdot pribadi di sini: Saya melakukan magang beberapa tahun yang lalu, dan tepat pada hari terakhir saya, ketika saya mendapat evaluasi, bos saya memberi tahu saya, meskipun sangat puas dengan pekerjaan saya secara keseluruhan, bahwa salah satu manajer memiliki perasaan saya. telah membongkar beberapa "tugas yang tidak terlalu menyenangkan" di magang lain ketika mereka akan mengharapkan saya untuk mengambilnya. Aku malu membiarkan mereka merasa dikecewakan, dan pada gagasan bahwa aku akan terlihat seperti sedang malas, ketika maksudku adalah sebaliknya: Aku mencoba untuk mengambil tugas-tugas yang lebih sulit dan membuat pekerja magang yang lebih muda lainnya dengan rambut lebih sedikit masalah -pulling. Saya tidak menyadari bahwa, seandainya saya berada di posisinya, saya akan bosan dengan kurangnya tantangan dan mungkin merasakan caranya. Intinya adalah, Anda perlu berkomunikasi untuk memastikan tidak ada yang membuat asumsi yang salah tentang 3 hal yang sangat berbeda:

• apa yang dapat Anda lakukan ,
• apa yang ingin kamu lakukan ,
• dan apa yang ingin Anda lakukan .

Jadi sebagian juga salah Anda karena membiarkannya menjadi seperti ini. Tapi itu normal, itu pelajaran yang harus dipelajari semua orang. Ini memegang dua huruf: N - O .

Anda biasanya menggunakannya sebagai awalan untuk jawaban yang lebih panjang tapi tidak terlalu banyak biaya: Tidak, saya tidak bisa melakukan ini. Tidak, saya tidak tahu bagaimana melakukan ini. Tidak, saya tidak yakin saya orang yang tepat untuk ini. Tidak, saya belum pernah melakukannya.

Pada awalnya, sangat mudah untuk merasa seperti Anda hanya bisa mengatakan "ya, saya akan (akhirnya) melakukannya", dan menumpuk semuanya dan menyelesaikannya, mungkin dengan memasukkan beberapa jam tambahan. Itu semua salah. Anda perlu memahami bahwa waktu Anda adalah, setelah keterampilan Anda, aset Anda yang paling berharga, untuk Anda dan perusahaan Anda. Jika disalahgunakan, itu berdampak pada proyek, tenggat waktu, dan anggaran . Sesimpel itu.

Selain itu, agak mengkhawatirkan bahwa Anda akan memiliki terlalu banyak orang untuk melapor. Tidak masalah untuk memiliki lebih dari satu pelanggan untuk ditangani, dan beberapa pemilik proyek atau bahkan pemangku kepentingan utama yang perlu Anda ajak berkomunikasi. Tetapi, secara keseluruhan, terutama karena Anda adalah karyawan baru, Anda sebagian besar harus melapor kepada beberapa manajer saja (dan kemungkinan besar hanya manajer langsung Anda, dan mungkin pemimpin atau pengembang senior). Bagaimana bisa seperti ini? Saya tidak tahu Ini bisa menjadi masalah organisasi di perusahaan Anda, atau bisa jadi hasil dari Anda melakukan bantuan dan kemudian dihubungi secara langsung, dan gagal mengatakan "tidak". Atau bisa jadi manajer langsung Anda sebagai masalah dengan tugas pengiriman, untuk semua yang saya tahu (saya benar-benar menebak, tetapi polanya dapat dikenali dan terkenal).

Saya sarankan Anda melakukan hal berikut dengan agak cepat: bicarakan langsung dengan manajer langsung Anda, jelaskan bahwa manajer lain mungkin sedikit memaksa, atau (mungkin kurang cengeng) bahwa Anda memiliki terlalu banyak barang yang ditumpuk dari terlalu banyak orang, dan Anda perlu masukannya (dan mungkin juga masukan mereka) untuk mengetahui mana yang harus diprioritaskan.

Permintaan Perubahan 180 derajat

Ini adalah masalah besar lainnya. Mereka mungkin bukan kesalahan Anda, tetapi Anda dapat mencoba membantu mereka mengatasinya.

"Permintaan perubahan 180-degress", seperti yang Anda sebut dengan indah dan tepat, adalah tanda yang jelas bahwa persyaratan tidak jelas sejak awal, dan tidak ada yang berusaha cukup keras untuk membuatnya dipahat dan dibersihkan dari waktu ke waktu.

Itulah biasanya ketika seseorang perlu menelepon (atau lebih baik, dengan berjalan kaki), dan memegang tangan para pemangku kepentingan dan memberi tahu mereka dengan jelas: "di sanalah kita berada, ke sanalah kita ingin kita pergi, apakah Anda mengonfirmasi bahwa kami menuju ke arah yang benar? " Tidak apa-apa untuk tidak mendapatkan jawaban yang jelas di awal, tetapi semakin banyak waktu berlalu, semakin jelas jadinya, atau proyek ini adalah bencana yang menunggu untuk terjadi.

Biasanya saya akan mengatakan ambil semua pemangku kepentingan dalam jangkauan, menempatkan mereka di sebuah ruangan, mengarahkan mereka melalui masalah-masalah litigasi dan secara bertahap mencoba untuk menyelesaikan ini - dan dapatkan prioritas saat Anda berada di sana. Namun dalam kasus Anda, ini mungkin bukan panggilan Anda untuk melakukannya. Tetapi Anda menyebutkan bahwa mereka benar-benar memberi Anda tanggung jawab atas proyek; jadi jika memang itu masalahnya, maka lakukan tanggung jawab dan lakukan itu. Dan JANGAN menghindar dari mengatakan "kami TIDAK BISA melakukan itu" , atau bahkan "kami TIDAK AKAN melakukan itu" . Sangat penting untuk membatasi ruang lingkup proyek.

Jika tidak ada ruang lingkup, tidak ada persyaratan yang jelas di akhir diskusi.

Email Kelebihan

Orang cenderung berperilaku berbeda berdasarkan media komunikasi yang mereka gunakan. Secara pribadi, meskipun saya orang yang agak bersuara (dan telah bekerja sebagian besar di negara-negara asing, jadi saya juga akhirnya tidak suka banyak bicara di telepon), saya lebih suka dalam urutan preferensi berdasarkan produktivitas:

• berbicara dengan orang tatap muka ,
• berbicara dengan orang-orang di telepon,
• berbicara dengan orang lain melalui IM,
• berbicara dengan orang lain melalui email.

E-Mail bagus untuk pelacakan, untuk mendapatkan konfirmasi, untuk mengirim catatan.

Untuk penjadwalan, perencanaan, dan pembahasan poin-poin bermasalah, mereka hampir tidak berguna. Ketuk pintu orang itu sampai dia membukanya dan duduk dengan notepad dan salinan dokumentasi Anda untuk mengklarifikasi hal-hal. Setelah selesai, kirim email dan minta konfirmasi. Jika itu muncul kembali dengan jawaban negatif atau upaya yang agak tersembunyi dalam menyelundupkan sesuatu yang lain ke dalam amplop, pergilah mengepung kantor teman bicara Anda lagi.

Ini adalah rekayasa perangkat lunak. Ini seringkali lebih produktif ketika Anda tidak mengetik pada keyboard, dan benar-benar dapat mengurangi biaya yang harus Anda hadapi.

Melakukan Nilai Kerja Tim

Apakah Anda melakukan pekerjaan yang setara dengan nilai tim? Mungkin.

Apakah Anda melakukan hal yang setara dengan nilai kerja tim Anda? Mungkin tidak.

Maksud saya adalah bahwa tim Anda mungkin sibuk bekerja, dan Anda terlalu banyak bekerja. Dan itu masalahnya: Anda kelebihan dengan hal-hal yang harus dikeluarkan dari jadwal proyek saat ini, atau diberikan kepada seseorang dengan waktu di tangan mereka.

Apakah saya idiot ketika awalnya saya mengharapkan hal-hal menjadi berbeda?

Tidak; baru di pesta. Ini seperti hang-over atau hubungan pertama. Anda akan mengatasinya.

Saya kira posting ini telah berubah menjadi kata-kata kasar, tapi tolong katakan padaku bahwa ini tidak sama untuk setiap pengembang.

Ini sama untuk setiap pengembang di organisasi yang kacau, baik itu startup atau raksasa yang mapan, dan tanpa pengalaman atau kepercayaan diri untuk membuat segala sesuatunya bergerak sedikit untuk memberi peluang peluang Anda untuk bertahan hidup di sisi kanan skala.

PS Gaji saya hampir sama jika tidak lebih rendah dari kasir di supermarket.

Saya melakukan gaji yang layak pada pekerjaan yang akan tampak jelek. Bukan nomor pada cek yang diperhitungkan, melainkan konteksnya. Apa yang Anda lakukan, usia Anda, tempat Anda tinggal dan bekerja, dll ...

Yang sedang berkata, jika Anda dibayar sangat rendah, bekerja terlalu banyak, dan tidak sepenuhnya junior, pergi meminta kenaikan gaji itu atau mendapatkan pekerjaan baru!

Itu mudah:

• jika mereka menghargai apa yang Anda lakukan, mereka dengan senang hati akan menyetujui kenaikan gaji,
• jika tidak, masa depan di perusahaan ini tidak terlihat sangat cerah (untuk Anda, setidaknya, itulah yang penting), jadi jangan merasa sedih untuk pergi.

Sadarilah bahwa meminta kenaikan gaji adalah hal yang baik, meskipun Anda tidak akan cenderung berpikir begitu pada awalnya. Ini membuktikan Anda melacak apa yang Anda lakukan, dan mengisyaratkan bahwa Anda mengawasi opsi lain sambil tetap bersedia untuk tetap berada di pesawat. Dan adalah hal yang baik untuk membiasakan diri meminta mereka, karena mereka seperti wawancara pekerjaan atau tawar-menawar secara umum: itu adalah sesuatu yang membutuhkan latihan, dan mereka tidak jatuh dari langit jika Anda tidak menjangkau mereka sendiri. Beberapa perusahaan akan mendistribusikan kenaikan gaji secara teratur tanpa diminta, tetapi itu hanya karena mereka cukup pintar untuk mengetahui bahwa itu membuat Anda setengah bahagia dan kurang mau berubah, dan mereka ingin memotong rumput di bawah kaki Anda (kebanyakan orang akan merasakan sedikit gelisah tentang menaikkan tawaran kenaikan gaji yang telah mereka tawarkan secara langsung).

Bagaimana cara melanjutkan permintaan ini agak keluar dari ruang lingkup proyek INI di sini, jadi saya tidak akan masuk ke rinciannya. Tetapi saya sarankan Anda menyiapkan catatan ID komit SCM Anda, bug dan prestasi Anda yang sudah diperbaiki, dan bahwa Anda juga menyiapkan laporan yang membandingkannya dengan upaya keseluruhan tim. Cara ini:

• Anda dapat mengukur sendiri apakah Anda secara efektif melakukan lebih banyak daripada rekan-rekan Anda atau tidak,
• Anda bisa bertahan jika mereka mengatakan permintaan Anda tidak dibenarkan.

Selain komentar orang lain:

1. Ya, itu normal bagi karyawan entry level untuk diberikan pekerjaan yang tidak ingin dilakukan orang lain.

2. Anda harus melihat ini sebagai blok bangunan untuk karir masa depan Anda.

Jadi apa yang harus kamu lakukan? Untuk membuktikan diri Anda sebagai pengembang profesional, Anda perlu memastikan pekerjaan Anda terstruktur dan terencana, jika tidak, Anda mungkin kesulitan membangun hal-hal baik yang sedang Anda lakukan - jadi Anda harus mencoba melakukan hal-hal seperti yang berikut (jika kamu belum).

1. Catat pekerjaan Anda dengan akurat, untuk setiap proyek. Jadi, jika Anda menghabiskan satu jam memperbaiki bug di proyek A, masuk kali ini. Ini akan berguna untuk ditunjukkan kepada manajer Anda jika Anda ingin membahas beban kerja.

2. Tulis tes unit. Anda menyebutkan beberapa proyek yang Anda kelola penuh dengan bug, jadi dugaan saya adalah bahwa ada beberapa (jika ada) pengujian unit. Untuk setiap laporan bug, tulis unit test yang mereplikasi bug, lalu perbaiki bug. Ini akan membantu memastikan tidak ada regresi terjadi, meningkatkan kualitas kode, dan berfungsi sebagai platform untuk refactor kode jika Anda diberi kesempatan (misalnya, itu dapat membantu Anda meyakinkan para pemangku kepentingan bahwa menulis ulang beberapa bagian dapat meningkatkan kualitas tanpa memperkenalkan bug baru, karena unit test suite).

3. Cari pekerjaan baru - Anda mengerjakan banyak proyek sekaligus, Anda telah menulis kode dari awal, dan Anda mungkin telah mengalami seluruh siklus hidup proyek - ini semua adalah pengalaman bagus untuk melamar di tempat lain.

Situasi Anda agak tegang, namun masih normal. Tetapi cara Anda menanganinya sangat buruk. Inilah yang perlu Anda lakukan:

• Cobalah untuk menghadapi atasan Anda. Anda harus memiliki beberapa bukti (angka) tentang berapa banyak waktu sebenarnya biaya dasar kode buruk. Jika dia tidak mengerti hal-hal seperti utang teknis, berhentilah menyebutkannya. Itu akan menghancurkan kepalamu, dan kamu bisa ditandai sebagai pria 'sikap buruk'. Bukan tugas Anda untuk mengajari atasan Anda melakukan pekerjaannya.

• Pertahankan backlog Anda sendiri (kanban). Ketika tugas baru datang, letakkan di akhir, dan beri tahu perkiraan waktu penyelesaian.

• Tingkatkan waktu respons Anda, periksa email Anda hanya dua kali sehari. Biasanya sebelum makan siang dan sesaat sebelum Anda pergi. (Memeriksa email tidak harus diikuti dengan pengkodean, karena dapat merusak kepala Anda).

• Buat peningkatan kode kecil sebagai bagian dari setiap tugas. Ini hanyalah tugas Anda untuk meningkatkan kode, keterampilan, dan alat yang Anda gunakan. Ini juga akan meningkatkan moral Anda dalam jangka panjang.

• Tidak ada pengalihan proyek di siang hari. Hari ini Anda hanya mengerjakan proyek X, dan Anda akan memulai tugas lain untuk Y besok.

• Alokasikan satu jam per hari untuk pemeliharaan gerbang. Itu berarti tugas-tugas kecil yang sepele untuk dilakukan. Jika tugas ini memakan waktu lebih dari 10 menit (tidak peduli apa alasannya), tugas itu masuk ke dalam tumpukan dan Anda memberi tahu manajer bahwa itu akan ditunda.

Sekarang sampai pada bagian yang sulit. Saat ini manajer tidak berkomunikasi satu sama lain, dan anggap saja Anda akan menyelesaikan proyek mereka sendiri dengan prioritas maksimal. Ini membawa banyak tekanan di kepala Anda, karena Anda sedang bertengkar. Anda perlu memaksa manajer untuk mulai mengoordinasikan pekerjaan Anda. Pada akhirnya Anda harus memiliki simpanan bagus & sederhana dan manajer harus menggertak satu sama lain tanpa Anda.

Jadi mari kita lakukan permainan peran sederhana. Ada tiga manajer dan proyek (Xavier dengan proyek X, Yvonne dengan proyek Y dan Zed dengan proyek Z). Anda memiliki jaminan simpanan selama dua minggu, 5 hari untuk X dan 5 hari untuk Y.

• Z meminta Anda untuk melakukan beberapa tugas (1 hari)
• Anda menjawab bahwa itu akan dilakukan dalam 11 hari.
• Z menjawab bahwa itu adalah tugas yang sederhana dan tidak boleh memakan waktu lebih dari satu hari (perhatikan bahwa Z menerapkan tekanan kecil).
• Anda menjawab bahwa Anda saat ini bekerja untuk X dan yang terakhir untuk Z. Anda dapat melakukan pekerjaannya setelah itu.
• Z menjawab bahwa Anda harus segera melakukan tugasnya (tekanan meningkat, pelanggaran langsung terhadap wilayah X dan Y).
• Anda menjawab bahwa melakukan tugasnya akan menunda pekerjaan untuk X dan Y. Dia harus meminta mereka terlebih dahulu. Anda juga CC X dan Y.

Sekarang ada dua ujung:

• Manajer akan mulai saling menggonggong, banyak email, mungkin beberapa pertemuan ... Anda harus menjauh dan membiarkan pemenang memberi Anda tugas.

• Tidak ada yang akan terjadi, Z akan menanyakan dua hari kemudian di mana tugasnya. Anda menjawab bahwa Anda sedang bekerja untuk X saat ini, dan dia tidak menyebutkan apa pun tentang proyek Z. Lagi CC X.

Sekarang jenis perilaku ini dapat membuat Anda dipecat. Tetapi situasi Anda tidak berkelanjutan, dan Anda mungkin akan segera berhenti. Solusi ini hanya berfungsi jika manajer saling bersaing (sangat biasa). Anda juga harus menyimpan catatan pekerjaan Anda (backlog), jika seseorang akan mengeluh, bahwa Anda malas.

Tujuh tahun yang lalu saya melakukan cukup banyak pekerjaan pemeliharaan 100% untuk sementara waktu dan menulis artikel tentang itu: Seni Pemrograman Pemeliharaan . Satu bagian yang mungkin berguna bagi Anda:

1. Dapatkan untuk Menyukainya

Bagaimana orang bisa menyukai pemrograman pemeliharaan? Pengembang bermimpi menjadi arsitek utama di tim mereka, dan ketika mereka akhirnya mempertahankan perangkat lunak yang ada, rasanya hampir seperti hukuman. Tidak harus seperti itu: pemrograman pemeliharaan memiliki serangkaian tantangan sendiri, dan membutuhkan banyak kreativitas, kemampuan beradaptasi, kesabaran, disiplin, dan komunikasi yang baik. Ini bisa baik untuk karir Anda juga: memiliki entri bombastis seperti "Arsitek n-tier 24/7 aplikasi perusahaan" di resume Anda terlihat bagus, tetapi pengusaha sebenarnya menghargai orang yang memecahkan masalah; dan pemrograman pemeliharaan dapat menjadi kesempatan yang baik untuk menunjukkan keterampilan Anda dalam memecahkan masalah.

Masalah Anda terdengar seperti membuat Anda lebih sering mendengar tentang. Tampaknya menjadi pekerjaan yang dapat dengan mudah ditampung di The Daily WTF .

Banyak organisasi lebih fokus pada penjualan atau mendorong fitur daripada pada kualitas. Apa yang gagal dilihat oleh perusahaan-perusahaan itu adalah bahwa ada lebih dari kualitas eksternal dari suatu perangkat lunak. Ward Cunningham menciptakan istilah utang teknis .

Anda mungkin juga ingin membaca Steve McConnell tentang hutang teknis . Dia punya beberapa poin menarik. Dalam Google Tech Talk, Ken Swaber berbicara tentang pengembangan perangkat lunak yang gesit . Bagian yang baik adalah tentang cerita yang mirip dengan Anda Dia berbicara tentang proyek perangkat lunak yang telah menjadi "braindead" setelah 10 tahun pemrograman oleh berbagai programmer tanpa pernah melakukan refactoring . Saya pikir jika Anda melihat video ini, Anda akan melihat banyak kesamaan dengan apa yang Anda gambarkan.

Sistem perangkat lunak apa pun akan menurun kualitasnya saat diperluas. Bahkan untuk bertahan itu harus. The Lehman Hukum menjelaskan prinsip ini dengan cukup baik. Pada akhirnya itu akan bermuara pada pertanyaan berikut: "Bagaimana saya meyakinkan bos Anda untuk melakukan refactoring?" .

Bagaimana saya mendekati masalah yang sama:

• Saya berhadapan dengan bos saya dan menjelaskan bahwa kualitas kode menurun ketika kami terus berkembang ( Lehman Laws ).
• Saya mencoba menjelaskan konsep utang teknis kepada bos saya . Dan cara dia membiarkan Anda bekerja adalah cara yang akan menghabiskan uang dalam jangka panjang.
• Untuk benar-benar menunjukkan kepadanya betapa parahnya masalah itu, saya (pada waktu saya sendiri) melakukan analisis kode statis. Atasan tidak mengerti perangkat lunak, tetapi mereka mengerti angka. Meskipun metrik kode memiliki kekurangannya , ada baiknya Anda memiliki sesuatu yang dapat diukur yang dapat Anda bicarakan. Cobalah untuk mencari tahu apa bacaan normal untuk metrik ini, dan Anda akan terkejut ketika Anda membandingkan ini dengan basis kode Anda sendiri.
• Jika tidak ada yang membantu dan tidak ada perubahan, satu-satunya hal yang dapat Anda lakukan adalah menjelaskan bahwa fitur baru tertentu akan memerlukan pengerjaan ulang bagian lain dari basis kode Anda. Jelaskan bahwa jika Anda memiliki kode duplikat dan mereka ingin mengubah sesuatu yang biaya perubahan duplikat juga.
• Jawaban umum untuk poin sebelumnya adalah bahwa tidak ada yang meminta dan dengan demikian tidak membayar untuk pengerjaan ulang ini. "Mungkin" pengerjaan ulang ini berlebihan. Anda harus menjelaskan bahwa perangkat lunak harus selalu berubah. Seperti Hukum Lehman katakan; itu harus berubah agar tetap digunakan. Jika tidak, program lain yang melakukan perubahan akan selalu hidup lebih lama. Mereka yang mengharapkan perubahan dan dapat beradaptasi dengan perubahan yang akan bertahan. Inilah pengembangan perangkat lunak tangkas . ( Wikipedia )

Bos saya saat ini menggunakan konsep hutang teknis untuk menjelaskan kepada pelanggan kami bahwa kami terkadang perlu mengerjakan ulang bagian dari perangkat lunak yang kami buat. Hanya untuk membuktikan bahwa - jika Anda memiliki bos yang masuk akal, adalah mungkin untuk mengubah keadaan menjadi lebih baik.

Situasi yang Anda hadapi hampir (jika tidak sepenuhnya) sama untuk banyak siswa baru.

Ini terjadi pada fase awal karier. Inilah intinya: Kita harus mengatasi masalah ini dan membuktikan nilai kita kepada perusahaan (baik itu berukuran sedang atau MNC ). Kita harus dapat membuat keputusan tentang keadaan yang menuntut kita lakukan. Jadi tidak ada salahnya melakukan upaya dalam pekerjaan, asalkan Anda diperhatikan dan berdiri sebagai individu untuk pekerjaan Anda. Jika Anda layak, perusahaan akan memperhatikan! Adios dan semoga sukses.

Menurut pendapat saya, perusahaan yang melarang refactoring tidak layak untuk bekerja. Refactoring adalah keterampilan pengembangan perangkat lunak yang penting, dan alat kontrol versi membuatnya sangat mudah untuk mengembangkan perubahan dalam isolasi tanpa merusak 'trunk' (kalau-kalau refactor benar - benar merusak sesuatu). Seperti kata Paman Bob (diparafrasakan): "Anda seharusnya tidak meminta untuk menjadi seorang profesional dan melakukan pekerjaan Anda dengan benar."

Pemeliharaan pemrograman seharusnya tidak berarti mengabadikan kode yang buruk.

Saya telah menerima email ini lima tahun yang lalu dari salah seorang teman saya.

Email body:    

Seorang insinyur trainee yang baru bergabung bertanya kepada bosnya, "apa arti dari Appraisal?"

Bos: "Apakah Anda tahu arti pengunduran diri?"

Trainee: "Ya saya lakukan"

Bos: "Jadi, izinkan saya membuat Anda memahami apa itu penilaian dengan membandingkannya dengan pengunduran diri"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Trainee: "Ya bos cukup, sekarang saya mengerti masa depan saya. Untuk penilaian saya harus mengundurkan diri ... !!!"

Jika saya jadi Anda, saya akan menghabiskan beberapa jam setelah bekerja membangun kembali aplikasi secara gratis. Mungkin itu akan menjadi tugas yang menyenangkan. Saat Anda selesai, tunjukkan ke atasan Anda. Jika berhasil dan Anda sedang melakukan pemeliharaan, ia seharusnya tidak perlu khawatir. Ini akan membuat pekerjaan Anda jauh lebih mudah dan akan membuka mata para atasan terhadap potensi Anda di perusahaan.

Saya seorang mahasiswa penuh waktu yang bekerja magang paruh waktu dengan harga US $ 10 per jam. Saya melakukan hal-hal QA yang membosankan, berulang, dan mudah. Saya menganggap diri saya sangat beruntung, karena saya tahu suatu hari ini akan membuka pintu ke tempat yang lebih besar dan lebih baik.

Ya, Anda harus selalu memelihara aplikasi, yang ditulis oleh Anda dan orang lain. Satu-satunya pengecualian adalah jika Anda menulis sebuah program yang tidak pernah membutuhkan pemeliharaan apa pun. Jadi, Anda lebih baik dalam pemeliharaan.

Saya pikir ada sedikit petunjuk dalam pertanyaan Anda tentang kesalahan dalam pendekatan Anda. Artinya, memperbaiki bug tidak melibatkan peningkatan kode.

Tetapi kemudian saya mendengar bahwa saya tidak diizinkan untuk memperbaiki kode yang ada dan hanya fokus pada perbaikan bug ketika bug dilaporkan.

Saya tidak percaya seseorang mengatakan kepada Anda "Anda harus memperbaiki bug tanpa memperbaiki kode." Ini sulit dan tidak mungkin. Yang tidak bisa Anda lakukan adalah menulis ulang aplikasi hanya karena Anda tidak suka, atau merasa sulit untuk memahami, pendekatan yang digunakan dalam basis kode yang ada.

Saran saya adalah belajar refactor. Setiap kali Anda memperbaiki bug, Anda memiliki peluang untuk meningkatkan setidaknya beberapa kode. Berapa banyak basis kode yang akan di-refactored tergantung pada apa bug itu dan seberapa baik atau buruk kodenya. Tetapi jika Anda memperbaiki bug dan secara sadar meninggalkan bau kode di semua tempat, maka Anda tidak melakukan pekerjaan Anda dan Anda sedang membangun hutang teknis .

Beberapa bug sebenarnya diperbaiki hanya dengan refactoring, dan kadang-kadang berguna untuk memperbaiki agar dapat membantu Anda memahami kode . Ini karena refactoring harus meningkatkan rawatan dan koherensi kode.

Ketika saya memperkirakan perbaikan bug, saya biasanya akan membuat keputusan tentang apakah refactor utama akan menjadi cara terbaik untuk melakukannya, dan memperhitungkannya. Sama dengan tes unit. Kedua hal ini harus menjadi bagian dari cara Anda menulis kode, bukan sesuatu yang opsional yang melibatkan waktu tambahan.

Jadi Anda seharusnya tidak bertanya, "bisakah saya memperbaiki kode ketika saya memperbaiki bug?" Karena Anda memang harus demikian. Anda seharusnya tidak bertanya, "bisakah saya menggunakan refactoring untuk memperbaiki bug?" Karena jika kode yang menyebabkan aplikasi bug keluar sangat membutuhkan refactoring, Anda harus tetap melakukannya. Anda seharusnya tidak bertanya, "bisakah saya menulis unit test ketika saya memperbaiki bug ini?" Karena Anda harus menulis tes regresi bahkan sebelum Anda mulai mencoba untuk memperbaiki bug.

NB: Saya merasa beberapa atribusi untuk jawaban ini harus diberikan kepada Jeff Atwood, mengingat saya menautkan 3 artikelnya.

Ini semua tentang uang. Dugaan saya adalah bahwa sebagai pemula, Anda mungkin terlalu baik untuk pelanggan yang sudah mendapatkan lebih dari yang mereka bayar.

Pelajari cara mengutip harga untuk permintaan baru. Ini jauh dari mudah dan pelanggan akan sering mencobanya. Jika Anda bisa, mintalah bantuan manajer proyek / produk berpengalaman.

Setelah Anda berpikir dalam hal uang, berkomunikasi dengan manajemen menjadi jauh lebih mudah. Jika pelanggan Anda saat ini menyediakan uang penuh waktu, Anda tidak boleh mengambil proyek baru. Tetapi Anda akan mengerti bahwa manajemen masih akan mencoba menggertak Anda untuk melakukannya.

Jika Anda memang berharga bagi perusahaan, Anda akan mendapatkan posisi tawar. Anda dapat meminta mereka untuk mempekerjakan lebih banyak orang, mendapatkan lebih sedikit proyek baru, membantu Anda mengurangi beban perawatan, atau meningkatkan gaji Anda.

Seharusnya bukan keputusan atasan Anda untuk mengatur mikro Anda sejauh Anda dilarang meningkatkan kode yang ada. Gunakan penilaian profesional Anda sendiri. Ketika Anda memperkirakan pekerjaan, saya akan memperhitungkan waktu tambahan untuk memungkinkan beberapa refactoring, jika itu akan meningkatkan produktivitas di masa depan.

Bagaimanapun, sepertinya Anda tidak berkomunikasi secara efektif dengan atasan Anda.

1. Anda memiliki bukti bahwa refactoring akan menghemat uang. Buat konsep proposal untuk proyek refactoring dan tunjukkan berapa banyak waktu dan uang yang dapat dihemat bisnis. Uraikan dengan tepat perubahan apa yang akan Anda buat pada kode, dan berapa lama waktu yang dibutuhkan.

2. Simpan log yang akurat untuk mencatat berapa banyak waktu yang Anda habiskan untuk coding, rapat, dan menjawab email. Ini akan melindungi Anda jika Anda terlambat.

3. Pelan - pelan. Ini mungkin tampak sedikit berlawanan dengan intuisi, tetapi waktu Anda hanya akan disalahgunakan jika Anda melakukan semuanya dengan cepat. Orang akan lebih menghargai waktu Anda jika Anda berbuat lebih sedikit. Misalnya, saya hanya akan memeriksa email sekali atau dua kali per hari. Jika tidak, Anda berisiko kehabisan tenaga.

4. Mengingat tingkat pembayaran Anda, tidak ada gunanya mendapatkan sakit kepala. Pastikan Anda berangkat tepat waktu setiap hari. Jangan masukkan jam tambahan tanpa kompensasi tambahan. Pengecualian adalah jika ada opsi kemajuan yang baik, atau jika reputasi perusahaan akan sangat meningkatkan resume Anda, maka Anda hanya perlu menyedotnya.

Tanpa tahu lebih banyak, saya hanya menyarankan agar Anda mencoba untuk lebih terbuka dengan manajer Anda. Mungkin mulai meningkatkan perkiraan tugas Anda. Selalu ingatkan mereka tentang betapa sibuknya pekerjaan Anda. Anda juga harus bertemu dengan bos Anda dan menjelaskan bahwa Anda ingin kenaikan gaji dalam enam bulan ke depan, dan tanyakan bagaimana Anda dapat meningkatkan kinerja Anda untuk mencapai kenaikan gaji ini.

Semoga berhasil.

Dalam pengalaman saya, dunia akademis atau 6-12 bulan pertama dari permulaan yang berorientasi pada teknologi adalah satu-satunya dua bidang yang dapat diandalkan di mana Anda akan menemukan batu tulis kosong yang sebenarnya. Mereka berdua menanggung biayanya sendiri, tetapi jika Anda suka kode dan sering ngeri dengan kualitas kode yang Anda temukan di alam liar, Anda harus mulai mengarahkan karier Anda ke salah satu arah ini.

Cobalah berbicara dengan atasan Anda dan lihat apakah Anda dapat menyelesaikannya. Kedengarannya seperti Anda jauh di atas kepala Anda dalam hal ini, dan itu tidak ada hubungannya dengan menjadi programmer yang buruk.

Perusahaan web yang lebih kecil cenderung memiliki banyak proyek pada saat yang bersamaan, yang dalam banyak hal membuat Anda berada di tempat yang sulit. Cobalah untuk melakukan yang terbaik dari situasi Anda, atau mencoba mencari pekerjaan baru jika Anda pikir Anda bisa. Saya berjanji ada pekerjaan pengkodean yang lebih baik di luar sana, jadi jangan biarkan yang pertama ini membuat Anda takut.

Semoga beruntung, dan saya harap Anda dan rekan kerja Anda memahami gravitasi atau usaha Anda!

Pengalaman pribadi

Seperti banyak orang di sini saya juga mengenali situasi Anda. Saya pada dasarnya mendapat pekerjaan coding pertama saya dengan gaji rendah dan harus memelihara banyak kode yang dibangun dengan struktur yang buruk. Pada awalnya saya merasa lucu untuk mempelajari hal-hal baru, tetapi ketika saya pada akhirnya memiliki banyak proyek untuk dipelihara, proyek-proyek baru untuk dibuat dan papan tulis yang tumbuh lebih besar dan lebih besar setiap hari dengan poin saya tidak selesai dengan saya menyadari bahwa itu tidak bekerja.

Setelah bertahan selama dua tahun, saya berhenti dan menemukan pekerjaan pengkodean lain beberapa bulan kemudian yang sangat cocok untuk saya.

Lagi pula, berkali-kali bukan hanya proyek Anda yang mungkin menjadi masalah. Saya menemukan diri saya lebih nyaman di tempat kerja ketika saya diakui dan dihormati untuk pekerjaan saya. Masalah dengan situasi di mana Anda berada adalah bahwa majikan Anda mungkin hanya memperhatikan bug yang muncul dari proyek yang dibuat, dan bukan waktu yang Anda ambil untuk menghapus semua bug lainnya.

Gaji

Jika Anda ingin lebih banyak uang, Anda sering bisa mendapatkannya. Saya berhasil menegosiasikan gaji saya di bawah dua tahun ke kenaikan 33%.

Pada dasarnya, pikirkan nilai pekerjaan Anda dan seberapa besar kebutuhan perusahaan Anda. Jika mereka tidak mampu memberi Anda gaji yang Anda peroleh, maka perusahaan perlu melihat pengeluaran mereka atau menyadari bahwa bisnis mereka tidak berfungsi.

Dan seperti yang disebutkan oleh banyak orang di sini, dan saya setuju, Anda adalah bagian yang sangat bernilai dari teka-teki perusahaan. Sial, Anda mungkin satu-satunya yang bisa memecahkan teka-teki itu. :)

Karena saya belum bisa berkomentar karena saya seorang lurker di situs Stack Exchange ini, saya hanya akan menambahkan informasi di sini.

1. Karena Anda baru memulai, gaji Anda tidak akan menjadi bintang kecuali Anda bekerja di perusahaan besar seperti Microsoft, Amazon, atau yang serupa. Tapi itu tidak seharusnya menjadi seorang karyawan grosir! Jangan tahan dengan hal itu terlalu lama, dapatkan pengalaman melakukan apa yang Anda lakukan dan terus maju ketika kesempatan yang lebih baik muncul.

2. Untuk pertunjukan tingkat entri ini agak normal. Beban kerja Anda terlalu tinggi, tetapi jenis pekerjaan itu diharapkan. Untuk menjadi pengembang yang lebih baik, Anda harus belajar dari kesalahan orang lain. Semakin banyak Anda melihat, semakin baik Anda menjadi. Tapi itu menyiratkan bahwa Anda mencari hal-hal untuk dipelajari, bukan mempelajari kebiasaan buruk ...

3. Rasio pemeliharaan untuk pekerjaan proyek harus bergeser dari waktu ke waktu. Jika tidak, itu berarti perusahaan tempat Anda bekerja tidak menyadari cara mempertahankan pengembang yang baik; mereka bermaksud agar Anda melakukan hal yang sama hari demi hari. Buatlah tujuan tahunan untuk diri Anda sendiri, ke mana Anda ingin berada, gaji dan harapan kerja yang bijaksana, dan bergerak sesuai itu.

4) Jika Anda tidak senang, pergi! Hidup ini terlalu singkat untuk berurusan dengan orang bodoh.

Semua yang terbaik.

Anda mulai menggunakan pelacak masalah untuk melacak daftar todo Anda.

Ini tidak hanya akan membantu Anda melacak apa yang penting, tetapi juga akan membantu pengguna dan bos Anda untuk melihat apa beban kerja Anda saat ini.

Juga, jika mereka pernah menyewa pengembang kedua (atau Anda berhenti dan pengganti Anda sekarang mengambil beban kerja Anda) ini akan membantu dalam mengelola beban kerja, dan Anda akan dapat menghindari saling menginjak jari kaki lainnya.

Satu-satunya cara untuk memutus rantai ini adalah mengembangkan infrastruktur baru yang dirancang untuk fleksibilitas dan diuji unit + integrasi penuh.

Jika Anda berhasil menjual ini kepada manajemen (tandatangani pengembang dan manajer lain ke konsep dalam pertemuan 1: 1), maka Anda dapat secara perlahan mencapai kondisi, di mana sebagian besar kode aplikasi ada dalam infrastruktur dan mudah untuk memperluas dan memelihara, sedangkan aplikasi sebenarnya berbobot ringan dan dapat ditulis dengan cukup cepat.

Pengembangan infrastruktur dapat memungkinkan pada awalnya mengganti bagian dari aplikasi yang ada dan setelah beberapa saat (mungkin perlu beberapa tahun) mengganti seluruh aplikasi.

Dalam jangka panjang dapat mengurangi waktu pengembangan aplikasi baru dan waktu pemeliharaan aplikasi yang ada di masa depan secara drastis.

Pengembangan baru akan membutuhkan setidaknya 80% dedikasi (lebih disukai lebih banyak) dengan tim lebih dari satu pengembang (beberapa pikiran lebih baik dari satu). Semua pengembang harus dapat berpikir kreatif dan melanggar prasangka yang ada.

Cobalah mendefinisikan dan merancang tingkat tinggi infrastruktur baru seperti itu, lalu sajikan definisi itu kepada rekan kerja dan manajemen Anda.

Pada kondisi kerja Anda, mintalah untuk memimpin tim infrastruktur baru yang menangani masalah-masalah ini (berdasarkan definisi dan desain Anda) dan bawa pengembang baru untuk memelihara barang-barang lama sambil Anda membantu mereka jika perlu (hingga 10-20% dari waktu). Jika manajemen menyetujui ide tersebut, Anda dapat meminta untuk menegosiasikan kembali persyaratan Anda. Bersiaplah untuk mencari pekerjaan lain jika mereka menolak. (Ingat, pekerjaan Anda membutuhkan keterampilan, pengetahuan, dan pengalaman, Anda tidak mudah untuk diganti karena mereka membayar Anda untuk percaya.)

Apakah manajer Anda mengetahui semua permintaan perubahan ini (permintaan pemeliharaan)? Apakah dia menyadari bahwa waktu Anda dihabiskan untuk menyaring permintaan seperti itu sehingga Anda tidak punya wewenang untuk memberikan sanksi? Atau apakah Anda hanya melakukan perubahan setiap kali seorang manajer bertanya kepada Anda?

Bagi saya sepertinya port of call pertama Anda adalah meletakkannya di meja manajer Anda. Tidak ada yang harus datang kepada Anda secara langsung. Masalah harus datang melalui bidang siapa pun seperti itu - biasanya tim pendukung. Adalah normal bahwa Anda mendukung kode Anda untuk periode penyerahan singkat - biasanya sekitar satu minggu atau lebih. Perubahan harus dihitung biayanya dan dibebankan (transfer charge) di perusahaan mana pun yang akan mengklasifikasikan dirinya sebagai "ukuran sedang", dan ini tampaknya sedang dilewati (tidak heran mereka membanjiri Anda - Anda seperti pelacur di pesta prom).

Harus ada prosedur permintaan yang tepat untuk mengangkat masalah dan mengubah permintaan. Dukungan / pemeliharaan adalah tentang memperbaiki bug dan masalah (yang sesuai dengan spesifikasi asli, tetapi gagal karena bug dalam kode atau acara di luar - seperti daya mati atau sistem hulu rusak, dll.).

Jika perusahaan Anda tidak menawarkan ini dan mengharapkan Anda untuk mengatasi dan bertanggung jawab atas segudang permintaan acak ini, maka dengan serius Anda perlu mempertimbangkan untuk pindah. Bayaran selalu buruk di bagian bawah - dalam pekerjaan pemrograman pertama saya (hampir 25 tahun yang lalu) saya menghabiskan 8 tahun untuk perusahaan yang sama dan upah saya naik sedikit (meskipun selalu jauh lebih tinggi daripada kasir!). Dalam 2 tahun setelah kepergian saya, saya telah menggandakannya - dan dua tahun setelah itu saya membawa pulang lebih dari sepuluh kali dari yang saya mulai (tetapi kemudian menjadi kontraktor independen). Seperti biasa, beri Anda taji, pelajari perdagangan Anda, dan kirim ke lingkungan yang lebih hangat.

Mungkin Anda berada dalam posisi untuk pergi ke manajer dan berkata: "Lihat, saya akan jujur ​​dengan Anda. Gaji saya sangat buruk, saya bisa mendapatkan N kali ini sebagai programmer entry level di X.

Saya melakukan terlalu banyak hal dengan A, B dan C. Saya tidak bisa mempertahankan ini. Jujur, dan tidak ada pelanggaran yang dimaksudkan, saya akan berjalan keluar dari ruangan ini dengan ini diperbaiki, atau dengan surat pengunduran diri saya pergi dengan Anda. Sekarang ini semua di udara, bagaimana kita bisa bekerja sama untuk memperbaikinya? "

Jawabannya adalah mencoba dan menjelaskannya dalam istilah yang dapat dipahami;

• Ini seperti ganti oli. Mereka tidak mendesak .... tetapi harus dilakukan secara teratur
• cat karat dan itu akan terlihat bagus. Sampai berdarah
• membangun atap meja teras atap baru tanpa dukungan kekuatan. Mungkin akan bekerja untuk sementara waktu. Maka itu akan runtuh dan melukai orang dan Anda akan bertanggung jawab.
• a / c itu bagus. Unit jendela sangat bagus untuk satu atau dua kamar. Mencoba menempatkan 146 unit jendela AC di gedung apartemen dan Anda akan ... mengalami masalah.
• Mengajar 5 anak baik-baik saja. 10 tidak terlalu buruk. Tapi ada batasannya. Cobalah mengajar 75 anak secara tidak resmi dan Anda akan melihat ini.

Jika ini tidak beresonansi. Tinggalkan - HARI YANG ANDA DAPATKAN PENAWARAN, bukan hari berikutnya! Setelah Anda MEMILIKI pekerjaan baru, pergi dengan pemberitahuan NOL. Secara harfiah tidak datang pada hari itu. Tetapi pastikan Anda memiliki satu atau dua kolega yang tahu apa yang Anda lakukan. Ini benar-benar akan membantu perusahaan keluar, jika perusahaan dapat membantu, dengan menunjukkan kepada mereka bahwa rasa tidak hormat dan kesombongan mereka ada harganya. Perusahaan terakhir saya berada di TIGA KALI EMPAT TECH DALAM WAKTU 6 BULAN TANPA PEKERJAAN. Setidaknya itu membuat pernyataan dan memberi kesempatan pada orang yang sedang pergi itu kesempatan bagus untuk mengatakan, 'yeah, baguslah kamu katakan setiap hari tapi kamu begitu kenyang, aku bahkan tidak memberimu kepuasan atas pemberitahuanku.

Akhirnya, ketahuilah bahwa ruang lingkup urusan ini adalah NORM dan standar 20 tahun yang lalu sebelum lincah, tdd, bdd, dan refactoring menjadi lebih dari norma. Anda mungkin berbicara dengan orang-orang senior yang segera menjawab "baik saya telah melakukan ini sendiri dan itu berfungsi dengan baik, bla, bla, bla." Nah, kuda dan gerbong ure yang lain bekerja dengan baik 150 tahun yang lalu. Di bidang teknologi, teknik dari 20 tahun yang lalu sudah ketinggalan zaman seperti transportasi dari 150 tahun yang lalu. Jika mereka menolak denda ini. Hanya tahu bahwa mereka tidak akan pernah mempekerjakan pengembang teknologi saat ini yang layak yang akan tinggal. Mereka akan mendapatkan yang terburuk dari yang terburuk dan itu akan sangat merugikan bisnis mereka. Jika mereka bergantung pada teknologi dan tidak dapat beradaptasi, mereka akan gagal dan pada akhirnya itu mungkin hadiah terbaik untuk Anda. Saya t'

Sepertinya manajemen Anda pada dasarnya tidak menghormati Anda atau memahami beban kerja Anda.

Anda seharusnya tidak mengimplementasikan setiap permintaan fitur yang datang. Manajer Anda harus bertindak sebagai penyangga antara Anda dan permintaan masuk (kecuali mungkin permintaan break / fix paling sederhana). Maka dia harus duduk bersama Anda dan menentukan kelayakan dan prioritas untuk setiap permintaan yang disetujui.

Juga, Anda harus membuat mungkin 2x (setidaknya) apa yang mereka bayar kepada Anda.

Kedengarannya mereka mungkin benar-benar membutuhkan setidaknya 1 pengembang lagi untuk bekerja bersama Anda, tetapi dengan apa yang mereka bayarkan kepada Anda itu terdengar sangat tidak mungkin.

Jika mereka tidak mau membayar Anda secara memadai atau membantu Anda mengelola beban kerja Anda, saya akan mencari pekerjaan baru. Anda ingin bekerja di suatu tempat di mana Anda menjadi bagian dari tim , dan di mana manajemen Anda bekerja dengan Anda untuk menyelesaikan proyek Anda. Turun dari kapal yang tenggelam sesegera mungkin.

Menjadi pahlawan di tim satu hanya akan membuat Anda lelah.

Saya hanya seorang siswa (masih) tetapi itu cukup normal (dari pengalaman magang saya). Itulah yang Anda dapatkan ketika bekerja di aplikasi dukungan dan web.

Saya menyarankan Anda untuk memahami apa yang diinginkan klien (manajer) sebelum memulai pengkodean. Itu bisa rumit karena kadang-kadang mereka tidak mengetahuinya sendiri sehingga bekerja dengan mereka sampai mereka menyetujui sesuatu. Pastikan Anda berdua menyetujui solusi final sebelum Anda membuat kode.

Juga jika Anda seorang pengelola, Anda dapat mengubah banyak hal dalam kode - cukup pastikan itu tidak mengubah perilaku atau memperkenalkan bug. Saya berharap manajer tidak 'mengizinkan' Anda untuk mengubah apa pun karena mereka sudah terbiasa dan senang dengan keadaan sekarang dan mereka tidak ingin membayar untuk perubahan baru.

Akhirnya, jangan khawatir jika Anda tidak dapat menangani sesuatu karena Anda melakukan sesuatu yang lain. Saya menyarankan Anda untuk memberi tahu orang-orang bahwa Anda kewalahan dengan pekerjaan dan permintaan mereka akan memakan waktu. Jika tidak, manajer hanya akan berpikir Anda malas. Biarkan mereka tahu bahwa Anda sudah memiliki pekerjaan dan mereka mungkin mempekerjakan lebih banyak orang. Tidak ada cara lain bagi mereka untuk mengetahui bahwa pekerjaan itu terlalu berat untuk satu orang.

Ini adalah masalah manajemen proyek. Gunakan semacam manajemen proyek untuk memutuskan prioritas tertinggi apa yang harus dikerjakan.

a) Anda membutuhkan tumpukan item untuk dikerjakan. Anda meletakkan rencana Anda untuk meningkatkan kode di backlog.

b) Semua bug masuk ke dalam tumpukan

c) Tunggakan diprioritaskan.

d) Anda melakukan semuanya dalam urutan prioritas.

Bug mungkin menjadi prioritas yang lebih tinggi, tetapi jika begitu Anda memperbaiki semua yang Anda punya siklus untuk menghabiskan fitur baru atau pada desain refactoring.

Ini paling mudah jika Anda hanya melakukan perbaikan refactoring secara bertahap, saat Anda melewati bagian yang memiliki masalah / bug untuk diperbaiki. Kemudian Anda dapat memberi tahu manajemen, "Saya harus memperbaiki A, tetapi B pada dasarnya rusak dan saya harus melakukan solusi C untuk memperbaiki semuanya sehingga D akan lebih mudah / lebih murah di masa depan" Di mana A = Bug, B = The anti-pola, C = Solusi, D = Keuntungan Masa Depan

Jika Anda tidak dapat membenarkan pekerjaan sebagai investasi yang layak dilakukan, pebisnis tidak akan pernah menerimanya.

Ini bisnis seperti biasa. Anda akan dieksploitasi selama Anda tetap bekerja di sana. Adalah kepentingan terbaik perusahaan untuk melanjutkan model ini daripada membuat Anda merasa bahagia dengan apa yang Anda lakukan. Ketika sampai pada itu, mereka tidak benar-benar peduli. Ini tentang membuat kode yang dapat diandalkan untuk mereka dan jika Anda adalah one-man-band, mereka pasti membuat Anda senang. Mengapa mereka berubah?

Kabar baiknya dalam semua ini adalah Anda VIP untuk mereka bahkan jika mereka tidak mengetahuinya. Apa yang saya sarankan lakukan adalah untuk berbaris lebih banyak peluang sebelum melompat kapal lalu ambil bola dan minta gaji yang lebih tinggi. Jika tidak pindah ke peluang yang lebih baik. Menurut pendapat saya, Anda harus segera menemukan pekerjaan yang lebih menarik. Arahkan setinggi yang Anda bisa. Setelah Anda sampai di toko pengembang, Anda akan jauh lebih bahagia seperti Google atau startup yang menyenangkan di mana ada budaya pengembang kolaboratif di mana Anda akan benar-benar merasa bahagia.

Apa yang saya lakukan secara pribadi adalah menggunakan organisasi kontraktor pemburu kepala dan dengan cepat mendapatkan banyak pengalaman hebat, berpindah dari satu ke yang lain sambil tetap mempertahankan pekerjaan tetap dari kontraktor saya. Itu membuat Anda tidak bosan dan menantang Anda. Akhirnya, di waktu luang saya membangun beberapa bisnis kecil yang berkembang menjadi bisnis aktual, dan kemudian saya melompat dari melakukan pekerjaan kontrak.