Читацькі дописи
IT Community

Цей матеріал – не редакційнийЦе – особиста думка його автора. Редакція може не розділяти цю думку.

Програмування — це проста штука: вам дають завдання, ви пишете код, відправляєте в репозиторій і забуваєте. Яка різниця, що буде далі? Як цей код вплине на продукт? Як він буде підтримуватись через рік? Це все турботи менеджерів, DevOps-ів і майбутніх нещасних розробників, які працюватимуть з вашим творінням.

Але якщо раптом у вас є підозра, що варто розуміти більше і мислити ширше, а не просто писати рядки коду — треба бути обережним. Деякі книжки можуть зіпсувати вас як класичного «типового розробника», що живе за принципом «It works, don’t touch it».

Я зібрала список особливо небезпечних книг, які можуть змусити вас мислити системно, будувати кар’єру, рефакторити код і навіть ефективно взаємодіяти з іншими людьми. 

Ось вони — 7 книг, які програмістам краще не читати, якщо вони не хочуть випадково стати занадто хорошими у своїй роботі.

«The Pragmatic Programmer» — Andrew Hunt, David Thomas

Небезпека: може зробити вас занадто самостійним і вдумливим інженером.

 Чому слід уникати?

• Можна почати самостійно знаходити та виправляти проблеми;
• Доведеться думати перед тим, як писати код; 
• Ви почнете ставити запитання про доцільність рішень, що небезпечно; 

Ризик: Один програміст прочитав цю книгу та почав писати код так, щоб його легко підтримували інші. Колеги припинили страждати, код став чистішим, а хаосу поменшало. Він навіть автоматизував тестування! Його керівництво запідозрило, що він більше не працює, бо від нього перестали приходити баги.

«Clean Code» — Robert C. Martin

Небезпека: після неї ваш код перестане бути справжнім «мистецтвом спагетті».

Чому слід уникати?

• Ви перестанете виправдовувати безлад у коді словами «Головне, що працює».
• Колеги зможуть зрозуміти ваш код (а ви хіба не пишете його для себе?).
• Доведеться прибрати костилі та продумувати архітектуру наперед.

Ризик: Декілька розробників після цієї книги почали писати занадто читабельний код. Це настільки шокувало менеджерів, що вони запідозрили, що команда більше не працює.

«Soft Skills: The Software Developer’s Life Manual» — John Sonmez

Небезпека: після неї ви можете захотіти бути соціально адекватним та розвивати кар’єру.

Чому слід уникати?

• Ви почнете думати про власний розвиток.
• Вас можуть помітити керівники та запропонувати підвищення.
• Ваші думки можуть стати зрозумілими іншим людям.

Ризик: Один розробник після прочитання почав вести технічний блог і став лідом у компанії. Тепер замість спокійного життя у нього цікава робота, високий дохід і купа знайомих. Катастрофа.

«The Phoenix Project» — Gene Kim, Kevin Behr, George Spafford

Небезпека: може змусити вас бачити зв’язок між кодом, бізнесом і хаосом в компанії.

Чому слід уникати?

• Ви почнете розуміти проблеми бізнесу і навіть пропонувати рішення.
• Ваші аргументи стануть переконливими, і ви навчитеся уникати хаосу в розробці.
• Ви зрозумієте, що DevOps — це не магія, а просто добре налагоджені процеси.

Ризик: Після прочитання один програміст зрозумів, що вся його команда щодня витрачає 30% часу на виправлення хаотичних багів, які можна було б уникнути. Він запропонував DevOps-підхід, і тепер у всіх менше авралів. Якесь занадто спокійне життя…

«Refactoring» — Martin Fowler

Небезпека: може змусити вас переглянути свої минулі гріхи у коді.

Чому слід уникати?

• Доведеться працювати з технічним боргом.
• Ви почнете оптимізувати код, навіть якщо він і так «Майже працює».
• Ваші рефакторинги зменшать розміри проєкту, і тепер він буде зрозумілий новачкам.

Ризик: Один програміст прочитав цю книгу та оптимізував базу коду, скоротивши її на 50%. Його запідозрили в тому, що він прибрав якусь важливу бізнес-логіку, бо тепер все працює занадто добре.

«The Manager’s Path» — Camille Fournier

Небезпека: може змусити вас замислитися про кар’єрне зростання.

Чому слід уникати?

• Ви дізнаєтесь, що управління командою — це не тільки мітинги.
• Ви можете захотіти розв’язувати проблеми на рівні компанії, а не тільки в коді.

Ризик: Один розробник після цієї книги почав давати конструктивний зворотний зв’язок і навчати молодших колег. Через рік він став менеджером, і тепер його називають «колишнім програмістом».

«Thinking in Systems» — Donella H. Meadows

Небезпека: змушує програмістів мислити не тільки кодом, а й системами.

Чому слід уникати?

• Ви почнете бачити проблеми в архітектурі ще до того, як вони зламають все.
• Ви перестанете приймати локальні костилі, думаючи про глобальну оптимізацію.

Ризик: Один розробник після цієї книги передбачив проблеми в архітектурі на рік вперед. Його запідозрили у використанні магії.

Висновок

Якщо ви хочете залишитися просто «писцем коду», а не стати ефективним інженером, архітектором рішень або лідером, вам варто триматися якомога далі від цих книг.

Але якщо ви раптом хочете навчитися мислити масштабно, будувати чистий код, розуміти бізнес і ставати впливовою людиною у своїй команді… Що ж, тоді вам не врятуватися. 

Цей матеріал – не редакційнийЦе – особиста думка його автора. Редакція може не розділяти цю думку.