Кодирането не е едно от тях
Да, кодирането е продуктивна част от работата като програмист и като разработчици се очаква да създаваме код. Това е нашата работа!
Но да си разработчик е нещо повече от просто кодиране, което наистина може да покаже колко продуктивни можеш да бъдеш.
Ето 6 начина да бъдете продуктивни като разработчик без кодиране.
Задавайте въпроси
Забелязах сред много старши разработчици, че когато им бъде представена нова функция, те ще бъдат първите, които задават въпроси за тези функции.
Те искат да разберат не само как компонентът или функцията са проектирани да работят, но и каква е целта на функцията и какви дизайнерски решения са взети за интегрирането на функцията в проекта.
Задаването на въпроси дава възможност за по-широко разбиране за това как и защо всичко се съчетава. Погледът от птичи поглед на цялостния проект позволява на разработчиците по-добре да планират и изпълняват проекти.
Особено тези проекти, планирани в дългосрочен план. Писал съм за въпросите, които си задавам, преди дори да напиша ред код. Виж това.
Кажи не'
Да кажеш „не“ е трудно. Не само когато става дума за работа като разработчик, но и в живота. Но да можеш да кажеш „не“ е ефективен начин да останеш фокусиран и да свършиш нещата.
Винаги ще има ситуация, в която някой от UX или (по-вероятно) от ръководството по време на средата на спринта ще ви попита дали можете да направите това или другото.
Когато кажете „не“, вие гарантирате две основни неща –
- Пълзенето на обхвата е предотвратено. Пълзенето на обхвата е, когато се правят неофициални промени в билет, като по този начин се променя обхватът на билета. Понякога, когато това се случи, билетът трябва да бъде преоценен и обсъден отново.
- Предвидената задача се изпълнява. Рязането и промяната на нещата причиняват забавяния, а забавянията се случват, защото договорената задача не е завършена в необходимия срок.
Не забравяйте, че казването на „не“ не означава, че няма да направите нещо. Това просто означава, че може да се създаде нов билет за справяне с ново (извън обхват) изискване.
Направете почивка
Веднъж работих върху бъг, който ме разочарова цял следобед. Свърших работа и тази нощ не спах добре. Сънувах буболечката.
На следващата сутрин го реших за 15 минути!
Това просто показва важността на почивката. Умът има нужда от почивка, дори за 10 минути на всеки час.
Разбийте функциите на подзадачи
Говорейки за счупване, някои функции могат да бъдат огромни и трябва да бъдат разбити.
Толкова големи, че им дават големите 13 точки. Ако сте като моя екип, тогава ще опитате да ограничите билета до максимум 8 точки.
Но ако трябва да вземете 13 точки в спринт, тогава този билет може лесно да бъде разделен на по-малки подзадачи.
Разбиването на задачите на по-малки задачи е победа поради 3 ключови причини:
- Поддържа заявките за изтегляне малки. Това е изключително важно, защото въпреки че прегледът на PR е част от работата на всеки програмист, масивният PR не е това, което повечето разработчици искат да видят.
Те отнемат много време и енергия за преглед и са склонни към код с лошо качество, който се промъква из мрежата. - Напредъкът на тикета може лесно да бъде проследен. След като една от подзадачите бъде изпълнена, тя може да бъде изпратена до секцията за преглед на табла на JIRA.
- Ако билетът не е завършен в рамките на спринта, трябва да се пренесат само оставащите точки. Всички инженерни мениджъри обичат да гледат графиката за изгаряне на спринта. Диаграма, в която числата вървят надолу вместо нагоре, е много търсена.
Приоритизирайте времето си
Срещи, срещи, срещи. Те могат да заемат по-голямата част от деня. Те също са важни, така че не могат да бъдат пропуснати.
Няма да ви предложа да излезете или да прекъснете разговор по средата на срещата, на която сте планирали да участвате, само защото не допринасяте. Това е просто грубо.
Това може да работи за Илон Мъск, но може да не работи за всички.
Ключът тук е да не забравяте да приоритизирате времето си. Най-добрият начин, който открих да направя това, е да планирате време за себе си в публичния календар на екипа, за да можете да продължите с това, което трябва да се направи.
Простото блокиране на известно време през деня ви дава законна причина да кажете, че съжалявате, но не можете да присъствате на това и това или че ще закъснеете, тъй като имате нещо друго насрочено.
Поставяне на цели
Те могат да бъдат под формата на OKR (цели и ключови резултати) и цели за спринт.
Поставянето на цели за спринта позволява на целия екип да знае какво се очаква от текущия спринт и да работи към тези очаквания.
Демонстрацията на резултатите от спринта също става по-лесна, тъй като вече знаете какво ще покажете на останалата част от екипа и/или заинтересованите страни.
Бонус
Споделяне на знания
Свещ, която запалва друга свещ, не губи яркостта си. По-скоро заедно те блестят още по-ярко.
Обичам споделянето на знания. Това е шанс за целия екип да се съгласуват един с друг и кара всеки в екипа да бъде независим.
Това означава, че когато един от екипа излезе в отпуск, не е нужно цялото шоу да спира и да чака този член на екипа да се върне.
Всичко може да върви по план.
Благодаря за четенето!
Ако това беше полезно, ще съм благодарен, ако дадете на тази публикация 👏, споделяне във вашата мрежа и ако още не сте го направили, последването би било чудесно.
Моля, помислете и за абониране за Medium с моята връзка за „препоръка“. Medium е страхотна платформа за учене и това е, което използвам, за да съм в крак с това, което се случва в технологичното пространство, както и да се уча от опита на други разработчици.
Вашият абонамент ще подкрепи директно мен и много други писатели на Medium.
Повече съдържание в PlainEnglish.io. Регистрирайте се за нашия безплатен седмичен бюлетин. Следвайте ни в Twitter, LinkedIn, YouTube и Discord .
Интересувате ли се от мащабиране на стартирането на вашия софтуер? Вижте Circuit.
