Topi apa yang seharusnya tidak dipakai oleh seorang programmer? [Tutup]


29

Dalam pengalaman saya, pengembang perangkat lunak cenderung memakai banyak topi dan mengisi banyak peran dengan tanggung jawab yang berbeda. Dari tidak hanya coding, tetapi kadang-kadang juga menulis SQL, mendesain antarmuka pengguna, mendesain database, manipulasi grafik, bahkan pengujian QA.

Jika peran utama adalah menulis perangkat lunak / kode, peran apa yang seharusnya tidak diambil pengembang? Apakah ada?

Maksud dari pertanyaan ini bukan karena pengembang tidak mampu mengisi peran lain - tetapi memiliki peran tambahan benar-benar berfungsi melawan peran utama , atau harus benar-benar menjadi peran khusus seseorang yang tidak terutama memprogram.


20
Sebuah topi ... oh, tunggu ..
ChaosPandion

21
IMO, seorang programmer, tidak boleh memakai salah satu sombrero Meksiko besar itu, karena pinggirannya akan terus membentur monitor.
Mason Wheeler

1
@Peter Turner: 'topi programmer awesomest' akan menjadi salah satu pekerjaan baru yang me-mount dua kaleng bir. Hanya saja, tanpa bir. Red Bull.
BlairHippo

4
Mengutuk. Judul yang menjanjikan ...
Tidak ada yang tahu

4
@ Alasan, menjaga sombrero di atas monitor akan melindungi dari pantulan di layar yang mengkilap. Dengan kata lain - teknik.

Jawaban:


54

Sysadmin. Mengembangkan perangkat lunak dan menangani infrastruktur TI adalah dua keahlian yang berbeda yang terlihat mirip dengan orang luar. (Ini semua hanya menggedor komputer, kan?) Untuk perusahaan bertubuh kecil, godaan akan sangat kuat untuk membuat The Computer Guy bertanggung jawab atas semua mesin di kantor.

Jika Anda memiliki keterampilan untuk benar-benar memakai kedua topi itu, luar biasa; tetapi itu adalah salah satu hal yang bisa menjadi tenggang waktu yang jauh lebih besar daripada yang disadari orang, dan jika Anda belajar sendiri ketika Anda pergi, kemungkinan Anda tidak melakukannya dengan sangat baik.


7
INI. Serius, hanya karena saya bekerja ON komputer tidak berarti saya dapat memperbaiki infrastruktur. Anda hanya membuang-buang waktu pengembang Anda.
Jaco Pretorius

5
+1 kerusakan yang dapat ditimbulkan oleh sysadmin amatir sangat besar.
davidtbernal

Dan jika Anda mendapatkan topi sysadmin, mereka mungkin menempel Anda dengan topi manajer fasilitas juga yang harus dihindari di semua biaya.
HLGEM

3
OTOH, saya bekerja di sebuah perusahaan dengan departemen IT yang sangat tidak kompeten dan lamban. Apa yang saya tidak akan berikan hanya untuk dapat membuat perubahan firewall saya sendiri ...
Gabe Moothart

1
Seseorang menunjukkan bahwa bos saya tidak berpakaian, tetapi mengatakan kepada mereka bahwa ia akan menjadi kotor dari lantai memasang komputer. Mereka menunjuk ke arah saya yang menunjukkan bahwa saya harus melakukannya. Saya hampir melompat di meja mereka dan mencekiknya, tetapi saya menyesap kopi dan mengatakan bahwa saya tidak melakukan perangkat keras.
JeffO

35

Anda mengenakan topi apa pun yang diminta atasan Anda. Itulah yang membuat Anda menjadi pemain tim. Itulah yang membuat Anda menjadi Pemecah Masalah .

Orang terlalu terperangkap dalam gagasan menjadi "pengembang" atau "arsitek" atau "analis". Persetan dengan itu. Anda harus menjadi pemecah masalah. Kode hanyalah alat di sabuk Anda.

Pemecahan Masalah tidak pernah ketinggalan zaman.

Jika majikan saya ingin saya melakukan dukungan teknis atau membuat komputer, biarlah. Sepertinya mereka membuang-buang uang, mempertimbangkan gaji pengembang, tapi itu urusan mereka. Saya di sini untuk menyelesaikan masalah. Bagaimanapun saya bisa melakukan itu, saya akan melakukannya. Dan jika saya merasa seperti, setelah waktu tertentu, bakat saya terbuang sia-sia atau kepuasan kerja saya tidak seperti yang saya inginkan, maka saya hanya memiliki banyak hak untuk pindah ke pekerjaan lain.

