«Хорошого програміста мавпою не назвуть». IT-сленг, який варто знати, якщо працюєш з іноземними айтівцями

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

Мене звати Євген, я IT Lead в онлайн-школі англійської мови Englishdom, і сьогодні я зібрав список сленгових слів і фраз, які популярні серед англомовних програмістів. А також постарався дослідити, як саме вони з’явились. Прочитайте і запам’ятайте, щоб розуміти своїх закордонних колег.

Чи дійсно сленг популярний в IT

Насправді так. Дослідження українських мовознавців показують, що 88,9% айтівців користуються робочим сленгом дуже часто або постійно — і абсолютна більшість з них не готові від нього відмовитися. І лише 2,8% працівників IT-сфери не використовують його взагалі.

Цікаво, що різниця між сленгом та встановленими нормами в IT-термінології досить незначна. Слова «драфт», «баг», «міт», «дедлайн» — вже цілком звичні лексеми, які вийшли далеко за межі спільноти програмістів навіть в українській мові.

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

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

Готові? Починаємо.

Vibe coding

Vibe coding — це практика написання коду, створення вебсторінок або розробки застосунків за допомогою генеративного штучного інтелекту. Спеціаліст просто описує ідею ШІ, а платформа робить все інше.

У вайбкодингу зовсім не обов’язково розуміти, як працює код, тому метод часто використовують Junior-розробники з малим досвідом або спеціалісти взагалі без жодних знань програмування. Проте навіть якщо ШІ видав код, що дійсно працює, це не рятує від проблем і багів.

You don’t have to know how to code to vibecode — just having an idea, and a little patience, is usually enough.

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

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

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

Spaghetti Code

Spaghetti Code — це погано структурований, неякісний та складний для розуміння код з непередбачуваною логікою.

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

Саме через хаотичність спагеті-код вкрай важко підтримувати та дебажити. Будь-які зміни у ньому — це ризик зламати увесь код. Бо часто жодних коментарів там немає.

Спагеті-код з’являється на проєкті з різних причин:

• Нестача досвіду розробника — він кодить, як вміє, а не як потрібно для нормальної роботи з ним. Якщо джуна посадили на складну задачу, а він з нею якимось дивом справився — скоріш за все всередині спагеті-код.
• Занадто швидкий процес розробки — коли треба все «на вчора». Тоді йдуть в хід спрощення — «Хай поки буде так, а потім напишу нормально». Кількість «милиць» зростає, спеціалісти, що працюють над проєктом, змінюються, тому спрощення стають легасі, бо ніхто не знає, як змінити їх, не зруйнувавши код загалом.
• Відсутність планування — коли відразу починаєш кодити, не задумуючись про архітектуру проєкту. Як результат — є окремі сегменти коду, які потім треба звести докупи, але ніякого цілісного розуміння.

Цікаво, що хоч лексема «Spaghetti Code» досить стара — вперше з’явилась у 1980-х, її все ще вважають сленгом. Вічно молодий термін!

Boilerplate Code

Boilerplate Code — це шаблонний код, який повторно використовується в різних проєктах практично без змін.

«Boilerplate» буквально перекладається як «шаблонний». Ніяких «киплячих тарілок» — привіт хибним друзям перекладача.

Developers often feel frustrated by the need to write boilerplate code repeatedly.

Розробники часто відчувають розчарування через необхідність постійно писати типовий код.

Етимологія слова «boilerplate» має довгу історію. Буквально це перекладається як «котельне залізо». І вперше вона отримала значення «шаблонний» у поліграфістів. Справа в тому, що типографські форми для друку газет набирали зі свинцевих літер. Але форми, що потрібні були часто (наприклад, назва газети чи заголовки рубрик), відливали зі сталі, щоб продовжити їх строк служби. Саме їх і називали «boilerplate». Згодом це слово перейшло в інженерію, а звідки — в програмування.

Duck

«Duck» — це «качка», все правильно. Але у програмуванні у цього слова є особливе значення. Так називають фічу, яку додали в план проєкту виключно для того, щоб привернути увагу менеджменту або інвесторів.

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

Чому «duck»? З цим пов’язана цікава історія. Моушн-дизайнер створював анімації королеви для гри Battle Chess. Проте щоб не отримати мільйон правок на свою роботу, він домалював королеві домашню тварину — качку, яка махала крилами протягом усієї анімації. Коли дизайнер показав готовий результат менеджеру, той відповів:

That looks great. Just one thing — get rid of the duck.

Вигладяє чудово. Лише одне — прибери качку.

Хитрість спрацювала, а історія стала байкою, яку охоче розповідали одне одному. А «duck» стала синонімом фічі, якою можна пожертвувати або яку ніхто і так не збирався додавати у продукт.

Brownout

Слово «brownout» стали вживати, коли напруга в електричній мережі падала настільки низько, що навіть лампочки світили так тьмяно, що здавались коричневими. Ще не блекаут, але досить близько, бо ніякі прилади все одно не працюють.

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

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

To prevent a brownout during Black Friday, we added auto-scaling rules and rate limiting to our backend APIs.

Щоб уникнути часткової деградації сервісу під час Чорної П’ятниці, ми додали правила автоскейлінгу та ліміти запитів у бекенд-API.

В технічних чи офіційних документах компанії частіше вживають фрази «partial outage» або «performance issues», а між собою — «brownout», «service degradation» чи «degraded performance».

Rubberducking

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

