Як навчитись програмувати і знайти роботу [повна версія]

Оригінальна публікація: How to Learn to Code and Get a Developer Job [Full Book]

Якщо ви хочете навчитись програмувати та стати розробником, то ви саме там, де треба. Ця книга допоможе вам.

І це безоплатна повна версія на freeCodeCamp.

Крім того, я записав БЕЗОПЛАТНУ аудіокнигу за мотивами цієї книги, яку опублікував як 100-й випуск подкасту freeCodeCamp. Її можна знайти в будь-якому застосунку з подкастами. Не забудьте підписатися. Для зручності я прикріпив посилання нижче.

Кілька років тому одне з найбільших видань Нью-Йорка зв’язалось зі мною щодо угоди про видання книги. Я зустрівся з ними, але не мав часу написати її.

Нарешті я знайшов час. Вирішив, що опублікую книгу безоплатно на freeCodeCamp.

Інформація має бути безоплатною, правда ж? 🙂

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

Я здобув ці знання, коли:

• вчився програмувати в 30+,
• працював інженером-програмістом,
• а потім керував freeCodeCamp.org. Зараз цей сайт щодня відвідують понад мільйон людей з однією метою: вивчати математику, програмування та комп’ютерні науки.

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

Я не купував книги чи курси.

(Насправді я витрачав гроші на поїздки в сусідні міста, щоб брати участь у професійних заходах. Пізніше побачите, що воно було того варте.)

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

Я розробив декілька навчальних інструментів, якими ніхто не хотів користуватися. Але якось на вихідних я створив freeCodeCamp.org. Тут швидко зібралася активна спільнота.

Ми всі допомагали одне одному. А тепер люди з усього світу використовують freeCodeCamp, щоб підготуватися до своєї першої роботи в ІТ.

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

Не переймайтесь. Додайте сторінку до закладок. Ви зможете повернутися до неї і прочитати за кілька разів.

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

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

Обіцяю не зловживати вашим часом. Тут немає пафосу чи пустослів’я, а лише відверті та практичні поради.

Додам в кожен розділ стільки думок, скільки можливо.

А де ж зміст?

А ось він:

Зміст

1. Передмова: для кого ця книга?
2. Короткий виклад на 500 слів
3. Розділ 1: як розвивати навички
4. Розділ 2: як розбудувати нетворкінг
5. Розділ 3: як заробити репутацію
6. Розділ 4: як заробляти на програмуванні (клієнти на фрилансі та пошук роботи)
7. Розділ 5: як досягти успіху на першій роботі
8. Епілог: у вас все вийде

Передмова: для кого ця книга?

Книга підійде всім, хто думає над кар’єрою в ІТ.

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

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

Можливо, ви старшого віку, маєте дітей чи доглядаєте за родичами. Тож у вас може бути менше часу.

Або ж ви молоді, але не маєте часу відкладати гроші чи набувати навичок, які збільшать ваш дохід. Тож у вас може не вистачати фінансів.

Чи, можливо, ви живете далеко від великих технологічних міст, таких як Сан-Франциско, Берлін, Токіо чи Бенгалуру.

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

Тож можливості обмежені.

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

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

Іншими словами: не переймайтесь, ви у правильному місці.

Чи може кожен навчитися програмувати?

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

Чи були комп’ютери на африканських саванах, де первісні люди жили тисячі років, перш ніж розселитися по Європі, Азії та Америці?

Програмування — це не те, до чого людство пристосовувалося в ході еволюції. Комп’ютери в тому вигляді, в якому ми їх знаємо (настільні ПК, ноутбуки, смартфони), з’явилися у 80-х, 90-х та 2000-х роках.

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

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

І я так само. Я розчаровувався і здавався. Не один раз.

Але — як й інші люди, які зрештою досягли успіху — через кілька днів пробував знову.

Визнаю: навчитися програмувати і влаштуватися на роботу — важко. А для деяких людей ще важче через обставини.

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

Я ріс в сім’ї середнього класу в США — я американець у четвертому поколінні з англомовної родини. Вчився в університеті. Мій батько теж вчився в університеті. І його батько так само (а його батьки були фермерами зі Швеції).

Мені пощастило і я скористався моментом, коли життя досить спокійне.

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

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

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

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

Немає нічого поганого в тому, щоб навчитися програмувати для хорошої стабільної роботи.

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

Дехто може казати, що ви повинні марити програмуванням. Ніби-то після повного робочого тижня ви маєте проводити вихідні над проєктами з відкритим кодом.

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

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

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

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

Якщо у вас так — це чудово. Але це точно не вимога.

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

Для початку прочитайте невеликий виклад. А потім все решту.

Короткий виклад на 500 слів

Навчитися програмувати важко. А знайти роботу — ще важче. Але для багатьох людей це того варте.

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

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

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

Автоматизація вплине на програмування. Вона вже вплинула. На десятиліття.

Інструменти генеративного ШІ — серед яких GPT-4 та Copilot — можуть допомогти перейти від імперативного (коли ви чітко вказуєте комп’ютерам, що робити) до декларативного програмування (коли ви ставите перед комп’ютерами завдання вищого рівня). Іншими словами: програмування у стилі «Зоряного шляху».

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

Вийшло переконати, що кар’єра в ІТ — це те, що вам потрібно?

Добре. Ось як увійти до цієї галузі.

Розвивайте свої навички

Вам потрібно вивчати:

• front end: HTML, CSS, JavaScript;
• back end: SQL, Git, Linux та вебсервери;
• наукові обчислення: Python та його численні бібліотеки.

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

Найкращий спосіб освоїти їх — будувати проєкти. Намагайтеся щодня писати хоча б частину коду. Якщо ви пройдете навчальну програму freeCodeCamp від початку до кінця, то опануєте ці технології та створите десятки проєктів.

Працюйте над нетворкінгом

Отримання роботи значною мірою залежить від того, кого ви знаєте.

Немає нічого поганого в тому, щоб бути інтровертом, але потрібно виходити із зони комфорту.

Зареєструйтесь на GitHub, X (Twitter), LinkedIn та Discord.

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

Спілкуйтесь з людьми. Дайте можливість говорити іншим, а самі уважно слухайте. Запам’ятовуйте імена.

Додавайте людей на LinkedIn, підписуйтесь на них у X (Twitter) та відвідуйте вечірки після заходів.

Заробляйте репутацію

Діліться короткими демонстраціями своїх проєктів.

Продовжуйте подавати заявки на виступи на дедалі більших конференціях.

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

Робіть внесок до відкритих проєктів. Ця робота схожа на професійну розробку програмного забезпечення.

Розвивайте навички, нетворкінг і репутацію одночасно. Не дозволяйте собі відкладати найскладніші етапи.

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

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

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

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

Найголовніше — висипайтеся та займайтеся спортом.

Будь-яка достатньо вмотивована людина може навчитися програмувати і влаштуватися на роботу.

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

Пам’ятайте: у вас все вийде.

Ця книга присвячена глобальній спільноті freeCodeCamp

Дякую всім, хто підтримував нашу благодійну організацію та нашу місію протягом останніх років.

Саме завдяки вашій волонтерській діяльності та благодійності ми змогли допомогти багатьом навчитися програмувати і вперше влаштуватись на роботу розробником.

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

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

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

Ще раз дякую всім.

Окрема подяка Еббі Реннемейєр за редакційні коментарі та Естефанії Кассінгена Навоне за дизайн обкладинки.

А тепер книга.

Розділ 1: як розвивати навички

«Кожен митець спочатку був аматором» — Ральф Волдо Емерсон

Шлях до оволодіння навичками програмування — довгий.

Для мене він був досить неоднозначним.

Для вас він може бути іншим.

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

Спочатку я розповім, як навчився програмувати у 2011 році.

Потім я поділюся тим, чого навчився в процесі.

Я розкажу, як навчатися ефективніше за мене.

Час історій: як 30-річний викладач самостійно навчився програмувати?

Я був викладачем і керував школою англійської мови. У нас навчалося близько сотні дорослих учнів, які приїхали до Каліфорнії з різних куточків світу. Вони вивчали англійську, щоб вступити до університету.

Більшість викладачів обожнювали викладати. Їм подобалося проводити час з учнями та допомагати їм вдосконалювати розмовну англійську.

Але вони ненавиділи паперову роботу: звіти про відвідування, табелі успішності, імміграційні документи.

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

Але що я знав про комп’ютери?

Програмування? Хіба для цього не треба бути розумним? Я ледве міг налаштувати Wi-Fi роутер. І з математикою мені не пощастило.

Одного дня я просто відкинув усі сумніви і подумав: «А таки спробую. Що я втрачаю?»

Я почав гуглити запитання на кшталт «як автоматично переходити по посиланнях на вебсайтах» та «як імпортувати дані з вебсайтів до Excel».

Тоді я цього не усвідомлював, але я вчився автоматизовувати робочі процеси.

Так і почалося навчання: спочатку з макросами Excel, а потім — з інструментом AutoHotKey, за допомогою якого можна запрограмувати мишу так, щоб вона переміщалася до певних координат екрана, натискала, копіювала текст, а потім переміщалася до інших координат і вставляла той текст.

Після кількох тижнів хаотичних пошуків я з’ясував, як автоматизувати кілька завдань. Я міг відкрити таблицю Excel і вебсайт, запустити код, а потім повернутися через 10 хвилин і таблиця була б повністю заповнена.

Це була аматорська робота. Те, що розробники могли б назвати «брудним лайфхаком». Але завдання було виконано.

Я використовував свої новонабуті навички автоматизації, щоб і далі оптимізувати роботу школи.

Через деякий час викладачам майже не доводилося торкатися комп’ютера. Я виконував роботу кількох викладачів, маючи навички початківця.

Це помітно вплинуло на школу. Раніше велика частина нашого часу йшла на рутинну роботу за комп’ютером. Ми стали вільними.

Викладачі стали щасливішими. Вони проводили більше часу з учнями.

Учні стали щасливішими. Вони розповідали своїм друзям з рідної країни, щоб ті обов’язково відвідали нашу школу.

Незабаром ми стали однією з найуспішніших шкіл у всій системі освіти.

У мене з’явилось ще більше сміливості. Пам’ятаю, як подумав: «Можливо, я зможу навчитися програмувати».

Я знав пару розробників з наших вечорів настільних ігор. У них була традиційна освіта: дипломи з Каліфорнійського технологічного інституту, коледжу Харві Мадда та інших відомих навчальних програм.

У той час 30-річним людям набагато рідше спадало на думку вчитися програмувати.

Я набрався сміливості й поділився своїми мріями з деякими друзями.

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

Я ділився цими мріями зі своїми друзями-розробниками:

— Хочу робити те, що ви.

Але вони лише знизували плечима. Потім казали щось на кшталт:

— Ну, можеш спробувати. Але потрібно перейти цілу гору знань.

А ще:

— Це досить конкурентна галузь. Як ти збираєшся змагатися з тими, хто змалку займається програмуванням?

І ще:

— Ти хороший викладач. Чому тобі просто не займатися тим, що добре виходить?

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

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

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

Раніше лікарі вважали, що неможливо пробігти милю за 4 хвилини. Вони думали, що від такого швидкого бігу серце просто вибухне.

Але потім комусь це вдалося. І серце не вибухнуло.

Як тільки Роджер Банністер — 25-річний студент Оксфорда — подолав цей психологічний бар’єр, так зробили й безліч інших людей. На сьогоднішній день понад тисячу людей пробігли милю швидше, ніж за 4 хвилини.

Я не робив нічого такого сміливого та безпрецедентного. Багато відомих розробників навчилися програмувати самостійно.

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

Вона написала декілька перших комп’ютерних алгоритмів. Її вважають першою у світі програмісткою. Ніхто її не навчав. Бо не було нікого, хто міг би її навчити. Які б сумніви вона не мала, вона їх безперечно подолала.

Звісно, я не Ада Лавлейс. Я звичайний викладач, у якого були робочий комп’ютер, непоганий інтернет і можливість шукати серед мільярдів вебсторінок за допомогою Google.

Я налаштувався і вирішив, що таки зроблю це.

«Навчальне пекло», у яке я вляпався

«Якщо ти працюєш 10 років, то отримуєш 10 років досвіду чи 1 рік досвіду 10 разів? Щоб здобути справжній досвід, потрібно аналізувати свої дії. Якщо ти постійно навчаєшся, то здобудеш досвід. Якщо ні — то ні, скільки б років ти не пропрацював» — Стів Макконнелл (інженер-програміст)

Наступні кілька тижнів я гуглив та розглядав випадкові уроки, на які натрапив в інтернеті.

Гляньте, урок з Ruby.

О, стає складніше. Я отримую повідомлення про помилки, які не згадуються в уроці. Що відбувається?

Гляньте, урок з Python.

Людська психологія — дивна річ. Як тільки щось стає складним, ми запитуємо себе: я правильно роблю?

Можливо, урок застарів. Можливо, автор не знав, про що говорив. Хтось взагалі користується цією мовою програмування?

Коли стикаєшся з неоднозначними повідомленнями про помилки, то здається, що нічого не виходить.

Вдавати прогрес було легко. Настав час пообідати.

У кафе я зустрів друга.

— Як справи з програмуванням? — запитав він.

— Чудово. Сьогодні програмував 4 години.

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

— Звісно, — відповідав я, знаючи, що нічого не зробив. — Скоро подивишся.

Після цього я міг піти до бібліотеки і взяти нову книгу з JavaScript.

Одне старе прислів’я каже, що купівля книг дарує найкраще відчуття у світі. Адже ти ніби купуєш час, щоб прочитати їх.

Саме в такій ситуації я опинився через кілька тижнів після того, як почав програмувати.

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

Я написав перші 100 рядків коду з кількох уроків, але жодного не завершив.

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

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

Щоб вийти за межі основ потрібна справжня праця.

Гуртом і на розробника легше навчатись