Tetapi untuk pertanyaan mendasar - tidak ada topi yang tidak Anda kenakan. Heck, jika mereka ingin Anda mengambil kopi, lakukanlah. Pecahkan masalah mereka; ketahuilah bahwa Anda memiliki hak untuk menemukan pekerjaan lain jika Anda menginginkan perubahan.


5
@Josh: Saya pikir itu akan menjadi salah satu dari situasi "mencari pekerjaan baru".
Adam Lear

21
Berhati-hatilah dengan ini. Atasan cenderung mengambil keuntungan dari mereka yang mau melakukan apa saja. Pastikan Anda diberi kompensasi dengan benar.
Tony

5
Saya tidak berpikir Chris cukup mengatakan "melakukan apa pun" (well, dia sedikit pada akhirnya; saya tidak akan mengambil kopi untuk siapa pun yang tidak mengambil saya minuman juga), tetapi mengatakan "Saya seorang pengembang, saya tidak akan mengganti kartrid printer "hanya menjadi sombong.
Peter Boughton

10
Saya tidak setuju. Sangat mudah untuk mengatakan bahwa seorang pengembang harus dapat melakukan apa pun yang diminta tetapi itu tidak berarti dia HARUS. Ada beberapa masalah konflik kepentingan yang muncul dalam situasi ini. Saya tidak ingin akses ke sistem produksi karena saya akan disalahkan ketika mereka turun ("oh, baik XXX ada di sana bulan lalu, jadi saya yakin dia mengacaukan sesuatu karena dia seorang dev, bukan admin")
MBonig

7
-1; ada inti kebenaran di sini, tetapi ada beberapa keterbatasan dalam pola pikir ini, jawaban ini tidak cukup untuk mengakui. Bagaimana dengan ketika masalah mendasar yang sebenarnya adalah bahwa majikan Anda mengisap manajemen personalia? Saya pernah menyaksikan keruntuhan kantor karena para atasan bersikeras memilih insinyur yang cerdas dan cakap dalam peran yang mereka benci dan lakukan dengan sangat buruk. Ada kalanya mengatakan "Tidak!" adalah hal terbaik yang dapat Anda lakukan untuk diri sendiri dan atasan Anda.
BlairHippo

29

Penguji!

Silakan kirim kami penguji langsung dari sekolah penguji jika perlu!

Tanpa penguji, orang-orang berharap semuanya berjalan baik karena programmer adalah penguji dan mereka sangat pintar sehingga harus bekerja.

Saya tidak mengatakan dogfooding bukan ide yang baik. Saya hanya berpikir penguji sangat penting sekarang karena saya seorang programmer.


4
Penguji yang berdedikasi baik pasti di bawah nilai!
Peter Boughton

3
Makanan anjing!? Saya hanya memasak lobster bintang lima! ... dan itulah mengapa saya perlu tester untuk memberi tahu saya ketika saya mengacaukan sesuatu. Saya membuat benda itu dan tahu cara kerjanya. Tidak seorang pun yang membuat UI pernah memenuhi syarat untuk mengujinya secara menyeluruh, hanya karena mereka tahu cara kerjanya, bukan cara kerjanya dengan seseorang yang tidak.
Morgan Herlocker

15
Tidak ada yang salah dengan menjadi tester pada umumnya. Adalah salah untuk menjadi satu-satunya tester untuk kode ANDA SENDIRI. Kode programmer dengan serangkaian asumsi dalam pikiran, dan jika tester memiliki asumsi yang sama, mereka tidak akan menjalankan bagian yang tidak terduga, dan akan kehilangan banyak bug.
dbkk

5
Menguji kode Anda sendiri jelas tidak boleh. Seorang programmer dapat mencakup banyak hal lain, tetapi pengujian fungsional yang sebenarnya (jika Anda tidak melakukan pengujian unit, Anda mungkin tidak menjadi seorang programmer) dari kode Anda sendiri adalah ide yang sangat buruk. Dogfooding dengan itu bagus, pikiran.
glenatron

3
+1 - programmer berpikir secara berbeda dari non-programmer dalam hal cara menggunakan program. Apakah Anda pernah menemukan bug di item menu "File -> Save"?

26

