Командний прагматизм та інженерія

Коли справа доходить до розробки будь-якого типу – мені байдуже, для Інтернету, для мобільних пристроїв чи для іншої платформи – є багато книг, онлайн-курсів тощо, які роблять неймовірно легким навчання будь-якому це ти хочеш навчитися.

Щоб було зрозуміло, я також не відкидаю жоден із доступних способів навчання. Зрештою, ми всі вчимося по-різному, чи не так? І хто я такий, кажучи, який шлях кращий за будь-який інший, особливо з огляду на той факт, що я щодня пишу про теми тут і на інших сайтах?

Але я можу точно сказати для себе – хтось, хто любив навчатися через формальну освіту, навчальні посібники, курси тощо – найкращий спосіб отримати досвід у цій галузі був двояким:

• робота з іншими людьми,
• ламати речі та вчитися їх лагодити.

Я маю на увазі робити це в такому конкретному порядку? ні. Чи означає це, що я на крок попереду інших? Це смішно.

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

Якби мені довелося підсумувати це, я б сказав, що мова йде про пошук балансу командного прагматизму та інженерії. Але чому, якщо нічого з перерахованого вище не є новим (враховуючи, що компанії, що займаються програмним забезпеченням, існують десятиліттями), я намагаюся писати про це зараз?

Командний прагматизм та інженерія

Можливо, я міг би скласти список причин, чому я вважаю цю конкретну тему важливою, але є три конкретні речі, які я хотів би згадати в цій публікації. І, заради довжини (читай: часу), я зроблю все можливе, щоб вони були короткими.

Насправді, TL;DR того, про що я збираюся говорити, має відношення до прагматизму та інженерних навичок. Спочатку я також збирався включити погляд на бізнес загалом, але загальний допис трохи відійшов від теми.

1 Прагматизм

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

Тобто в якийсь момент мова йшла виключно про те, щоб знайти баланс між пошуком рішення, яке працює для користувача, яке добре побудоване, і яке вирішує їхню проблему. І я все ще підписуюся під цим.

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

Тобто легко написати базовий об’єктно-орієнтований код, задокументувати його, мати кілька класів або функцій, які викликають один одного, підключитися до WordPress, а потім запустити це.

2 Інженерна майстерність

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

Хоча я віддаю перевагу використанню об’єктно-орієнтованого програмування в тому типі роботи, яку виконую, я не з тих, хто вступає в релігійну війну або втручається в те, яку версію якої мови, яку технологію чи функціональну, процедурну чи об’єктно-орієнтовану програмування краще.

Простіше кажучи: мова йде про загальний рівень навичок, якого ви можете досягти протягом своєї кар’єри.

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

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

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

Зрештою, це може допомогти покращити як ваші здібності, так і якість того, що ви та ваша команда приносите до столу.

Завжди є більше

Як я вже говорив у цій публікації, завжди є більше. Ймовірно, я розповім більше про бізнес-аспект цього в наступних публікаціях.

Однак наразі я залишу те, що я написав, там, де воно сидить, і перейду звідти пізніше.