Навчання забирало весь мій вільний час, але я не помічав прогресу. Згодом я міг набирати символи { та *, не дивлячись на клавіатуру. Але на цьому поки все.

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

Я дізнався про місце неподалік, яке називалося «хакерспейс». Коли я вперше почув цю назву, то трохи злякався. Хіба хакери не займаються незаконними справами? Я був викладачем англійської мови, який любив грати в настільні ігри. Я не хотів проблем.

Ну, я зателефонував за вказаним номером і поговорив зі Стівом. Я нервово запитав:

— Ви ж не робите нічого незаконного?

Стів засміявся.

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

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

Коротше, не бійтеся цього слова.

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

Адже саме в цьому і полягає суть хакерспейсу: у створенні чогось.

Стів запросив мене відвідати хакерспейс у суботу. Він сказав, що там буде кілька розробників з околиць.

Коли я вперше переступив поріг хакерспейсу, я був вражений.

У приміщенні пахло гаром від електрики. На імпровізованих столах лежали паяльники, смужки світлодіодних ламп, аматорські плати Arduino та купи роботів-пилососів Roomba.

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

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

Стів увімкнув проєктор і провів коротку неформальну презентацію. Він продемонстрував написаний ним застосунок, який розпізнавав QR-коди у відео та замінював їх зображеннями.

Хтось із аудиторії відкрив QR-код на своєму ноутбуці й підніс його перед камерою. Застосунок Стіва замінив QR-код на зображення піци.

Хтось з аудиторії вигукнув:

— А можеш зробити так, щоб піца оберталася?

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

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

Я подумав: він — геній.

Того ж вечора я йому сказав про це після закінчення заходу.

Ми разом їли сендвічі. І я сказав йому:

— Я міг би весь час програмувати і не досягти твого рівня. Для мене за щастя, якби через 10 років я міг програмувати хоча б наполовину, як ти.

Але Стів заперечив. Він сказав:

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

Звісно, я й на секунду не повірив. Але сам факт, що він так сказав, викликав у мене трепет.

У мене повірив розробник. Він побачив мене — звичайного викладача, звичайного «кодового дитинча» — і вирішив, що у мене все вийде.

Ми з Стівом розмовляли до пізньої ночі. Він показав свій нетбук за 200 доларів, який навіть за стандартами 2011 року був слабким.

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

Я запам’ятав модель його ноутбука і того ж вечора замовив такий самий.

Після кількох днів налагодження нового комп’ютера з допомогою Stack Overflow я успішно встановив Ubuntu. Тоді почав вивчати, як користуватися редактором коду Emacs. До наступної суботи я вже знав кілька команд і поспішив ними похвалитися.

Стів схвально кивнув. Він сказав:

— Супер. Але що ти створюєш?

Я не зрозумів, про що він:

— Я вчуся користуватися Emacs. Дивись. Я запам’ятав...

Стів задумався:

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

Окрім кількох скриптів, які я написав, щоб допомогти викладачам у школі, я нічого не доводив до кінця. Але я почав розуміти, про що говорив Стів.

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

Стів сказав:

— Хочу, щоб ти створив проєкт на HTML5, а наступної суботи презентував його в хакерспейсі.

Його слова шокували мене. Але я випрямив спину і сказав:

— Хороший план.

За тебе ніхто розробником не стане

«Я намагаюся звільнити твій розум, Нео. Але я можу лише показати тобі двері. Ти сам повинен пройти через них» — Морфеус у фільмі «Матриця», 1999 рік

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

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

Давайте швидко поясню, що таке HTML5: це просто нова версія HTML, який існує ще з часів перших вебсторінок 90-х.

Якщо вебсайт — це тіло, то HTML — його кістки. Все інше лежить поверх цих кісток (JavaScript можна вважати м’язами, а CSS — шкірою; але повернемося до історії).

Я знав, що в HTML можна посилатися на різні частини однієї вебсторінки, використовуючи id-властивості. Тож я подумав: а що, якби я розмістив зміст зліва? Тоді, натискаючи на різні пункти зліва, сторінка праворуч прокручувалася б вниз, щоб показати ці пункти.

За півгодини я написав прототип.

Але настав час вирушати на роботу до школи. Весь день я думав лише про свій проєкт і як його завершити.

Я побіг додому, відкрив ноутбук і провів увесь вечір за проєктом.

Я скопіював офіційну (і ліцензовану за Creative Commons) документацію HTML безпосередньо на свою сторінку, «вбудувавши» її в HTML.

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

Я постарався використати якомога більше нових «семантичних» тегів HTML5.

Проєкт готовий.

Яке ж задоволення я відчув! Побіг до найближчого футбольного поля і пробіг кілька кіл. Я це зробив. Я завершив проєкт.

Тоді я вирішив: відтепер усе, що я робитиму, буде проєктом. Я працюватиму над створенням кінцевого продукту.

Наступного вечора я підійшов до трибуни, підключив ноутбук і презентував свою вебсторінку. Я відповідав на всі запитання щодо HTML5.

Іноді я щось плутав і хтось з аудиторії казав:

— Неправильно. Дозвольте перевірити документацію.

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

Не було тривожності, яку я міг відчути на засіданні викладачів.

Натомість я відчув себе частиною аудиторії, навчаючись разом із ними.

Зрештою, ці інструменти були новими і тільки починали набирати популярності. Ми всі намагалися зрозуміти, як їх використовувати.

Після моєї доповіді Стів підійшов до мене і сказав:

— Непогано.

Я посміхався (мабуть, надто довго) і нічого не відповів. Просто був задоволений собою.

Потім Стів примружився, стиснув губи і сказав:

— Починай наступний проєкт сьогодні ввечері.

Мій шлях в програмуванні

У наступних розділах ми будемо повертатися до історії молодого Квінсі та його шляху в програмуванні. Проте зараз я хочу розібрати деякі уроки та відповісти на кілька запитань, які могли у вас виникнути.

Чому навчитися програмувати так важко?

Освоїти будь-яке нове вміння — важко. Чи то вести м’яч у футболі, чи то міняти масло в машині, чи то вивчати нову мову.

Навчитися програмувати важко з кількох причин. Деякі з них притаманні саме програмуванню.

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

Що таке програмування?

Програмування — це вміння пояснити комп’ютеру його роботу таким чином, щоб він зрозумів.

Ось і все. В цьому полягає весь сенс програмування.

Але не зрозумійте неправильно. Спілкуватися з комп’ютерами важко. За людськими мірками вони «тупі». Вони роблять лише те, що ви їм скажете. Але — якщо ви не вмієте добре програмувати — вони, швидше за все, робитимуть не зовсім те, що вам потрібно.

Можливо, ви думаєте: а як щодо серверів? А баз даних? А мережі?

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

У перші кілька десятиліть комп’ютеризації програмісти писали код, що був «близьким до заліза» — часто працюючи з апаратним забезпеченням напряму, змінюючи біти з 0 на 1 і навпаки.

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

У 1960-х роках англійське слово «bug» означало комаху, що повзала всередині комп’ютера розміром із кімнату і згоряла на одній із плат.

Сьогодні ми пишемо код на багатьох рівнях абстракції вище фізичного обладнання.

Ось що таке програмування. Воно значно простіше, ніж було раніше, і з кожним роком стає ще легшим.

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

Чому навчитися програмувати досі так важко?

Є три головні причини, чому навчитися програмувати складно навіть сьогодні:

1. Інструменти досі примітивні.
2. Більшість людей погано справляється з невизначеністю, а вчитися програмувати — це суцільна невизначеність. Люди губляться.
3. Більшість людей погано сприймає постійний негативний зворотний зв’язок. Вчитися програмувати — це постійні повідомлення про помилки. Люди втрачають терпець.

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

Інструменти досі примітивні

«Комп’ютере. Почати нову програму. Створити наступне. Крісло біля робочого місця. Тепер створити стандартну алфавітно-цифрову консоль, розміщену ліворуч. Тепер легендарну дисплейну консоль для правої руки. Підключити обидві консолі до головного комп’ютерного ядра "Ентерпрайзу", використовуючи нейросканувальний інтерфейс» — Барклі з серіалу «Зоряний шлях: Нове покоління», 4 сезон 19 серія: «Ступінь N»

Саме так люди зможуть програмувати в майбутньому. Це приклад із мого улюбленого науково-фантастичного серіалу — «Зоряний шлях: Нове покоління».

Кожен персонаж у «Зоряному шляху» вміє програмувати. Лікарі, офіцери, пілоти. Навіть маленький Веслі Крашер (якого грає юний актор Віл Вітон) може змусити корабельний комп’ютер виконувати його команди.

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

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

А що, якби програмування було таким же простим, як звичайне пояснення завдання комп’ютеру людською мовою?

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

Колись програмування навіть найпростішого застосунку вимагало ретельно виписаних інструкцій.

Ось два приклади «Шифру Цезаря» — класичного навчального проєкту з інформатики.

Його також називають «ROT-13». Вам потрібно зсувати літери на 13 позицій. Наприклад, A стає N (13 літер після A), а B стає O (13 літер після B).

Покажу два приклади цієї програми.

Спочатку — програма на мові асемблера x86:

format     ELF     executable 3
entry     start

segment    readable writeable
buf    rb    1

segment    readable executable
start:    mov    eax, 3        ; syscall "read"
    mov    ebx, 0        ; stdin
    mov    ecx, buf    ; buffer for read byte
    mov    edx, 1        ; len (read one byte)
    int    80h

    cmp    eax, 0        ; EOF?
    jz    exit

    xor     eax, eax    ; load read char to eax
    mov    al, [buf]
    cmp    eax, "A"    ; see if it is in ascii a-z or A-Z
    jl    print
    cmp    eax, "z"
    jg    print
    cmp    eax, "Z"
    jle    rotup
    cmp    eax, "a"
    jge    rotlow
    jmp    print

rotup:    sub    eax, "A"-13    ; do rot 13 for A-Z
    cdq
    mov    ebx, 26
    div    ebx
    add    edx, "A"
    jmp    rotend

rotlow:    sub    eax, "a"-13    ; do rot 13 for a-z
    cdq
    mov    ebx, 26
    div    ebx
    add    edx, "a"

rotend:    mov    [buf], dl

print:     mov    eax, 4        ; syscall write
    mov    ebx, 1        ; stdout
    mov    ecx, buf    ; *char
    mov    edx, 1        ; string length
    int    80h

    jmp    start

exit:     mov     eax,1        ; syscall exit
    xor     ebx,ebx        ; exit code
    int     80h

Цей приклад на мові асемблера x86 взято з проєкту Rosetta Code під ліцензією Creative Commons.

А ось та сама програма, написана на Python:

def rot13(text):
    result = []

    for char in text:
        ascii_value = ord(char)

        if 'A' <= char <= 'Z':
            result.append(chr((ascii_value - ord('A') + 13) % 26 + ord('A')))
        elif 'a' <= char <= 'z':
            result.append(chr((ascii_value - ord('a') + 13) % 26 + ord('a')))
        else:
            result.append(char)

    return ''.join(result)

if __name__ == "__main__":
    input_text = input("Enter text to be encoded/decoded with ROT-13: ")
    print("Encoded/Decoded text:", rot13(input_text))

Значно простіше і легше читати, правда?

Цей приклад на Python створив GPT-4. Я поставив запит так само, як капітан Пікар звертається до корабельного комп’ютера в «Зоряному шляху».

Ось що я написав: «Комп’ютере. Нова програма. Візьми кожну літеру слова, яке я скажу, і заміни її на літеру, що стоїть на 13 позицій пізніше в алфавіті. Потім зачитай мені результат. Слово — Banana».

GPT-4 написав код на Python, а потім зачитав мені результат: «Onanan».

Саме це називається декларативним програмуванням. Ми проголошуємо: «Комп’ютере, ти маєш зробити ось це». Комп’ютер досить розумний, щоб зрозуміти наші інструкції та виконати їх.

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

Галузь розробки програмного забезпечення поки не досягла зрілості.

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

Мабуть, зараз ми досі перебуваємо в епосі, що відповідає бронзовому віку програмування. Але залізного віку ми можемо досягти ще за нашого життя. Інструменти генеративного ШІ, як-от GPT, стрімко стають потужнішими та надійнішими.

Спільнота розробників досі розділена щодо того, наскільки корисними такі інструменти будуть для розробки програмного забезпечення.

З одного боку — підприємці-інфлюенсери, які просувають ідею «стань власним босом» та кажуть щось на кшталт:

— Вам більше не потрібно вчитися програмувати. ChatGPT напише весь код за вас. Вам потрібна лише ідея для застосунку.

З іншого боку — «стара гвардія» розробників із десятиліттями досвіду у програмуванні, багато з яких скептично ставляться до того, чи справді ці інструменти настільки корисні для написання коду виробничого рівня.

Як і в більшості випадків, справжня відповідь десь посередині.

На YouTube легко знайти відео, де люди починають з ідеї застосунку, а потім запитують ChatGPT про потрібний код. Деякі люди навіть можуть взяти цей код і зробити з нього робочий застосунок.

Великі мовні моделі, як-от GPT-4, вражають, а швидкість їхнього вдосконалення вражає ще більше.

Проте багато розробників скептично ставляться до того, наскільки корисними ці інструменти зрештою стануть. Вони сумніваються, чи вдасться змусити ШІ припинити «галюцинувати» (тобто видавати хибну інформацію).

Це фундаментальна проблема «інтерпретованості». Можуть пройти десятиліття, перш ніж ми по-справжньому зрозуміємо, що відбувається всередині такого «чорного ящика», як GPT-4. А до того часу нам варто перевіряти все, що він каже, та розуміти, що в наданому коді буде чимало помилок і недоліків безпеки.

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

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

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

А це означає прокладати свій шлях крізь велику невизначеність.

Вчитись програмувати — це неоднозначний процес

Коли ви вчитеся програмувати, то постійно запитуєте себе: «Я розумно витрачаю свій час? Я вивчаю правильні інструменти? Автори книг і курсів взагалі розуміють, про що говорять?»

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

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

Усе ускладнюється ще й тим, що деякі розробники вважають дотепним відповідати на запитання абревіатурою «RTFM» (акронім від англ. Read The Fucking Manual — «читай чортів посібник»). Зовсім не допомогло. Який посібник? Який розділ?

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

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

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

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

15% запитів, які люди гуглять щодня, — це запити, які шукають вперше. Погана новина, якщо ви ця людина.

Моя теорія така: більшість розробників вирішують проблему і просто рухаються далі, так і не задокументувавши розв’язок. Тож ви можете бути одним із десяти розробників, яким довелося самостійно вигадувати розв’язок спільної проблеми.

Ну, звісно, існують ще старі теми на форумах і архів Stack Overflow.

Як не заплутатися, коли вчишся програмувати

Хороша новина: і компетентність, і впевненість приходять із практикою.

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

Хотілося б, щоб існував простіший розв’язок проблеми невизначеності. Але вам просто потрібно її прийняти. Вчитися програмувати — це неоднозначний процес, і навіть досвідчені розробники борються з невизначеністю.

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

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

Люди думають, що розробка програмного забезпечення — це набір коду в комп’ютері. Але насправді це навчання.

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

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

Навчіться почуватися комфортно в умовах невизначеності і ви багато досягнете.

Вчитися програмувати — це одна помилка за іншою

Багато людей, які вчаться програмувати, почуваються загнаними в глухий кут. Прогрес йде не так швидко, як вони очікували.

Одна з головних причин — у програмуванні цикл зворотного зв’язку набагато коротший, ніж в інших галузях.

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

Ви подумаєте: «О ні, екзамен провалено, треба краще вчитися до заліку».

Викладач може залишити нотатки червоною ручкою, щоб допомогти вам.

Погана оцінка за екзамен чи письмову роботу може зіпсувати день.

Зазвичай ми сприймаємо зворотний зв’язок саме так.

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

Але найчастіше код не працюватиме.

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

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

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

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

Саме так інколи відчувається програмування. Хочеться схопити комп’ютер і накричати на нього: «Чому ти не розумієш, що я намагаюся зробити?»

Як не впасти у відчай

Знову ж таки, головне — це практика.

З часом у вас виробиться стійкість до повідомлень про помилки та трасування стека на весь екран.

Програмування ніколи не буде таким важким, як на самому початку.

Ви не лише не знаєте, що робите, а й не звикли отримувати такий безособовий, безперервний негативний зворотний зв’язок.

Тож кілька порад:

Порада №1: пам’ятайте, що ви не гірші за інших

Кожен, хто вчиться програмувати, стикається з розчаруванням від спроб злитися розумом із комп’ютером і домогтися порозуміння (ще один натяк на «Зоряний шлях»).

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

Сприймайте комп’ютер як свого друга, а не супротивника. Він просто просить уточнити інструкції.

Порада №2: дихайте

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

Так не працює. Поясню причину.

Всесвіт складний. Програмне забезпечення складне. Навряд чи вам вдасться просто натрапити на щось вартісне, як Форресту Ґампу.

Можливо, ви чули теорему про нескінченну мавпу. Це експеримент, де ви уявляєте шимпанзе, що друкують на друкарських машинках.

Якби у вас була ціла кімната з такими мавпами, то скільки часу знадобилося б, щоб одна із них випадково надрукувала фразу «бути чи не бути»?

Припустимо, що кожна мавпа друкує один випадковий символ за секунду. Швидше за все, знадобилось би квінтильйон років, щоб одна з них надрукувала «бути чи не бути». Це 10 у 18-му ступені. Мільярд мільярдів.

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

Навіщо я вам це розповідаю? Тому що не потрібно бути однією з тих мавп.

За цей час ви, напевно, змогли б знайти спосіб навчити тих мавп друкувати слова. Вони, мабуть, зуміли б надрукувати весь «Гамлет», а не лише його найвідомішу фразу.

Навіть якщо вам якимось чином пощастить і ви вирішите помилку, чого ви навчитеся?

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

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

Замість того, щоб навмання перебирати варіанти в надії вирішити помилку, — пригальмуйте.

Зробіть глибокий вдих. Розімніть м’язи. Налийте чашку гарячого напою.

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

Порада №3: використовуйте метод каченяти

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

Звісно, звучить безглуздо. Як це може бути корисним?

Але це працює.

Метод каченяти — чудовий інструмент, щоб сповільнитися і проговорити проблему вголос.

Звісно, зовсім не обов’язково використовувати саме качечку. Можна пояснювати улюблену програму на Python улюбленому кактусу або SQL-запит кішці, яка постійно стрибає на клавіатуру.

Сам факт того, що ви пояснюєте думки вголос, допомагає краще осмислити ситуацію.

Як більшість людей вчиться програмувати?

Тепер поговоримо про традиційні шляхи до першої роботи розробника.

Навіщо вам знати, що роблять інші? Спойлер: насправді вам це не потрібно.

Робіть так, як підходить саме вам.

Ви можете сумніватися в собі та рішеннях, які прийняли щодо навчання. Можливо, вас буде вабити шлях, який ви не обрали.

Моя мета в цьому розділі — розвіяти будь-які тривожні думки, які могли виникнути.

Важливість наукових ступенів у галузі комп’ютерних наук

Дипломи досі залишаються золотим стандартом підготовки до кар’єри в ІТ. Особливо ступінь бакалавра з комп’ютерних наук.

Перш ніж ви скажете: «Але у мене немає диплома з комп’ютерних наук» — не хвилюйтеся. Він вам не потрібен, щоб стати розробником.

Але їхня користь беззаперечна. Поясню причину.

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

«Освіта в галузі комп’ютерних наук може створити хорошого розробника так само, як знання про пензлі і пігменти можуть створити хорошого художника» — Ерік Реймонд (розробник, вчений-інформатик і письменник)

Кафедри комп’ютерних наук традиційно були частиною математичних факультетів. У 60-х і 70-х університети не зовсім розуміли, куди подіти комп’ютерну справу.

В інших університетах комп’ютерні науки вважалися розширенням електротехніки. Ще зовсім недавно навіть Каліфорнійський університет у Берклі — один із найкращих державних університетів світу — пропонував ступінь з комп’ютерних наук лише як подвійний диплом разом із електротехнікою.

Але зараз більшість університетів усвідомила важливість комп’ютерних наук як галузі знань.

На момент написання цього тексту комп’ютерні науки — це спеціальність із найвищим рівнем оплати праці. Вищим навіть за спеціальності, безпосередньо пов’язані з грошима (такі як фінанси та економіка).

За даними Glassdoor, випускники американських університетів зі спеціальністю «Комп’ютерні науки» отримують вищу зарплату на першій роботі, ніж представники будь-якої іншої спеціальності. Сімдесят тисяч доларів США. Багато для людини, яка щойно закінчила коледж.

Більше ніж у випускників за спеціальностями «Сестринська справа» (59 000 $), «Фінанси» (55 000 $) та «Архітектура» (50 000 $).

Отже, диплом з комп’ютерних наук може допомогти отримати високооплачувану роботу початкового рівня. Мабуть, нікого не здивує. Але чому так?

Як роботодавці ставляться до ступеня бакалавра

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

Так казали в Google. Так казали в Apple.

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

Чимало випускників freeCodeCamp влаштувалися в ці компанії і деякі з них не мали диплому.

Але ті випускники freeCodeCamp були особливо сильними кандидатами, щоб компенсувати відсутність наукового ступеня.

Ці вакансії можна розглядати як такі, що оцінюють кандидатів за різними критеріями:

1. Досвід роботи
2. Освіта
3. Портфоліо та проєкти
4. Чи є рекомендація від когось, хто вже працює в компанії? (нетворкінг розглянемо в другому розділі)
5. Інші репутаційні чинники (репутацію розглянемо в третьому розділі)

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

Майте на увазі: зі ступенем бакалавра легше потрапити на співбесіду навіть до тих роботодавців, де диплом не є обов’язковим.

Чому так багато вакансій вимагають ступеня саме з комп’ютерних наук?

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

Хочете вступити до армії офіцером, а не солдатом? Вам знадобиться ступінь бакалавра (підійде будь-яка спеціальність).

Хочете отримати робочу візу для роботи за кордоном? Вам, мабуть, знадобиться ступінь бакалавра (підійде будь-яка спеціальність).

Для більшості вакансій, де написано про обов’язкову вищу освіту, підійде будь-яка спеціальність.

Чому так? Хіба спеціальність взагалі не має значення?

Що ж, ось моя теорія: важливо те, що ви взагалі закінчили університет, а не те, що ви вивчали.

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

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

Знаєте, як називають студента, який закінчив медичний університет з найгіршими балами серед своєї групи? Лікар.

Так працює для більшості роботодавців.

HR-спеціалісти часто просто ставлять галочку для фільтрації заявок. Вони відсіюють претендентів без диплома. Тобто вони можуть навіть не побачити заявки від людей без диплома.

Знову ж таки, не кожен роботодавець такий. Але — у США, і, мабуть, ще більшою мірою в інших країнах — багато хто саме такий.

Прикро, але так працює ринок праці. Можливо, це зміниться протягом наступних кількох десятиліть.

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

Не через те, як університети рекламують себе:

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

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

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

Гаразд, багато фонової інформації. Тож дозвольте відповісти на запитання прямо.

Чи треба диплом, щоб працювати розробником?

Ні. Багато роботодавців наймуть вас без ступеня бакалавра.

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

А як щодо ступеня молодшого спеціаліста? Він цінний?

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

Проте я би не рекомендував вступати до університету лише з метою отримати ступінь молодшого спеціаліста. Я на всі 100% заохочую до отримання ступеня бакалавра, бо він значно корисніший.

За даними Міністерства освіти США, заробіток бакалавра на 31% більший за заробіток молодшого спеціаліста.

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

Чи варто вступати до університету, щоб отримати ступінь бакалавра у дорослому віці?

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

Чи є сенс «повертатися до навчання» у формальному розумінні?

Так.

Але, думаю, немає сенсу кидати роботу для того, щоб повернутися до навчання на денній формі.

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

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

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

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

Замість того, щоб вступати до традиційного університету, я рекомендую людям [старшим за 30 років] розглянути один із некомерційних онлайн-університетів. Western Governor’s University та University of the People — два університети, які мають хорошу репутацію і цілком доступну вартість навчання.

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

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

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

Якщо вже є ступінь бакалавра, чи є сенс отримати ступінь бакалавра з комп’ютерних наук?

Ні. Другий ступінь бакалавра майже ніколи не вартий витраченого часу та грошей.

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

А як щодо ступеня магістра з комп’ютерних наук?

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

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

Багато моїх друзів навчались на магістратурі з комп’ютерних наук у Технологічному інституті Джорджії.

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

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

Дипломи будуть важливими в майбутньому?

Так. Я вважаю, що дипломи будуть важливими ще десятиліттями (можливо, і століттями).

Дипломи існують вже більше тисячі років.

Багато провідних американських університетів старші за США (Гарварду більше 400 років).

«Відмирання» дипломів перебільшують.

У деяких колах стало модним критикувати університети і стверджувати, що наукові ступені більше не важливі.

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

Що не менш важливо, вони можуть забезпечити безпечнішу, стабільнішу та загалом кращу кар’єру.

Звісно, можна непогано заробляти матросом на офшорних платформах, обслуговуючи нафтові вишки.

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

Одна з цих робіт — небезпечна, виснажлива праця. Інша — робота, якою ви могли б комфортно займатися 40 років.

Багато «лідерів думок», які критикують університетську освіту, самі ж нею і скористалися.

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

Університет — це спосіб представити свій клас? Зрештою, шанси зустріти в Гарварді вихідця з багатої сім’ї втричі вищі, ніж з бідної.

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

Ви можете обрати легкий режим і отримати диплом, що дасть більше можливостей у майбутньому.

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

У мене є чимало друзів, які успішно скористалися обома підходами.

Які альтернативи диплому?

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

Звісно, існують сертифікаційні програми та інтенсиви.

Але вони не мають такої ж цінності для роботодавців і рідко бувають такими ж вимогливими.

Примітка: коли я кажу «сертифікаційні програми», я маю на увазі програми, де ви проходите курс, а наприкінці отримуєте сертифікат. Вони мають обмежену цінність. Але іспитові сертифікати від таких компаній, як Amazon і Microsoft, є досить цінними. Ми детальніше розглянемо їх пізніше.

Я кажу людям: «Мати диплом чи не мати — ось питання».

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

Я зустрічав багато бухгалтерів, помічників юриста та інших «працівників розумової праці» без ступеня бакалавра. Вони вміють опанувати набір навичок, застосовувати його і заробляти на цьому.

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

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

Але так не підходить кожному.

Якщо хочете формальної освіти — здобувайте ступінь бакалавра. Якщо не хочете формальної освіти — нікуди не вступайте, а просто вчіться самостійно.

Головне, що дадуть інтенсиви та інші програми, — це структура і трохи соціального тиску. Це непогано. Але чи вартує більше тисячі доларів?

Як навчитись програмувати

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

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

Тож незалежно від того, здобуваєте ви формальну освіту чи ні, майте на увазі: вам доведеться вчитися самостійно.

Що означає бути розробником-самоучкою?

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

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

Так само Ада Лавлейс самостійно навчилася програмувати, адже до неї програмування не існувало. Вона його винайшла.

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

Якщо хтось заперечує факт, що ви самоучка, просто скажіть: «За такою логікою називатися самоучками можуть лише ті, хто виріс з вовками».

Покажіть їм цей розділ і скажіть: «Квінсі передбачив твій снобізм». А потім просто живіть далі.

Адже, погодьтеся, життя занадто коротке.

Ви — самоучка.

Яка суть самостійного навчання?

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

Але як бути впевненим, що це потрібні навички та правильні ресурси?

Ось тут і стає в нагоді спільнота.

У світі існує безліч спільнот, учасники яких допомагають одне одному вдосконалювати навички.

Поняття «спільнота» важко визначити. Чи є Tech Twitter або freeCodeCamp спільнотами? Або численні групи у Discord та Reddit, присвячені конкретними навичками програмування?

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

А як щодо живих заходів? Щомісячних зустрічей розробників Ruby в Окленді? Зустрічі спільноти стартапів Нью-Йорка? Групи користувачів Linux у Центральному Техасі?

Спільноти можуть бути онлайн або офлайн, а також поєднувати обидва формати.

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

З якої мови програмування почати?

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

Існують різні типи мов програмування, але сьогодні більшість проєктів розробляються з використанням «скриптових мов високого рівня», до яких належать JavaScript і Python. Ці мови поступаються в ефективності, яку забезпечують «мови програмування низького рівня», серед яких C. Натомість вони значно простіші у використанні.

Сучасні комп’ютери в мільярди разів швидші ніж у 70-х і 80-х, коли більшість програм писали на таких мовах, як C. Ця потужність більш ніж компенсує відносну неефективність скриптових мов.

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

Python — це потужна мова програмування для наукових обчислень (зокрема, для науки про дані та машинного навчання).

А JavaScript... Ну, JavaScript може все. Це і швець, і жнець, і на дуду грець. JavaScript — це той гвинтик, що тримає всесвітню павутину в цілості.

«Будь-яка програма, яку можна написати на JavaScript, зрештою буде написана на JavaScript» — Закон Етвуда (Джефф Етвуд, засновник Stack Overflow та Discourse)

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

Тому я раджу почати з JavaScript. Ця мова не тільки набагато простіша у використанні, ніж Java та C++, але й легша у вивченні. Крім того, для тих, хто володіє JavaScript, набагато більше вакансій.

Також варто зосередитися на HTML і CSS. Якщо уявити вебсторінку як тіло людини, то HTML — це кістки, а CSS — це шкіра (JavaScript — це м’язи, які дозволяють вебсайту рухатися та бути інтерактивним).

З HTML і CSS можна ознайомитись за один день. Їх — як і більшість інструментів, про які я згадую, — легко вивчити, але важко опанувати.

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

Якщо у вас Mac, то macOS має командний рядок, який підтримує майже всі ті самі команди, що й Linux (MacOS і Linux мають спільного предка — Unix).

Але якщо ви користуєтеся Windows, то потрібно встановити WSL (Windows Subsystem for Linux). Після цього ви зможете виконувати команди Linux на своєму комп’ютері. А якщо любите експериментувати, то можете навіть налаштувати подвійний запуск обох операційних систем — Windows і Linux — на одному комп’ютері.

Якщо збираєтеся встановити Linux на комп’ютер, раджу почати з Ubuntu. Це найпопулярніший (і найбільш задокументований) дистрибутив Linux, тож він має бути найпростішим у використанні.

Подумайте добре, адже Linux користуватися значно складніше, ніж Windows і macOS. Але натомість ви отримаєте надзвичайно швидку, безпечну та гнучку операційну систему.

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

Вам також варто освоїти Git — систему контролю версій, що дозволяє командам розробників координувати зміни до кодової бази.

Можливо, ви вже чули про GitHub. Це вебсайт, який полегшує спільну роботу над проєктами з відкритим кодом. Крім того, він розширює деякі можливості Git. Більше про GitHub ви дізнаєтеся в розділі про репутацію.

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

Ви також будете чути про бази даних NoSQL (нереляційні бази даних, такі як графові та документальні, а також бази даних «ключ-значення»). Детальніше про них ви можете дізнатися пізніше. Спочатку зосередьтеся на SQL.

Зрештою, варто дізнатися про вебсервери. Почніть із Node.js та Express.js.

Якщо ви не знайомі з терміном «Full stack», то це поєднання front end (HTML, CSS, JavaScript) та back end (Linux, бази даних SQL і Node + Express).

Існує й багато інших інструментів, з якими варто ознайомитися (наприклад: React, NGINX, Docker та бібліотеки для тестування). Їх реально освоїти у процесі роботи.

90% підготовки варто витратити на основні навички:

1. HTML
2. CSS
3. JavaScript
4. Linux
5. Git
6. SQL
7. Node.js
8. Express.js

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

Мабуть, ви думаєте: «Чудово. Як вивчити це все?»

Де можна навчитися програмувати?

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

Саме так. Я маю на увазі основну навчальну програму freeCodeCamp, що допоможе опанувати:

• front end;
• back end;
• інженерну математику;
• і наукові обчислення (зокрема, Python для науки про дані та машинне навчання).

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

freeCodeCamp став стандартом для більшості людей, які вчаться програмувати самостійно.

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

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

На freeCodeCamp зараз доступно близько тисячі безоплатних курсів на різні теми: від підготовки до сертифікації AWS і розробки мобільних застосунків до Kali Linux.

Навчитись програмувати самостійно ще ніколи не було так просто.

Розвиток навичок — це вічна робота

Ми вже говорили, чому самостійне навчання є найкращим варіантом і як до цього підійти.

Ми вже говорили про альтернативи самостійному навчанню, а саме — про наукові ступені з комп’ютерних наук.

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

А тепер змінимо тему і поговоримо про те, як побудувати другий стовп кар’єри: нетворкінг.

Розділ 2: як розбудувати нетворкінг

«Хочеш йти швидко — йди сам. Хочеш дійти далеко — йди з кимось» — Африканське прислів’я

«Нетворкінг». Можливо, ви здригнетеся, почувши це слово.

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

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

Ще іншим — вітати з днем народження малознайомих людей у LinkedIn або лайкати їхні дописи у надії, що вас помітять.

Але нетворкінг не має відбуватися саме так.

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

Зрештою, саме в цьому й полягає суть: допомагати розв’язувати проблеми та бути корисними.

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

Час історій: як 30-річний викладач знайомився з людьми в ІТ?

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

Гаразд, я вже мав деякі базові навички програмування. Тепер я міг викрутитися з будь-якої ситуації.

Що ж було далі? Як-не-як, я був новачком у цій галузі.

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

Як викладач, я отримував зарплату за те, що передавав знання. А як розробник, я отримував би зарплату за те, що писав код.

Я вже знав одну дуже важливу істину про суть роботи: все залежить від того, кого ти знаєш.

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

Єдине, що стояло між мною та прибутковою роботою в ІТ, — це HR-менеджер, який міг би сказати:

— Так. Квінсі, здається, потрібний нашій команді.

Звісно, як новачок в ІТ, я не знав їхніх правил.

Академічні правила набагато формальніші.

Ти носиш костюм.

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

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

Кар’єрний ріст відрізняється. Конференції відрізняються. Структури влади відрізняються.

Я не одразу усвідомив цей факт.

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

Я завжди носив акуратно складені копії свого резюме.

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

«Кожен, хто почав мислити, ставить частину світу під загрозу» — Джон Дьюї

Це досі моя улюблена цитата.

Але це занадто:

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

Я ліз зі шкіри. Мабуть, це відчували всі, з ким я розмовляв.

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

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

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

Я прочитав багато книг, щоб краще зрозуміти культуру розробників.

«The Coders at Work» — чудова книга 80-х років.

«Hackers: Heroes of the Revolution» — хороша книга 90-х років.

Якщо вас цікавлять сучасні культурні джерела, подивіться серіал «Пан Робот». Його герої дещо екстремальні, але вони добре передають спосіб мислення та манери поведінки багатьох розробників.

Незабаром я вже говорив як розробник — а не викладач — і не виглядав таким безнадійним.

Кілька разів на тиждень я відвідував місцеві заходи, пов’язані з ІТ. Моїм улюбленим був навіть не захід для розробників, а «Santa Barbara Startup Night» — захід, де люди презентували свої ідеї. Деякі навіть змогли залучити фінансування від «бізнес-ангелів» — заможних людей, які інвестують у компанії на ранніх стадіях розвитку.

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

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

Майк був «нетехнічним»: він працював продакт-менеджером. Він багато знав про технології та UX-дизайн, але не вмів програмувати.

Іноді розробники зневажали «нетехнічних» людей.

— Він просто бізнесмен, — казали вони. Або:

— Вона — офісна працівниця.

Але я ніколи не чув, щоб хтось так говорив про Майка. Його поважали усі.

Я спеціально спостерігав за тим, як Майк спілкувався з розробниками. Зрештою, мене теж можна було назвати «нетехнічним», оскільки я почав програмувати лише кілька місяців тому.

Часто мої старі звички давали про себе знати. Під час розмов у мене виникала спокуса похизуватися своїми досягненнями.

Багато розробників скромно оцінюють свої вміння. Вони могли казати, що граються з Python. А я відкривав рота і казав щось типу:

— О, так. Я написав стільки алгоритмів на Python! Я пишу на Python навіть уві сні.

А потім я йшов додому, гуглив ім’я цього розробника і виявлялось, що він — один з головних авторів великої бібліотеки Python. Мені було дуже соромно.

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

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

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

Незабаром люди в південній Каліфорнії почали мене впізнавати. Вони казали:

— Я постійно бачу тебе на заходах. Як тебе звати?

Одного вечора мені сказали:

— Давай підпишемося одне на одного у X (Twitter).

Пару днів до того я зареєструвався у X (Twitter), але вважав цей сайт лише черговою модною забавкою. Скільки ж можна насправді висловити за 140 символів? Я не писав жодних дописів, але профіль я вже мав і на мене дійсно підписались.

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

За кілька місяців я познайомився з різними людьми:

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

Чому саме колеги були найважливішими? Вони найменше могли б допомогти знайти роботу, хіба не так?

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

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

Ми зростали разом. Ми були сім’єю, а такі зв’язки — найміцніші.

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

Але детальніше про це — в наступному розділі, а зараз поговоримо про мистецтво та науку побудови нетворкінгу.

Все справді залежить від того, кого ви знаєте?

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

Насправді все залежить і від того, і від іншого.

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

Давайте припустимо, що ви активно розвивалися і дотримувалися моїх порад з першого розділу. Коли час почати будувати нетворкінг?

Найкращий час для початку — вчора.

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

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

Тож перший крок — скласти повний перелік людей, яких ви знаєте. Не хвилюйтеся: я не прошу звертатися до них.

Подумайте, перш ніж діяти. Розробіть стратегію.

Спочатку складіть перелік усіх людей, яких знаєте.

Як створити дошку із власними знайомствами

Створіть список людей, яких знаєте.

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

Рекомендую скористатися Trello.

Створіть 5 колонок: «До розгляду», «Зв’язатися», «Очікування відповіді», «Нещодавно зв’язувалися» та «Поки не зв’язуватися».

Потім створіть мітки, щоб класифікувати людей залежно від того, звідки ви їх знаєте. Ось кілька ідей: «Друг дитинства», «Друг сім’ї», «Колишній колега», «Однокласник», «Друзі з технічних заходів».

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

Ось дошка, яку я створив на Trello як приклад. Це персонажі із мого улюбленого фільму дитинства — класичної стрічки «Черепашки-ніндзя» (1989 рік).

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

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

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

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

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

Крім того, ви можете додавати нотатки до кожної картки, коли дізнаєтеся щось нове. Вони нещодавно брали участь у благодійному марафоні на 5 км? Їхня бабуся нещодавно святкувала 90-річчя? Ці факти можуть здаватися незначними, але якщо людина ділиться ними в соціальних мережах, то для неї це дуже важливо.

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

Як я вже казав раніше, допомога — найкращий спосіб налагодити знайомства. Ми детально поговоримо про це трохи пізніше.

Додайте людину до своєї дошки, але подумайте, чи варто одразу з нею зв’язуватися. Якщо так, то помістіть її в стовпець «Зв’язатися», якщо ні — в «Поки не зв’язуватися».

Можливо, ви запитаєте: чому стовпець називається «Поки не зв’язуватися»? Тому що ніколи не знаєш, коли знайомство може стати в нагоді. Завжди цініть дружбу чи знайомство.

Як тільки ви заповнили дошку, позначили всіх і відсортували їх по колонках, — ви готові починати роботу.

Як підготуватися до нових знайомств

Головне, що потрібно пам’ятати, коли контактуєте з людьми і намагаєтеся справити враження: будьте простими.

Люди дуже зайняті, тому можуть запам’ятати лише певну кількість фактів про вас. Донесіть до них лише найголовнішу інформацію про себе. Найкращий спосіб це зробити — написати коротку біографію.

Як написати коротку біографію для соцмереж

Постарайтеся бути однаковими у всіх соціальних мережах.

Про себе я пишу так:

«Мене звати Квінсі. Я викладаю у freeCodeCamp. Живу в Далласі, штат Техас. Допоможу навчитись програмувати».

А тепер спробуйте написати щось про себе. Подивіться, чи вдасться вкластися в сто або менше символів. Намагайтеся уникати складних слів та жаргону.

Себе важко описати в кількох словах, але це важливо.

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

На цьому етапі знадобиться гарна фотографія, на якій ви посміхаєтеся.

Як зробити вдале фото для соцмереж

Якщо у вас є можливість, просто знайдіть місцевого фотографа і заплатіть йому за декілька професійних портретів.

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

Особисто я сам зробив фото за допомогою програми Photobooth, яка входить до стандартного набору програм на MacOS. Мій друг витратив приблизно 10 хвилин на фон і тінь у Photoshop. Можливо, він трохи відбілив зуби. Ось фото:

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

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

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

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

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

Обов’язково зберігайте фото у хорошій якості. Так люди зможуть використовувати його для реклами доповіді на конференції або участі в подкасті (з часом ви досягнете цих висот).

Як зв’язатися з людьми з минулого

Біографія і фото готові, тому можна почати зв’язуватися з людьми.

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

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

Вам потрібно швидко перейти до суті.

Тож до якої суті потрібно перейти?

Якщо коротко:

1. Я тебе знаю.
2. Ти мені подобаєшся.
3. Я поважаю те, чим ти займаєшся.

Ось і все.

Людям подобається, коли їх знають. Їм подобається, коли їх люблять. Їм подобається, коли їхню працю та життя помічають.

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

А як щодо інших 364 днів? Кожен хотів би трохи уваги й у ці дні.

Ось простий спосіб, як це зробити.

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

Крок №2: подумайте, що можна було б сказати, аби трохи покращити настрій цієї людини.

Крок №3: виберіть соціальну мережу, в якій вона була активною останнім часом та напишіть приватне повідомлення.

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

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

«Привіт, [ім'я]! Вітаю з [новою роботою / підвищенням / народженням дитини / завершенням проєкту]. Радий бачити, що ти досягаєш своїх цілей».

Щось коротко і по суті. Привітання + комплімент. Така базова формула.

Не просто кажіть так, а будьте щирими.

Цій людині потрібно відчути, що її цінують. Їй потрібно підняти настрій. Її потрібно підбадьорити, щоб вона продовжувала рухатися до своїх цілей.

Люди чудово відчувають нещирість, тому намагайтеся не нав’язуватись. Не давайте людям приводу думати, що їх хочуть використати.

Тому важливо бути лаконічними. Поважайте час людей. Ніхто не хоче отримувати довгі листи, на які доведеться писати довгу відповідь.

Причина в тому, що люди зайняті.

Як побудувати тісні знайомства

Люди дуже зайняті, тому часто їм хочеться бачити в незнайомцях вигоду:

• ця людина керує автобусом, яким я добираюся на роботу;
• ця людина готує напій саме так, як я люблю;
• ця людина з HR-відділу відповідає на мої запитання щодо відпустки;
• ця людина склала крутий плейлист з джазом, який я слухаю під час написання коду;
• ця людина щотижня надсилає корисні листи з безоплатними ресурсами для розробників.

Певною мірою ви є тим, що робите для інших.

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

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

Має бути причина, щоб людина звернула на вас увагу і захотіла дізнатися більше.

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

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

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

Навпаки: ви звертаєтеся до них, бо маєте що запропонувати.

У вас надзвичайне вміння: вміння підкорювати машини. Ви — розробник.

Або, принаймні, ви на шляху до того, щоб ним стати.

Отже, ви вже маєте хорошу причину звернутися до людей.

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

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

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

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

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

«Привіт, [ім'я]. Вітаю з [новою роботою / підвищенням / народженням дитини]! Я зараз активно вивчаю програмування і створюю портфоліо. Ти одразу спав мені на думку як людина, яка встигає зробити дуже багато справ. Чи є якісь інструменти або застосунки, які б полегшили тобі життя? Можливо, я зможу їх запрограмувати для практики».

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

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

Безсумнівно, найшвидший спосіб потрапити в чорний список — надіслати комусь повідомлення «Привіт, як справи?», де явно бракує імені. Це дуже нагадує шаблон.

Іноді я отримую повідомлення, в якому замість імені вказано прізвище. «Привіт, Ларсон». Тобто? Я тепер у військовому коледжі?

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

Якщо повідомлення починається з «Привіт, 🍜 Сара! Шукаєш нову роботу?», то можна бути впевненим — це спам.

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

Чому? Тому що сам факт нагадування людям про те, звідки ви знайомі, змусить деяких з них задуматися: «Ой, я цю людину майже не знаю».

Як підтримати розмову

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

Месенджери мають невимушену атмосферу, тому дотримуйтеся невимушеного стилю спілкування.

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

Як тільки отримаєте відповідь, внесіть її до своєї дошки, щоб не забути.

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

Почніть зі створення макету користувацького інтерфейсу (міліметровий папір буде виглядати особливо професійно). Сфотографуйте результат та надішліть людині зі словами: «Щось таке?»

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

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

Після цього просто підтримуйте розмову. Можливо, вона зійде нанівець. Не хвилюйтеся — нехай так і буде. Через кілька тижнів знайдеться привід, щоб знову написати.

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

Пам’ятайте, що розмова має бути невимушеною та позитивною. Якщо вам здається, що спілкування розвивається повільно, це не проблема. У вас будуть ще десятки розмов і справ. Ви будете працювати над знайомствами як бджілка.

Як знайомитися з новими людьми та розширювати коло знайомств

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

Але як знайти нові знайомства?

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

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

Коли зустрічаєте когось особисто, ваша пам’ять отримує набагато більше інформації, яку можна зафіксувати:

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

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

Ось чому я раджу виходити з дому та знайомитись з людьми на заходах.

Як знайомитися з людьми на заходах

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

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

Якщо ви ходите до церкви, мечеті чи храму, то знайомтеся з людьми і там.

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

Можливо. А може й ні. Але не варто нехтувати такими людьми.

Хтось із них може керувати малим бізнесом.

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

Можливо, вони теж розробники. Зрештою, нас — розробників програмного забезпечення — мільйони. Не всі живуть у Кремнієвій долині. 😉

Коли знайомитеся з кимось, не варто одразу діставати телефон і питати:

— Можна додати вас на LinkedIn?

Натомість краще поводитися спокійно. Представтеся.

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

Якщо все ж таки забули, не вгадуйте. Просто скажіть: «Нагадайте, будь ласка, як вас звати?» і зафіксуйте ім’я в голові.

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

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

Велика ймовірність, що ви знову зустрінетесь в майбутньому. Можливо, у тому самому місці через кілька тижнів. Саме тоді ви робите крок:

— Привіт, [ім’я]! Як там [те, про ми що говорили минулого разу]?

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

— Які плани наступного [дня тижня]? Підемо на [ще один захід]?

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

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

Якщо співрозмовник виглядає зацікавленим, ви можете сказати:

— Чудово. Як мені зв’язатися, щоб надіслати деталі?

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

Такий підхід може здатися надто повільним. Навіщо бути таким обережним?

Повторю: люди зайняті. Розумні люди дбайливо ставляться до свого часу та особистої інформації.

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

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

Як використовувати нетворкінг

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

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

Хто знає, коли вони перетворяться на дерева і принесуть плоди. Мета полягає в тому, щоб продовжувати саджати дерева і в якийсь момент вони допоможуть вижити.

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

Будьте доброзичливими, уважними та чуйними.

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

Ніколи не принижуйтесь.

Ніколи не дозволяйте собі заздрити чужому успіху.

Одного дня ви пожнете те, що посіяли. Якщо ви поширюєте позитивну енергію, то готуєте себе до щедрого врожаю.

Розділ 3: як заробити репутацію

«Шлях до здобуття хорошої репутації — це прагнути бути тим, ким хочеш здаватися» — Сократ

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

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

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

Але спочатку я розповім, як побудував власну репутацію.

Час історій: як 30-річний викладач побудував репутацію розробника?

У попередній серії «Час історій»: Квінсі почав знайомитись з розробниками, підприємцями та HR-менеджерами в ІТ. Він часто відвідував хакерспейси та інші заходи, але йому ще належало вийти на арену та випробувати свої сили...

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

Одного дня я зіткнувся з особливо неприємною помилкою і не міг зрозуміти, як її виправити. Тож я зробив те, що б зробили багато людей: відклав справу та заліз в інтернет. Саме тоді я побачив його: Startup Weekend EDU.

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

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

Я розповів Стіву про цей захід, а потім вимовив чарівні слова:

— Я буду за кермом.

Я попав в яблучко, адже Стів не мав водійського посвідчення.

Залучивши Стіва, ми доповнили нашу команду кількома розробниками з хакерспейсу Santa Barbara.

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

Нарешті, після місяця підготовки, настав вирішальний день. Ми втиснулися в мою Toyota Corolla 2003 року з облущеним покриттям, увімкнули енергійну музику і вирушили в 5-годинну дорогу.

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

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

Я згадав шкільні роки. У мене не було багато спогадів, оскільки я забрав документи одразу ж після першого року навчання в старшій школі (але мені вдалось скласти GED — так називають тест для отримання свідоцтва про неповну середню освіту — працюючи в Taco Bell, перш ніж зрештою вступити до коледжу. Але це вже інша історія).

Але одна проблема, яку я пам’ятав і яка досі не давала мені спокою: реферати.

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

Вислухавши багато непоганих ідей від інших пасажирів у машині, я втрутився:

— У мене є ідея. Ми повинні написати застосунок, який оформлює використані джерела.

Хтось засміявся та сказав:

— Клас!

Стів ж відповів:

— Це ж хороша назва! Можемо назвати застосунок «Клас-ифікація через "С"».

Ми всі засміялися і відчули себе розумними, а потім почали обговорювати деталі.

Коли ми прибули на місце, там було близько сотні розробників. Це був офіс відкритого типу з низькими кабінками, оточеними дошками для записів.

Я почув шепотіння про одного з розробників:

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

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

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

Я пітнів і розмахував руками, коли розповідав про свою ідею. Я сказав щось на кшталт:

— Посилання на джерела — це відстій. Окей, вони не відстій. Вони необхідні. Їх потрібно додавати до робіт, але працювати з ними — це жах. Давайте напишемо застосунок, який створюватиме за вас список використаних джерел. Хто зі мною?

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

Потім настав час формувати команди. Наша група з Санта-Барбари переглянулася і було очевидно, що ми — команда.

Ми дізнались пароль до Wi-Fi і зайняли найкраще робоче місце: кабінет у куті, де можна було зачинити двері.

Я почав малювати ескізи інтерфейсу та зазначив:

— Нам потрібно щось, що завжди під рукою. Одразу в меню браузера.

— Як плагін для браузера, — запропонував Стів.

— Так. Давайте його і створимо.

Я показав приклади трьох форматів, які можуть знадобитися для есе: MLA, APA та Chicago.

— Ми можемо згенерувати всі три одразу, щоб люди могли просто скопіювати та вставити? — запитав я.

— Можемо зробити навіть краще, — сказав Стів. — Можемо створити для кожного кнопку, яка додаватиме джерело одразу до буфера обміну.

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

Це був мій перший хакатон, тому я не хотів переживати через проживання в хостелі. Я не пошкодував грошей і зняв номер у готелі. У нас було два односпальні ліжка, тож ми по черзі спали на підлозі.

У суботу вранці наші амбіції зросли. Я підійшов до дошки та сказав команді:

— Посилання на вебсайти — це чудово, але багато джерел міститься в книгах або наукових статтях. Для них також потрібно мати можливість генерувати цитування.

Ми знайшли API, який можна використовувати для отримання інформації про цитування на основі ISBN (серійного номера книги), і зліпили скрипт, який міг шукати наукові статті на основі DOI (серійного номера наукової статті), а потім збирати потрібні дані зі сторінки результатів.

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

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

Як викладач, я регулярно виступав перед колегами (іноді перед десятками людей). Але це була інша ситуація.

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

Я так і не зміг заснути, тож відкрив електронну пошту. Команда Startup Weekend надіслала листа, до якого було додано PDF-файл книги. Це була неофіційна збірка класичних праць про стартапи: «4 Steps to the Epiphany» та «The Lean Startup».

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

Була 4-та ранку і я таки не міг заснути, тож просто почав читати. Одна річ, на якій ці книги дійсно наголошують, — це створення чогось, за що будуть платити (що є найвищим визнанням серед клієнтів).

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

У мене з’явилась ідея: потрібно взяти застосунок і почати продавати його людям.

Але був ранок неділі. Де я міг знайти потенційних клієнтів? Ну, наш готель якраз розташовувався неподалік від головного кампусу Стенфордського університету.

Я відвіз свою команду до місця проведення заходу, попрощався і сказав:

— Я повернуся, коли матиму готівку від клієнтів.

Мої колеги посміялися:

— Тільки не запізнись на презентацію, — не знаю, чи вони сприйняли мене серйозно.

Але мені було не до жартів. На моєму ноутбуці працював прототип застосунка. Я проклав маршрут до університету і вирушив виконувати свою місію.

Я навчався у звичайному державному університеті в Оклахомі. Тож я відчув себе зовсім не у своїй тарілці, коли під’їхав до одного з найкращих університетів світу.

Навчання у Стенфорді коштує 50 000 $ на рік. А я заїхав на парковку на машині, яка коштувала вдесятеро менше.

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

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

Я зайшов до головної бібліотеки, проходячи повз стійку охорони та табличку з надписом «Торгівля заборонена».

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

Я вмостився на стільці поруч із ним:

— Псс. Ей! Подобається цитувати?

— Що?

— Цитувати. Ну, писати список використаних джерел.

— Нууу...

— Ну остання сторінка роботи, де треба вказати всі...

— Я знаю, що таке список використаних джерел.

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

Студент підняв брови:

— А він працює з MLA-файлом?

Я стримав емоції і сказав:

— MLA, APA і навіть Chicago. Дивись, — я натиснув кнопку і з’явилися три посилання, кожне з власною кнопкою «скопіювати в буфер обміну».

Студент кивнув, схоже, дещо вражений. Тож я спробував довести справу до кінця.

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

Він замислився.

Я чув, що тиша — найкращий друг продавця. Тож я сидів і дивився йому в очі, що здавалося нестерпно довго.

Нарешті він сказав:

— Круто, я в грі.

— Чудово. З тебе двадцятка.

Хлопець похитнувся:

— Скільки? Це дорого.

Тоді була епоха стартапів, які фінансувалися венчурним капіталом (Uber і Lyft втрачали гроші на кожній поїздці в гонитві за часткою ринку). Тож реакція студента була очікуваною.

Але я швидко зреагував:

— Гаразд, скільки в тебе готівки з собою?

Він глянув у гаманець, а потім сказав:

— П’ять баксів.

Я подивився на зім’яту купюру й знизив плечима:

— Продано.

Він посміхнувся і я надіслав йому електронного листа з інструкціями для встановлення. Потім сказав:

— Ще одне. Давай сфотографуємося разом.

Я перевів телефон у режим селфі. Він почав посміхатися і я додав:

— Ось. Потримай п’ятидоларову купюру.

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

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

Ми завершили презентацію фотографіями зі студентами Стенфорда і які тепер були нашими клієнтами, що заплатили за послугу. Коли я показав зароблені гроші, аудиторія вибухнула оплесками.

Загалом такий досвід був одним із найкращих у моєму житті. Ми посіли друге місце і виграли API-кредит від однієї з компаній, що спонсорувала захід.

На вечірці після заходу я накинувся на піцу, щоб мати більше часу на спілкування з усіма, з ким тільки можна: я кидав заявки на LinkedIn, підписувався в X (Twitter), робив селфі з іншими та активно використовував хештег заходу.

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

Подорож хакатонами

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

Далі стало набагато складніше. У мене не було команди. Я був сам.

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

Іноді люди приєднувалися до моєї команди. Іноді я приєднувався до інших команд.

Я хотів не просто розробляти застосунки, а писати для них код. Мої амбіції часто виходили за межі можливостей.

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

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

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

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

Прорив

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

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

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

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

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

Хакатон «TechCrunch Disrupt». Хакатон «DeveloperWeek». Хакатон «ProgrammableWeb». Хакатон «Salesforce» з призовим фондом у мільйон доларів. Стільки значних подій і стільки знань. Це була та кузня, де викувалися мої навички розробника.

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

Я зміг довести справу до кінця.

Завдяки цим досягненням про мене дізналися.

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

Чому репутація настільки важлива

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

До появи готівки існував борг.

Його записували в книзі обліку або старійшина просто тримав усе в голові.

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

— Джон точно знає, як підкувати коня.

— Джейн — найкраща оповідачка в нашій місцевості.

— Сміливість Джея в бою врятувала нас від загарбників три зими тому.

Помітили, що всі приклади — про те, що хтось у чомусь вправний? А не тому, що хтось є хорошою і приємною людиною.

Звісно, корисно бути спокійною, приземленою людиною. Але це не «Великий Лебовські» і ми не виживемо лише завдяки своєму шарму.

Розробнику легко сказати:

— О так. Я знаю JavaScript як свої п’ять пальців. Я можу створити будь-який застосунок на JavaScript, який працюватиме на будь-якому пристрої.

Або:

— Я завжди виконую замовлення в рамках бюджету і достроково.

Але звідки ви знаєте, що такі твердження не перебільшені?

Зрештою, один хитрий чоловік колись сказав:

«Якщо можеш бути хорошим у чомусь одному, то вчися добре брехати. Тоді будеш хорошим у всьому»

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

Брехати може будь-хто і деякі люди цим користуються.

На початку кар’єри мені довелось виконати неприємне завдання: звільнити викладача, який збрехав про наявність ступеня магістра. Минали роки, а цього ніхто не помічав.

Щороку він вносив неправдиві дані у документи, щоб отримати більшу надбавку до зарплати. Щороку йому це сходило з рук.

Але одного дня мене насторожила маленька невідповідність. Я переглянув його справу, зателефонував до кількох архівів і з’ясував, що він не закінчив навчання.

Коли я його викрив, це було схоже на сцену з мультфільму про Скубі-Ду. «Все б зійшло з рук, якби не ви, кляті діти».

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

Вигода від брехні завжди присутня і привабливо виблискує. Деякі готові піддатися цій спокусі.

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

Тому роботодавці використовують поведінкові питання на співбесіді: щоб спробувати виявити кандидатів, які схильні до обману.

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

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

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

Історія рясніє прикладами працівників, які завдали катастрофічної шкоди роботодавцям заради власної вигоди.

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

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

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

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

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

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

Як побудувати репутацію розробника

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

1. Хакатони
2. Внесок до відкритих проєктів
3. Створення контенту, орієнтованого на розробників
4. Підйом по кар’єрних сходах у компаніях під загальновідомою назвою
5. Створення портфоліо з клієнтами на фрилансі
6. Запуск власного відкритого проєкту, компанії або благодійної організації

Як шукати хакатони та інші змагання для розробників

Хакатони — це найшвидший спосіб одночасно побудувати репутацію, знайомства та навички.

Більшість з них безоплатні та відкриті для широкої публіки. Вам просто потрібно мати час і гроші на поїздку.

Якщо ви живете в місті, де проводиться багато хакатонів — наприклад, у Сан-Франциско, Нью-Йорку, Бенгалуру чи Пекіні — ви можете приїжджати на захід, а потім повертатися додому і спати у власному ліжку.

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

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

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

Найкращий спосіб знайти майбутні заходи — просто загуглити «хакатон [назва міста]» і переглянути різні календарі подій, які з’являться у результатах пошуку. Багато з них проводяться університетами, місцевими роботодавцями або навіть благодійними організаціями, що зосереджуються на освіті.

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

Поцікавтесь, хто спонсорує захід. Зазвичай це компанії, що працюють за моделлю B2D і пропонують API, інструменти для роботи з базами даних або різні SaaS-сервіси.

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

Хакатони часто пропонують призи від конкретних спонсорів. Наприклад, «Найкраще використання API від [спонсора]». Можливо, простіше буде зосередитись на впровадженні конкретних інструментів спонсора у свій проєкт, а не намагатися виграти головний приз — це також можна вказати як перемогу на LinkedIn або в резюме. Усі в плюсі.

Іноді хакатон настільки престижний — або приз настільки значний — що логічно спробувати виграти змагання.

За час відвідування хакатонів я міг виграти грошові призи на суму, що покриває кілька місяців оренди, кілька років коворкінгу та навіть приватну екскурсію будівлею ООН у Нью-Йорку.

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

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

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

Як робити внесок до відкритих проєктів

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

Багато утримувачів проєктів з відкритим кодом — Linux Foundation, Mozilla (Firefox) і, звичайно, freeCodeCamp — мають високі стандарти якості коду.

Перегляньте GitHub, щоб знайти відомі проблеми або запити на нові функції. Потім внесіть зміни в код і відкрийте PR. Якщо ваш PR підтвердять, це стане значною заслугою.

Один із найкращих способів отримати роботу в ІТ-компанії — активно робити внески до її відкритого коду.

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

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

Як створювати контент, орієнтований на розробників

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

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

Узагальнено це можна назвати «контентом». Я не великий шанувальник цього слова, бо воно надає цим роботам відчуття одноразовості. Але саме таку назву ми чуємо найчастіше.

Розробка програмного забезпечення — це неймовірно широка галузь. Існують відеоблоги про життя розробників, навчальні матеріали з підготовки до співбесіди, прямі трансляції з написанням коду на Twitch та подкасти з розробниками, як-от freeCodeCamp Podcast.

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

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

Ви можете обрати конкретну тему і поступово стати визнаним експертом.

Наприклад, деякі розробники спеціалізуються на підручниках для конкретних технологій.

Мій друг Ендрю Браун — колишній технічний директор із Торонто, який склав усі основні іспити з DevOps. Він створює безоплатні курси для підготовки до всіх сертифікацій AWS, Azure та Google Cloud, а також надає послуги з підготовки до іспитів.

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

Як піднятися по кар’єрних сходах, працюючи у великих компаніях

Можливо, ви бачили, що розробника можуть представити як «колишнього співробітника Google» або «колишнього інженера Netflix».

Деякі ІТ-компанії мають настільки суворі процедури найму — і настільки високі стандарти — що отримання роботи в такому місці є великим досягненням.

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

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

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

Як побудувати репутацію, створюючи портфоліо з клієнтами на фрилансі

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

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

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

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

Як створити портфоліо своїх робіт

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

У всіх обмежений час. Ніхто не буде завантажувати ваш код і запускати його на своєму комп’ютері.

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

Тому я рекомендую використовувати інструмент для запису екрана і робити 2-хвилинні відеодемо.

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

Але завжди починайте з демо. Люди хочуть бачити, як щось працює. Вони хочуть щось наочне.

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

Дві хвилини — це ідеальна тривалість, оскільки тоді можна завантажити відео на X (Twitter) і воно автоматично відтворюватиметься, коли люди прокручуватимуть стрічку.

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

Такі демо можна публікувати на YouTube, X (Twitter), GitHub і, звісно, на власному портфоліо.

Для запису таких відео я рекомендую використовувати QuickTime, який вбудовано в MacOS. Якщо ж користуєтеся Windows, вам підійде Game Recorder — застосунок, що входить до стандартного пакету Windows 10.

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

Декілька порад щодо запису: використовуйте якомога більший розмір шрифту та додатковий мікрофон. Будь-який мікрофон — навіть від дешевих навушників — буде кращим за вбудований мікрофон ноутбука.

Приділіть достатньо часу на запис і перезапис, поки не досягнете бажаного результату.

Уміння демонструвати свої проєкти та презентувати код — корисна навичка, що стане в нагоді впродовж усієї кар’єри. Не варто шкодувати часу на підготовку до презентації.

Як запустити власний проєкт з відкритим кодом, компанію або фонд

Бути засновником — це найшвидший, однак і найризикованіший спосіб зарекомендувати себе як розробник.

Це ризиковано, оскільки ви вкладаєте час, гроші, а можливо, навіть особисті стосунки — і все заради невідомого результату.

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

Якщо ви тривалий час будете брати участь у хакатонах, то створите репутацію розробника.

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

Підприємництво не входить у тематику цієї книги. Але якщо вам цікаво, ось невеличка порада:

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

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

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

Як не зруйнувати репутацію

«Потрібно все життя, щоб побудувати хорошу репутацію, а щоб її втратити достатньо однієї хвилини» — Вілл Роджерс (актор, ковбой і один із моїх героїв, коли я зростав в Оклахома-Сіті)

Побудова репутації — це марафон, а не спринт.

Щоб побудувати досить міцну репутацію, яка відкриє потрібні двері, можуть знадобитися роки.

Але — як і в марафоні, де панує жорстка конкуренція — одне спотикання може коштувати дорогоцінного часу, а одне травмування може вивести вас з гри.

Не говоріть дурниць в інтернеті

Раніше люди постійно говорили дурниці. Їхні слова висіли в повітрі кілька хвилин, поки всі хитали головами, а зрештою розвіювалися.

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

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

Ви можете підтвердити існування даних, але не можете спростувати їх відсутність.

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

Можете видалити коментар або обліковий запис, можете навіть спробувати прибрати їх з результатів пошуку. Але, ймовірно, хтось уже зробив резервну копію на Wayback Machine і коли через кілька років одну з цих баз даних зламають, то ці дані, швидше за все, досі будуть там і хтось зможе їх оприлюднити.

Зараз небезпечно бути надто балакучим. Тож спершу подумайте, а потім вже говоріть.

Моя порада, яка, можливо, прозвучить жалюгідно: киньте звичку сперечатися з людьми в мережі.

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

Я ж надаю перевагу такому принципу: «Хвали перед усіма, а критикуй наодинці».

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

Але загалом я намагаюся не критикувати людей. Навіть тих, хто на це заслуговує.

У суперечці всі виглядають погано.

Не варто демонструвати злість, заперечувати аргументи або кидатися на когось, хто лише сказав щось безглузде.

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

Я також намагаюся не скаржитися. Так, мабуть, я міг би розраховувати на краще обслуговування, якби пригрозив написати у X (Twitter) про скасування рейсу.

Однак люди зайняті. Вони не хочуть витрачати свій дорогоцінний час на мої скарги в соцмережах.

Моя порада щодо користування соцмережами: намагайтеся висловлюватися позитивно.

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

Не обіцяйте того, чого не можете виконати

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

Пам’ятаєте про хакатон у Лас-Вегасі, де мені не вдалося вчасно завершити проєкт до його презентації, і нам довелося використовувати слайди замість готового застосунку?

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

Набагато краще бути скромним в оцінці своїх здібностей.

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

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

Опануйте залежності, перш ніж вони зашкодять репутації

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

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

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

Якийсь час існувала тенденція мікродозингу ЛСД та вживання фармацевтичних амфетамінів.

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

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

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

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

Спробуйте розмежувати кар’єру від особистого життя

Ви, напевно, чули такі слова: «Не змішуйте роботу з особистим життям».

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

Можливо, не настільки, як лікарі чи астронавти. Але все ж. Люди будуть дивитися на вас з повагою.

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

Не хизуйтеся своїм багатством.

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

Не зловживайте своєю владою, щоб отримати бажане у стосунках.

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

Ніколи не забувайте, скільки всього ви маєте і скільки всього можете втратити.

Користуйтеся прийомом оповідача

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

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

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

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

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

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

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

Такий прийом працює ще краще, коли думаєте про своє життя в часових періодах («період Taco Bell») чи в переломних моментах («складання вступного іспиту»).

Як це пов’язано з репутацією? Власне, ваша репутація — це підсумок того, ким ви є і того, що значите для людей.

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

Коли описуєте свої дії, ви чіткіше усвідомлюєте їх у власній свідомості. Чому я це зробив? Про що я думав? Можна було зробити краще?

Багато людей руйнують свою репутацію — навіть не усвідомлюючи цього — просто через погані звички.

Протягом багатьох років я вважав, що мушу бути постійно «кумедним». Я шукав будь-яку нагоду, щоб пожартувати над собою. Багато хто розумів, що я роблю, і вважав це кумедним. Але багато хто не розумів і просто вважав мене дурнем.

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

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

«Коли робиш одну й ту саму помилку знову, це вже не помилка. Це — вибір» — Пауло Коельо

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

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

Ваша репутація стане вашою спадщиною

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

Людина, якою ви хочете бути в кінці фільму. Герой, який викликає захоплення у людей. Чому б не почати поводитися так уже зараз?

Ви можете уявити, як це — бути успішним розробником? Створювати системи програмного забезпечення, на які покладаються люди?

Яким буде ваше майбутнє «я»? Як ви будете підходити до ситуацій і вирішувати проблеми? Як ви будете розповідати про свої досягнення і невдачі?

Навіть сама думка про майбутнє може прояснити власні думки та пріоритети.

Я часто згадую «старого Квінсі» з його болями в спині. Йому доводилось кожні 30 хвилин робити перерву й бігти до туалету.

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

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

Я часто думаю про старого Квінсі і аналізую, як я дійшов до того, де знаходжусь сьогодні.

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

Чи можу я заробити хорошу репутацію вже сьогодні, якщо буду розмірковувати як у майбутньому?

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

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

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

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

Саме про це поговоримо далі.

Розділ 4: як заробляти на програмуванні (клієнти на фрилансі та пошук роботи)

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

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

Для початку розповім, як я отримав свою першу роботу.

Час історій: як 30-річний викладач отримав свою першу роботу на посаді розробника?

У попередній серії «Час історій»: Квінсі активно брав участь у хакатонах і навіть виграв кілька з них. Він вибудовував свою репутацію розробника, який «небезпечний» у роботі з JavaScript. Тобто не дуже вправний...

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

Найкраще в житті в Каліфорнії — це погода. Ми жартували, що коли орендуєш надзвичайно дорогу однокімнатну квартиру в передмісті, то платиш не за житло, а довкілля.

Моєю метою було проводити якомога менше часу в тій тісній, столітній щурячій норі, а решту — гуляти містом.

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

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

Що ж, того вечора мала відбутись зустріч спільноти Ruby on Rails у Санта-Барбарі і я ще раніше зареєструвався.

Я не знав багато про Ruby on Rails, але вже реалізував кілька невеликих проєктів на цьому фреймворку. Я був розробником, який переважно працював з JavaScript та Python.

Але я подумав: чому б і ні? Мені потрібно продовжувати працювати над нетворкінгом. До того ж місце проведення було всього за кілька кварталів від мене.

Я зайшов, а там було лише кілька розробників, які сиділи за столом і розмовляли. Швидко стало зрозуміло, що вони працювали разом над місцевим стартапом, підтримуючи велику кодову базу Ruby on Rails. Більшість із них працювали там уже кілька років.

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

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

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

А потім стало зрозуміло, що вони шукають розробників Ruby on Rails.

Я відверто розповів про свій досвід і свої здібності:

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

Але чоловік, на диво, не збентежився:

— Ну, якщо хочеш, приходь на співбесіду. Подивимося, чи підійдеш нашій команді.

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

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

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

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

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

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

Звісно, тепер я розумію, що ставився до цієї можливості неправильно. Але дозвольте закінчити історію.

Коли я домовився про співбесіду, мене попросили надіслати резюме. Я не був упевнений, що робити, тому перерахував професійний досвід з усіх шкіл, в яких я працював протягом років (про роботу в Taco Bell я не згадав).

Звісно, мій досвід роботи жодним чином не стосувався програмування. Але що мені залишалося робити? Вручити чистий аркуш паперу?

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

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

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

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

— Радий був познайомитися, [ім’я]. Буду радий працювати разом.

Спочатку я зустрівся з головним інженером. Ми зайшли в невеликий кабінет і зачинили двері.

Дошка на стіні була вкрита ескізами діаграм на мові UML (Unified Modeling Language — уніфікована мова моделювання). Різнокольорові лінії, нанесені маркером, ілюстрували взаємозв’язки між різними серверами та сервісами.

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

Але він навіть не заговорив про дошку. Він просто сидів, весь час пильно дивлячись на мене.

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

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

Я ковтнув слину, нахилився вперед і зібрав усю свою впевненість:

— Так. Думаю, що зможу.

А він відповів:

— Добре. Чудово. Зачекай у ресторані Pho внизу. Генеральний директор має з’явитися там за хвилину.

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

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

— Гаразд, повертайся нагору і поговори з [головним інженером].

Я пішов нагору. І мені запропонували роботу.

Тепер хочу наголосити: більшість людей отримують свою першу посаду розробника по-іншому.

Мабуть, ви думаєте: «Ого, Квінсі випадково отримав роботу розробника, яку навіть не шукав. Зовсім як Форрест Ґамп! Якби ж нам усім так щастило».

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

Це не була легка робота у великій ІТ-компанії з усіма виплатами, пільгами та корпоративними розвагами. Це була робота підрядника, за яку я отримував приблизно стільки ж, скільки заробляв викладачем.

Але це була робота розробника. Компанія платила мені за те, щоб я писав код.

Тепер я був професійним розробником.

Чого хочуть роботодавці

Перенесемось на десять років уперед. За цей час я побував по обидва боки столу. Мене запрошували на співбесіди HR-менеджери як розробника і я проводив співбесіди з розробниками як HR-менеджер.

Я багато спілкувався з розробниками, які шукали роботу. Деякі з них подали сотні резюме, але отримали лише кілька запрошень на співбесіду.

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

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

Роботодавці понад усе цінують одну річ: передбачуваність.

Як думаєте, кого з цих кандидатів обрав би роботодавець?

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

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

В) Схожий на Б за результатами роботи, також добре ладнає з колегами і дотримується дедлайнів. Але за останні 3 роки змінив роботу три рази.

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

А — це підступний кандидат, якого деякі менеджери-початківці можуть помилково взяти на роботу. Якщо вам цікаво, чому наймати А — така погана ідея, прочитайте статтю «Ми звільнили найкращого співробітника, що стало найкращим рішенням» (англійською мовою).

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

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

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

Зверніть увагу: може знадобитися 6+ місяців, щоб новий розробник досягнув того рівня, коли стане корисним для команди.

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

Більшість роботодавців уникають ризиків

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

У середньому, на пошук розробника йде близько трьох місяців. Роботодавцям спочатку потрібно:

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

Якщо коротко, то багато роботи.

А тепер уявіть, що після цього всього новий працівник каже:

— Привіт, я отримав вигіднішу пропозицію від іншої компанії. Бувайте, друзі.

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

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

Тепер доведеться починати весь процес спочатку і шукати нового кандидата.

Наймати працівників — складно.

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

Роботодавці не хочуть ризикувати, а страждають люди, які шукають роботу

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

• Потрібно підготувати резюме або CV. У процесi цього ви будете приймати рішення, які потім постійно аналізуватимете протягом усього періоду пошуку роботи.
• Доведеться шукати вакансії в інтернеті, вивчати роботодавців і оцінювати, чи вони підійдуть вам.
• Більшість вакансій ведуть до онлайн-форм, де доведеться раз за разом вписувати своє резюме, сподіваючись, що форма не зависне через помилки сервера або JavaScript.
• Після цього потрібно чекати, поки роботодавець все опрацює. Деякі роботодавці отримують стільки запитів, що не встигають переглянути їх вручну (Google отримує 9000 заявок на день). Роботодавці використовують програми для фільтрації заявок, а рекрутери в середньому витрачають 6 секунд на перегляд кожного резюме. Часто вашу заявку ніхто навіть не перегляне.
• Швидше за все, ви не отримаєте відповіді від компанії. У них немає особливого бажання повідомляти, чому вас відхилили (щоб ви не подали позов про дискримінацію). Якщо пощастить, то отримаєте листа з текстом: «Ми вирішили розглянути інших кандидатів».
• Весь час, який ви витрачаєте на подачу заявок — можливо, кілька годин на тиждень — виснажує психічно і, звісно, не оплачується.

Неймовірно. Бачите, який жахливий процес найму для роботодавців, а особливо — для кандидатів.

Але якщо не здастеся, то зрештою отримаєте пропозиції. Пам’ятайте: що посієш, те й пожнеш.

Ось дані про пошук роботи одного з користувачів freeCodeCamp протягом 12 тижнів:

З кожною новою пропозицією початкова ставка ставала дедалі вищою. Звісно, варто зауважити, що мова йде про роботу в Сан-Франциско — одному з найдорожчих міст світу.

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

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

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

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

Протягом усієї книги я ділився техніками, які допоможуть підвищити ймовірність того, що вам «пощастить» отримати роботу.

«Удача — це зустріч готовності з можливістю. Якби ви не були готовими, коли з’явилася можливість, то вам би не "пощастило"» — Опра Вінфрі

Ось чому протягом усієї книги я закликав вас розвивати всі три аспекти одночасно і думати про них з першого дня (ще задовго до пошуку роботи).

Моя історія про те, як я навіть не шукав роботу, але все одно її отримав, може здатися абсурдною. Але таке трапляється частіше, ніж ви можете собі уявити.

Реальність така: навчитися програмувати важко.

Але важливо вміти програмувати.

У кожній галузі — практично в кожній компанії світу — керівники намагаються перекинути роботу на програмне забезпечення.

Тобто потрібно залучати розробників.

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

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

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

Проте, навіть попри звільнення, більшість економістів очікують, що кількість робочих місць для розробників та інших фахівців у галузі програмного забезпечення продовжуватиме зростати. Наприклад, Бюро статистики праці США прогнозує зростання кількості розробників на 15% протягом наступного десятиліття.

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

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

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

Чого очікувати від співбесіди на посаду розробника

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

Типовий перебіг співбесіди може бути таким:

1. Проходження онлайн-тесту на оцінку ваших навичок програмування або перший етап інтерв’ю.
2. Якщо пройдете тест або перший етап, вас чекає технічна співбесіда по телефону або відеодзвінку.
3. Після цього — зустріч в офісі компанії. Зазвичай це кілька співбесід з HR-відділом, менеджерами та розробниками, з якими ви будете працювати.

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

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

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

Їй важливо дізнатися, чи розумієте ви основи програмування та комп’ютерних наук (чи просто відтворюєте завчені розв’язки).

Звісно, практика роботи з алгоритмами та структурами даних дуже допоможе. Але вам також потрібно вміти мислити вголос і пояснювати хід своїх думок під час написання розв’язків.

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

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

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

Намагайтеся зробити співбесіду якомога інтерактивнішою для інтерв’юера. Посміхайтеся та час від часу встановлюйте зоровий контакт. Спробуйте оцінити його мову тіла. Він розслаблений? Киває головою, коли ви пояснюєте певні моменти?

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

Важливо, щоб інтерв’юер сприйняв вас позитивно: щоб він вболівав за вас і міг закрити очі на недоліки або пробачити помилки в коді.

Ви продаєте себе як потенційного працівника. Переконайтеся, що інтерв’юер бачить у вас вигідну інвестицію.

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

На таких поведінкових інтерв’ю вам доведеться переконати інтерв’юера, що у вас сильні комунікативні навички.

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

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

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

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

Варто домовлятися про зарплату на першій роботі?

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

Я докладно писав про те, як домовлятися про зарплату при працевлаштуванні на посаду розробника (англійською мовою).

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

Роботодавець має роботу, яку потрібно виконати. Наскільки сильно він потребує ваших послуг? Які інші варіанти в нього?

А вам треба дохід, щоб вижити. Які інші варіанти у вас? Який запасний план?

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

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

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

Отже, ви опинилися в моїй ситуації — коли компанія раптово пропонує роботу — і стає ніяково обговорювати умови праці.

Зізнаюся чесно: коли мені запропонували роботу, я взагалі нічого не розпитував.

Чи варто було мені тоді обговорити розмір зарплати? Напевно, так.

Чи мав я достатньо аргументів? Скоріше за все, ні. Мій запасний план був досить простим: продовжувати ходити на хакатони, пити чай і писати код в бібліотеці.

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

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

Чи варто користуватися послугами рекрутера під час пошуку роботи?

Так. Якщо ви можете знайти рекрутера, який справді допоможе отримати першу роботу, то чому б не спробувати?

Я вже писав, що рекрутерів недооцінюють (англійською мовою).

Багато роботодавців готові платити рекрутерам, щоб ті приводили їм висококваліфікованих працівників.

Рекрутери так само вмотивовані отримати бонус, як і ви знайти роботу:

1. Оскільки їхня винагорода залежить від вашої стартової зарплати, вони зацікавлені допомогти вам виторгувати якомога вищу оплату.
2. Чим більше кандидатів вони працевлаштовують і чим швидше це зроблять, тим більше зароблять. Тому вони зацікавлені у тому, щоб знайти вам роботу якнайшвидше і перейти до наступного клієнта.
3. Оскільки вони отримують винагороду лише в тому випадку, якщо ви успішно влаштуєтеся на роботу (і пропрацюєте там принаймні 90 днів), то для них важливо, що ви компетентні та добре впишетеся в корпоративну культуру.

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

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

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

Як знайти клієнтів на фрилансі

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

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

Знайти клієнтів на фрилансі значно легше, ніж влаштуватися на роботу розробником. Чому так?

Подумайте про місцевий малий бізнес. Це може бути сімейний ресторан, невеликий магазин, продаж сантехніки або юридична фірма.

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

А тепер інше питання. Скільки з них можуть дозволити собі найняти штатного розробника для створення і підтримки цих систем? Далеко не всі.

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

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

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

Ви також можете зустріти керівників малих бізнесів, яким потрібні ERP- та CRM-системи, системи обліку товарів тощо.

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

Чи варто укладати договір на фрилансі?

Потрібно знайти стандартний шаблон договору, адаптувати його під свої потреби та узгодити з юристом.

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

Малий бізнес навряд чи подасть на вас до суду через кілька тисяч. Але якщо це все-таки трапиться, то ви будете раді, що підписали договір.

Скільки брати за фриланс?

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

Або ж можна поставити фіксовану ціну за проєкт. Наприклад:

— Я розроблю цю систему за 1000 $.

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

Як знати, що клієнт на фрилансі заплатить?

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

Завжди намагайтеся отримати всі гроші ще до повного завершення проєкту. Тоді клієнт не зможе відкладати виплату чи просити виконати додаткову роботу.

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

А це зовсім інше, ніж «А мені взагалі заплатять за всю цю роботу?»

Чи варто використовувати такі платформи, як Upwork або Fiverr?

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

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

Такі платформи створюють ефект «голодних ігор», де перемагає той, хто готовий зробити роботу найдешевше.

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

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

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

Кожен з вас може принести успіх у портфоліо іншого.

Фриланс — це як компанія з одним співробітником, тому на вас чекає багато додаткової роботи

Не варто недооцінювати обсяг додаткової роботи, коли працюєте розробником на фрилансі.

Почнемо з того, що вам доведеться зареєструвати власну юридичну особу.

Найпоширеніший підхід в Україні — це створити ФОП.

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

Коли варто залишити фриланс і почати шукати роботу?

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

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

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

Наскільки ж насиченим і складним буде перший рік у ролі професійного розробника? Зараз розберемося.

Розділ 5: як досягти успіху на першій роботі

«Кораблю безпечно стояти у порту, але його будують не для цього» — Ґрейс Гоппер (математикиня, американська вчена в галузі комп’ютерних наук та контрадмірал ВМС США)

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

Ви навчитеся ефективно працювати в команді з іншими розробниками.

Ви навчитеся орієнтуватися у великих базах коду.

Ви опануєте системи контролю версій, інструменти CI/CD, системи управління проєктами та багато іншого.

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

А найголовніше — ви навчитеся керувати собою.

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

Час історій: як 30-річний викладач досягнув успіху на своїй першій посаді розробника?

У попередній серії «Час історій»: Квінсі вперше отримав посаду розробника в місцевому стартапі. Він став одним із десятка розробників, які підтримували велику і складну кодову базу. І він взагалі не мав уявлення, що йому робити…

Я прокинувся о 4-й ранку і більше не міг заснути. Я намагався, але відчував тривогу і паніку.

Я пропрацював у галузі освіти десять років. Спочатку як репетитор, потім — викладач, а згодом — директор школи.

За кілька годин я мав почати все з нуля; почати все з початку як розробник.

Чи матиме значення весь мій попередній досвід і досягнення в новій кар’єрі?

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

Коли я повернувся додому, дружина вже збиралася на роботу. Вона сказала мені не хвилюватися:

— Я любитиму тебе, навіть якщо тебе звільнять.

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

Тож я сів на підлогу в коридорі й почав писати код на своєму нетбуці.

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

Було дивно йти порожнім офісом до відділу розробників, коли єдиним орієнтиром було світло вивіски «Вихід».

Я поставив свій нетбук на пустий робочий стіл і закінчив писати код.

Через деякий час навколо мене заблимало світло. Прийшов бос. Спочатку він навіть не звернув на мене уваги: він просто сів за стіл і почав швидко стукати по клавішах механічної клавіатури.

— Ларсоне! — нарешті сказав він. — Готовий до першого дня?

Я не був готовий, але хотів здаватись впевненим. Тож сказав фразу з одного з моїх улюблених фільмів «Великий переполох у малому Китаї»:

— Завжди готовий.

— Чудово, — сказав бос. — Тоді підберемо тобі комп’ютер.

— Та в мене вже є, — відповів я, постукавши по своєму нетбуку за двісті доларів. — Тут встановлений Linux Mint і я вже навіть налаштував .emacs, щоб…

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

Я вже хотів сказати, що звик до свого ґаджета і працюю з ним значно швидше, але він не хотів мене слухати:

— Ми всі користуємося однаковими інструментами. Так значно легше працювати разом. Є стандарт — працюй за ним, розумієш.

Тоді я вперше почув фразу «Є стандарт — працюй за ним», але потім вона звучала дуже часто.

Наступні кілька годин я налаштовував свій новий робочий ноутбук, поки інші розробники поступово приходили в офіс.

Близько 10-ї години ранку ми почали зустріч. Усі стали навколо дошки й по черзі розповідали, над чим працюватимуть сьогодні.

Кожен давав короткий звіт про свій прогрес.

Коли дійшла черга до мене, я почав представлятися. Я і так вже нервував, як раптом у кімнату зайшов не хто інший, як Майк — той ультрамарафонець, який організовував заходи «Santa Barbara Startup». Він жував бебі-моркву і вже пробіг того ранку близько 50 кілометрів.

Коли я закінчив, Майк привітав мене й сказав, що бачив мене на своїх заходах. Потім дав короткий 15-секундний звіт про одну з функцій, над якою працював.

Уся зустріч тривала десь 10 хвилин, після чого всі розійшлися по своїх робочих місцях.

Зрештою, мені вдалося запустити кодову базу компанії на новому ноутбуці. Це була програма Ruby on Rails, яка розвивалася протягом п’яти років. Я запустив команду rake stats і побачив мільйони рядків коду. Я злякався. Як я маю розібратись з цим?

Мій сусід, кремезний бородатий програміст, сказав:

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

Я зітхнув, але подумав: «Ну, хоч не мільйон. І це добре».

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

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

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

Це був один із перших уроків про динаміку роботи в команді. Не варто зловживати терпінням колег і засипати їх великою кількістю запитань. Потрібно вчитися розбиратися самостійно.

Але кодова база була величезною і майже не задокументованою, окрім вбудованих коментарів у коді та досить бідної вікі-сторінки команди.

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

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

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

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

— Чому не попросив про допомогу раніше?

Ще однією проблемою було розуміння самої кодової бази («моноліту» та його численних мікросервісів).

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

Я часто «ламав збірку» через те, що додавав код, який, на мою думку, був достатньо протестованим. Але мій код ламав якусь іншу частину системи, про яку я навіть не думав. Це дратувало всю команду, яка не могла додати свій код, доки не було виправлено основну проблему.

Таке траплялося кілька разів на тиждень. Я не був єдиним, хто робив такі помилки. Але відчувалося так, ніби тільки я винен.

Були дні, коли мені здавалося, що я просто не створений бути розробником. Я казав собі: «Кого я обманюю? Я просто прокинувся одного дня і вирішив, що стану розробником».

У голові постійно крутилися слова моїх знайомих розробників, які я чув ще рік тому, коли тільки починав свій шлях у програмуванні:

— Як ти збираєшся змагатися з тими, хто змалку займається програмуванням?

— Потрібно перейти цілу гору знань.

— Чому тобі просто не займатися тим, що добре виходить?

Я почав робити дедалі довші перерви, лише б відірватися від комп’ютера. В офісі була кухня, повна снеків. Я постійно знаходив причину піти перекусити. Будь-що, аби відкласти те відчуття, що я взагалі не розумію, чим займаюсь.

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

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

Але коли я приходив у офіс, всі були доволі привітними й терплячими. Якщо я справді застрягав, я просив допомоги. Потроху рухався вперед, іноді навіть вдавалося виправити одну-дві помилки.

Я почав швидше орієнтуватися в кодовій базі, швидше аналізувати стек викликів, коли код видавав помилки і швидше публікувати нові функції.

Кожного разу, коли бос кликав мене до себе в кабінет, я думав: «Ну все, я був правий. Сьогодні мене звільнять». Але він просто давав мені нові завдання. Хух!

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

Звісно, я чув про «синдром самозванця». Але не усвідомлював, що це саме він. Я думав, що в мене просто «синдром нездари в програмуванні».

Якось я сидів поруч з Ніком і він виглядав досить виснаженим. Я запропонував принести йому воду з кухні.

Коли я повернувся, він відкрив пляшку, зробив ковток і відкинувся на спинку крісла. Він дивився на монітор, повний коду:

— Цей баг, чувак. Вже три тижні намагаюся його пофіксити. Мені здається, що дебажу його навіть уві сні.

— Три тижні, щоб виправити один і той самий баг? — перепитав я. Раніше я ніколи не стикався з подібним.

— Деякі баги складніше виправити. Цей — один з підступних.

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

А тут Нік — дипломований програміст, випускник Каліфорнійського університету, з роками досвіду в цьому проєкті — не міг розв’язати одну-єдину проблему вже три тижні.

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

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

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

Протягом наступних місяців я продовжував розробляти нові функції для кодової бази і працювати з командою. Робота досі була складною і виснажливою, але поступово ставало трохи легше.

Я щодня спілкувався з колегами за обідом. Ми грали в настільні ігри. Одного тижня навіть організували шаховий турнір.

Через кілька раундів я зіграв проти CEO.

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

Але за декілька ходів йому поступово вдалося повернути контроль над грою. Зрештою, він виграв партію.

Коли я запитав, як він знаходить час підтримувати свій рівень у шахах і керувати компанією, він відповів:

— Та я й не підтримую. Я граю лише раз чи два на рік.

Потім він на мить замовк з піднятою рукою, ніби хотів виголосити лекцію, і сказав:

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

Він кивнув і вибачився, бо мусив бігти на зустріч.

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

Якщо постійно робите одну й ту саму задачу — автоматизуйте її

Ще один важливий урок, який я засвоїв: оскільки в мене було найменше досвіду серед команди, мені часто діставалася робота, яку ніхто не хотів робити. Одне з таких завдань — бути «наглядачем збірки».

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

Я відкривав той код, запускав тести й розбирався, що пішло не так. Потім писав людині, яка зламала збірку, що саме їй треба виправити.

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

Не минуло багато часу, як хтось із команди сказав:

— Збірка часто ламається, тож її треба просто автоматизувати.

Я нічого не сказав, але трохи напружився. Це здавалося поганою ідеєю. Як якийсь скрипт може так само добре знаходити помилку, як я — людина-розробник?

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

Було дивне відчуття, коли приходило повідомлення про зламану збірку, а через секунду — вже інше повідомлення з точною помилкою і людиною, яка має це виправити.

Я навіть відчув щось схоже на образу. Я нічого не сказав, але подумки думав: «Це мав бути я. Цей скрипт забрав у мене роботу».

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

Тому що на практиці, якщо завдання можна автоматизувати (тобто розбити на чіткі кроки, які комп’ютер здатен виконувати за вас), то його варто автоматизувати.

У вас знайдеться набагато цікавіша робота, на яку можна витратити свій час.

Уроки від старших

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

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

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

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

Він засміявся і відповів:

— Ну, коли ти тільки прийшов, то й справді був найгіршим у команді. Я б сказав: ти й досі найгірший.

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

А потім він додав:

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

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

Я попрощався з командою і вийшов. Вдихнув вечірнє каліфорнійське повітря.

Я одразу занурився в роботу. Почав шукати замовлення на фрилансі, щоб заробити на прожиття. Знайшов квартиру в районі затоки, одразу через міст від центру технологічного світу — району СоМа в Сан-Франциско.

Тоді я став професійним розробником із роком досвіду за плечима.

Я був готовий мріяти по-новому і рухатися далі.

Я вирушив у світ стартапів.

Уроки з першого року роботи розробником

За перший рік роботи професійним розробником я багато чого зробив добре. Я б поставив собі четвірку з мінусом.

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

Ось кілька порад. Нехай вони допоможуть вам вчитися швидше і без зайвого стресу.

Відкиньте своє его

Багато людей, які приходять в ІТ, починають з самого низу. Часто їх називають «Junior Developer».

Може бути трохи ніяково, коли ви вже доросла людина, а в назві посади написано «junior». Але набравшись терпіння та доклавши зусиль, ви підете далі.

Одна з моїх проблем полягала в тому, що у мене було 10 років професійного досвіду. Я не був новачком. Так, я тільки починав в ІТ, але мав значний досвід у викладанні і навіть управлінні (на останній роботі я керував командою з 30 людей).

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

Мені хотілося кричати: «Я колись був босом — не потрібно мені вказувати», але насправді мені потрібно було вказувати.

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

Такі речі трапляються постійно.

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

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

Не тільки тому, що з вами буде важко співпрацювати. А й тому, що це відволікатиме вас від роботи.

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

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

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

Мабуть, це просто синдром самозванця

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

Це відчуття не зникає. Воно сидить десь в глибині душі і може знову вилізти, щойно візьмешся за щось нове.

— Допоможи розібратися з цією помилкою.

— Ну… Не думаю, що зможу.

— Попрацюємо над новою функцією разом?

— Ну… Якщо інших варіантів немає, то так.

— Виступиш на нашій конференції?

— Я?

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

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

Звісно, якщо дати мені скальпель і попросити провести операцію на серці, я почуватимуся самозванцем. Якоюсь мірою таке відчуття є цілком обґрунтованим, якщо ви дійсно знаєте, що не впораєтеся.

Проблема в тому, що в розробці можна вже багато чого вміти, але все одно відчувати тривогу без вагомої причини.

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

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

Головне — просто прийняти ситуацію: «Мабуть, просто синдром самозванця дається взнаки».

І не зупинятися.

Знайдіть «своїх», але не застрягайте там

Як тільки працевлаштуєтесь розробником вперше, то почнете працювати з іншими розробниками. Ура! Знайшли «своїх».

Ви будете проводити з ними багато часу і згодом можете стати дуже згуртованою командою.

Але не ігноруйте людей, які не є розробниками.

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

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

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

Всьому свій час

Я часто даю таку пораду тим, хто тільки починає програмувати:

— Спочатку опануйте базові навички (JavaScript, SQL, Linux тощо), а вже потім візьміться за щось конкретне.

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

Наприклад, якщо ви вже знаєте PostgreSQL, то буде нескладно вивчити MySQL. Якщо працювали із Node.js, то зможете швидко перейти на Ruby on Rails або Java Spring Boot.

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

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

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

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

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

Епілог: у вас все вийде

Я хочу, щоб ви запам’ятали одне: у вас все вийде.

Ви зможете розібратись з поняттями.

Ви зможете освоїти інструменти.

Ви зможете стати розробником.

А коли хтось ще й заплатить за написаний код, ви офіційно станете професійним розробником.

Навчитися програмувати і знайти першу роботу — непросто, але не відступайте.

Не здавайтесь і обов’язково досягнете успіху. Це лише питання практики.

Створюйте проєкти. Показуйте їх друзям. Створюйте проєкти для друзів.

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

Ніколи не пізно. Попереду ще багато часу.

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

Будьте готовими, що це займе багато часу. Будьте готовими до невизначеності.

Але найголовніше — продовжуйте працювати за клавіатурою. Ходіть на заходи. Діліться своїми перемогами з друзями.

Як колись сказав Лао-цзи:

«Подорож у тисячу миль починається з одного кроку»

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

Не загасіть той вогник, який розпалили.

Почніть писати код для наступного проєкту вже сьогодні.

І завжди пам’ятайте:

У вас все вийде.

Переклад виконали: Борецька Ольга, Маркута Діана, Борецька Анастасія, Борецька Каміла, Перчишин Анастасія, Ліщук Юлія.