Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Чому ти не розвиваєшся як програміст: «Чотири вершники деградації» і як їх подолати

«Кожен повинен бути самомотивуючою біологічною машиною
Євген Черняк, бізнесмен, ведучий YouTube-каналу Big Money

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

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

Так, бути програмістом — складно. Тут не можна просто взяти й навчитися писати код, пройти базові курси, подивитись кілька відео на YouTube, прочитати кілька книжок — і на цьому зупинитися. Бути програмістом — це як брати участь у марафоні, треба постійно підтримувати «форму», вчитися і витягувати себе із зони комфорту. В іншому разі ти ризикуєш ̶з̶і̶й̶т̶и̶ ̶з̶ ̶р̶о̶з̶у̶м̶у̶ зійти з дистанції на самому початку.

Ілюстрація Аліни Самолюк

Причини стагнації

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

Однотипні проєкти, проєкти з низькою якістю коду

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

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

Робота на фрилансі без команди

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

До того як прийти в OpenGeeksLab, я півтора року був фрилансером. Працював на проєкті, власником якого був житель Аляски. Золотий клієнт. Завжди вчасно розраховувався і ніколи не сперечався за відпрацьовані мною години. Проєкт був на популярному в ті часи MEAN-стеку із використанням бібліотечки Fabric.js. І якщо перший рік я ще пиляв фічі, грався з прототипним наслідуванням для побудови кастомних об’єктів у Fabric, розбирався, як під капотом працює AngularJS digest тощо, то останні пів року просто сидів і вигадував, що б то поліпшити.

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

Відсутність мотивації

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

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

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

Професійне вигорання

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

Що робити в такій ситуації? Не панікувати. І читати далі.

Поради щодо розвитку

Ф̶а̶к̶а̶п̶и̶ ̶с̶т̶а̶ю̶т̶ь̶с̶я̶. У житті буває по-різному. Але людині під силу все змінити й вийти на якісно новий рівень.

Йди в ІТ, якщо справді любиш технології та хочеш вчитися

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

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

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

Ініціюй ротацію чи зміни компанію

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

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

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

Візьми тайм-аут

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

Що робити, щоб видихнути? Тут у всіх свої способи. Повалятися тиждень тюленем в all-inclusive чи підкорити нову гірську вершину. Зробити у вихідні генеральне прибирання чи не вилазити з піжами, дивлячись Netflix. Влаштувати вдома вечірку в стилі хюґе чи зірватися на концерт улюбленого гурту в інше місто. Як каже гугл, відповідей — безліч.

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

Зміни посаду

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

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

Я за освітою системний аналітик. І це допомогло мені стати програмістом, який вміє ставити гарні питання.

Розважайся

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

Розвивайся

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

Я у вільний час колупаю сервер, граюся з технологіями. Ще, наприклад, пройшов курс з DevOps на Udemy. Він був про те, як працює Docker і оркестровка. На мітингу поділився здобутими знаннями з колегами. Наразі в нашій компанії всі проєкти йдуть по CI/CD pipelines. Такий рутинний процес, як деплой, автоматизований на всіх проєктах, і його може зробити будь-який розробник.

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

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

Комунікуй

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

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

Обирай сильніших за себе

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

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

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

Спробуй менторство

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

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

Проявляй ініціативу грамотно

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

Я пішов в OpenGeeksLab фронтенд-розробником. Писав на Angular і сів на великий проєкт. Якось колишній CTO компанії зібрав усіх нас на тімбілдинг і розповів про мікросервіси. Мене це зацікавило. За кілька тижнів зайшов проєкт з мікросервісами. Мені довелося дуже швидко опановувати, що це таке, як взаємодіють сервіси, як працює AWS, що таке оркестровка і Docker swarn. Після того, як з усім розібрався, справа пішла, і я потихеньку перекочував у серверну інфраструктуру.

Я довгий час підкидав ідеї щодо оптимізації процесів розробки, працював з будь-яким стеком, який траплявся. Зайти на PHP? Ок. Фронт на jQuery? Ок. З цього моменту розвиватися стало простіше. Наприклад, багато фронтенд-розробників знають бібліотеку Redux Saga, але мало хто знає, що є Saga Design Pattern, а ще менше — що його можна застосовувати на бекенді.

Висновок

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

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

LinkedIn

Похожие статьи

24 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
на популярному в ті часи MEAN-стеку

я думав, він і сьогодні популярний. А що популярне тепер?

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

Якщо ти йдеш в ІТ лише заради грошей, краще не йди.

що означає заради грошей?, варіанти відповіді

