Ако сте нов в света на ИТ-то, може да си помислите, че тази статия е някаква шега. Опитните програмисти обаче едва ли дори ще се усмихнат – всичко, което ще прочетете по-долу, е ужасно сериозно.
Вариант 1: Не прави това, което ти каже шефът
Защо не: Доста често мениджърите знаят много повече за даден проект от средностатистическия програмист. Нещо повече, една кола може да има само един шофьор: ако всяко от четирите колела се управляват от различен човек, вероятно ще катастрофирате или, в най-добрия случай, няма да стигнете до крайната точка (изобщо или навреме).
Пример: Мениджър моли програмист да проектира помещение с врата. Според техническото задание вратата няма дръжка. Вместо това има педал. Програмистът е виждал хиляди врати през живота си и решава, че мениджърът сигурно се е побъркал. Опитва се да спори (без успех) и в крайна сметка „оправя“ нещата. Естествено, случката завършва с уволнение.
Програмистът е уволнен, защото:
- Това е врата за склад, където хората ще влизат с кашони в ръце – педалът е основната идея за проекта;
- Клиентът е компания, която произвежда педали за врати;
- Дръжката на вратата е продадена на клиента по отделен договор и трябва да се монтира на втория етап от проекта.
Поука: Четете техническото задание внимателно и се придържайте строго към него. Ако има нещо, което не разбирате – просто попитайте. Ако не сте съгласни – опитайте се да убедите събеседниците си. Недейте просто да си траете и да правите точно това, което не трябва.
Вариант 2: Не тествате кода, който пишете
Защо не: Трябва да уважавате работата и труда на тестърите. Става въпрос за елементарна вежливост – също като да си измиеш зъбите, преди да отидеш на зъболекар.
Пример: Програмист трябва да замени думата „ОК“ с фразата „РЕГИСТРИРАЙ СЕ“ в прозореца за регистрация. Намират въпросната фраза в кода, подменят я и директно пращат работата си на тестъра, без да я проверят. Според плана, тестването трябва да стане автоматично и да приключи за около два часа под надзора на тестърите. Оказва се обаче, че новата фраза не се побира в бутона и целият дизайн е съсипан. Задачата трябва да се свърши отново, което отнема цял един ден.
Има термин, който се нарича „smoke testing“ (тестване за пушек) и тръгва от радиоелектрониката. Включваш уреда и гледаш дали няма да започне да пуши. Това е най-базовото ниво на тестване. Естествено, тестването е работа на тестърите, но ако програмистите допускат бъгове в кода заради небрежност, със сигурност няма да се радват на популярност сред колегите си.
Поука:: Когато пет минути от собственото ти време могат да спестят цял ден на някой друг, не бъди мързелив. Програмирането е работа за педанти, които са готови да проверяват отново и отново.
Вариант 3: Занимавай се със странични неща, докато си на работа
Защо не: Работодателят плаща за твоето време. Ако крадеш от това време, това си е чиста кражба.
Пример: Програмист има две работи, които върши отдалечено, и на пръв поглед всичко е наред. Шефовете му изобщо не знаят за това. Изведнъж, и на двете места възникват спешни ситуации. Тестърите му изпращат нови задачи на всеки 15 минути и искат да реагира незабавно. Програмистът отговаря бавно, оплита кода и в крайна сметка разочарова и двата екипа.
Поука: Ако си се съгласил да работиш на пълен работен ден, прави точно това. Ако имаш свободно време – помоли мениджърите да ти дадат повече работа и съответно, повече пари.
Вариант 4: Използвай любимата си библиотека, без да питаш шефовете
Защо не: Работата на програмиста изисква той да може да следва правилата, наложени в екипа. Ако харесваш ReactJS, но това не е библиотеката, която използва компанията, просто забрави. Използвай платформата, избрана от мениджърите.
Пример: Програмист получава задание да разработи нова функционалност на конкретен сайт. Решава, че ще е най-лесно и най-бързо да използва ReactJS и нищо не може да го разколебае
Седмица по-късно се прави ривю на кода и програмистът е уволнен, защото:
- Забравил е, че има папка с 10 GB код на Angular;
- В компанията няма други програмисти, освен него самият, които да използват React, така че никой не може да го замести, ако случайно се разболее;
- Клиентът изрично е поискал Angular.
Поука: Архитектурните решения, изборът на платформа, технологиите, библиотеките и т.н. са работа на техническия мениджър. Ако имаш идея, сподели я. Ако решиш да си мълчиш и да си правиш, каквото искаш, можеш спокойно да започнеш да си търсиш нова работа. Естествено, не от първия път но резултатът е почти неизбежен, ако сгафиш два пъти.
Вариант 5: Искай повишение седмица преди да предадеш важен проект
Защо не: Хората наричат това изнудване.
Пример: Програмист е създал библиотека за гласово разпознаване като част от голям проект – библиотеката е почти готова и трябва да бъде предадена следващата седмица. На друг програмист ще му трябват месеци, за да се ориентира в кода. Човекът решава, че сега е най-подходящият момент да си поиска повишение.
Мениджърът няма избор и вдига заплатата на служителя. След като проектът е предаден, програмистът е уволнен или пък вече не му поверяват важни задачи. Загубил е доверието на ръководството.
Поука: „Предложение, на което не можеш да откажеш“ подхожда повече на италианската мафия, отколкото на ИТ-тата.
Ако си програмист, със сигурност има и други начини да ти посочат вратата. Ако се задълбочим в темата, вероятно можем да ги изброяваме с дни. Но се надяваме нашият списък да ви е дал добра идея какво да правите (ако мразите работата си) или пък не (ако я обичате, на което силно се надяваме). Успех!
Ако чувстваш, че имаш нужда от помощ как ДА НЕ ТЕ УВОЛНЯТ и как да си намериш фантастична работа, нашият екип от страхотни HR експерти е винаги на разположение, да ти пмогне. Не се притеснявай и ни потърси за още полезни съвети!
