Halo Habr! Pengembang sering kali dipekerjakan untuk memecahkan masalah bisnis seperti seorang profesional. Tetapi terkadang pengembang tidak mendengarkan pendapat pengembang tentang masalah di mana mereka lebih kompeten daripada perwakilan bisnis. Fakta bahwa ini bisa dilakukan dan mengapa itu harus menjadi pengembang, saya ingin berbicara.
Kebahagiaan dan kepuasan kerja
— . , . — . , , .
(software development) , . , , , , , , — . .
?
, , . — , , « ?» ( . ). ( , hard skills ). — , « ?». Agile (https://agilemanifesto.org/).
, *argumentum ad auctoritatem ( ).* , — , .
, — . , , , , , — errare humanum est. , , .
?
best practices , , . — . , — , , . — , .
, , , . :
, . , , . . — , , .
: , . . — , . , , , , , , .
?
, , . , , , , . , , . — — , , TDD ( ) code review, . — — , best practices, , .
, , . , , . , , . , , — , , .
— . , . , , best practices — . , , , , .
, , . , — , , , , .
, . , , .
Artikel ini adalah pendapat yang sangat subjektif tentang bagaimana seorang pengembang bisa mendapatkan lebih banyak kesenangan dari pekerjaannya dengan menunjukkan profesionalisme dan menyampaikan kepada bisnis ide-ide subjektif yang dianggap benar oleh pengembang, sebagai seorang profesional. Artikel ini sebagian besar terinspirasi oleh ide-ide Agile, buku "Arsitektur Bersih" oleh Robert Martin, serta pengalaman, pengalaman, dan pengalaman saya sendiri dari teman dan kolega.