Якщо ви працюєте в дизайні, ілюстрації, анімації чи будь-якій іншій творчій дисципліні, рано чи пізно ви зіткнетеся з тією ж стіною: Програмне забезпечення та комп'ютерні програми, які ви використовуєте щодня, — це не просто «інструменти»а радше ціла екосистема з власними правилами, особливостями та особливостями. Розуміння цих маленьких нюансів може мати вирішальне значення між проблемами з комп’ютером та відчуттям, що він творить на вас дива.
Окрім комбінацій клавіш та кількох випадкових хитрощів, Існує цілий всесвіт деталей про операційні системи, програмування, налагодження, «технологічну» культуру та способи роботи. Це впливає на те, як розроблені та функціонують додатки, які ви використовуєте як креативник. Розуміння цього світу зсередини допомагає вам краще працювати з командами розробників, вимагати реалістичних речей… і мати потужніші ідеї, оскільки ви знаєте, що можна створити, а що ні.
Unix, Mac, Linux та чому система важливіша, ніж здається
Для багатьох творчих людей класичною дискусією є «Mac чи Windows для дизайну?»Але у світі програмного забезпечення розмова часто йде далі: Unix проти всього іншого. macOS та більшість дистрибутивів Linux успадковують філософію Unix, що робить їх дуже потужними платформами для розробки та автоматизації завдань, які потім безпосередньо впливають на інструменти, які ви використовуєте.
Програмісти часто кажуть, що «Уся система Unix схожа на одне велике середовище розробки»Тому що все розроблено для об'єднання невеликих, потужних утиліт з терміналу: обробки зображень, автоматизації експорту, запуску скриптів рендерингу, керування серверами або компіляції коду без використання графічних майстрів. Саме тому багато розширених креативних пакетів, ігрових двигунів та 3D-інструментів розроблені з урахуванням таких середовищ.
Натомість, у Windows все візуально зрозуміліше та зручніше для користувача, але Історично склалося так, що він був менш "дружнім" до глибокої розробки та роботи з командного рядка.Сьогодні розрив значно скоротився (WSL, PowerShell тощо), але культура Unix все ще пронизує значну частину програмного забезпечення, яке ви використовуєте, навіть не усвідомлюючи цього.
Чому вас це цікавить як творчу людину? Тому що Автоматизація, скрипти та плагіни, які заощаджують ваші години, часто виникають у світі Unix.Робота в командах, які опанували це, часто призводить до більш надійних, стабільних робочих процесів, які легше масштабувати в міру зростання проєкту.
Програмування — це рідкісний гібрид: логіка, інженерія… і багато креативності.
Ззовні програмування може здаватися чистим холодним розрахунком, але насправді Це дивна суміш математики, інженерії та жорстокої креативностіТак само, як ви створюєте ілюстрацію чи розкадровку, розробник створює логіку, щоб програмне забезпечення виконувало саме те, що було задумано.
Більшість фахівців погоджуються з тим, що Навички вирішення проблем і креативність так само важливі, якщо не важливіші, ніж знання мільйона мов.Для тієї ж функціональності зазвичай існує багато способів її реалізації, так само як існує тисяча способів розробити обкладинку чи логотип; головне — знайти найчистіше, найелегантніше та найпростіше в обслуговуванні рішення.
Ось чому дедалі цінніше, що творчі команди розуміють це Код — це також дизайнІснують рішення щодо архітектури програмного забезпечення, потоки даних та внутрішні структури, які значно впливають на те, що ви можете вимагати від програми, плагіна чи вебсайту, не перетворюючи проект на непідтримуваного Франкенштейна.
І так, програмування викликає залежність: Багато розробників описують свою роботу як найкращу логічну головоломку з усіх.Такий, де ви самі визначаєте правила та деталі, і це дуже добре відповідає способу мислення людини, яка любить створювати щось з нуля.
Компіляція, командний рядок та інші «ритуали» кодування
Якщо ви коли-небудь чули, як хтось каже «йде компіляція» і зникає зі свого стільця з кавою, знайте, що Це не завжди виправдання, але воно ідеальне.Компіляція означає перетворення вихідного коду на виконуваний файл програми, і в таких мовах, як C++, або у великих ігрових двигунах це може зайняти багато хвилин або навіть годин.
З дня на день, Цей час компіляції призначений для дихання, перегляду концепцій або просто перезавантаження вашого розуму.У креативних середовищах, коли ви працюєте з рендеринговими двигунами або складними збірками ігор, відбувається щось подібне: виникають простої в очікуванні завершення роботи машини, і багато команд користуються ними для обговорення ідей, полірування дизайну або перегляду завдань.
З цим пов'язаний командний рядок, той чорний екран, який спочатку лякає, але як тільки ви його освоїте, Це стає своєрідною чарівною паличкоюТе, що ви там насправді робите, — це програмування в мініатюрі: ви пишете інструкції мовою сценаріїв (наприклад, Bash) для автоматизації дій, які були б головним болем у графічному інтерфейсі.
Для досвідченого творчого фахівця вивчення чотирьох речей про термінали може бути безцінним: Перейменовуйте тисячі файлів, конвертуйте пакети форматів, запускайте скрипти рендерингу, переміщуйте резервні копії або синхронізуйте проекти не торкаючись миші. Це ще один спосіб «розмовляти мовою» комп’ютера та наблизитися до способу мислення програмістів.
Темна сторона коду: крапка з комою, помилки та нескінченне налагодження
Одна з найжорстокіших курйозів програмного забезпечення полягає в тому, що Дрібні речі можуть зламати гігантські речіНеправильно розміщена крапка з комою, відсутня дужка або дужка, що закривається в неправильному місці, може зіпсувати сотні ідеально продуманих рядків, так само як неправильно заблокований шар може знищити весь PSD.
Розробники проводять значну частину свого дня у дуже не гламурному, але важливому режимі: помилки налагодженняПолювання на помилок схоже на полювання на істот, які ховаються в абсурдних місцях: вони не завжди спричиняють збій програми, іноді вони лише викликають дивні помилки в певний час або з'являються з певними даними чи на певних пристроях.
У вашому світі це перекладається на такі речі, як Інструменти, які не працюють лише з одним типом файлів, анімації, які добре виглядають на вашому комп’ютері, але аварійно завершують роботу, вебсайти, які не працюють лише в певному браузері...які, як не дивно, зазвичай є видимою частиною набагато глибшої помилки в коді.
Щоб пережити це, більшість програмістів розробляють арсенал методів налагодження: Використовуйте журнали, графічні налагоджувачі, точки зупинки та роздруківки стану змінних....і навіть пропонувати внутрішні винагороди за знаходження певних особливо невловимих помилок. Це ще одна причина, чому «швидкі» зміни майже ніколи не бувають такими швидкими.
І так: тут є гумор. Багато коментарів у коді перетворюються на маленькі витвори мистецтва сарказму: «// Магія. Не чіпай.», «// п'яний, виправимо пізніше» або «// зламати браузер IE (припускаючи, що IE — це браузер)»Цей гумор окопів є важливою частиною культури розробників.
Лінь, автоматизація та контроль версій: замасковані переваги
Це може звучати дивно, але це в розробці Лінь, якщо її правильно зрозуміти, вважається професійною чеснотою.Ідея проста: якщо щось повторюється та виконується вручну, хтось розумний шукатиме спосіб автоматизувати це, щоб йому ніколи більше не довелося цього робити. Саме ця «лінь» рухає скрипти, плагіни, автоматизовані дії та макроси, які ви потім використовуєте щодня, не знаючи, звідки вони взялися.
У серйозних проектах ця філософія спирається на інший ключовий елемент: контроль версій, з Git як абсолютним королемЗавдяки Git команди можуть працювати над одним проєктом, не наступаючи один одному на ногу, тестувати божевільні ідеї в окремих гілках, відкочуватися, коли щось ламає половину програми, або бачити, хто що і коли торкався.
Для творчого фахівця, який співпрацює з розробниками, розуміння основ є надзвичайно важливим. Що таке коміт, гілка чи злиття? Це дуже допомагає: дозволяє відстежувати прогрес розробки, контролювати, коли було внесено зміни, що впливають на ваш дизайн, і краще координувати, коли додавати нові функції та зосереджуватися на вдосконаленні того, що вже є.
Крім того, ця культура автоматизації також застосовується до завдань, які, здавалося б, менш «технічні»: Скрипти розгортання, автоматична генерація документації, тести, що запускаються автоматично щоночі, конвеєри, що конвертують ресурси, стискають зображення або генерують версії для різних пристроїв без втручання людини. Все це походить від того, що хтось відмовився повторювати той самий процес вручну сто разів.
Коментарі, зрозумілі назви та одержимість читабельним кодом
Так само, як файл дизайну з добре названими шарами та організованими групами безмежно цінується, Коду потрібен порядок, контекст і хороші теги.Інакше це стає непрохідними джунглями навіть для людини, яка написала це кількома тижнями раніше.
Хороші програмісти надають великого значення двом речам: змістовні імена та коментарі, що надають реальний контекстВиклик змінної userAge o totalCost Це говорить набагато більше, ніж x o tempІ зазначати, чому було обрано певний алгоритм або який трюк використовується, набагато корисніше, ніж коментувати "// додати два числа".
На практиці це створює своєрідний внутрішній «технічний сценарій» для проєкту, який інші розробники можуть прочитати, щоб зрозуміти його. рішення щодо проектування програмного забезпечення, що лежать в основі кожного модуляКоли код добре написаний, найкращим коментарем іноді є сам код, який пояснює себе завдяки вдало підібраним іменам.
Ця одержимість ясністю дуже добре узгоджується з концепціями, про які ви, можливо, чули, такими як Чистий код, рефакторинг або правило «не повторюйся» (DRY)Вся ця філософія вказує на одне й те саме: програмне забезпечення має бути легким для розуміння, зміни, тестування та розширення, не порушуючи при цьому жодної функціональності.
Тестування, TDD та чому «запустити це сьогодні» недостатньо
Ще один менш помітний, але фундаментальний аспект будь-якої програми, яку ви використовуєте, це екосистема тестування, що стоїть заЮніт-тести, інтеграційні тести, автоматизовані чи ручні тести існують саме для того, щоб невелика зміна, яка додає запитувану вами опцію, непомітно не зламала 20 інших частин системи.
Існують такі методології, як TDD (розробка через тестування), де Спочатку пишуться тести, а потім код, який забезпечує їх успішне проходження.Це здається нелогічним, але змушує розробника з самого початку думати про бажану поведінку, граничні випадки та про те, як перевірити, чи все продовжує працювати правильно з часом.
Для творчих команд це перетворюється на щось дуже конкретне: Запит на «лише цю невелику зміну кнопки» або «додавання нового ефекту» має реальну ціну з точки зору тестування та перевірки.Не те щоб вони не хотіли вам допомогти; справа в тому, що будь-яка модифікація, якою б незначною вона не здавалася для інтерфейсу, може мати побічні ефекти, і вони повинні переконатися, що решта програми не зламається.
Крім того, багато компаній створюють тестові набори, які працюють, поки команда спить або у вихідні: Код компілюється, виконується серія тестів, а результати переглядаються.Якщо щось піде не так, це виявляється задовго до того, як досягне кінцевих користувачів… і це включає творчих працівників, які покладаються на ці інструменти у виробництві.
Алгоритми, структури даних та швидкість: невидимий двигун ваших інструментів
За кожним пошуком файлу, кожним фільтром, застосованим за секунду, або кожним полотном, яке залишається плавним навіть з тисячами шарів, стоїть щось, чого ви не бачите: алгоритми та структури даних, обрані зі зловмисним наміромВикористання списку, стеку, черги або словника (хешмапу) суттєво впливає на продуктивність.
Наприклад, Якщо вам потрібно швидко знайти потрібні елементи, словник набагато ефективніший, ніж простий список.Це дозволяє вашому редактору знаходити стиль, символ або ресурс за мілісекунди, навіть у величезному проєкті. Те саме стосується того, як зберігаються пікселі, вектори, 3D-сітки або аудіодоріжки.
Коли креативний додаток працює повільно, це не завжди вина вашого комп’ютера: Іноді вузьким місцем є рішення щодо розробки програмного забезпечення, прийняті роки тому.або у швидких скороченнях, які були обрані «тимчасово», а потім залишалися назавжди, що, на жаль, поширене явище в багатьох проектах.
Ось чому так багато колонок з професійними порадами наполягають на Уникайте передчасної оптимізації, але з самого початку вибирайте правильні алгоритми та структури.Цей міцний фундамент забезпечує масштабованість: більше шарів, більше ефектів, більше користувачів, більше пристроїв… без збоїв системи.
Культура програмістів: дивні жарти, бінарний код та «ложки немає»
Якщо ви працюєте з розробниками, рано чи пізно ви почуєте такі речі, як «Є 10 типів людей: ті, хто розуміє двійкову систему числення, і ті, хто ні».Це класичний жарт, який грає на тому факті, що 10 у двійковій системі числення дорівнює 2 у десятковій. Цей тип технічного гумору є частиною цілої субкультури: меми, сабреддіти, посилання на «Матрицю», «Зоряні війни», «Зоряний десант»…
відома фраза «Немає ложки» Аналогію з Матрицею часто використовують для опису відчуття бачення крізь інтерфейс і розуміння того, як побудовано додаток під ним. Коли ви знаєте, як програмувати, перегляд програми чи веб-сайту вже не є просто споживанням їх: ви починаєте уявляти її модулі, її архітектуру, як взаємодіють частини, де щось може дати збій.
Помилки також обговорюються так, ніби вони Істоти Зоряного десанта: маленькі на вигляд, але здатні спричинити величезний безладЦя спільна мова створює спільноту; гумор — це спосіб впоратися з тиском величезних систем, що тримаються за ваш код.
Для творчого професіонала зв'язок з цією культурою робить стосунки з програмістами більш плавними: зрозуміти його жарти, його посилання та його дивацтва Це значно полегшує спілкування під час обговорення термінів, технічних обмежень або змін в останню хвилину.
Як (насправді) навчаються програмісти і що це означає для вас
Ще один цікавий факт полягає в тому, що, хоча існують ступені, навчальні табори та магістерські програми, Більшість справжнього навчання програмуванню відбувається через працюЦе більше схоже на професію, ніж на університетський предмет: ви вчитеся на практиці, ламаєте речі, лагодите їх і повторюєте цикл знову і знову.
Більшість розробників погоджуються з однією ідеєю: Тобі не потрібно все запам'ятовуватиІснує офіційна документація, форуми, статті, книги, такі як «97 речей, які повинен знати кожен програміст», та безліч онлайн-ресурсів, таких як Підручники з мов програмування іспанською мовоюВажливо знати, як шукати, вибирати та застосовувати ці знання до конкретної проблеми, так само, як ви не знаєте напам'ять усіх комбінацій клавіш Photoshop, але знаєте, де шукати, коли вони вам знадобляться.
Крім того, майже всі рекомендують спеціалізуватися: Оберіть область (веб, мобільні пристрої, серверна частина, дані, відеоігри…) та зануртесь глибше Замість того, щоб намагатися охопити весь технологічний ландшафт. Ця ж логіка може надихнути вас: справжнє розуміння того, як працює програмне забезпечення у вашій творчій ніші, зробить вас набагато сильнішими, ніж знання трохи про все, не опанувавши нічого.
Також у багатьох внутрішніх опитуваннях повторюється важливість наставника та «парного програмування»: Програмуйте в парах, дозволяйте іншим переглядати ваш код, просіть про допомогу та приймайте критику.Те саме, що й коли ви ділитеся розкадровкою чи дошкою настрою з кимось іншим і приймаєте відгуки для покращення твору.
Реальність розробницької роботи: самотність, зосередженість та гігантські навушники
Усередині повсякденне життя команди розробників програмного забезпечення має чимало спільного з творчою студією: Багато годин перед екраном, тривалі періоди концентрації та стосунки любові та ненависті з перервамиНерідко можна побачити половину команди у величезних навушниках із шумопоглинанням, майже так, ніби це обов'язкові робочі шоломи.
Музика стає інструментом продуктивності: М'які списки для архітектурного мислення, щось потужніше для механічних завдань, повна тиша для налагодження складних помилокНавушники — це не просто примха: вони є соціальним сигналом «не перебивайте мене зараз, я в режимі зосередження», так само, як деякі студії використовують прапорці або невеликі фізичні сигнали на столі.
Є й інший, менш помітний бік: Надмірна робота на самоті перед комп'ютером може ізолюватиБагато ветеранів наполягають на тому, що не можна дозволяти ставитися до себе як до робота, і що життєво важливо культивувати життя поза програмуванням: хобі, стосунки, фізична активність, відпочинок. Мозок, який розробляє рішення, і той, який розробляє інтерфейси, — це один і той самий мозок, і йому потрібен простір.
Паралельно існує щось цілком реальне, що називається залежність від програмуванняКоли ви чимось справді захоплені, легко провести цілі ночі, «лише щоб закінчити цей модуль», і забути поїсти, поспати чи навіть встати зі стільця. Як і з будь-якою творчою пристрастю, вам потрібно навчитися встановлювати межі, щоб уникнути вигорання.
Мислення, синдром самозванця та здорова конкуренція
Більшість людей, які починають займатися програмуванням, мають технічний досвід, але Це не означає, що людину з гуманітарною освітою не можна перекваліфікувати.Найбільше ветерани цінують не атестат про повну загальну середню освіту, а послідовність, здатність навчатися та певний комфорт у логічному мисленні.
Майже кожен у цій галузі живе з чимось досить поширеним: синдром самозванцяЦе відчуття «я недостатньо знаю, мене зараз спіймають, я не підходжу до завдання» може виникати незалежно від вашого віку. Багато хто використовує його як мотивацію для подальшого навчання, якщо це не призводить до паралізуючої тривоги.
Конкурентоспроможність також є частиною ландшафту, але у своїй здоровій формі вона радше схожа на «Суперництво» серед колег, щоб побачити, хто найкраще оптимізує модуль або хто пише найелегантніший код Це ж не війна, щоб побачити, хто кого наступить. Коли програміст, яким ви захоплюєтесь, цінує вашу роботу, це дуже схоже на те, як коли інша творча людина захоплюється вашою ілюстрацією чи відео.
У цьому середовищі навчитися приймати зворотний зв'язок є надзвичайно важливим: Коли тебе хвалять, не збивайся зі шляху; коли тебе критикують, не здавайся.Цей сектор змінюється так швидко, що завжди будуть технології, які ви не контролюєте, та люди, які знають більше про щось конкретне, і жити з цим – частина гри.
Найбільш трудомістка частина: налагодження, управління розчаруванням та прийняття рішення про те, коли переключитися
Якщо подивитися лише на кінцеві результати, можна подумати, що розробники цілими днями пишуть нові функції, але насправді Значна частина часу витрачається на налагодження помилок та коригування вже існуючих елементів.Просування проєкту вперед часто означає виправлення невеликих помилок, які заважають розвитку решти системи.
Це спричиняє значні піки розчарування: Проблеми, які неможливо виявити, збірки, що зазнають невдачі без очевидного пояснення, клієнти, які вимагають неможливих термінів виконанняБагато фахівців кажуть, що у них були моменти, коли хотілося все кинути та змінити галузь, особливо під час роботи над складними продуктами.
Стратегії, які вони рекомендують, звучать знайомо: Наполегливість, самомотивація, певна гордість за добре виконану роботу та щира пристрасть до ремеслаЯк і в будь-якій вимогливій творчій дисципліні, саме це поєднання змушує вас пробувати ще раз, коли щось не виходить, і що відрізняє тих, хто залишається на поверхні, від тих, хто стає справді хорошим.
Певний ступінь плинності кадрів також є поширеним явищем: Хороші кандидати постійно отримують пропозиції.Багато порад тут вказують на одне й те саме: шукайте корпоративну культуру, яка відповідає вашим цінностям, і пам’ятайте, що на співбесіді ви також оцінюєте компанію. Ви витратите багато годин, розмірковуючи над її проблемами; гарне міжособистісне підлаштування та спільні цінності важливіші, ніж може здатися у вашому резюме.
Технічні співбесіди, інтеграція команди та комунікація
У спільноті розробників технічні співбесіди досить відомі… і водночас мають досить погану репутацію. Багато ветеранів вважають, що Вони переоцінені, і невдача в одному з них мало що говорить про ваш потенціал.Зазвичай вони вимірюють певний набір навичок під тиском, а не вашу фактичну здатність навчатися, співпрацювати та успішно завершувати проекти в довгостроковій перспективі.
Замість цього М'які навички часто мають вирішальне значеннявміння спілкуватися, ставити запитання, коли щось незрозуміло, враховувати зворотний зв'язок, співпрацювати з людьми з різним досвідом (як ви, якщо ви творча людина) та зберігати спокій у напружені моменти.
Приєднуючись до компанії, головна рекомендація для будь-якого молодшого програміста... Не бійтеся ставити запитання, але робіть це обдумано.Заплануйте з наставником певний час для відповідей на запитання, уникайте перебивання, якщо це не терміново, та ретельно підготуйте свої запитання. Те саме стосується і роботи в технічній команді: чим чіткіше та структурованіше ваше спілкування, тим краще ви впишетесь.
У середовищах, де наставник не призначений, найбільш доцільним варіантом дій є завоювати довіру досвідченої людини та створити міцні професійні стосунки з цією людиною. Зрештою, великі проекти залежать як від якості коду та дизайну, так і від якості стосунків між тими, хто їх створює.
Зрештою, магія інструментів, якими ви користуєтеся щодня, походить від досить людського поєднання: Люди, які постійно навчаються, розчаровуються, стають конкурентоспроможними, співпрацюють, сміються з дивних бінарних жартів і поступово перетворюють ідеї на програмне забезпечення.Коли ви, як творча людина, розумієте ці цікавості та способи роботи, набагато легше говорити однією мовою, запитувати, що насправді можна побудувати, та брати участь у цьому майже «магічному» процесі, коли комп’ютер робить саме те, що ви уявляєте.