Думати як програміст, а не як програма: якому розробнику не загрожує ШІ

Інтернет затопило цунамі контенту, створеного штучним інтелектом. Не дивно, що багато спеціалістів, зокрема й програмістів, почали турбуватися: а чи не зможе вже незабаром ШІ забрати в них роботу?

Я вважаю, що зможе. Але не у всіх. Мене звати Сергій Немчинський, я засновник та директор навчального центру FoxmindEd, програміст з досвідом понад 20 років, і я розповім, як стати розробником, з яким не може конкурувати ШІ.

Що означає «думати як програміст»

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

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

1. Аналізувати завдання

Багато студентів-програмістів думають, що на майбутній роботі завдання їм ставитимуть приблизно так:

«Напишіть код, який може відсортувати масив даних трьома способами».

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

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

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

Якщо дані неповні (а так буває в більшості випадків), то треба додумувати деталі самому. Це складно, потребує досвіду і часу. Ось якого алгоритму я раджу дотримуватися в такому випадку:

• уважно прочитайте опис завдання кілька разів;
• зрозумійте, яких саме деталей не вистачає;
• складіть список запитань до замовника;
• намагайтеся отримати максимально детальні відповіді від замовника;
• починайте думати над рішенням.

2. Оцінювати поточну ситуацію

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

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

3. Розкладати завдання на складові

Наступний крок — декомпозиція завдання. Вам знайомий вираз, що слона треба їсти маленькими шматочками? Це стосується і роботи програміста. 

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

4. Грамотно комунікувати

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

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

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

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

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

5. Планувати

В бізнесі часто використовують термін road map — дорожня мапа. Звісно, мова не про путівники, а про план створення та подальшого розвитку продукту. Коли завдання поділене на невеликі шматки, і більш-менш зрозуміло, хто за що відповідає, треба написати план дій. Підкреслюю, саме написати, а не скласти в голові. По-перше, покладатися на свою пам’ять дуже самовпевнено: ви обов’язково щось забудете. По-друге, якщо працюєте не сам, планом можна буде поділитися з командою.

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

6. Шукати рішення

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

На відміну від сисадміна, програміст працює з прозорою скринькою. Адмін може сказати: ця програма не може це зробити. Програміст так сказати не може, тому що він сам цю програму і пише. Не працює? Зроби так, щоб запрацювало, знайди рішення!

Ціна рішення — це інша справа. Можливо, це займе значно більше часу, ніж заплановано. Тоді дайте обґрунтовану калькуляцію своєму проджект-менеджеру, а він хай веде перемовини з клієнтом.

Наостанок

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

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

Читайте також

Чи правда, що жінки гірше кодять? 7 міфів про жінок в ІТ

Світчери в ІТ: як почати кар’єру, якщо ви працювали в інших сферах

Що робить та скільки заробляє QA Engineer і чи легко йому «увійти в ІТ»?