Ако работите в дизайн, илюстрация, анимация или която и да е друга творческа дисциплина, рано или късно ще се сблъскате със същата пречка: Софтуерът и компютърните програми, които използвате ежедневно, не са просто „инструменти“а по-скоро цяла екосистема със свои собствени правила, странности и особености. Разбирането на тези малки нюанси може да е от решаващо значение дали да се борите с компютъра си или да се чувствате сякаш той ви прави магия.
Отвъд клавишните комбинации и няколко случайни трика, Има цяла вселена от подробности за операционните системи, програмирането, дебъгването, „технологичната“ култура и начините на работа. Това влияе върху начина, по който приложенията, които използвате като творец, са проектирани и функционират. Разбирането на този свят отвътре ви помага да работите по-добре с екипите за разработка, да искате реалистични неща... и да имате по-силни идеи, защото знаете какво може и какво не може да бъде създадено.
Unix, Mac, Linux и защо системата е по-важна, отколкото изглежда
За много творци класическият дебат е „Mac или Windows за дизайн?“Но в света на софтуера разговорът често отива една крачка по-далеч: Unix срещу всичко останало. macOS и повечето Linux дистрибуции наследяват философията на Unix, което ги прави много мощни платформи за разработване и автоматизиране на задачи, които след това пряко влияят на инструментите, които използвате.
Програмистите често казват, че „Цялата Unix система е като една голяма среда за разработка“Защото всичко е проектирано да свързва малки, мощни инструменти от терминала: обработка на изображения, автоматизиране на експортиране, стартиране на скриптове за рендиране, управление на сървъри или компилиране на код, без да се разчита на графични помощници. Ето защо много усъвършенствани творчески пакети, игрови енджини и 3D инструменти са проектирани с мисъл за този тип среди.
За разлика от това, в Windows нещата са по-визуални и лесни за ползване, но В исторически план, той е бил по-малко „приятелски настроен“ към дълбока разработка и работа от команден ред.Днес разликата е намаляла значително (WSL, PowerShell и др.), но Unix културата все още прониква в голяма част от софтуера, който използвате, без дори да го осъзнавате.
Защо се интересувате от това като творец? Защото Автоматизации, скриптове и плъгини, които ви спестяват часове, често произхождат от този свят на Unix.Работата в екипи, които са го усвоили, често води до по-стабилни работни процеси, които са по-лесни за мащабиране с разрастването на проекта.
Програмирането е рядък хибрид: логика, инженерство... и много креативност
Отстрани програмирането може да изглежда като чисто студено изчисление, но в действителност... Това е любопитна смесица от математика, инженерство и брутална креативностТочно както създавате илюстрация или сценарий, разработчикът създава логически елементи, така че софтуерът да прави точно това, което е било замислено.
Повечето професионалисти са съгласни, че Уменията за решаване на проблеми и креативността са също толкова важни, ако не и по-важни, от знанието на милион езика.За една и съща функционалност обикновено има много начини за нейното внедряване, точно както има хиляда начина за проектиране на корица или лого; ключът е да се намери най-изчистеното, най-елегантното и най-лесното за поддръжка решение.
Ето защо все по-ценно е творческите екипи да разбират, че Кодът е също дизайнСъществуват решения за софтуерна архитектура, потоци от данни и вътрешни структури, които силно влияят на това, което можете да поискате от приложение, плъгин или уебсайт, без да превърнете проекта в неподдържаем Франкенщайн.
И да, програмирането е пристрастяващо: Много разработчици описват работата си като най-добрата логическа пъзел, която съществува.Такова, в което ти определяш правилата и частите, и това се вписва много добре в начина на мислене на някой, който обича да създава неща от нулата.
Компилиране, команден ред и други „ритуали“ за кодиране
Ако някога сте чували някой да казва „компилира се“ и да изчезва от стола си с кафе, знайте това Не винаги е извинение, но е перфектно.Компилирането означава преобразуване на изходния код в изпълнима програма, а в езици като C++ или в големи игрови двигатели това може да отнеме много минути или дори часове.
ден за ден, Това време за компилация е за дишане, преглед на концепции или просто за нулиране на ума виВ творчески среди, когато работите с рендериращи двигатели или тежки компилации на игри, се случва нещо подобно: има прекъсвания, докато машината завърши, и много екипи се възползват от тях, за да обсъждат идеи, да усъвършенстват дизайни или да преглеждат задачи.
С това е свързан и командният ред, онзи черен екран, който в началото е плашещ, но щом го овладеете, Това се превръща в нещо като вълшебна пръчицаТова, което всъщност правите там, е програмиране в миниатюра: пишете инструкции на скриптов език (като Bash), за да автоматизирате действия, които биха били досадни в графичен интерфейс.
За напреднал творец, изучаването на четири неща за терминалите може да бъде безценно: Преименувайте хиляди файлове, конвертирайте пакетно формати, стартирайте скриптове за рендериране, премествайте резервни копия или синхронизирайте проекти без да докосвате мишката. Това е друг начин да „говорите езика“ на компютъра и да се доближите до начина, по който мислят програмистите.
Тъмната страна на кода: точка и запетая, грешки и безкрайно дебъгване
Една от най-жестоките любопитни страни на софтуера е, че Малките неща могат да счупят гигантски нещаНеправилно поставена точка и запетая, липсваща скоба или скоба, която се затваря на грешното място, може да съсипе стотици перфектно обмислени редове, точно както неправилно заключен слой може да унищожи цял PSD файл.
Разработчиците прекарват голяма част от деня си в един много небляскав, но важен режим: грешки при отстраняване на грешкиЛовът на бъгове е като лов на същества, които се крият на абсурдни места: те не винаги причиняват срив на програмата, понякога само задействат странни грешки в определени моменти или се появяват с определени данни или на определени устройства.
Във вашия свят това се превежда като неща като Инструменти, които се провалят само с един тип файл, анимации, които изглеждат добре на компютъра ви, но се сриват в производствения процес, уебсайтове, които се сриват само в определен браузър....които, изненадващо, обикновено са видимата част от много по-дълбока грешка в кода.
За да оцелеят в това положение, повечето програмисти разработват арсенал от техники за дебъгване: Използвайте лог файлове, графични дебъгери, точки на прекъсване и разпечатки на променливи състояния....и дори предлагат вътрешни награди за откриване на определени особено трудноуловими грешки. Това е друга причина, поради която „бързите“ промени почти никога не са чак толкова бързи.
И да: има хумор. Много коментари в кода се превръщат в малки произведения на изкуството от сарказъм: „// Магия. Не пипай.“, „// пиян, поправям по-късно“ или „// хак за браузъра IE (ако приемем, че IE е браузър)“Тозият хумор в окопите е важна част от културата на разработчиците.
Мързел, автоматизация и контрол на версиите: прикрити добродетели
Може да звучи странно, но е в процес на разработка. Мързелът, когато е правилно разбран, се счита за професионална добродетел.Идеята е проста: ако нещо е повтарящо се и ръчно, някой умен ще потърси начин да го автоматизира, така че никога повече да не се налага да го прави. Този „мързел“ е това, което движи скриптове, плъгини, автоматизирани действия и макроси, които след това използвате ежедневно, без да знаете откъде идват.
В сериозните проекти тази философия се основава на друг ключов елемент: контрол на версиите, с Git като абсолютен кралБлагодарение на Git, екипите могат да работят по един и същ проект, без да си пречат, да тестват шантави идеи в отделни клонове, да се връщат назад, когато нещо повреди половината от приложението, или да виждат кой какво е пипал и кога.
За един креативен професионалист, който си сътрудничи с разработчици, разбирането на основите е от съществено значение. Какво е commit, branch или merge? Това помага много: позволява ви да проследявате напредъка на разработката, да наблюдавате кога е въведена промяна, засягаща дизайна ви, и по-добре да координирате кога да добавите нови функции и да се съсредоточите върху усъвършенстването на вече съществуващото.
Освен това, тази култура на автоматизация се отнася и за задачи, които са на пръв поглед по-малко „технически“: Скриптове за внедряване, автоматично генериране на документация, тестове, които се изпълняват автоматично всяка вечер, конвейери, които конвертират ресурси, компресират изображения или генерират версии за различни устройства без човешка намеса. Всичко това произтича от някой, който е отказал да повтори един и същ процес на ръка сто пъти.
Коментари, ясни имена и мания по четим код
Точно както един дизайнерски файл с добре именувани слоеве и организирани групи е безкрайно ценен, Кодът се нуждае от ред, контекст и добри тагове.В противен случай се превръща в непроходима джунгла, дори за човека, който го е написал няколко седмици по-рано.
Добрите програмисти отдават голямо значение на две неща: смислени имена и коментари, които предоставят реален контекстИзвикване на променлива userAge o totalCost Това казва много повече от x o tempИ отбелязването защо е избран определен алгоритъм или какъв трик се използва е безкрайно по-полезно от коментирането „// добавяне на две числа“.
На практика това създава един вид вътрешен „технически скрипт“ за проекта, който други разработчици могат да прочетат, за да го разберат. решенията за софтуерен дизайн, които стоят зад всеки модулКогато кодът е добре написан, най-добрият коментар понякога е самият код, който се обяснява благодарение на добре подбраните имена.
Тази мания за яснота се вписва много добре в концепции, за които може би сте чували, като например Чист код, рефакторинг или правилото „не се повтаряй“ (DRY)Цялата тази философия сочи към едно и също нещо: софтуерът трябва да е лесен за разбиране, промяна, тестване и разширяване, без да се нарушава всичко.
Тестване, TDD и защо „да го накараш да работи още днес“ не е достатъчно
Друг по-малко видим, но основен аспект на всяка програма, която използвате, е екосистемата за тестване задЕдиничните тестове, интеграционните тестове, автоматизираните или ръчните тестове съществуват именно за да предотвратят малка промяна, която добавя поискана от вас опция, безшумно да повреди 20 други части на системата.
Съществуват методологии като TDD (Разработка, управлявана от тестове), където Първо се пишат тестовете, а след това кодът, който ги кара да преминат.Изглежда нелогично, но принуждава разработчика да мисли от самото начало за желаното поведение, граничните случаи и как да провери дали всичко продължава да работи правилно с течение на времето.
За творческите екипи това се превръща в нещо много конкретно: Заявката за „само тази малка промяна на бутона“ или „добавяне на нов ефект“ има реална цена по отношение на тестване и валидиране.Не че не искат да ви помогнат; въпросът е, че всяка промяна, колкото и малка да изглежда за интерфейса, може да има странични ефекти и те трябва да се уверят, че останалата част от приложението няма да се повреди.
Освен това, много компании създават тестови пакети, които се изпълняват, докато екипът спи или през уикенда: Кодът се компилира, изпълнява се серия от тестове и резултатите се преглеждат.Ако нещо се обърка, то се открива много преди да достигне до крайните потребители... и това включва и творците, които разчитат на тези инструменти в производството.
Алгоритми, структури от данни и скорост: невидимият двигател на вашите инструменти
Зад всяко търсене на файл, всеки филтър, приложен за секунда, или всяко платно, което остава течно дори с хиляди слоеве, има нещо, което не виждате: алгоритми и структури от данни, избрани със злонамерено намерениеИзползването на списък, стек, опашка или речник (хешмап) прави огромна разлика в производителността.
Например Ако трябва бързо да намерите елементи, речникът е много по-ефективен от обикновен списък.Това позволява на вашия редактор да намери стил, символ или ресурс за милисекунди, дори в огромен проект. Същото важи и за начина, по който се съхраняват пиксели, вектори, 3D мрежи или аудио записи.
Когато едно творческо приложение е бавно, не винаги вината е на компютъра ви: Понякога пречката се крие в решенията за дизайн на софтуер, взети преди години.или в бързи преки пътища, които са били взети „временно“ и след това са оставали завинаги, нещо, за съжаление, често срещано в много проекти.
Ето защо толкова много колони с професионални съвети настояват за Избягвайте преждевременната оптимизация, но изберете правилните алгоритми и структури от самото начало.Тази солидна основа позволява мащабируемост: повече слоеве, повече ефекти, повече потребители, повече устройства… без системата да се срива.
Култура на програмистите: странни шеги, двоичен код и „няма лъжица“
Ако работите около разработчици, рано или късно ще чуете неща като „Има 10 типа хора: такива, които разбират двоичната система, и такива, които не я разбират.“Това е класическа шега, която използва факта, че 10 в двоична система е 2 в десетична. Този вид технически хумор е част от цяла субкултура: мемета, subreddits, препратки към „Матрицата“, „Междузвездни войни“, „Звезден рейнджър“...
Известната фраза „няма лъжица“ Аналогията с Матрицата често се използва, за да се опише чувството да виждаш през интерфейса и да разбираш как е изградено приложението. Когато знаеш как да програмираш, разглеждането на програма или уебсайт вече не е просто тяхното консумиране: започваш да си представяш неговите модули, архитектурата му, как частите комуникират, къде нещо може да се проваля.
Буболечките също се обсъждат, сякаш са Същества от Звездните рейнджъри: малки на вид, но способни да причинят огромна бъркотияТози споделен език създава общност; хуморът е начин да се справите с натиска от огромни системи, които се придържат към вашия код.
За един креативен професионалист, свързването с тази култура прави отношенията с програмистите по-гладки: да разбирам шегите му, препратките му и странностите му Това значително улеснява комуникацията при обсъждане на крайни срокове, технически ограничения или промени в последния момент.
Как програмистите (наистина) учат и какво означава това за вас
Друг интересен факт е, че въпреки че има степени, обучителни лагери и магистърски програми, По-голямата част от истинското учене в програмирането се случва чрез работаТова е по-скоро като занаят, отколкото като университетски предмет: учиш се, като правиш нещо, чупиш неща, поправяш ги и повтаряш цикъла отново и отново.
Повечето разработчици са съгласни с една идея: Не е нужно да запомняте всичкоИма официална документация, форуми, статии, книги като „97 неща, които всеки програмист трябва да знае“ и тонове онлайн ресурси, като например Уроци по езици за програмиране на испанскиВажното е да знаете как да търсите, избирате и прилагате тези знания към конкретен проблем, точно както не знаете всички клавишни комбинации на Photoshop наизуст, но знаете къде да търсите, когато имате нужда от тях.
Освен това, почти всички препоръчват специализиране: Изберете област (уеб, мобилни устройства, бекенд, данни, видеоигри…) и се задълбочете Вместо да се опитвате да обхванете целия технологичен пейзаж. Същата логика може да ви вдъхнови: истинското разбиране на това как работи софтуерът във вашата творческа ниша ще ви направи много по-силни, отколкото да знаете по малко за всичко, без да владеете нищо.
Нещо, което се повтаря и в много вътрешни проучвания, е важността на ментора и „програмирането по двойки“: Програмирайте по двойки, оставете другите да преглеждат кода ви, поискайте помощ и приемайте критика.Точно същото е, както когато споделяте сценарий или мудборд с някой друг и приемате обратна връзка, за да подобрите произведението.
Реалността на работата с разработчици: самота, концентрация и гигантски слушалки
Вътре, ежедневието на софтуерен екип споделя доста неща с едно креативно студио: Много часове пред екрана, дълги периоди на концентрация и връзка на любов и омраза с прекъсванияНе е необичайно да се види половината от екипа да носи огромни шумопотискащи слушалки, сякаш са задължителни работни каски.
Музиката се превръща в инструмент за продуктивност: Меки списъци за архитектурно мислене, нещо по-мощно за механични задачи, пълна тишина за отстраняване на грешки в сложни грешкиСлушалките не са просто прищявка: те са социален сигнал от рода на „не ме прекъсвай сега, в режим на фокусиране съм“, точно както някои студия използват знаменца или малки физически сигнали на масата.
Има и друга, по-малко видима страна: Работата толкова много време сама пред компютър може да бъде изолиращаМного ветерани настояват, че не бива да се оставяте да бъдете третирани като робот и че е жизненоважно да култивирате живот извън програмирането: хобита, взаимоотношения, физическа активност, почивка. Мозъкът, който проектира решения, и този, който проектира интерфейси, са един и същ и се нуждаят от пространство.
Успоредно с това има нещо съвсем реално, наречено пристрастяване към програмиранетоКогато наистина сте запалени по нещо, е лесно да прекарате цели нощи „само за да завършите този модул“ и да забравите да ядете, да спите или дори да станете от стола си. Точно както при всяка творческа страст, трябва да се научите да си поставяте граници, за да избегнете прегаряне.
Начин на мислене, синдром на самозванеца и здравословна конкуренция
Повечето хора, които се занимават с програмиране, идват с технически опит, но Това не означава, че някой с „хуманитарно“ образование не може да бъде преквалифициран.Това, което ветераните ценят най-много, не е видът диплома за средно образование, а постоянството, способността за учене и известен комфорт с логическото мислене.
Почти всеки в индустрията живее с нещо доста широко разпространено: синдром на самозванецаТова чувство „не знам достатъчно, ще ме хванат, не съм на ниво“ може да се появи, независимо от това колко напред сте. Мнозина го използват като мотивация да продължат да учат, стига да не води до парализираща тревожност.
Конкурентоспособността също е част от пейзажа, но в здравословната си форма е по-скоро като „Съперничество“ между колегите, за да се види кой оптимизира модула най-добре или кой пише най-елегантния код Не е като война, за да се види кой кого стъпва. Да имаш програмист, на когото се възхищаваш, който цени работата ти, е много подобно на това друг креативен човек да се възхищава на илюстрацията или видеото ти.
В тази среда, да се научим да приемаме обратна връзка е от решаващо значение: Когато те хвалят, не се отклонявай от пътя; когато те критикуват, не се отказвай.Секторът се променя толкова бързо, че винаги ще има технологии, които не контролирате, и хора, които знаят повече за нещо специфично, и животът с това е част от играта.
Най-отнемащата време част: отстраняване на грешки, справяне с фрустрацията и вземане на решение кога да се премине
Ако погледнете само крайните резултати, може да си помислите, че разработчиците прекарват целия ден в писане на нови функции, но в действителност... Голяма част от времето се прекарва в отстраняване на грешки и коригиране на вече съществуващи неща.Продължаването на проекта напред често означава отключване на малки грешки, които пречат на останалата част от системата да напредва.
Това причинява значителни пикове на фрустрация: Проблеми, които не се откриват, конструкции, които се провалят без видимо обяснение, клиенти, изискващи невъзможни сроковеМного професионалисти казват, че са имали моменти, в които са искали да напуснат всичко и да сменят сектора, особено когато работят върху сложни продукти.
Стратегиите, които препоръчват, звучат познато: Упоритост, самомотивация, известна гордост от добре свършената работа и искрена страст към занаятаТочно както във всяка взискателна творческа дисциплина, тази смесица е това, което те кара да опиташ отново, когато нещо не се получи, и това, което разделя тези, които остават на повърхността, от тези, които стават наистина добри.
Известна степен на текучество на работни места също е често срещана: Добрите кандидати получават оферти непрекъснато.Много съвети тук сочат едно и също нещо: търсете фирмена култура, която е в съответствие с вашите ценности и не забравяйте, че на интервю вие също оценявате компанията. Ще прекарате много часове в размисъл върху нейните проблеми; доброто междуличностно съответствие и споделените ценности са по-важни, отколкото може да изглежда в автобиографията ви.
Технически интервюта, интеграция в екипа и комуникация
В общността на разработчиците техническите интервюта са доста известни... и също така имат доста лоша репутация. Много ветерани вярват, че Те са надценени и провалът на един от тях не говори много за вашия потенциал.Те обикновено измерват специфичен набор от умения под напрежение, а не действителната ви способност да учите, да си сътрудничите и да завършвате успешно проекти в дългосрочен план.
Вместо това, Меките умения често са от решаващо значение: умение как да общувате, да задавате въпроси, когато нещо не е разбрано, да използвате обратна връзка, да си сътрудничите с хора от различен произход (като вас, ако сте креативни) и да запазите спокойствие в напрегнати моменти.
Когато се присъединява към компания, най-добрата препоръка за всеки младши програмист е Не се страхувайте да задавате въпроси, но го правете обмислено.Планирайте конкретни часове с ментор, за да отговаряте на въпроси, избягвайте да прекъсвате, освен ако не е спешно, и подгответе внимателно въпросите си. Същото важи и когато се присъединявате към технически екип: колкото по-ясна и структурирана е вашата комуникация, толкова по-добре ще се впишете.
В среди, където не е назначен ментор, най-препоръчителният начин на действие е да спечелите доверието на някой с опит и да изградите солидни професионални взаимоотношения с този човек. В крайна сметка, големите проекти зависят както от качеството на кода и дизайна, така и от качеството на взаимоотношенията между тези, които ги изграждат.
В крайна сметка, магията на инструментите, които използвате всеки ден, идва от доста човешка смесица: Хора, които постоянно се учат, разочароват се, стават конкурентни, сътрудничат си, смеят се на странни бинарни шеги и постепенно превръщат идеите в софтуерКогато вие, като творец, разбирате тези любопитни факти и начини на работа, е много по-лесно да говорите на един и същ език, да питате какво всъщност може да се построи и да участвате в този почти „магически“ процес на каране на компютър да прави точно това, което си представяте.