1. 0% — люблю програмувати, 100 — гроші
2. 30% — люблю програмувати, 70 — гроші
3. 50% — люблю програмувати, 50 — гроші
4. 70% — люблю програмувати, 30 — гроші
5. 100% — люблю програмувати, 0 — гроші

Який з варіантів заради грошей? Часто чую це від людей які закінчили профільний ВУЗ
Є моменти коли любишь робити, діякі ні, такі як працювати з технологією яку вже забили років так 10 назад, але ти повинен любити це лайно тому що це частина програмування! (тут думаю

Ініціюй ротацію чи зміни компанію

підійде)
Але наприклад алгоритми мені цікаві, розбириратися в них! Також я люблю і гроші!

Агонь! Стаття.
Видно, що автор пройшов усі кола пекла і добре їх проаналізував і поділився як добрий дідусь порадою.
Браво, автору. Давно такої статті не читав.

Я у вільний час колупаю сервер, граюся з технологіями. Ще, наприклад, пройшов курс з DevOps на Udemy. Він був про те, як працює Docker і оркестровка. На мітингу поділився здобутими знаннями з колегами. Наразі в нашій компанії всі проєкти йдуть по CI/CD pipelines.

Если CTO который учит такому людей в компании, возникает вопрос, по каким критериям набирали тех лидов... разве что это случилось очень давно.

Курсы на udemy, очень хорошо помогают научиться объяснять вещи простым языком. И у нас в компании на данный момент разработчик любого уровня может настроить ci/cd процессы и облачную инфраструктуру под свой проект, по крайней мере на раннем этапе проекта. А некоторым, кто по старинке все поднимал стейтфул инстансы и все настраивал ручками приглянулась перспектива автоматизации и переноса все на стейтлес контейнеры.

у нас в компании на данный момент разработчик любого уровня может настроить ci/cd процессы и облачную инфраструктуру под свой проект, по крайней мере на раннем этапе проекта

Думаю, всё же имеется в виду что-то вроде «надо ещё одна лямбда — добавили лямбду» или «подкрутил готовый CI/CD темплейт» — вряд ли все Ваши разработчики (тем более, любого уровня) могут всё с нуля, т.к. это могут даже не все DevOps’ы, т.к. банально в разных облаках своя специфика. «Настроить облачную инфраструктуру под свой проект на раннем этапе» для «разработчика любого уровня» — это всё же громковато сказано и значит немного другое :)

Перестал читать после этой цитаты:

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

Как фрилансеру без команды с десятилетним стажем, мне смешно это слышать. Именно благодаря фрилансу я смог расширить свои горизонты в современных практиках и технологиях. Одному клиенту надо переписать парсер XML с Питона на С++. У другого в коробке из-под обуви камера с RSA SecurID брелком и надо распознать цифры с LCD дисплея. Третьему клиенту надо тестировать трейдерские стратегии на исторических данных для торговли на бирже. Не то, чтобы каждый программист уже рождался со знанием быстрых библиотек для парсинга XML или пониманием структуры трейдерских данных, но это то, что можно приобрести прямо во время работы над проектом.

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

P.S. В целом, я согласен с тем, что живое общение обогащает, но больше в контексте жизни вообще, а не знания технологий. Ну и на фриланс вообще-то лучше переходить, побыв подмастерьем в хороших продуктовых компаниях. Но само нахождение на фрилансе не препятствует ни изучению новых технологий, ни общению.

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

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

Меня даже больше интересует, почему конкретный кейс, когда человек работал на одного заказчика, и даже в условиях тонны свободного времени (по описанию) не брал других заказов, так легко выдаётся за типичный фрилансерский.

был забанен на апворке 😐 а на том же angel в основном нужен фул тайм

Так AngelList — это же не фриланс).

Как фрилансеру без команды с десятилетним стажем, мне смешно это слышать.

Там же javascript, уже от одного названия хочется выйти в окно %)

Я не особо любитель javascript, но нам сейчас можно пилить проекты в очень разных областях: мобайл, веб, бекенд, декстоп, есть webgl.

Для особо упоротых есть даже Tensorflow.js (я выкатил глаза в 5 копеек когда увидел это чудо)