Власне, чому «rubberducking»? Бо ефект у цієї розмови точно такий же, якби розробник розмовляв з гумовою качечкою, що стоїть біля монітора.

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

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

Правда, слово не вийде перекласти українською, щоб зберегти його сенс та залишити коротким. Найкращий відповідник — «розмова з гумовою качечкою», але й вона не передає всіх смислів. Мабуть, саме тому українською лексема не така популярна.

I finally solved the bug after ten minutes of rubberducking with a teammate.

Я нарешті вирішив баг після десяти хвилин rubberducking із колегою.

Code monkey

«Code monkey» — програмісти так досить зневажливо називають інших розробників, які мають достатньо знань та вмінь, щоб справлятися зі складними завданнями, але виконують переважно прості таски без глибокого розуміння проєкту загалом.

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

Our company values creativity — we don’t hire code monkeys, we hire engineers who think.

Наша компанія цінує креативність — ми не наймаємо мавп-кодувальників, ми наймаємо інженерів, які мислять.

Цікаво, що Кембриджський словник англійської взагалі дає лексему «code monkey» як іронічний синонім слова «coder», без жодних негативних значень. Але практика показує, що хорошого програміста мавпою не назвуть.

Hype-Driven Development (HDD)

Нові технології з’являються в IT-сфері кожного місяця. І мало не кожну представляють як революційну.

Hype-Driven Development — це процес розробки, де стек технологій для проєкту обирають не за доречністю та можливостями, а за рівнем хайпу, на хвилі ентузіазму. Не найкраща ідея, але таке трапляється часто. Як результат, кожен HDD-проєкт проходить через 5 стадій розвитку:

1. Максимальний ентузіазм. Здається, що новий фреймворк, бібліотека чи парадигма вирішать проблеми проєкту і виведуть його на новий рівень.
2. Робота кипить. В рамках HDD не очікуйте, що про нову технологію багато відомо або в команді є профі з досвідом, які з нею працювали. Все розробляється практично інтуїтивно.
3. Виявляються проблеми. Завжди є точка, коли виявляється, що впровадження нової технології потребує купу часу і зусиль, не вирішує всіх критичних задач, але водночас додає нових.
4. Розчарування. «Все даремно! Ми тільки втратили час та сили. Нова технологія — фігня на паличці».
5. Прийняття. Команда повертається до більш звичних та зрозумілих методик розробки. Можливо, використовує здобуті знання для нових проєктів чи фіч. В іншому випадку спеціалісти глибоко вивчають нові технології, щоб довести проєкт до потрібного результату уже з новим стеком, але так відбувається не надто часто.

Особливо часто Hype-Driven Development трапляється в пет-проєктах розробників, які вони створюють самостійно або з невеликою командою ентузіастів.

Code Smell

«Смердючий код» — так англомовні розробники називають неоптимізований, занадто складний, застарілий, незрозумілий або просто максимально незручний для обслуговування код. Формально він працює, але його використання може призвести до проблем у майбутньому.

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

This giant method is definitely a code smell; we should refactor it into smaller functions.

Цей гігантський метод — справжній «смердючий код»; нам варто розбити його на менші функції.

Heisenbug та інші

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

• Heisenbug. Гейзенбаг — це каламбур від імені відомого фізика Вернера Гейзенберга. Його принцип невизначеності стверджує, що спостереження квантової системи впливає на результати вимірювання. Тобто, коли розробник починає шукати чи досліджувати гейзенбаг, той змінює свою поведінку та умови, що призводять до його відтворення.
• Higgs-Bugson. А це вже каламбур від «бозона Хіггса» — останньої знайденої елементарної частинки, що описує Стандартну модель у фізиці. «Higgs-Bugson» — це баг, існування якого в системі передбачено через непрямі логи, але відтворити його або навіть довести його існування не вдається. Власне, так до кінця і не ясно, чи існує цей баг взагалі.
• Hindenbug. Гінденбаг — це баг, що може нанести просто колосальну шкоду застосунку або інфраструктурі проєкту загалом. Наприклад, знищити базу даних чи спричинити витік персональних даних користувачів. Назва бага пішла від назви німецького дирижабля «Гінденбург», катастрофа у 1937 році якого стала причиною до смерті 36 людей. Це призвело до практично повної зупинки розробки нових дирижаблів — їх перестали розглядати як безпечні літальні апарати.

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

Drug Report та інші

Те ж стосується й каламбурів про багрепорти. Практично всі з них — дуже вузькоспеціалізовані жарти, які обігрують з самої фрази «bug report». Ось, наприклад:

• Drug Report — настільки розпливчастий та незрозумілий багрепорт, що здається, що його писав тестувальник, який зловживає нехорошими речовинами.
• Chug Report — трішки легша версія Drug Report. Репорт все ще незрозумілий і дивний, але хоча б щось ясно. Наче написаний пізно ввечері після кількох літрів пива.
• Shrug Report — в репорті показана проблема, але немає ніяких способів її відтворити. «Shrug» — це «знизати плечима». Прочитав такий репорт і не розумієш, що з цією важливою інформацією тобі робити.
• Smug Report — наше улюблене. «Smug» перекладається як «самовдоволений». В такому багрепорті є купа деталей, що не стосуються бага, додатковий фідбек, про який не просили, а часто ще й навіть пропозиції, як баг пофіксити. Автору такого репорта хочеться вигукнути: «Ну то роби сам, якщо такий розумний».

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

А які цікаві сленгові слова, фрази чи каламбури в англійській мові знаєте ви та як часто ними користуєтесь? Пишіть в коментарі.