JavaRush /Java блог /Random UA /Кава-брейк #48. 9 корисних звичок для junior-розробника

Кава-брейк #48. 9 корисних звичок для junior-розробника

Стаття з групи Random UA
Джерело: Free Code Camp Ви колись аналізували свої звички? Хороші допомагають стати тим, ким ви хочете бути. Шкідливі звички поступово перетворять вас на того, ким би ви не хотіли ставати. Пропрацювавши більше 12 років розробником програмного забезпечення, у мене виробабося певні звички, якими я пишаюся, а деяких я хотів би позбутися. Спочатку я не усвідомлював їх значення, але потім мені стало ясно, які з цих звичок мені допомагали рости, а які заважали. Це спонукало мене провести інвентаризацію і написати про те, що, можливо, надихне вас зробити те саме.Кава-брейк #48.  9 корисних звичок для junior-розробника - 1

Добровільно беріться за речі, в яких не знаєтеся

На початку своєї кар'єри ви знаєте не так багато. Тому ви напевно почуватиметеся самозванцем. Адже компанія платить вам зарплату як фахівцю, а ви навіть не знаєте половини назв тих технологій та фреймворків, з якими працюють ваші колеги. А про другу половину ви чули лише тому, що вчасно пошукали у Google. Якщо замінити слова «на початку кар'єри» на «на початку будь-якого нового проекту», можна отримати досить точне уявлення про кар'єру у сфері розробки софту. Кожен новий проект – це початок чогось нового. Ми знайомимося з новими людьми, розуміємося на нових вимогах, вивчаємо нові фреймворки. І так щоразу. Ось чому так важливо постійно вчитися новому. Якщо ви весь час робите лише те, в чому добре знаєтеся, ви не зможете впевнено братися за новий проект. Перед вами завжди з'являтиметься страх перед невідомістю. Взявши за правило самостійно братися за завдання, про які вам нічого невідомо, ви зможете отримувати нові навички та знання. Якщо потрібно виправити щось у збірці, а ви ніколи раніше з подібною роботою не стикалися, беріться за це завдання! Ви отримаєте необхідний досвід та нові навички. Якщо у фронтенд-коді JavaScript виявлено помилку, а ви поки що працювали тільки з бекендом Java, виправте її! Робити те, в чому ви не впевнені, — чудовий спосіб професійного зростання. Але не обманюйте очікування оточуючих. Не виставляйте себе асом у всьому. Щиро скажіть, що ви не робабо цього раніше, але хотіли б навчитися.

Просіться попрацювати з кимось у парі

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

Повідомляйте, що робите (і чого не робите)

Я вже не пам'ятаю, скільки разів, коли я з ентузіазмом хапався за завдання, думаючи, що впораюся за день, мені доводилося закінчувати його за тиждень. З досвідом я став рідше потрапляти в подібні ситуації, але часом я все ще надто оптимістичний у своїх оцінках. Причин для подібної оцінки часу є кілька:
  • керівництво вимагає якнайшвидше закінчити нову фічу, тому що дедлайн близький;
  • хочеться добре виглядати на фоні колег по офісу;
  • багато речей просто не працюють так, як очікувалося;
  • і багато багато іншого…
Загалом, цілком імовірно, що ваша оцінка часу також буде надмірно оптимістичною. Як це виправити? Ви можете керувати очікуваннями вже у процесі роботи! Постійно розповідайте про те, чим ви займаєтесь, та завжди повідомляйте, що саме вас затримує. Я не маю на увазі, що потрібно видавати апдейт статусу завдання кожні 15 хвабон. Просто слідкуйте за тим, щоб люди, яких це стосується, знали, на якому етапі ви знаходитесь. Найкраще про це повідомляти на початку та наприкінці робочого дня. Якщо ваш керівник або менеджер команди/проекту очікує від вас результатів, доповідайте йому щодня: «Я працюю над тим і тим. Зіткнувся з такою проблемою. Ось варіанти її вирішення». Так усі зацікавлені особи знатимуть про ваш прогрес. Ніхто не звинуватитиме вас, якщо ви раптом зіткнетеся з проблемою, — але тільки якщо ви при цьому триматимете людей в курсі подій. Додатковий плюс: повідомляючи про поточний статус виконання завдання, ви зможете почути від інших рекомендації чи варіанти вирішення проблеми. Візьміть за звичку регулярно повідомляти заінтересованим особам про результати вашої роботи.

