Menulis jawaban untuk artikel itu mudah dan menyenangkan. Anda tidak perlu mempelajari struktur artikel selama berjam-jam, cukup dengan mengikuti rencana orang lain dan hanya mengutarakan pemikiran Anda dengan jelas di atas kertas. Namun demikian, saya berani menyarankan bahwa pandangan kritis "dari sisi lain" pada masalah yang diangkat dalam artikel "
Ketakutan dan Kebencian dalam TI " oleh
eugene_crabs yang disegani masih akan menarik. Hari ini, saya adalah pendukung iblis, yang membela sistem tidak manusiawi.
Tidak seperti dia, saya tidak mengenakan jumbai senor, dan saya memiliki beberapa tahun lebih sedikit pengalaman pengembangan, dan saya tidak memiliki pendidikan khusus, jujur saja. Tetapi saya tidak punya masalah dengan minat dasar pada pekerjaan, dan bagi saya tampaknya alasannya adalah persepsi yang sedikit berbeda dari kenyataan.
Artikel untuk berbagai pembaca.
RE: Kompleksitas Berlebihan
Bagian AsliKetika saya bekerja pada kelenjar, saya sangat menyukai properti yang saya lihat melalui bagaimana hal ini bekerja - byte apa yang bergerak, di area memori apa ini terjadi dan bagaimana kompiler menangani kode. Ada perasaan tenang dan kontrol. Ketika saya beralih ke pengembangan backend sedikit kemudian, saya terkikik tentang konfigurasi xml tanpa akhir untuk EJB atau pegas yang sama. Saya akan tahu apa yang menanti saya di masa depan. Sekarang saya hanya tidak mengerti (dan sudah putus asa memahami) apa yang terjadi di dalam keterikatan saya yang tidak rumit. Banyak lapisan abstraksi, wadah dalam wadah, banyak buku pedoman, skrip, alat, versi, file konfigurasi. Saya masih belum tahu bagaimana proyek ini dikerahkan, yang telah saya kerjakan selama enam bulan sekarang. Dan tentu saja, Anda tidak dapat membuat monolit, setidaknya di tahap pertama. Pastikan untuk segera membagi semuanya menjadi layanan microser, karena begitu benar (di konferensi mereka mengatakan bahwa mereka melakukan ini di perusahaan X). Dan tentu saja, kita tidak dapat menggunakan Apache HTTP Client yang baik untuk pergi ke layanan yang kita butuhkan setiap beberapa menit sekali, karena klien ini tidak sinkron, dan tidak memiliki limiter tingkat bawaan, mekanisme tekanan balik atau barang mewah lainnya. Untuk pertanyaan saya, "Mengapa semua ini diperlukan untuk memuat 1 permintaan / menit?" Saya hanya mendapat tatapan mencela dari rekan-rekan saya, yang dahinya tulisan "Ini Anda bodoh" bersinar.
Topik terpisah adalah Mr. Javascript dengan kerangka kerjanya yang tak terhitung jumlahnya. Sejujurnya saya tidak mengerti bagaimana mungkin untuk menciptakan begitu banyak alat untuk sebuah alat yang hanya perlu menggambar formulir di halaman web dan dari waktu ke waktu mengirim permintaan untuk backend. Untung aku melakukan backend.
Pada contoh frontend (dan bukan hanya itu), kita dapat dengan jelas melihat bagaimana kita berjalan dalam lingkaran: mari kita jalankan semua logika di sisi server -> dan sekarang di sisi klien -> dan sekarang di server lagi dan seterusnya pada infinitum iklan. Mari menulis frontend dan backend dalam satu bahasa -> dan sekarang mari kita dalam bahasa yang berbeda -> dan mari kita lagi dalam satu bahasa. Mari kita buat skema untuk format data -> skema hanya untuk orang-orang tua -> dan tidak, skema dibutuhkan semua sama. Salah satu sidekick saya menaiki perpustakaan open source-nya dari yaml ke xml, hanya karena ada skema di sana dan itu bagus ketika Anda terkikik dengan konfigurasi yang sangat besar, dan sebuah IDE yang menyadari XSD dapat melakukan setengah pekerjaan untuk Anda. Masalah berikut mengikuti dari di atas.
Tentu saja, senang memanipulasi sistem sederhana. Saya mengerti keajaiban itu ketika Anda memahami cara kerjanya hingga ke detail terkecil: ketika Anda turun ke tingkat assembler dan kode mesin, dan ketika Anda melangkah lebih dalam - ke tempat prosesor itu adalah serangkaian gerbang logika.
Situasi saat ini sedemikian rupa sehingga perkembangan arus utama dalam perangkat lunak dan perangkat keras prosesor sudah sangat jauh dari pemahaman kristal tentang bagaimana ini bekerja oleh satu orang: prosesor penuh dengan logika yang dihasilkan, cache multi-level dan prediktor cabang sedemikian rupa sehingga bug di dalamnya tidak begitu besar. mereka tidak diperhatikan, atau bahkan dianggap, oleh seluruh tim pengembangan, dan berkembang begitu hebat sehingga mereka menerobos pengaruhnya ke tingkat pengguna. Selain itu, kita dipaksa untuk membawa banyak sekali fungsi lama, sehingga memastikan kompatibilitas, jika tidak kita akan menang dalam kecepatan dan kesederhanaan, tetapi kalah dalam pekerjaan untuk apa perangkat ini awalnya dikembangkan.
Situasinya sama dengan perangkat lunak: pemahaman, dan lebih dari itu menulis instruksi perakitan, tetap hanya di daerah-daerah yang sempit, dan kerangka kerja dan lapisan-lapisan abstraksi memerintah tertinggi dalam apa yang hidup dan berputar di sekitar pengguna.
Dari sudut pandang seseorang yang ingin mengontrol kode dan mesinnya, ini buruk. Dari sudut pandang pengguna - bagus, karena menyederhanakan pemahaman, pekerjaan dan jalur dari ide ke produk. Harga yang kami bayar untuk keinginan pengguna ini adalah bahwa kapasitas prosesor yang berkembang segera dikonsumsi oleh kompleksitas program, yang, tampaknya, tidak dibenarkan oleh apa pun, dan tidak menghasilkan nilai tambah (catu daya, seperti yang mereka katakan di tempat kerja saya sebelumnya).
Namun, jika Anda menggali lebih dalam, ternyata kami mengubah sumber daya ini untuk meningkatkan pemirsa dengan menyederhanakan interaksi.
Sebelumnya, terminal tiket pesawat menuntut pengetahuan tentang singkatan, memahami bagaimana maskapai bekerja dan keterampilan bekerja dengan terminal teks, sekarang setiap pengguna pergi ke Aviasales bersyarat dan mengambil tiket murah di rute yang sulit tanpa banyak wasir.
Anda tidak dapat membuat antarmuka dapat dimengerti oleh orang kebanyakan di terminal teks, karena kejelasan antarmuka adalah resolusi monitor, dan gambar-gambar bagus yang tidak menakuti otak, dan font yang indah, dan tips yang muncul ketika Anda mengarahkan tombol, dan antarmuka sentuh.
Dan juga, kemampuan untuk menguji semua chip ini, dengan fokus pada perilaku pengguna. Bekerja pada air terjun, Anda meluncurkan rilis setahun sekali, mengumpulkan umpan balik pada versi saat ini sepanjang tahun. Sampai beberapa tahap dari antarmuka Anda pergi sepuluh tahun, sepuluh rilis. Dengan meluncurkan koreksi kecil dan mengujinya di sana, Anda akan sampai pada tahap yang sama dalam satu setengah tahun. Tetapi pekerjaan semacam itu membutuhkan langkah yang berbeda, alat dan teknologi lain, dan penolakan terhadap hal-hal tertentu. Dalam kejujuran, dari menjilat kode: semuanya harus bekerja sekarang, karena itu memerlukan proses langkah ini.
Sebagai gantinya, perlombaan gila untuk fitur-fitur baru ini memberi kami basis pengguna yang semakin berkembang: semakin mudah tombol ditekan, semakin banyak orang yang bisa menekannya, dan basis pengguna yang berkembang membawa uang tidak hanya untuk gaji Anda, tetapi juga untuk pengembangan perangkat keras baru. Semakin banyak orang dapat menggunakan smartphone secara produktif, semakin banyak mereka akan membelinya, semakin baik perangkat kerasnya di versi berikutnya. Fakta bahwa kami segera menukar besi ini bukan untuk penerbangan ke Mars, tetapi untuk pemirsa yang tumbuh ... yah, ini dapat dibandingkan dengan perusahaan yang menginvestasikan semua pendapatannya dalam pengembangan, dan bukan dalam dividen dan keuntungan dalam laporan tahunan. Hanya sekarang, untuk beberapa alasan, Anda membenarkan ketika Musk dan Bezos melakukan ini, tetapi Anda tidak dapat membenarkan industri ini.
Baik atau buruk, orang bisa berdebat. Di satu sisi, kualitas perangkat lunak, di sisi lain - kemajuan konstan dalam perangkat keras, khalayak, dan gaji tinggi di industri. Mungkin saya akan memilih yang kedua (walaupun saya lebih suka memperlambat), tetapi saya mengerti orang-orang yang memilih yang pertama.
Tapi satu hal akan menyatukan kita - kita tidak bisa melakukan apa-apa dengan ini.
RE: Terlalu banyak hal
Bagian AsliAlat, bahasa, buku, konferensi, kerangka kerja, dll. Untuk waktu yang lama di belakang hari-hari ketika, untuk pengembangan perangkat lunak, itu sudah cukup untuk memiliki pengetahuan tentang satu PL, beberapa perpustakaan, dan itu saja. Sekarang kami sedang menunggu ratusan kerangka kerja, dengan selusin bahasa (bahkan dalam kerangka satu proyek), modis dan tidak terlalu DBMS, pialang pesan yang ada di mana-mana, ratusan rake penyebaran tersebar ratusan kilometer persegi dan kesenangan lainnya. Sebagai aturan, seorang programmer rata-rata tidak punya waktu untuk mempelajari semua ini di tempat kerja (kecuali untuk alat-alat yang sudah digunakan dalam proyek-proyeknya), karena Anda perlu mengerjakannya. Banyak orang harus menghabiskan waktu pribadi mempelajari teknologi ini, meskipun kemungkinan besar 90% dari yang dipelajari tidak akan pernah berguna. Saya sendiri punya lima ratus artikel di saku saya, banyak tayangan video yang tidak terlihat dari konferensi, dan setiap panggilan ke Habr menandakan kunjungan wajib ke McConaughey.
Tetapi bahkan kerja keras dengan bahasa tertentu atau, misalnya, DBMS di perusahaan Anda terkadang tidak memungkinkan Anda untuk tetap dalam tren, karena teknologi menjadi usang sebelum diterapkan. Bahkan java sekarang akan dirilis dengan kecepatan firefox.
Berkat aliran pengetahuan tanpa akhir yang berkembang pesat, banyak dari kita merasa seperti siswa abadi atau penipu, tidak peduli berapa banyak sistem yang Anda bangun. Dan ini sangat bermanfaat bagi SDM dan pemberi kerja - Anda dapat dengan mudah menjatuhkan RFP Anda dengan beberapa pertanyaan rumit. HR ras jenis ini benar secara politis disebut pengembangan diri.
Fakta bahwa ada banyak alat adalah kelanjutan logis dari paragraf sebelumnya. Ketika ada banyak energi di wilayah ini, ini memungkinkan Anda untuk menghabiskan energi ekstra untuk menguji hipotesis, beberapa di antaranya akan gagal, beberapa akan mengering, tetapi beberapa akan membentuk dasar standar industri baru. Keluhan tentang kekacauan mirip dengan keluhan tentang ketidakefisienan evolusi, yang karena alasan tertentu menciptakan banyak spesies, sebagian besar yang mati dengan tenang, dan bahkan mayoritas tidak terlalu sukses, dan hidup dalam kisaran yang sempit. Apakah benar-benar mustahil untuk segera membuat seseorang yang dapat bertahan hidup bahkan di kutub utara, bahkan di padang pasir, meskipun faktanya dia sendiri agak lemah - dia tidak berlari cepat, tidak ada cakar, giginya kecil dan kusam, sudut pandangnya kecil.
Adalah baik untuk melihat hasil evolusi dari samping, dan bertanya-tanya pada diri sendiri seberapa jauh yang diperlukan untuk menciptakan keuntungan yang sangat jelas - jari yang fleksibel dan otak yang maju.
Tetapi pada awal perjalanan, hasilnya tidak begitu jelas: dinosaurus juga pernah berkuasa di bumi, dan jika ada analis pertukaran di masa mereka, hanya sedikit yang akan menaruh tikus pada beberapa mamalia melawan favorit yang jelas ini.
Limbah dalam bentuk alat yang "salah" adalah pendamping konstan jalur yang mengarah ke atas.
RE: Programmer Harus Menjadi Analis Bisnis & Wawancara Kerja
Bagian AsliBaru-baru ini, saya telah mengamati tren memaksakan otoritas departemen bisnis pada pengembang. Sekarang, selain untuk memenuhi tugas utamanya, pengembang harus memahami subjek pada tingkat analis yang baik dan umumnya berpikir tentang bisnis. Tinggalkan saya sendiri, saya tidak tahu cara meningkatkan rasio konversi Anda.
Wawancara kerja
Ini adalah jenis disiplin khusus yang paling penting dan dicintai. Memang, pada kenyataannya, ini tergantung pada apakah Anda akan tidur di sofa tua hancur di odnushka sewaan di suatu tempat di luar Moskow Ring Road, atau apakah Anda harus bersembunyi di kardus berbaring di pemanas di bawah jembatan. Jika pada awal karier saya wawancara itu sedikit bicara dari hati ke hati, sekarang lebih seperti ujian. Mungkin ini disebabkan oleh fakta bahwa pada masa itu tidak ada gaji dan keramaian yang sangat besar yang ingin masuk ke dunia IT atau hanya mode, saya tidak tahu. Tetapi kenyataannya adalah bahwa ketika Anda datang ke sebuah wawancara untuk posisi pengembang senior, dengan tingkat probabilitas tinggi Anda akan menghadapi tugas-tugas yang dibumbui dengan pertanyaan kuis. “Baiklah, selesaikan masalah di selembar kertas yang kita curi kemarin dengan leetcode. Salah pada unit dalam kondisi batas? Kesalahan Fuuuuu! Anda tidak tahu cara kerja% methodName% di% frameworkName% yang paling modis. Siapa yang menempatkannya di sini? Keamanan! ”Tidak ada yang peduli lagi bahwa kepala Anda diatur secara berbeda dan Anda tidak dapat menekankan tatapan merendahkan dari kutu buku berhidung tinggi dengan cepat dan tanpa kesalahan untuk membungkus algoritma untuk tugas yang belum sempat Anda pikirkan. Seperti berapa kilometer kode dan sistem produksi di belakang Anda. Yah, setidaknya pertanyaan teka-teki sudah mati, dan terima kasih untuk itu.
Tidak, tentu saja tidak. Tetapi dalam kondisi perlunya tes hipotesis cepat, itu jauh lebih produktif untuk melakukan ini di kepala yang sama yang membuat keputusan tentang arsitektur, hanya karena ada lebih sedikit overhead: Anda perlu berunding selama dua hari, dan berpikir selama satu jam. Anda tahu cara bekerja di area subjek - bagus, tidur di sofa yang kusut. Jika Anda tidak tahu caranya, mereka menunggu Anda di area-area di mana keandalan lebih penting daripada kemajuan: ruang, obat-obatan, militer, sistem komunikasi sinyal. Daerah-daerah ini adalah, dan mereka tidak kalah penting frontend. Benar, mereka membayar lebih sedikit. Seperti bias di pasar, yang ingin saya koreksi, tetapi ini adalah sesuatu yang lebih tinggi daripada tidak hanya orang, tetapi kebanyakan perusahaan.
Ngomong-ngomong, faktor yang sama ini memungkinkan Anda untuk memandang rendah SDM dengan pertanyaan rumit, hingga "Saya tidak tahu apa yang saya hadapi, mari kita bicara dengan editor teknis." Tidak ingin menjadi analis, tetapi ingin menulis kode pada TK yang siap pakai? Lihat di atas - area lain untuk Anda: programmer yang baik yang tidak melakukan kesalahan dan efisien serta kompeten menerapkan TK juga sangat diperlukan.
RE: Orang-orang IT
Bagian AsliDi sini kita akan menganalisis beberapa subspesies dari populasi ini, yang dengannya kita paling sering harus berurusan.
Sebenarnya pengembang dan simpatisan. Bertentangan dengan stereotip - untuk sebagian besar bukan kutu buku Ortodoks, tetapi orang-orang yang cukup normal. Tapi sebagai aturan, tidak ada yang perlu dibicarakan dengan mereka. Semua percakapan di luar jam kerja mulai bekerja. Tapi bagaimana lagi, jika Anda dipaksa untuk mempelajari semua teknolog ini sepanjang waktu? Saran saya adalah untuk menjauh dari orang-orang dengan kemeja kotak-kotak dengan ransel, jika tidak, Anda bisa mendapatkan kebosanan yang mematikan. Banyak dari mereka pergi bekerja bukan untuk bekerja, tetapi untuk bermain mainan. Mari kita ciptakan sepeda, kencangkan kerangka baru (dan kita akan mengamuk di malam hari di malam hari) dan kita pasti akan menjatuhkan segalanya di tengah jalan, karena mainan ini lelah, selain itu, kita membawa yang baru. Tetapi kemudian kita akan meledakkan pipi kita dan memberi tahu di konferensi bagaimana kita mengalahkan masalah yang kita ciptakan sendiri. KEUNTUNGAN! Orang-orang ini dengan mudah dibawa ke semua jenis sampah seperti "tugas menarik" dan "sistem kompleks" (tidak mungkin untuk membangun kalkulator tanpa selusin layanan mikro dalam budaya TI), yang dalam istilah manusia berarti mengambil kotoran masam dari mamut, tetapi untuk lebih sedikit uang, sehingga mengurangi upah industri. Seperti dalam lelucon “- Ayah, apa yang akan kita makan hari ini?" "Tidak ada apa-apa, Nak, aku sedang mengerjakan tugas-tugas menarik dalam tim yang ramah."
Manajer proyek. Jujur, selama 10 tahun saya tidak mengerti siapa manajer proyek dan mengapa mereka dibutuhkan. Di kantor yang sangat berbeda, kelihatannya seperti ini: ada banyak tugas, memilah apa yang ada dan bagaimana, dan melakukannya sebelum tanggal ini dan itu. Dan saya pergi untuk mendapatkan latte dari para hipsters di lantai pertama dan menulis di Instagram hari yang sulit hari ini. Hanya sekali saya melihat seorang pria yang membangun semua jadwal yang membosankan ini, disulap dengan tugas dan menjadi asisten kami, dan bukan hanya orang keren yang tidak dapat memprogram, tetapi saya benar-benar menginginkan ITP.
Pelayan Terkasih oleh banyak kategori. Berkat dumping mereka, masuk akal dan ideologis tidak dapat memasuki industri - dalam mengejar rubel yang panjang, banyak pekerja bergulir siap bekerja sama sekali secara gratis.
Kami akan diam tentang sisanya.
Pengembang yang membosankan yang hanya berbicara tentang pekerjaan? Aneh, rasanya membosankan bagi saya yang ingin diam-diam memotong kode sesuai dengan TK selesai dari 9 menjadi 18. Kami berdua salah, tetapi saya berbicara tentang sesuatu yang lain: organisasi pikiran seperti itu, di mana tugas berputar terus-menerus di kepala, memberikan dorongan signifikan pada kecepatan pengembangan dan pengujian hipotesis. Sedikit melebihi batas, dan kelelahan tampak di sana, tetapi ini adalah masalah mengendalikan kesehatan mental. Yang tidak meniadakan fakta bahwa beberapa perusahaan (kami tidak akan menunjuk pada mereka yang membayar karyawan taksi setelah 22 jam, mendorong mereka untuk tetap bekerja) menyadari bahwa karyawan yang terbakar bekerja lebih baik, menyediakan semua kondisi untuk pembakaran ini.
Proyek? Anda tidak tahu cara memasaknya. Sebuah proyek adalah alat universal: di satu sisi, itu mengambil sendiri tendangan ajaib untuk programmer (seorang programmer, dibiarkan sendiri, beralih untuk membuat hal-hal lucu untuk kekasihnya), dan di sisi lain, arsitek dan pemimpin tim dapat membuang bagian terbesar dari pekerjaan organisasi di atasnya mengatur pertemuan, menjaga relevansi jadwal, melaporkan pekerjaan yang dilakukan, komunikasi rutin dengan pelanggan, dan sebagainya.
RE: Bisnis
Bagian AsliPerangkat lunak di dunia modern tidak dilakukan hanya karena itu menyenangkan (walaupun kadang-kadang tampaknya). Hal ini paling sering dilakukan untuk mendapatkan pembantu - langsung atau tidak langsung. Dan sehubungan dengan fakta ini, kita dapat membagi orang menjadi 2 kategori.
Mereka yang peduli bagaimana - sehingga semua yang ada di dalamnya indah dan benar.
Mereka yang peduli tentang apa yang menjadi orang-orang yang peduli tentang esensi produk yang mereka buat.
Biasanya, pengembang berisi kedua kategori ini, hanya dalam proporsi berbeda.
Untuk keduanya, saya punya berita sedih.
Untuk kategori pertama - dari sudut pandang menghasilkan uang, tidak masalah bagaimana arsitektur yang benar dipilih dan seberapa indah kodenya. Sama seperti semua keselamatan Anda, praktik terbaik, dll. Anda dapat menempelkan tongkat ketiak, mendapatkan nenek, dan kemudian manajer yang membuat semua ini melompat ke kapal tetangga "untuk mendapatkan pengalaman baru", dan tim membangunkan istal di malam hari.
Untuk kategori kedua - 90% dari Anda melakukan apa yang telah dilakukan orang lain sejak lama. Dengan pengecualian langka, semua produk Anda sangat sekunder. Namun demikian, pengusaha yang licik berusaha memberikan "ideologi" ke sistem pembayaran berikutnya, perbankan online, dan sejenisnya. Saya telah melalui semua ini sendiri, dan saya harus mengatakan, lebih mudah untuk bekerja ketika Anda memiliki jawaban yang jelas untuk pertanyaan "mengapa semua ini perlu." “” - , , . , , . “ , ” . , HR, , 146% - “ , , ”.
Kebetulan seorang pria datang dengan uang. Mereka tidak melakukannya di generasi sekarang, dan bahkan seratus tahun yang lalu. Uang telah terbukti menjadi alat yang sangat baik untuk mengatur masyarakat yang heterogen dengan konsep kecantikan yang berbeda dan keinginan yang berbeda dari orang-orang yang termasuk di dalamnya.Anda dapat mencoba untuk menciptakan sesuatu yang lain, tetapi sejauh ini Anda belum menemukan sesuatu yang secara fundamental lebih baik. Tentu saja ada motivasi seperti dukungan sosial dan semangat tim, tetapi yang pertama adalah turunan dari uang yang telah dicerna negara, dan yang kedua adalah bumbu, bukan hidangan utama. Dalam keadaan darurat, pencuci mulut.Anda dibayar untuk pekerjaan Anda. Jika pekerjaan Anda tidak menghasilkan uang - Maaf, bisnis tidak membutuhkannya. Kasar, saya tahu. Ayo coba lebih lembut.. — , . , — , , . , , , , . , : - , , , — . 16% ? ! , 5%? !
Jika perusahaan tidak dapat membenarkan peninjauan kode karena kode mereka hidup selama tiga bulan, setelah itu diganti dengan yang baru, lalu kehabisan sana, apa yang Anda lakukan di sana? Ada sejumlah besar perusahaan di mana peninjauan kode dan refactoring merupakan komponen penting dari proses. Dan perusahaan pertama berfokus pada pengujian hipotesis, bukan pengkodean: ini juga normal, dan memungkinkan Anda menemukan ceruk baru di mana Anda dapat tumbuh, matang, menumpuk lemak dan mulai mempraktikkan tinjauan dan refactoring.Anda tidak boleh menyalahkan perancang yang membangun rumah batu bata mainan tanpa mengikatnya dengan mortar: tinggal di hamster di rumah ini, dan tugas rumah ini adalah untuk menguji hipotesis penampilan, dan tidak berfungsi sebagai rumah. Dan bahkan jika perancang ini siap membayar Anda untuk membantunya membangun rumah mainannya, jangan meludahi dia dengan fakta bahwa Anda memerlukan lubang mortar dan pondasi, tetapi menetap di pembangun normal.RE: Kesehatan
Bagian Asli, , ( ) . , . , - , . , . , , , . 35+ , “ , 25 ?” “ ?”. — .
Mungkin ini adalah satu-satunya titik di mana saya tidak memiliki apa pun untuk merespons sepenuhnya. Selain itu, di dunia saya seseorang memiliki kemauan dan alasan, dan jika dia percaya bahwa dia tidak perlu mengangkat beban, maka dia tidak akan mengangkatnya.