Розробники згадали свої перші робочі завдання: врятувати великий масив даних, пройти 450 тест-кейсів і нарізати папірці
Багато хто з українських розробників пам’ятає своє перше завдання на першій роботі в IT, ще й дуже яскраво. Для когось (неочікувано!) першим завданням стало нарізання папірців, хтось взагалі вирішив стати айтішником, зацікавившись завданням 1994 року — налаштувати електронну пошту, а ще когось призначили відповідальним за порятунок великих масивів даних. Журналістка DOU обрала найцікавіші історії.
Перше завдання — незапланований порятунок купи даних
Левко Іванчук, Senior Research Engineer у Honda Research Institute, Japan
У мене в університеті була чудова програма стажування, завдяки якій бакалаври могли провести три навчальні семестри в трьох різних компаніях. Саме так 2013 року я потрапив у канадську компанію Iders, яка розробляла та виготовляла електроніку.
Наприклад, «чорні» коробки для потягів, які комунікували з компанією-оператором через рейки, а не через мобільний зв’язок. Всі процеси на виробництві — від виготовлення чи замовлень компонентів до їхньої збірки на лінії, тестування і відправлення замовнику — контролювалися через власну IMS-систему. В команду, яка розробляла та підтримувала цю систему, я і потрапив.
Це була локальна SaaS, яка виглядала як власна операційна система завдяки Sencha Ext JS. Back-end був написаний на Django. На початку стажування в мене був нульовий бекграунд роботи з фреймворками та мовами, які там використовували. Єдине, що я більш-менш знав із курсів з баз даних, — це SQL, що дуже допомагало.
Першу задачу я отримав після двотижневого ознайомлення з системою, під час якого вивчав Django та PostgreSQL. Річ у тім, що до певних записів у базі даних можна було прикріпити будь-які файли. Наприклад, до запису про надходження партії мікрочипів могли кріпитися тисячі файлів з результатами тестів кожного чипа. Або ж файли тестування продукту перед надходженням замовнику. Таких записів з файлами були тисячі, файлів — ще більше, і їх рідко коли видаляли.
Проблема полягала в тому, що всі ці файли, незалежно від типу запису, дати чи ще чогось, зберігалися в єдину теку на сервері. Так, це не хибодрук. У базі даних зберігався повний шлях до файлу на сервері, але всі файли зберігались в одній теці. Моїм завданням було виправити цю ситуацію — як з майбутніми файлами, так і з уже завантаженими.
На момент створення цієї задачі команда ще не знала, що у файловій системі Ext4 є теоретичний ліміт кількості файлів для зберігання в одній теці. Першого ж дня я визначив, що ми використали близько 90% айнодів. Після цього задача отримала максимальний пріоритет: у будь-який момент могла надійти нова партія компонентів, і зовсім скоро наші користувачі не змогли б завантажувати нові файли. Тоді я відчув величезну відповідальність на своїх плечах.
Завантаживши на свою локальну копію 2% від усіх файлів, почав писати довгий скрипт, який виправляв цю ситуацію. В результаті багато вивчив про файлові системи, операції з файлами через Python та паралелізацію. Також класно розібрався з Django і його обмеженнями: часто доводилось писати більш оптимізовані SQL-запити, ніж генерував фреймворк. Команда дуже цікавилась прогресом, періодично додавали вимоги: потрібно було визначити, які файли є на диску, але не мають запису в БД (чи навпаки), як краще структурувати файли на сервері тощо. Зрештою був фінальний code review та вибір дати міграції. Пам’ятаю, як мене попросили приїхати у вихідні, коли цю міграцію запускали. За це отримав додаткову оплату, але жодних проблем не виникло.
Після цього я простажувався у компанії ще три місяці, а згодом повернувся до навчання в університеті. Наступного літа отримав від компанії пропозицію повернутись вже як штатний співробітник, втім довелося відмовитись: у моїх планах вже було стажування в Японії. Та все ж під час розмови жартівливо запитав у свого колишнього РМ’а, чи все нормально з файлами, на що він відповів: «Завдяки тобі ми уникли великої втрати даних, і тепер здається, ніби у нас ніколи й не було цієї проблеми».
Перше завдання — нарізати купу папірців
Ксенія Фрідман, QA in SQUAD
Виконуючи своє перше завдання, я мала нарізати папірці різного розміру, щоб протестувати кастомний друк на принтері. Мені дали пачку паперу, ножиці, озвучили вимоги до розмірів і пішли на обід. От лишень скільки треба зразків, не сказали. І доки колеги не повернулися, я різала й різала. Перший коментар, який я почула щодо усього цього дійства: «Горщику, не вари».
У результаті я нарізала паперу для усієї команди на кілька місяців наперед, тож можна сміливо сказати, що я завдання виконала. Зате це навчило мене ставити більше запитань і уточнювати очікуваний результат і критерії оцінювання для тих задач, де це неочевидно.
Йшов додому з відчуттям, що вивчив нову мову програмування
Роман Повзик, Data Analyst у Bini Bambini
Одне з моїх перших пам’ятних робочих завдань — налаштувати зв’язок між таблицею у Google Spreadsheet, сховищем даних Google BigQuery та дашбордом у Power BI через Direct Query. Тобто будь-яка зміна у Google-таблиці мала миттю відобразитися на дашбордах без втручання аналітика.
Це було своєрідне дослідження, оскільки тоді команда не знала, чи можливо це зробити. Тимлід радив спробувати використати Apps Script — мову на основі JavaScript.
На той час я уявлення не мав, що у Google-таблицях можна програмувати. Та й не володів мовами, крім Python, тому намагався шукати обхідних шляхів, щоб не вчити JavaScript.
Зрештою, зрозумів, що по-іншому виконати завдання не вийде, і таки почав копати у цьому напрямі. На щастя, нідерландський розробник Wouter Nieuwerth уже пройшов цей шлях до мене і написав код, в який просто потрібно вставити необхідні дані: адресу Google-таблиці, проєкт, датасет і таблицю у BigQuery тощо.
Я не вірив своєму щастю. Кілька разів перевірив роботу і зрозумів, що із завданням таки впорався. Пізніше задокументував цей процес, аби його могли відтворювати у команді.
Того дня я йшов додому з відчуттям, ніби справді вивчив нову мову програмування. І виконав мегаскладне (як здавалося тоді) завдання!
Настроил электронную почту в 1990-х — решил стать айтишником
Андрей Шаповалов, Expert on interoperability
Это был обычный день 1994 года, когда я вот уже несколько месяцев работал налоговым инспектором в одном маленьком районе. Вдруг меня вызывает начальник и говорит: «Ты самый молодой у нас. Вон там в углу компьютер в коробках. Настрой электронную почту».
Варианта отвертеться не было, а от задания я был в шоке. Никакой нужной мне информации не было в радиусе 100 км. Google появился намного позже. После телефонного разговора с коллегами из областного центра стало понятно, что мне нужно ехать к ним за комплектом ПО. Вернулся я обладателем
Корпоративная электронная почта у нас тогда строилась по стандарту FidoNet и фактически являлась простой переброской файлов. Но самое интересное было впереди. У нас был внутренний модем на 2400bps, и он никак не хотел соединять по межгороду. Тогда в поисках знающих людей я пошел в «Укртелеком» и не промахнулся. Знакомый моих родителей рассказал мне об азах связи и передачи данных в телефонных сетях, настройках модема, АТ-командах и помог заменить мою «последнюю милю».
После танцев с бубном и АТ-командами мы впервые подключили модем. Правда, рано я радовался: передать или получить хоть какой-то файл не удалось. Попытки изменить ситуацию результата не дали. Тогда по совету коллег из областной налоговой инспекции я пошел к начальнику с просьбой купить другой внешний модем, менее прихотливый к междугородней связи — U. S. Robotics 14 400 (интересно, он еще жив?).
Пара бессонных ночей, и вот я отправил первое электронное письмо с кратким отчетом: «Ваше распоряжение выполнено, мы подключились к электронной почте».
Сложно ли это было? На тот момент для меня — на грани возможного. Абсолютно все было в новинку, и при этом никто не отменял мою основную работу. Но в результате такого вот задания получился еще один айтишник ;)
Перше завдання стало найдовшим у кар’єрі
Олег Онуфрик, Software Engineer у SoftServe
Коли я отримав одне з моїх перших завдань, то вже два місяці працював інтерном у команді, яка займалася обробкою платежів. На проєкті було понад 1000 інтеграційних тестів. Тим часом наші білди на Jenkins були дуже повільними — один тривав понад годину.
Мені дали завдання: запускати тести паралельно під час білду. При цьому важливо було пришвидшити час білду, бо можливість чекати так довго випадає не завжди. Оскільки я джавіст, то для реалізації цього завдання користувався Maven-плагіном. Спочатку поділив тести за так званими suits відповідно до контексту. Далі почалось найцікавіше — конфігурація плагіну. Все б нічого, але щоб перевірити зміни, доводилось чекати на завершення білду. Локально тести відпрацьовували приблизно за шість годин через VPN та специфіку проєкту.
Це найдовше завдання в моїй кар’єрі: я виконував його близько двох місяців, доки не змінив проєкт. У результаті майже вдалось досягнути бажаного. Після мого переходу техлід доробив завдання, і це допомогло суттєво пришвидшити білди.
Перше завдання зайняло 30 хвилин на двох
Роман Павлюк, член ради директорів ELEKS, CTO Luftronix
Першим моїм робочим завданням стало написання редактора INI-файлів на одній з перших бета-версій першого Delphi. Це було на початку
Довелося мучитися із каруселлю відеослайдів
Хаітов Ельдар, інженер програмного забезпечення
Моє перше завдання стосувалося каруселі слайдів. Я мав зробити слайди з відео. Причому було два теги відео, і в них треба було динамічно змінювати джерело і підставляти у слайд залежно від того, який з них активний, а на який користувач перемикається. І зробити це так, аби не було блимання.
Я тоді дуже намучився, але впорався. Зі складнощів — сервіс не міг віддавати більше як шість відео, а вже з двох починалися певні затримки, які користувач не повинен був бачити. Хоча через те, що напрямок прокручування слайдів користувача був невідомим, без швів таки не обійшлося.
Первое задание — пройти 450 тест-кейсов
Андрей Постников, QA Engineer at Testmatick
Помимо организационных вопросов и знакомства с проектом, мое первое задание было пройти 450 тест-кейсов для полного понимания работы системы. На это ушла не одна неделя. Но результат не заставил себя долго ждать, так как полученные знания очень помогли мне при проверке первых багов, а также тестировании фич.
Для меня это был первый опыт в IT, первый коммерческий опыт, и кому-то это может показаться несложным, но мне поначалу было трудно. Голова кипела от огромного ежедневного потребления новой информации. Первое время я приходил на работу раньше других и уходил позже остальных, работая
В общем и целом, путь мой к сфере IT был тернист и долог, но после того, как я там оказался, легче не стало... По крайней мере поначалу. Со временем всё, конечно, устаканилось и обрело стабильный характер. Словом, дерзайте!
А ви пам’ятаєте ваше перше завдання? Діліться своїми історіями в коментарях!