Заведіть блог

Напевно, я не перший, від кого ви почули цю пораду, але все одно скажу: ведіть блог! Зовсім не обов'язково, щоб ваш блог був публічним. Це може бути пара сторінок на wiki вашої компанії або колекція GitHub-репозиторіїв з прикладами коду і кількома рядками тексту, що пояснює. Навіщо це потрібно? Тому що, коли ви пишете щось для того, щоб навчити інших (навіть якщо ці «інші» — це ви самі в майбутньому), це чудовий спосіб вчитися та професійно рости. Напишіть про те, як ви спромоглися вирішити якусь важку проблему. Або про те, як працює новий фреймворк, вихід якого ви давно очікували. Також можна вести щоденник того, що ви зробабо на тижні. Це, до речі, допоможе виробити звичку повідомляти, над чим ви зараз працюєте. Я кілька разів починав вести блог. Спочатку, звичайно, дуже важко підтримувати мотивацію та змушувати себе писати, розуміючи, що навряд чи хтось читає ваші пости. Досить дивно писати у порожнечу. З цієї причини я й закидав свої блоги. І ось три роки тому я завів черговий свій нинішній блог . Я писав без будь-якої аудиторії протягом півроку. І потім я виявив, що читачів у мене не було тому, що мій файл robots.txt не дозволяв пошукачам індексувати блог! Коротше, я змінив налаштування у robots.txt, і люди почали читати мої статті. Читачів було небагато, але все одно вони давали мені стимул не зупинятися. Поступово я покращив свої навички письма, і тепер мій блог має до 200 тисяч переглядів на місяць. І все це через те, що я колись вирішив почати писати про нові фреймворки та проблеми, які мені вдалося вирішити. А робив я це для того, щоб мати можливість повернутися до своїх записів, коли вони мені знадобляться, а не тому, що хотів зібрати велику аудиторію. Спочатку ведення блогу здасться нудною рутиною, але згодом, якщо ви не зупинитесь, це заняття почне приносити вам задоволення. Якщо ви почнете писати з бажанням вчитися і вчити, ви не тільки багато чого освоїте, а й станете цікавим для багатьох людей.

Заведіть собі записник

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

Документуйте свої перемоги

Записники необхідні і при виробленні звички документування своїх досягнень. Як я вже казав, пам'ять у мене погана. Звичайно, я можу згадати, що їв учора за обідом, але коли я зосереджений на якомусь складному завданні, потужність моєї пам'яті помітно знижується. Ось тому я маю правило записувати свої досягнення в кінці кожного дня. Не йдеться про якісь визначні справи, а просто про маленькі перемоги. Наприклад, виправлення бага, ще один крок на шляху до створення нової функції і т. д. Я також записую особисті перемоги, наприклад, виконання ранкового тренування. Я просто складаю вечорами список зробленого за день і записую все це в блокнот. Ви можете вносити подібні записи до таблички або користуватися якоюсь спеціальною програмою, якщо вам так зручніше. Згодом досягнень стає більше. Можна навіть якось відзначати найважливіші, щоби потім з легкістю їх знаходити. Наприклад, перед підготовкою до огляду ефективності (performance review), ви переглядаєте свій список, знаходите відповідні досягнення та виносите до окремого списку. Так огляд пройде набагато краще. Також список досягнень корисний, коли потрібно розповісти, що ви робабо.

Знайдіть час для важливих завдань