Anda harus berhati-hati untuk menjadi orang yang tepat untuk masalah perangkat keras kantor . Ini dapat mencakup pemecahan masalah PC, admin server, cadangan, dan bahkan kerja sistem telepon. Saya membuat kesalahan dengan menyebutkan pengalaman perangkat keras saya sebelumnya, dan akhirnya tugas perangkat keras / pemecahan masalah saya sangat bertentangan dengan tugas pemrograman saya.


Beri tahu pelaku bahwa mereka membutuhkan izin dari bos Anda, dan daftarkan semua waktu yang digunakan untuk ini.

@Thor Arah untuk mengerjakan hal-hal hardware -datang- dari bos saya. Itu sangat membantu untuk kantor, tetapi saya tidak dapat memfokuskan karier saya pada pemrograman sebanyak yang saya inginkan pada saat itu.
Jon Onstott

@ Jon, jika bos bilang kamu perlu melakukannya, yah ... kamu harus melakukannya. Anda kemudian dapat berdiskusi dengannya apakah ini memuaskan atau tidak, dan jika Anda tidak dapat mencapai kesepakatan, sekarang saatnya untuk pergi.

+1 Hal yang sama terjadi pada saya. Mereka ingin saya tidak hanya menulis kode tetapi juga menangani masalah jaringan bersama dengan vendor peramban dan yang telah menyebabkan banyak tekanan.
Rich

16

Seorang programmer tidak harus hanya tester untuk kode sendiri .

Pengembang menulis kode dengan serangkaian asumsi. Jika penguji memiliki seperangkat asumsi yang sama, mereka tidak akan menggunakan fungsionalitas yang tidak terduga di luar batas tersebut, dan banyak masalah akan tetap tidak terdeteksi.

Selain itu, untuk bergerak maju, para pengembang tidak memiliki motivasi yang tinggi untuk mencoba memecahkan banyak hal, sementara para penguji (mungkin berada di tingkat bawah sadar).

Ini tidak berarti pengujian dev tidak berguna. Justru sebaliknya - pengujian dev yang baik memungkinkan penguji untuk fokus pada menemukan masalah yang lebih dalam. Namun, pengujian dev bukan pengganti untuk tester khusus.


10

Dua yang bisa kupikirkan segera.

  1. Dukungan teknologi. Saya di sini bukan untuk membantu klien bekerja melalui situs baru atau mengajari mereka cara menggunakan fitur.
  2. Meskipun mungkin diperlukan untuk berinteraksi dengan klien di berbagai titik dalam proses, kecuali jika Anda seorang programmer pengelola, Anda tidak boleh berkomunikasi secara langsung dengan mereka tentang fitur dan implementasi desain.

Anda bisa mengatakan bahwa pengembangan CSS / UI akan berada di luar pemrograman "ranah" tetapi dalam pengalaman saya itu adalah keterampilan yang diperlukan saat ini. Anda tidak bisa pergi begitu saja dengan tabel dan bergantung pada orang lain untuk mengimplementasikannya dengan benar. Saya mungkin tidak suka menerapkan desain atau mengubah kode untuk menangani desain baru, tetapi itu adalah bagian dari pekerjaan.

Menulis pertanyaan tidak masalah, pengujian T / A baik-baik saja (dan IMO harus menjadi pekerjaan programmer, memiliki departemen eksternal yang dapat menemukannya, tetapi pertama-tama Anda harus mengujinya). Administrasi server agak sedikit abu-abu. Bergantung pada seberapa besar proyek tersebut atau jika Anda memiliki admin server khusus, itu mungkin atau mungkin tidak diperlukan.


7
Mengenai poin 2, setidaknya ada satu perusahaan yang memiliki prinsip pendiri bahwa orang yang menulis kode harus berbicara langsung kepada pelanggan: disintermediasi memiliki kelebihan.
Frank Shearar

10

Secara umum, sudah menjadi pengalaman saya bahwa sebagian besar programmer tidak harus mengembangkan tampilan dan nuansa antarmuka pengguna - walaupun saya tentu mampu mengembangkan UI (dan sering membuat satu ketika membangun prototipe atau bukti konsep), ini adalah lebih baik diserahkan kepada faktor manusia (yang di perusahaan kecil kami adalah seorang seniman grafis yang juga melakukan tata letak layar dan menciptakan sebagian besar manual dan brosur).

Selain itu, pengembang tidak boleh melakukan pengujian QA - itu adalah pekerjaan departemen QA (perusahaan tempat saya bekerja membuat perangkat medis tertanam, jadi ini merupakan persyaratan bahwa pengujian dilakukan oleh departemen terpisah).