Как бывшему (в данный момент) фрилансеру мне читать вот это смешно. Парсеры и все прочее — это прекрасно. Но крупный проект с кучей взаимодействий фрилансер в одно лицо не потянет. Да, может быть частью команды на проекте, но в реально крупные и критические проекты никто фрилансера не возьмет.
Да, развитие есть. Но оно в основном «по верхам». Т.е. поработал пол-годика на проекте, поизучал технологии и все. Новый проект, новый фреймворк. От нуля разбираться легко и имеет место быть полная (или частичная) иллюзия постоянного роста. Это когда технарь с горящими глазами рассказывает филологу про возможность влияния языка на мировоззрение, а тот со скукой вспоминает первый курс и гипотезу Сепира — Ворфа.
У фрилансера хороший кругозор. В этом его сила. У человека, который 10 лет копает одну тему свои сильные стороны. И он при решении задачи в профессиональной области может предложить решения, до которого фрилансер просто не дойдет.

Как и практически в любой области нету «серебряной пули».

Как бывшему (в данный момент) фрилансеру мне читать вот это смешно.

Мне как практикующему фрилансеру это читать вдвойне смешнее.
У приличного фрилансера часть есть основной удаленный проект и по-желание берется что-то на парт-тайм на повышенный рейт.

Да, может быть частью команды на проекте, но в реально крупные и критические проекты никто фрилансера не возьмет.

А что такое критический проект?
А много где в нашем аутсорсе что-то доверяют критичное?

Да, развитие есть. Но оно в основном «по верхам». Т.е. поработал пол-годика на проекте, поизучал технологии и все.

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

Практически на каждом проекте на фрилансе есть время на ресерч и на рефакторинг если договорится.

От нуля разбираться легко и имеет место быть полная (или частичная) иллюзия постоянного роста.

Legacy проектов тоже хватает даже в мобайле.

У человека, который 10 лет копает одну тему свои сильные стороны.

Что можно такое копать 10 лет? Разве что 10 лет прокрастинировать.

А что такое критический проект?

Например, управление технологическими процессами на заводе. Или электростанции.
Проектирование зданий.
Т.е. те, ошибка в которых — жизни людей.

А много где в нашем аутсорсе что-то доверяют критичное?

Фриланс и хорош тем, что можно не ориентироваться на наши любимые галеры.

Практически на каждом проекте на фрилансе есть время на ресерч и на рефакторинг если договрится.

Не путайте ресерч в месяц, хотя кто такое даст, когда «херак-херак и в продакшн» и ресерч в пол-года.

Legacy проектов тоже хватает даже в мобайле.

Области и 10 лет нету, какое legacy? Вы явно не дорабатывали чей-то код на каком-нить Фортране.

Что можно такое копать 10 лет? Разве что 10 лет прокрастинировать.

А вот это то, что я имею ввиду под фразой «нахвататься по верхам». Кривая опыта — коварная штука. В первый год прогресс просто сумасшедший. Зато потом методы накопления знания это не копипаста с SO и гугление. На 5й год приходит осознание, что уже ты — гуру и к тебе ходят за советами. И тогда опыт приобретается очень медленно и очень мучительно и вот тогда для тебя источник нового — чтение стандартов по отрасли и неформальное общение со всякими академиками. Ну и собственные ошибки. И потом знания этих самых людей воплощаются в эти самые стандарты. Которые прочитать — легко, понять — сложно, а написать — отдельный вид искусства.

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

Пример с парсером был упомянут только для выражения масштаба задач ) Но в целом мне лично повезло заниматься высокотехнологичными проектами, когда еще не было хайпа вокруг ML. При этом несколько проектов я бы назвал критичными, поскольку от них зависела дальнейшая судьба клиента — получение финансирования следующего раунда, создание proof-of-concept технологии, которая убедила начальство существенно расширить отдел R&D, и даже оформленный патент на технологию, о которой клиент до нашего сотрудничества даже и не думал. Однажды было банкротство клиента и долг под залог имущества, но это к вопросу о том, что не все R&D приводят к успеху.

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

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

начальство незадоволене

Ой-вей... Ну то хай зав’язують займатися фігньою та мікроменеджити, і життя налагодиться. Нє?
Відслідковування таймінгів поодиноких тікетів, особливо в ситуації, коли скоупи спринтів на довгому проміжку часу стабільно закриваються без залишків та відставань — то чисте БДСМ.

P.S. Рідкий випадок, що «тойсамийтікет» міг виявитися хотфіксом під продакшен я не розглядаю, бо то більша рідкість, аніж потуги менеджменту сидіть рахувать хвилиночки. Нагадують диваків, які біжуть трейдити по PA паттернам на 5-хвилинних таймфреймах ))

тиждень з’ясовував на доу, де програмістам краще живеться — у Флориді, Малайзії чи Австралії, а потім

так нікуди й не поїхав

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

npm почав приймати бібліотеки на хаскелі?

Подписаться на комментарии