Наприкінці дня у мене часто виникає відчуття, що сьогодні нічого й не зробив. І хоча документування своїх перемог (або хоча б завершених завдань) це важливо, головне все ж таки — завершувати ці завдання. Буває, одна нарада змінюється іншою і раптово настає кінець робочого дня. Після наради з колегами ви хотіли б продовжити роботу над своїм завданням, але як тільки ви встигаєте розігрітися, як починається нова відеоконференція. І після цього вам потрібно «розігріватись» заново, тому що ви вже втратабо контекст. Це знижує вашу продуктивність. Якщо я чогось і навчився у справі підвищення продуктивності, то це тому, що обов'язково потрібно резервувати час для виконання важливих завдань. Якщо ви не візьмете правило виділяти час на важливі завдання, дуже ймовірно, що ви так і не приступите до роботи над нею. Ваш час буде з'їдено звичайними повсякденними справами. Керувати своїм часом можна за допомогою різних методів і, щиро кажучи, я пересякую з одного підходу до іншого кожну пару місяців. Але суть залишається незмінною: для завдань, які потрібно обов'язково виконати, потрібно резервувати шматок часу в розкладі. Я виділяю одну годину вранці перед роботою на написання статей для блогу (або для інших сайтів). Також відвожу одну годину ввечері (коли діти вже сплять) працювати над особистим проектом. Зараз у мене є дошка Trello з колонкою для кожного дня тижня, куди я вношу завдання, якими хочу зайнятися вранці та ввечері. Щотижня я оновлюю цю дошку і пишу туди, що мені потрібно виконати наступного тижня. Так мені не доводиться витрачати дорогоцінний час на обмірковування того, чим далі зайнятися. Крім того, я щодня виділяю у своєму розкладі дві години для роботи, яка потребує особливої ​​концентрації, щоб колеги не намагалися призначати на цей час якісь наради. Все це допомагає мені долати завдання, заплановані на день. Загалом, не так важливо, як саме ви здійснюєте тайм-менеджмент. Головне — в принципі це робити і створити з цього звичку. В іншому випадку ваші дні будуть з'їдатися речами, які не надто важливі для вас.

Якщо ви застрягли, зробіть перерву

Розробники дуже часто заходять у глухий кут. І ці ситуації дуже дратують. У подібних випадках часто всі радять зробити перерву у роботі. Але іноді дуже важко дотримуватися таких рекомендацій, адже «рішення вже близько, я не можу перерватися зараз». І якщо я зроблю перерву прямо зараз, то після неї мені знову доведеться «вклинюватися» у суть справи. Навіщо добровільно гаяти часу? Але справа в тому, що коли ви застрягли в роботі, це заважає вам мислити здорово. Ви думаєте про те, що це дуже безглуздо застрягти над такою проблемою. Адже ваші колеги, напевно, легко б із цим впоралися (інший варіант — їм завжди дістаються легше завдання). При цьому ви не думаєте про те, як вирішити проблему. Зробіть перерву та попрацюйте деякий час над чимось іншим. Або (що ще краще) поверніться до цієї проблеми завтра. Деяке дистанціювання від проблеми дозволить вам побачити рішення, які раніше вислизали з вашого поля зору. Може, у вас ще такого не траплялося, але я вас запевняю: дуже часто потрібне рішення спадає на думку саме собою. Якщо ж у вас немає зайвого часу, можна застосувати метод Pomodoro – поділ завдання на 30-хвабонні відрізки з невеликим відпочинком між ними. Після кожного етапу я запитую себе, чи працюю я в режимі пошуку рішення, чи я застряг і мені слід зайнятися чимось іншим. Метод Pomodoro має додатковий плюс: кінець кожного етапу можна використовувати як тригер для інших звичок. Наприклад, для формування звички встати з-за столу та розім'ятися, випити води. Це іноді називається стеком звичок, тому що ви накладаєте одну на іншу, і в результаті отримуєте хороший ефект.

Не потрібно шукати чарівну паличку

Колись я написав книгу про певний стиль в архітектурі програмного забезпечення та регулярно отримую електронні листи з запитаннями на кшталт «Мені дуже подобається цей стиль і я хочу застосувати його у всіх моїх проектах! Як це зробити?" І знаєте, що я відповідаю? Не існує жодного архітектурного стилю, який би підходив для вирішення всіх проблем. Коли ви маєте маленький проект, ви створюєте простий CRUD API. А якщо у вас складна модель, ви будуєте складнішу шестикутну архітектуру. А при створенні мікросервісів у кожному окремому контексті ви використовуєте ще один із сотні архітектурних стилів. Немає універсального фреймворку, який можна використовувати для будь-якого проекту. Як і немає єдиної мови програмування чи стилю кодингу. Не намагайтеся знайти чарівну паличку. Її немає. Наявність своєї думки - це добре, коли за думкою стоять гідні аргументи. «Це найкращий архітектурний стиль» та «Я завжди так роблю» не належать до гідних аргументів. Тільки уявіть, що у вашій команді є розробник, який завжди має власні переваги і який з піною біля рота завжди доводить свою правоту, «бо так найкраще». Ви втомитеся від нього дуже швидко. Не будьте таким розробником.
Коментарі
ЩОБ ПОДИВИТИСЯ ВСІ КОМЕНТАРІ АБО ЗАЛИШИТИ КОМЕНТАР,
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