Di sisi lain, saya tidak melihat alasan mengapa pengembang tidak dapat mendesain database dan menulis SQL, jika mereka memiliki latar belakang untuk melakukannya - saya telah melakukannya berkali-kali.


2
+1 Setuju bahwa pengujian QA oleh pengembang yang menulisnya mengalahkan tujuan.
spong

2
@JoshK Beberapa pengujian QA dapat dilakukan oleh pengembang, tetapi pengujian QA utama harus dilakukan oleh orang lain. Jika Anda menguji aplikasi Anda sendiri yang Anda tulis, secara tidak sadar Anda akan berjalan di sekitar masalah potensial. Intinya adalah untuk menemukan masalah yang tidak dapat ditemukan pengembang, semacam mata baru yang bisa dibicarakan.
spong

2
@JoshK @ChaosPandion Setuju, beberapa pengujian sebelumnya oleh pengembang harus dilakukan - tetapi tidak boleh dipercaya, sehingga pisahkan pengujian QA oleh mereka yang tidak mengembangkannya.
spong

5
-1: Saya tidak setuju bahwa programmer tidak boleh mendesain GUI. Saya telah bekerja selama 8 tahun di sebuah perusahaan kecil, dan saya merancang semua antarmuka pengguna. Saya selalu mengikuti pedoman desain yang sangat baik oleh Microsoft, dan membaca beberapa buku desain HMI. Kami hanya mengalihdayakan grafis ke ilustrator eksternal.
Wizard79

3
Satu hal yang menggangguku di sini adalah implikasi bahwa orang grafis lebih cocok daripada seorang programmer untuk merancang UI. Mungkin seniman grafis Anda sangat pandai mendesain antarmuka, tetapi pada umumnya ia dapat berubah menjadi antarmuka yang membingungkan, tidak dapat digunakan, dan cantik sebagai lawan dari antarmuka yang membingungkan, nyaris tidak dapat digunakan, dan jelek yang Anda dapatkan dari programmer stereotip.
David Thornley

8

Dukungan teknologi

Begitu banyak hari saya terbuang dengan menerima panggilan dukungan teknologi ...

Beberapa yang populer adalah:

  • "Akun saya terkunci" atau "Saya lupa kata sandi saya"
  • "[Telepon | keyboard | mouse | komputer] saya tidak berfungsi"
  • "Komputer saya lambat, bisakah Anda memeriksanya untuk sesuatu yang tidak biasa?"
  • "Mengapa X terjadi ketika saya mengklik tombol ini? Seharusnya melakukan Y"
  • "Aku terus mendapatkan popup ini ...." atau "Kurasa aku punya virus"
  • "Orang ini tidak lagi di sini, bisakah kamu menonaktifkan semua barang mereka?"
  • "Kami memiliki karyawan baru, dapatkah Anda mengaturnya dengan login, kartu keamanan, telepon ext, email, dll?"

6

Peran apa pun yang membuatnya mengatur dirinya. Dalam tim kecil, sering ada kecenderungan untuk menjadikan salah satu pengembang senior sebagai manajer proyek, tetapi juga membuatnya tetap dalam tim sebagai programmer. Ini mengarah ke semua jenis masalah, karena orang ini, sebagai seorang programmer, pada dasarnya tidak dikelola. Alih-alih mendelegasikan semua tugas kepada anggota tim lain, ia akan sering tergoda untuk menugaskan banyak dari mereka untuk dirinya sendiri, terutama tugas yang paling sulit. Jadi tugas yang paling sulit, mereka yang paling mungkin menyebabkan masalah, ditugaskan kepada orang yang hanya 50% tersedia sebagai programmer dan dengan demikian melaporkan kepada siapa pun. Ketika anggota tim lain tidak dapat memberikan, alih-alih menendang pantat mereka, ia akan mencoba melakukan tugas mereka, untuk, karena sebagai manajer proyek, ia bertanggung jawab atas keberhasilan dan cara teraman untuk menyelesaikannya adalah dengan melakukannya sendiri bukan?


5

Dukungan teknis untuk sesuatu yang Anda tidak punya andil dalam mengembangkan, menyebarkan, atau memelihara, dan belum mendapatkan pelatihan untuk dan tidak terus mengikuti perkembangan perubahan besar. Sebagian dari pekerjaan saya adalah menjawab telepon untuk klien yang menanyakan mengapa internet mereka tidak berfungsi. Saya tidak berurusan dengan setengah dari bisnis itu, jadi saya tidak bisa memberi tahu mereka apa-apa tentang penggunaan.

