Я став лідом за 3 місяці
Цей пост мав би писати Юра, адже це він став лідом за 3 місяці своєї роботи на проекті, та й в компанії в цілому. Але він занадто сором'язливий, тому це зроблю я! Адже я зайшла на цей проект місяць тому і вже помітила, що Юра робить інакше, і чому швидко стає незамінним на проекті.
Вникає у всі процеси
Юра відразу сує свого носа у всі процеси на проекті. Він прийшов як frontend розробник, а вже став fullstack. Цим самим, він швидко вникає в проект, його архітектуру і, якщо що, відразу може посапортити багатьох членів команди, або навіть замінити їх.
Постійно моніторить, як можна покращити процеси та розробку
Як тільки Юра зайшов на проект, я вже чула від нього пропозиції, що можна покращити в плануванні, що потрібно порефакторити в коді, що можна замінити або взагалі видалити. Він завжди аргументує свою думку, а не просто "бо я так сказав, я знаю краще". І він це робить абсолютно ненав'язливо! А так, як він постійно багато читає і дізнається все першим, то це дійсно гідні поради.
СЛУХАЄ
Юра дійсно вміє слухати і швидко розуміти, що від нього хочуть. Він постійно задає правильні питання, тим самим дає зрозуміти замовнику, що він зацікавлений в якісному результаті. АЛЕ, якщо це відверто якась фігня, він завжди про це скаже і, знову ж, аргументує, чому те чи інше не варто робити, або взагалі неможливо.
Налагоджує теплі відносини з замовником (а не зі мною😭)
Я була вражена, коли побачила, як Юра спілкується з замовником. Він не заходить на дзвінок і відразу в лоб, ось я зробив те і те, від тебе мені треба ті і ті вимоги. Ні. Юра розпитає, як у нього справи, як його подорожі по бізнесу, трішки розповість про себе, про ситуацію в країні (а про це важливо говорити!) і тд. А потім вже на такій ноті говорить про проект і що потрібно зробити.
Сподіваюсь цей пост був корисним для вас і ви щось зможете винести для себе 💛
А ще можете привітати Юру з таким швидким підвищенням 🥳
#experience
Цей пост мав би писати Юра, адже це він став лідом за 3 місяці своєї роботи на проекті, та й в компанії в цілому. Але він занадто сором'язливий, тому це зроблю я! Адже я зайшла на цей проект місяць тому і вже помітила, що Юра робить інакше, і чому швидко стає незамінним на проекті.
Вникає у всі процеси
Юра відразу сує свого носа у всі процеси на проекті. Він прийшов як frontend розробник, а вже став fullstack. Цим самим, він швидко вникає в проект, його архітектуру і, якщо що, відразу може посапортити багатьох членів команди, або навіть замінити їх.
Постійно моніторить, як можна покращити процеси та розробку
Як тільки Юра зайшов на проект, я вже чула від нього пропозиції, що можна покращити в плануванні, що потрібно порефакторити в коді, що можна замінити або взагалі видалити. Він завжди аргументує свою думку, а не просто "бо я так сказав, я знаю краще". І він це робить абсолютно ненав'язливо! А так, як він постійно багато читає і дізнається все першим, то це дійсно гідні поради.
СЛУХАЄ
Юра дійсно вміє слухати і швидко розуміти, що від нього хочуть. Він постійно задає правильні питання, тим самим дає зрозуміти замовнику, що він зацікавлений в якісному результаті. АЛЕ, якщо це відверто якась фігня, він завжди про це скаже і, знову ж, аргументує, чому те чи інше не варто робити, або взагалі неможливо.
Налагоджує теплі відносини з замовником (а не зі мною😭)
Я була вражена, коли побачила, як Юра спілкується з замовником. Він не заходить на дзвінок і відразу в лоб, ось я зробив те і те, від тебе мені треба ті і ті вимоги. Ні. Юра розпитає, як у нього справи, як його подорожі по бізнесу, трішки розповість про себе, про ситуацію в країні (а про це важливо говорити!) і тд. А потім вже на такій ноті говорить про проект і що потрібно зробити.
Сподіваюсь цей пост був корисним для вас і ви щось зможете винести для себе 💛
А ще можете привітати Юру з таким швидким підвищенням 🥳
#experience
🔥59👍24❤9🎉8🥰2👏1👌1
Package Manager 📦
Якщо ви працюєте з Javascript або Node.js то, ймовірно, знаєте про npm. А які є альтернативи npm та які в них переваги/недоліки?
npm (Node Package Manager) - це менеджер пакетів за замовчуванням для Node.js, який ви отримуєте з інсталяцією Node.js. За допомогою цього інструменту ви можете встановлювати пакети, а також керувати ними та публікувати їх в npm-реєстр. В npm дуже широка спільнота, що теж дуже важливо. Також npm має кешування, що пришвидшує встановлення пакетів. А у файлі package-lock.json він зберігає інформацію, необхідну для правильної інсталяції та роботи пакетів.
yarn - це менеджер пакетів, створений Facebook і випущений у 2016 році. Yarn було створено для вирішення деяких проблем та обмежень npm, наприклад, повільне встановлення пакетів. Для цього yarn інсталює їх паралельно. Замість package-lock.json було введено yarn.lock. Ще yarn надає функціонал workspaces, за допомогою якого можна керувати кількома проектами одночасно, якщо у вас, наприклад, monorepo. А щоб зекономити трохи памʼяті, yarn використовує плоске дерево залежностей, завдяки чому уникає дублювання пакетів.
pnpm (скорочення від "performant npm") - менеджер пакетів, випущений у 2016 році. Як і в yarn, його мета усунути деякі обмеження npm, зокрема щодо швидкості встановлення та використання дискового простору. pnpm використовує унікальний підхід до керування залежностями, який може призвести до значного покращення продуктивності та економії памʼяті. Для цього він використовує спільне сховище в якому тримає пакети, і вони, відповідно не дублюються у кожному вашому проекті. Такий підхід дозволяє навіть встановлювати пакети без зʼєднання з мережею Інтернет.
Який з них використовувати?
Всі вони добре виконують свою роботу, тому можете вибирати будь-який і не прогадаєте. Від себе додам, що більшість попередніх проектів, на яких я працював, використовували yarn. Але зараз для мене найпривабливішою опцією виглядає pnpm і для наступного проекту я хочу спробувати використати саме його.
#experience
Якщо ви працюєте з Javascript або Node.js то, ймовірно, знаєте про npm. А які є альтернативи npm та які в них переваги/недоліки?
npm (Node Package Manager) - це менеджер пакетів за замовчуванням для Node.js, який ви отримуєте з інсталяцією Node.js. За допомогою цього інструменту ви можете встановлювати пакети, а також керувати ними та публікувати їх в npm-реєстр. В npm дуже широка спільнота, що теж дуже важливо. Також npm має кешування, що пришвидшує встановлення пакетів. А у файлі package-lock.json він зберігає інформацію, необхідну для правильної інсталяції та роботи пакетів.
yarn - це менеджер пакетів, створений Facebook і випущений у 2016 році. Yarn було створено для вирішення деяких проблем та обмежень npm, наприклад, повільне встановлення пакетів. Для цього yarn інсталює їх паралельно. Замість package-lock.json було введено yarn.lock. Ще yarn надає функціонал workspaces, за допомогою якого можна керувати кількома проектами одночасно, якщо у вас, наприклад, monorepo. А щоб зекономити трохи памʼяті, yarn використовує плоске дерево залежностей, завдяки чому уникає дублювання пакетів.
pnpm (скорочення від "performant npm") - менеджер пакетів, випущений у 2016 році. Як і в yarn, його мета усунути деякі обмеження npm, зокрема щодо швидкості встановлення та використання дискового простору. pnpm використовує унікальний підхід до керування залежностями, який може призвести до значного покращення продуктивності та економії памʼяті. Для цього він використовує спільне сховище в якому тримає пакети, і вони, відповідно не дублюються у кожному вашому проекті. Такий підхід дозволяє навіть встановлювати пакети без зʼєднання з мережею Інтернет.
Який з них використовувати?
Всі вони добре виконують свою роботу, тому можете вибирати будь-який і не прогадаєте. Від себе додам, що більшість попередніх проектів, на яких я працював, використовували yarn. Але зараз для мене найпривабливішою опцією виглядає pnpm і для наступного проекту я хочу спробувати використати саме його.
#experience
👍22🔥3🤔3❤2
Як швидко перейти з однієї технології на іншу? 🤯
Передісторія: на початку травня замовник вирішив, що нам терміново потрібен мобільний застосунок. Разом з командою ми обрали Flutter. Найцікавіше те, що він вирішив, що його повинні писати я та Юра, хоча я ніколи не писала на мобілку, і про це йому неодноразово говорила. Тому я повинна була швидко в ньому розібратись та почати допомагати Юрі в розробці. Проблема ще була в тому, що Flutter використовує мову програмування Dart, тобто я повинна була спочатку вивчити нову мову, а потім вже новий фреймворк.
В мене було зовсім мало часу і ось їм план дій:
1. Знайти статті, які допоможуть розібратись з новою технологією на базі тих, які ти вже знаєш. В моєму випадку, я почала читати статті, в яких пояснюється в чому схожість та відмінність JavaScript і Dart, Web-розробка і Flutter-розробка тощо. Ці статті швидко допомогли мені збагнути, які моменти я знаю зі свого досвіду, а які принципи для мене зовсім нові, і я повинна звернути на них увагу.
2. Почати писати невеличкий застосунок по гайду. Я думаю, вже всі давно зрозуміли, що нові знання по програмуванню потрібно відразу практикувати, бо толку буде мало. Так і в моєму випадку, я найшла в документації покрокову інструкцію розробки маленького застосунку, в якому, в принципі, були всі базові моменти, які я мала дізнатись про Flutter. Звичайно, перші кроки я повністю копіювала і вже потім розбиралась, що вони роблять. Далі поступово пробувала не дивитись на реалізацію, а писати невеличкі шматки коду самостійно.
3. Брати таски. Після того я відразу почала працювати над функціоналом, який не є початковим у нашому застосунку, тому я мала час повільно, але впевнено його робити. Було складно, вилазило багато моментів, про які я взагалі не здогадувалась, кожен новий елемент я гуглила, 100500 раз розказувала, що більше ніколи не проміняю JavaScript, але не дивлячись на це, завдяки практиці, я швидко вчилась.
Вкінці я отримала крутий досвід та результат - Mobile UI is absolutely epic! I can't believe you've only been working with Flutter for a few weeks. Both you and Yurii are incredibly talented. We always appreciate your help!!
#experience
Передісторія: на початку травня замовник вирішив, що нам терміново потрібен мобільний застосунок. Разом з командою ми обрали Flutter. Найцікавіше те, що він вирішив, що його повинні писати я та Юра, хоча я ніколи не писала на мобілку, і про це йому неодноразово говорила. Тому я повинна була швидко в ньому розібратись та почати допомагати Юрі в розробці. Проблема ще була в тому, що Flutter використовує мову програмування Dart, тобто я повинна була спочатку вивчити нову мову, а потім вже новий фреймворк.
В мене було зовсім мало часу і ось їм план дій:
1. Знайти статті, які допоможуть розібратись з новою технологією на базі тих, які ти вже знаєш. В моєму випадку, я почала читати статті, в яких пояснюється в чому схожість та відмінність JavaScript і Dart, Web-розробка і Flutter-розробка тощо. Ці статті швидко допомогли мені збагнути, які моменти я знаю зі свого досвіду, а які принципи для мене зовсім нові, і я повинна звернути на них увагу.
2. Почати писати невеличкий застосунок по гайду. Я думаю, вже всі давно зрозуміли, що нові знання по програмуванню потрібно відразу практикувати, бо толку буде мало. Так і в моєму випадку, я найшла в документації покрокову інструкцію розробки маленького застосунку, в якому, в принципі, були всі базові моменти, які я мала дізнатись про Flutter. Звичайно, перші кроки я повністю копіювала і вже потім розбиралась, що вони роблять. Далі поступово пробувала не дивитись на реалізацію, а писати невеличкі шматки коду самостійно.
3. Брати таски. Після того я відразу почала працювати над функціоналом, який не є початковим у нашому застосунку, тому я мала час повільно, але впевнено його робити. Було складно, вилазило багато моментів, про які я взагалі не здогадувалась, кожен новий елемент я гуглила, 100500 раз розказувала, що більше ніколи не проміняю JavaScript, але не дивлячись на це, завдяки практиці, я швидко вчилась.
Вкінці я отримала крутий досвід та результат - Mobile UI is absolutely epic! I can't believe you've only been working with Flutter for a few weeks. Both you and Yurii are incredibly talented. We always appreciate your help!!
#experience
👍28🔥9❤7😱2👏1
Частина 1. Наша перша технічна співбесіда.
… в якості інтерв’юерів 🫣
Так, ми раніше мали невеликий досвід у проведенні співбесід, але цього разу ми були повністю відповідальні за неї, повинні були провести її з початку та до кінця, самі продумати хід діалогу та питання.
На нашому проекті був потрібен розробник. Як ми раніше розповідали, зараз ми сфокусовані на розробці мобільного застосунку, тому потрібна була людина, яка підтримувала б веб. Нам підібрали кандидатів і від нас вимагалось тільки обрати найкращого.
Якщо чесно, спочатку ми думали, що це буде дуже легко, це ж не нас співбесідують, а ми. АЛЕ коли ми сіли скласти питання або хоча б якийсь хід розмови, ми розгубились. Що питати? Навіщо таке питати? А може це взагалі не потрібно дізнаватись?
І тоді ми почали згадувати наші співбесіди як кандидатів. Їх була достатня кількість, але лише від однієї у нас були дійсно тільки приємні спогади. Це була співбесіда на нашу попередню компанію і проводив її наш колишній (хах) тім лід. Він не питав по списку примітивні питання з першого сайту "що питати розробника". Це була розмова двох досвідчених програмістів. Він розповідав про себе, що він використовував, по ходу питав про наше відношення до тієї чи іншої методики. Він хотів почути не завчений матеріал, а саме нашу думку, що нам подобається і що ми б не хотіли використовувати в роботі. Питав про наш досвід, технології, наше відношення до цих технологій, чому ми обрали саме їх. Звісно були питання про патерни, алгоритми і тд, але ж знову, це була не теорія, а саме чи мали ми з ними досвід, і що реалізовували завдяки ним.
Після закінчення такої співбесіди, ти не виходиш як вижатий лимон, ти виходиш з новими поглядами на старі речі, та тільки з приємними емоціями і відчуттям якісно проведеного часу.
І нам максимально хотілось провести саме таку співбесіду, а не суху і чисто технічну.
Дуже багато тексту і не хочеться вас перевантажувати, тому далі буде…
#experience #interview
… в якості інтерв’юерів 🫣
Так, ми раніше мали невеликий досвід у проведенні співбесід, але цього разу ми були повністю відповідальні за неї, повинні були провести її з початку та до кінця, самі продумати хід діалогу та питання.
На нашому проекті був потрібен розробник. Як ми раніше розповідали, зараз ми сфокусовані на розробці мобільного застосунку, тому потрібна була людина, яка підтримувала б веб. Нам підібрали кандидатів і від нас вимагалось тільки обрати найкращого.
Якщо чесно, спочатку ми думали, що це буде дуже легко, це ж не нас співбесідують, а ми. АЛЕ коли ми сіли скласти питання або хоча б якийсь хід розмови, ми розгубились. Що питати? Навіщо таке питати? А може це взагалі не потрібно дізнаватись?
І тоді ми почали згадувати наші співбесіди як кандидатів. Їх була достатня кількість, але лише від однієї у нас були дійсно тільки приємні спогади. Це була співбесіда на нашу попередню компанію і проводив її наш колишній (хах) тім лід. Він не питав по списку примітивні питання з першого сайту "що питати розробника". Це була розмова двох досвідчених програмістів. Він розповідав про себе, що він використовував, по ходу питав про наше відношення до тієї чи іншої методики. Він хотів почути не завчений матеріал, а саме нашу думку, що нам подобається і що ми б не хотіли використовувати в роботі. Питав про наш досвід, технології, наше відношення до цих технологій, чому ми обрали саме їх. Звісно були питання про патерни, алгоритми і тд, але ж знову, це була не теорія, а саме чи мали ми з ними досвід, і що реалізовували завдяки ним.
Після закінчення такої співбесіди, ти не виходиш як вижатий лимон, ти виходиш з новими поглядами на старі речі, та тільки з приємними емоціями і відчуттям якісно проведеного часу.
І нам максимально хотілось провести саме таку співбесіду, а не суху і чисто технічну.
Дуже багато тексту і не хочеться вас перевантажувати, тому далі буде…
#experience #interview
👍43❤11❤🔥2