Tidak harus melakukan dukungan teknis, tidak ada masalah dengan itu. Menjadi seorang sekretaris / teknisi pendukung sambil mencoba mengembangkan sesuatu.

Ini cukup melelahkan karena harus mendengarkan orang mengeluh sepanjang hari dan tidak bisa memberi tahu mereka apa pun. Saya sarankan menghindari ini di semua biaya.


Ya itu sangat melelahkan untuk harus berganti kepribadian beberapa kali sepanjang hari. Sulit untuk mengerjakan tugas yang membutuhkan konsentrasi ketika Anda terus-menerus terganggu.
Rich

5

Penjualan .

Beberapa bugger yang malang harus melakukannya, tetapi pastinya bukan pengembangnya.


4

Seiring bertambahnya usia, saya menyadari bahwa yang terbaik adalah jika pengembang tidak melakukan penyebaran sendiri (saya berjuang mati-matian). Mereka seharusnya tidak memiliki hak apa pun atas basis data produksi kecuali hak pilih. Kode kami menjadi jauh lebih sedikit kereta (dan hal yang sama tidak muncul berkali-kali karena perubahan itu hanya dibuat dalam prod dan penyebaran dev kemudian menimpa lagi kemudian diperbaiki hanya pada prod dalam terburu-buru, bilas dan ulangi) ketika kita harus mulai memberikannya kepada orang lain untuk disebarkan dan tidak diizinkan melakukan perbaikan produksi dengan cepat karena penyebarannya tidak tepat. Lebih lanjut kami berhenti memiliki "pembaruan yang tidak disengaja tanpa disorot klausa tempat yang mengubah setiap catatan dalam tabel" masalah.


Ya, ya dan ya. Jangan pernah memberi pengembang akses ke produksi dan sangat terbatas (dan lebih disukai tidak ada) untuk pementasan. Jika tidak ada yang lain itu mengurangi stres mereka terkena.
ElGringoGrande

1
Iya nih! Saya seorang pengembang, dan saya tidak ingin akses ke semua barang produksi ini. Dan dengan orang lain melakukan penyebaran perangkat lunak, itu satu lagi tes proses penyebaran. (Dan mungkin pemulihan desaster juga akan membaik.)
cringe

3

Artis dan Perancang Antarmuka Pengguna .

Sebagian besar programmer sangat miskin dalam hal karya seni, tetapi perusahaan tidak perlu membayar artis untuk menggambar dan ikon untuk produk mereka, dan cukup menggunakan "seni programmer" - dengan hasil yang mengerikan. (Sampai Windows Vista, ini adalah faktor pembeda yang paling jelas antara Mac dan PC - Mac tampak cantik dan ramah, PC merusak pemandangan)

Dengan cara yang sama, banyak programmer tidak terlalu tertarik dengan antarmuka pengguna - mereka terutama peduli tentang kode mereka. Mereka hanya mengekspos isi variabel anggota mereka langsung ke beberapa bidang yang dapat diedit, sering tidak peduli di mana mereka meletakkan tombol dan bidang pada formulir mereka, dan menganggap bahwa ini cukup, sehingga perangkat lunak tidak dapat digunakan. (Seluruh industri ponsel sangat bersalah akan hal ini sampai iPhone tiba untuk menunjukkan kepada mereka bahwa Anda benar-benar dapat membuat UI ponsel yang baik untuk digunakan)

Lotus Notes adalah contoh cemerlang dari seberapa buruk kedua hal ini dapat terjadi jika Anda tidak mendapatkan desainer profesional untuk membantu programmer keluar.


2
"Kebanyakan programmer sangat miskin dalam artwook" dan "Banyak programmer tidak terlalu tertarik" tidak sama dengan "tidak ada programmer yang tertarik" dan "semua programmer buruk". Sebenarnya saya kenal pasangan yang cukup baik dalam hal itu.
MIA

1
@ Jim Leonardo: Memang. Itu sebabnya saya mengatakan "paling" dan "banyak" daripada "semua". :-)
Jason Williams

3

Menulis tes keseluruhan dan rencana tes. Serius, teman-teman, saya bisa menulis rencana pengujian saya sendiri, tetapi itu berarti memasukkan ke dalam produk apa pun kesalahpahaman, asumsi salah, dan kesalahan kognitif yang saya buat saat menulis barang. Itulah satu-satunya hal yang saya benci tentang satu perusahaan tempat saya bekerja; di mana saya sekarang, setidaknya kita memiliki ulasan kode yang mungkin akan menangkap hal ini.


Yap, sebagian besar tes harus ditulis berdampingan dengan spesifikasi, sebelum kode apa pun dibuat. Meskipun memiliki pengembang menambahkan tes tambahan berdasarkan pengetahuan tentang apa yang mereka sentuh bukanlah hal yang buruk.
Peter Boughton

3

Jangan pernah memakai lebih banyak "topi" daripada yang bisa Anda tangani dan nyamankan, mencoba merpati pengembang lubang dengan mengatakan bahwa mereka tidak boleh melakukan A atau B berarti bahwa perancang UI hebat mungkin tidak diperhatikan karena seseorang berpikir bahwa programmer harus menjauh dari UI.

Pada akhirnya, setiap orang akan memiliki kekuatan dan kelemahan yang berbeda dan seorang manajer / penyelia / pemimpin tim yang baik harus mengetahui cara terbaik untuk mengarahkan orang-orang yang bekerja untuk mereka untuk memastikan bahwa talenta digunakan dengan tepat. Demikian juga, jika Anda tidak nyaman merancang UI atau berhadapan dengan pengguna akhir, beri tahu tim Anda sehingga Anda dapat meminimalkan peran Anda di bidang itu. Namun, Anda harus siap untuk mengambil beberapa pekerjaan tambahan di bidang lain.

Juga, jika Anda memakai terlalu banyak topi (mis. Programmer, perancang UI, penguji, analis bisnis, dll) maka Anda akan melakukannya dengan buruk di beberapa di antaranya, atau Anda akan kelelahan. Pastikan Anda tahu berapa banyak topi yang bisa Anda tangani dan coba pertahankan beban kerja di sekitar level itu.

Di luar itu, benar-benar tidak ada "topi" yang tidak boleh dikenakan pengembang jika mereka memiliki keterampilan untuk unggul dalam peran itu.


1

Saya cenderung menerima pekerjaan apa pun yang dilemparkan kepada saya jika dan hanya jika:

  • Saya memperingatkan sebelumnya tentang tingkat keahlian saya dan kemungkinan implikasinya dan bos saya memutuskan bahwa itu dapat diterima
  • Ada orang tingkat guru yang dapat (dan mungkin akan pada tahap tertentu) membantu saya untuk menghadapi sesuatu yang tidak terduga
  • Baca beberapa dokumentasi, pertanyaan yang diajukan secara online, dll.

Dengan cara ini saya sebagian besar diasuransikan terhadap bos saya dan jika ada yang salah itu setidaknya bisa diperbaiki.


1

Pengembang adalah pemangku kepentingan dalam situasi (seperti pelanggan, pemilik, dll), sehingga mereka memiliki hak untuk mengharapkan pekerjaan yang bermakna. Menurut saya, itu berarti kesempatan untuk bekerja dengan kekuatan Anda .

Jadi, seorang pengembang tidak boleh memakai topi yang tidak memberi energi, berkontribusi pada pertumbuhan pribadi, dan mengarah pada kinerja puncak - dan mencuri waktu dari "topi" yang melakukan hal-hal ini untuk mereka.

Selain tidak menjadi satu-satunya yang menguji kode mereka sendiri, saya pikir "topi" apa pun tidak apa-apa jika itu berarti bagi pengembang yang mengenakan topi.


1

"Desainer" atau "pria kreatif". Anda akan beralih dari membuat maket antarmuka aplikasi dengan polos untuk menulis teks pemasaran untuk kampanye iklan online berikutnya atau diskusi tanpa akhir tentang warna biru yang "tepat" sebelum Anda mengetahuinya x_x.


0

topi itu dengan kaleng bir di sampingnya dengan sedotan. ide yang buruk jika Anda tertangkap.

edit:

Inilah topi yang saya benci tetapi itu memiliki pahala yang besar - itu adalah pertanda besar bagi saya yang mengatakan jika hal ini melanggar itu semua salahmu .... ah, tapi jika itu baik, maka kamu anakku adalah anak yang baik kita semua tahu kamu adalah - sekarang kembali ke ruang bawah tanah ... anak baik ... itu saja.

Topi menyalahkan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.