Я нещодавно розпочав свою кар’єру як веб-розробник середньої компанії. Як тільки я почав, я отримав завдання розширити існуючий додаток (погано закодований, розроблений декількома програмістами протягом багатьох років, обробляє одні і ті ж завдання по-різному, нульова структура).

Тож після того, як я успішно розширив цей додаток із запитуваною функціональністю, вони дали мені завдання повністю підтримувати додаток. Це, звичайно, не було проблемою, або я так подумав. Але тоді я почув, що мені не було дозволено покращувати існуючий код і зосередитися на виправленнях помилок лише тоді, коли повідомляється про помилку.

Відтоді у мене було ще три проекти, як і вище, які я зараз також повинен підтримувати. І я отримав чотири проекти, де мені було дозволено створювати додаток з нуля, і я також повинен підтримувати ці.

У цей момент я трохи починаю божеволіти від щоденних повідомлень користувачів (читайте менеджерів) для кожного додатка, який я маю підтримувати. Вони очікують, що я буду обробляти ці листи безпосередньо під час роботи над двома новими проектами (а після них вже є ще п’ять проектів). Сумно в тому, що я ще не отримав повідомлення про помилку про все, що я кодував сам. З цього приводу я отримував лише випадкові запити на зміну "робити щось" на 180 градусів.

Все-таки це нормально? На мою думку, я роблю еквівалент цілої команди розробників.

Я був ідіот, коли спочатку очікував, що все буде інакше?

Я думаю, що цей пост перетворився на велику злобу, але скажіть, будь ласка, що це не однаково для кожного розробника.

PS Моя зарплата майже дорівнює, якщо не нижча, ніж у касира в супермаркеті.

Під час одного з моїх стажувань я виявив, що витратив багато часу на виправлення помилок. Ви повинні усвідомити, що як працівник початкового рівня, ви не збираєтеся отримувати найсексуальнішу роботу, ви збираєтеся отримувати бурхливу роботу, яку ніхто більше не хоче. Це прикро, але так буває на кожній роботі.

Крім того, ви повинні усвідомити, що для компанії наявність коду, який працює, важливіше, ніж чистий код. З точки зору вашої компанії, ви змінюєте існуючу структуру - це витрачайте гроші на переробку того, що вже зроблено, і потенційно вводите ще більше помилок. Зазвичай ці типи компаній не є комп'ютерними / програмними компаніями, тому жоден достатньо високий менеджер не має технічного підґрунтя, щоб знати, що іноді потрібно робити ці основні ремонти. Це означає, що якщо вашою компанією керують технічно компетентні люди, і вони розуміють цінність хорошого коду, ви можете отримати більше свободи, хоча іноді вам потрібно вибирати свої битви (головна мета бізнесу - все-таки заробляти гроші, адже ).

З цього приводу, ви нерозумно бажаєте залишити свій слід на програмному забезпеченні та бажаєте більш значущої роботи. Також прикро, що вам доведеться мати справу з такою кількістю проектів одночасно, одночасно викладаючи запити від стількох різних менеджерів.

Як програміст, це факт, що ви витратите більше часу на підтримку та зміну коду інших людей, ніж ви будете писати свій власний з нуля. Якщо це проблема для вас, то, можливо, вам слід дотримуватися розвитку хобі та робити іншу кар’єру. Якщо у вас все в порядку з підтриманням коду, але ви вважаєте, що вас не використовують ефективно або перевантажують, то це питання, з яким потрібно обговорити свого менеджера. Якщо ваші проблеми серйозніші, ніж ви, або якщо ви відчуваєте, що ваші менеджери не знають, як ефективно керувати набором навичок, тоді було б непогано розглянути питання про пошук роботи в іншій компанії. Зважаючи на заявлену низьку зарплату, це, мабуть, найкращий спосіб дій.

Це здається, що управління має проблеми з управлінням вашим навантаженням та визначенням пріоритетів. Вам слід поговорити з вашим менеджером і дати їм зрозуміти, що ви перевантажені, і ви не можете зробити ефективну роботу, якщо всі продовжують бомбардувати вас запитами, які вони хочуть виконати негайно.

Це змушує вас переходити з одного завдання та проектувати на інше, витрачаючи багато часу на перемикання передач. Для ефективної роботи з розробки програмного забезпечення потрібно мати можливість зануритися у завдання і повністю зосередитись на ньому. Чим більше перерв відбувається, тим більше часу витрачається на зміну контексту. Дослідження показують, що для занурення та переходу до стану потоку, де наш розум працює найбільш ефективно, потрібно 15 хвилин . Якщо ви отримуєте перебої кожні 15 хвилин, ви ніколи не потрапляєте в потік, що є величезною тратою як для вас, так і для компанії.

Тож вам слід спробувати домовитись про більш розумний режим роботи зі своїм менеджером . Це має включати визначення пріоритетності вхідних запитів та планування певної міри наперед . Усі запити користувачів повинні міститись у списку, упорядкованому за пріоритетами. І пріоритети не повинні визначати запитувач (як звичайно кожен вважає, що його / її запит є найважливішим на землі), ні ви, а хтось, хто має достатньо ділових знань та огляду всього спектру продуктів, які ви підтримуєте ( власник продукту ).

В ідеалі всі вхідні запити повинні бути введені в трекер випуску, як JIRA або Mantis . Або, принаймні, надіслано власнику товару, а не вам. І він / вона має також вирішувати всі скарги користувачів через "чому мій запит ще не готовий ?!", що дозволяє зосередитись на роботі з розробки. Якщо це неможливо, вам слід принаймні домовитись про певні періоди часу, коли ви дивитесь на вхідні запити та розглядаєте їх, залишаючи безперебійну частину свого часу виключно для розвитку.

Якщо це можливо, наступним кроком може бути певне планування заздалегідь. Тобто, оцініть час, необхідний для виконання запитів на першочергові пріоритети, а потім сплануйте свій час на спринти , які можуть бути один або кілька тижнів кожен, і виділіть достатню кількість завдань на наступний спринт, щоб охопити ваш час.

Можливо, ви хочете зберегти частину свого часу для вхідних екстрених запитів, але решту можна планувати заздалегідь. І ви також можете віддати перевагу організувати роботу над різними проектами в окремі "смуги", тобто працювати над проектом "А" в понеділок, проектом "В понеділок-середу", "проектом С" вранці в четвер і "Днем" і т.д., і далі зменшити переключення контексту.

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

Зауважте, що навіть якщо ваша поточна позиція здається вашою компанією низькою, чим більше проектів ви підтримуєте, тим більше переговорної сили у вас є .

Пошук та навчання нового найму для обслуговування всіх цих проектів потребує значного часу (= грошей) для компанії. І ви можете правильно зазначити, що ваш код настільки кращий, ніж застарілі частини цих додатків, тому не за умови, що вони можуть легко знайти кандидата подібних можливостей за однакову суму грошей. Не кажучи вже про те, що якщо вони не покращать умови праці, вони змусять наступного хлопця набриднути і кинуть так само швидко, як і ви ... Постарайтеся, щоб вони зрозуміли, що утримати вас це в їхніх інтересах, і щоб ви були щасливими там, де ви знаходитесь :-) Це може дати вам певну владу домовлятися про вищезазначені умови та / або вимагати підвищення зарплати.

Скільки у вас переговорної сили - це велике питання. Ваше керівництво може або не може бути відкритим до цих ідей, а може і не може вас поважати достатньо, щоб серйозно поставитись до ваших благань. Але якщо ви добре граєте в карти, у вас є шанс. А якщо вони відмовляться ... завжди можна шукати краще робоче місце. Ця ситуація не однакова для кожного починаючого, хоча (на жаль) ваш досвід досить типовий. Але там справді є кращі робочі місця . Якість робочого місця лише слабко співвідноситься з географічним положенням, але я відчуваю, що в Північній Європі шанси вище. Тож якщо ви не зможете помітно покращити свої поточні умови, вам слід почати шукати негайно , перш ніж ви повністю згоїли і вигоріли.

Неодмінно краще шукати роботу, поки у вас все ще є, тому не потрібно приймати першу пропозицію тільки тому, що вам потрібні гроші негайно. Зрештою ви знайдете краще місце :-)

PS Моя зарплата майже дорівнює, якщо не нижче, ніж у каси в супермаркеті.

Хе, я хотів написати щось про те, як вести переговори, поки не прочитав. Тепер все, що я можу сказати, - відпустка! Якщо припустити, що це половина того, що зазвичай заробляє розробник зі ступенем. І якщо припустити, що все покращиться, і вони негайно дають вам збільшення на 10%, ви можете самі зрозуміти, скільки часу потрібно, щоб дістатися туди. Це також виглядає так, що ви нічого не вчитеся на роботі і, здається, не оточені там блискучими інженерами, тож це марна трата часу.

Я також був у подібній ситуації, і я можу вам сказати, що якщо ти залишишся на цьому шляху, це ніколи не закінчиться. Менеджмент буде тримати лопату у вас, бо ... вони можуть.

Є кілька додаткових думок, які я маю на цю тему.

1. Роби те що любиш. Якщо ви цього не любите, підготуйтеся до спроби знайти те, що ви можете любити.

2. Зв'язок. Чітко повідомте про свої нездатності здійснити нереальні очікування. У моєму подібному досвіді архітектор (який найбільше робив лопату) сказав: "Ви повинні керувати іншими очікуваннями від вас".

3. Вигоріти. Якщо ви не пережили вигорання, не спокушайте долю. Це висмоктує ваше життя і душу з розуму. Незважаючи на ваші зусилля, ваша робоча мета стає сірою, тужливою і безглуздою. Я даю цю пораду, оскільки за будь-яку ціну потрібно уникати вигорання.

4. Навчання. Ось срібна підкладка. Твоя підготовка та досвід, хоча і засмучує, і, можливо, недоплачує, насправді дуже цінний для твоєї кар’єри. Це ваша заощаджувальна благодать, щоб усвідомити це, оскільки ви зможете якомога більше засвоїти навчання та затримати будь-яку неминучу скляну стелю.

Зосередьтеся на тому, які таланти та вміння зростаєте ... Вони перенесуть вас через наступні можливості вашої кар’єри.

Тут ви маєте справу з кількома проблемами ... Почнемо з очевидних ...

Це нормально?

Ніяк ні. Але ... це звичайне? На жаль, так.

Щодо помилок, що виправляють помилки

Хоча це не виправдовує решту безладу, з яким вам доводиться стикатися, та численних проектів, якими вони вас перевантажують, я просто хочу швидко зауважити, що підхід "виправлення помилок" підходить лише для вас, як для розробника. , може бути ідеально розумним підходом для компанії та її керівництва.

Поверхня для більшої кількості помилок та витрат

Чим більше ви торкаєтеся коду, тим більше шансів ввести помилки, навіть якщо ваш намір полягає в тому, щоб поліпшити його. Це означає тривалий час розробки, час тестування та витрати. І якщо він проскакує до випуску сервісу із середнім та високим дефектом, це для них великий безлад.

Шум / туман у ваших журналах

З точки зору SCM, це також має певний сенс, якщо ви працюєте безпосередньо з гілки випуску служби, оскільки ви хочете мати чітке уявлення про зміни, пов’язані з виправленням помилок. Якщо є 15 комітетів із тисячами змін, що оточують помилку, яка фактично вимагала, можливо, змінити рядок коду на 1 рядок, це дуже дратує.

Отже, будучи новим наймом, ще розумніше попросити вас утриматися від рефакторингу та / або вдосконалення програмного забезпечення, і цілком нормально, на мій сенс, щоб бути максимально "хірургічним" зі своїми помилками. Це просто тримає головний біль у страху.

Ви можете щось з цим зробити?

Тепер це НЕ означає, що існували б способи досягнення як розумності кодексу, так і розумності розуму залучених людей. Будучи молодшими, їм слід переглядати ваші зміни, особливо виправлення помилок, і переконайтесь, що вони затверджені, перш ніж вносити їх до версій службових версій. Це дозволить запобігти або обмежити радикальні зміни та бути безпечнішими.

Проект із пекла

Crap Code, Стадо програмістів, копіювання, Crack Architecture

Знову ж таки, захисник диявола тут, але просто показує, що ваш початковий запит містить кілька непослідовних бітів.

Моя точка зору така: я дійсно дуже рідко взяв в кодову , який не був у цьому стані. І за випадковості, яку я зробив, нещодавно були розпочаті проекти чи прототипи, які розпочали досить зоряні програмісти. Але вражаюче переважна більшість з них виглядала як лайно, і страшна кількість з них були справжніми лайнами. Навіть ті, що розпочалися добрими або великими програмістами, можуть закінчитися лайном, термінами та іншими завданнями, що допомагають ...

Ласкаво просимо до реальної інженерної інженерії програмного забезпечення!

А ви знаєте, що весело? У світі веб-розробок це набагато гірше. Насолоджуйтесь! :)

Занадто багато проектів та запитів, не вистачає рук та часу

Проблема полягає тут, ймовірно, у:

• ваше керівництво (можливо, несвідомо) зловживає вами ,
• ваші колеги (можливо, несвідомо) зловживають вами ,
• ваш (можливо, несвідомо) недостатньо прикриває дупу і веде свої битви .

Ваші менеджери повинні знати, що ви працюєте над занадто великою кількістю проектів для управління. Якщо їх немає, переконайтеся, що вони якнайшвидше. Також переконайтесь, що вони знають, що це не все виборче місце в парку і що ви відчули тиск, і що це потрібно зупинити.

Постарайтеся озирнутися і переконайтесь, що ваші колеги не відхиляють більше завдань і проектів на вас, прямо (насправді кажучи "X зможе про це подбати") або опосередковано ("Я не потрібна людина для це, знайди когось іншого "-> в кінцевому підсумку ти є).

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

• що ти можеш зробити ,
• що ти хочеш зробити ,
• і що ви готові зробити .

Тож частково ви також винні в тому, що дозволите це стати таким чином. Але це нормально, це урок, який потрібно вивчити кожному. Це має місце в двох букв: N - O .

Зазвичай ви використовуєте його як префікс для більш тривалої, але не настільки зарядженої відповіді: Ні, я не можу цього зробити. Ні, я не знаю, як це зробити. Ні, я не впевнений, що я правильна людина для цього. Ні, я ніколи цього не робив.

Спочатку дуже легко відчути, що ти можеш просто сказати «так, я (зрештою) це зроблю», і складати речі і виконувати їх, можливо, додавши додаткові години. Це все неправильно. Вам потрібно зрозуміти, що ваш час - після ваших навичок - найцінніший актив для вас та вашої компанії. Якщо його неправомірно використовувати, це впливає на проекти, терміни та бюджети . Так просто.

Крім того, це виглядає трохи занепокоєнням, що у вас було б надто багато людей, щоб повідомити. Це нормально, щоб мати багато клієнтів, з якими потрібно мати справу, та кілька власників проектів або навіть основних зацікавлених сторін, з якими потрібно спілкуватися. Але в цілому, особливо якщо ви є новим наймачем, ви повинні здебільшого звітувати лише кільком менеджерам (і, швидше за все, лише своєму прямому керівнику та, можливо, провідному чи старшому розробнику). Як це вийшло таким чином? Не знаю. Це може бути організаційним питанням у вашій компанії, або може бути результатом того, що ви робите послугу, а потім безпосередньо контактуєте з вами і не можете сказати "ні". Або може бути, що ваш безпосередній керівник вирішує проблеми з диспетчерськими завданнями, наскільки я знаю (я справді здогадуюсь, але модель є впізнаваною і добре відомою).

Я рекомендую вам зробити це досить швидко: перейдіть особисто до свого прямого керівника, поясніть, що інші менеджери можуть бути трохи напористими, або (можливо, менш кричущими), що у вас є занадто багато матеріалів, що надсилаються надто багато людей, і що вам потрібен його внесок (а можливо і їхній), щоб знати, яким з них поставити пріоритет.

180-градусні запити на зміну

Це ще одне велике питання. Вони, напевно, не ваші вини, але ви можете спробувати допомогти їм вирішити це.

"Запити на зміну в 180 градусів", як ви їх красиво і гостро називаєте, - це явна ознака того, що вимоги нечіткі від початку руху, і що ніхто не намагається достатньо наполегливо закріпити їх та очистити з часом.

Це зазвичай, коли комусь потрібно встати по телефону (а краще, на ноги), і схопити зацікавлених сторін за руку і чітко сказати їм: "ось де ми є, саме там ви хочете, щоб ми пішли, чи підтверджуєте ви, що ми прямуючи в правильному напрямку? ". Добре не отримувати ясних відповідей на початку, але чим більше часу проходить, тим чіткіше вони повинні стати, або цей проект - це катастрофа, яка чекає, що трапиться.

Зазвичай я б сказав, захопіть усіх зацікавлених сторін в межах досяжності, покладіть їх у кімнату, проведіть їх через судові проблеми та поступово намагайтеся їх вирішити - і отримуйте пріоритети, поки ви на це. Однак у вашому випадку, можливо, це вже не ваш дзвінок. Але ви згадуєте, що вони справді відповідали за проекти; Так що якщо це дійсно так, то берете на себе відповідальність і робіть це. І НЕ ухиляйтесь від того, щоб сказати "ми не можемо цього зробити" , або навіть "ми не будемо робити цього" . Дійсно важливо обмежити обсяг проекту.

Якщо немає сфери, то в кінці дискусії немає чітких вимог.

Перевантаження електронною поштою

Люди, як правило, поводяться по-різному, виходячи з комунікаційного середовища, яким вони користуються. Особисто я, хоч і є досить тихою людиною (і працюю в основному в зарубіжних країнах, тому мені теж не дуже подобається розмовляти по телефону), я віддаю перевагу порядку уподобань на основі продуктивності:

• розмовляючи з людьми віч-на-віч ,
• розмовляти з людьми по телефону,
• розмовляти з людьми через чат,
• розмовляти з людьми електронною поштою.

Електронні листи приємні для відстеження, отримання підтверджень, надсилання нотаток.

Для планування, планування та обговорення проблемних питань вони близькі до марних. Постукайте у двері хлопця, поки він / вона не відкриє їх, і сідайте з блокнотом та копією вашої документації, щоб уточнити речі. Після завершення надішліть електронний лист і попросіть підтвердження. Якщо він повернеться з негативною відповіддю або злегка прихованою спробою прокрасти щось інше в конверті, перейдіть знову на облогу офісу вашого співрозмовника.

Це інженерія програмного забезпечення. Це часто більш продуктивно, коли ти не набираєш клавіатуру і може насправді скоротити наперед лайно, з яким ти будеш мати справу.

Виконання роботи в команді

Ви робите еквівалент вартості роботи команди? Може бути.

Ви робите еквівалент вартості вашої команди? Напевно, ні.

Що я маю на увазі, що ваша команда, ймовірно, зайнята роботою, а ви перевантажені роботою. І ось у чому полягає проблема: ви перевантажені речами, які повинні бути витіснені з поточних термінів проекту, або надані комусь із часом у руках.

Я був ідіот, коли спочатку очікував, що все буде інакше?

Немає; просто нова для партії. Це як перший зависання чи стосунки. Ви здолаєте це.

Я думаю, що цей пост перетворився на велику злобу, але скажіть, будь ласка, що це не однаково для кожного розробника.

Це те саме для кожного розробника в хаотичних організаціях, будь то стартапи або добре зарекомендували себе гіганти і не маючи досвіду чи впевненості, щоб змусити переміщатися на один біт, щоб підкреслити ваші шанси на виживання з правого боку шкали.

PS Моя зарплата майже дорівнює, якщо не нижче, ніж у каси в супермаркеті.

Я робив гідну зарплату на роботах, які здадуться хитрими. Це не число на чеку, яке враховує, це контекст. Що ти робиш, твій вік, де ти живеш і працюєш, тощо ...

Якщо говорити, якщо ви сильно недооплачуєтесь, працюєте занадто багато, і не зовсім молодші, ідіть, вимагайте підвищення та отримайте нову роботу!

Це просто:

• якщо вони цінують те, що ти робиш, вони з радістю погодиться на підвищення,
• якщо вони цього не роблять, майбутнє в цій компанії не виглядає дуже райдужним (для вас, принаймні, саме це важливо), тому не відчувайте себе погано.

Будьте в курсі, що просити про підвищення - це добре, навіть якщо ви спочатку не були б так подумані. Це доводить, що ви стежите за тим, що ви робите, і натякає на те, що ви стежите за іншими варіантами, залишаючись готовими залишатися на борту. І це добре звикнути запитувати їх, оскільки вони схожі на співбесіду на роботу чи торгуються взагалі: це потрібна практика, і вони не падають з неба, якщо ви самі не дотягнетесь до них. Деякі компанії регулярно розповсюджуватимуть підвищення, не вимагаючи, але це лише тому, що вони досить розумні, щоб знати, що це залишає вас напівзадоволеними та менш готовими до змін, і вони хочуть стригти траву під вашою ногою (більшість людей відчували б трохи непросто щодо підвищення пропозиції про підвищення, яку їм пропонували безпосередньо).

Як діяти з цим запитом трохи не виходить за рамки цього проекту, тому я не буду вникати в деталі. Але я рекомендую вам підготувати запис своїх ідентифікаторів, які здійснюють SCM, про виправлені помилки та досягнення, а також підготувати звіти, порівнюючи їх із загальними зусиллями команди. Сюди:

• ви можете виміряти для себе, чи ефективно ви зробили набагато більше, ніж ваші однолітки чи ні,
• ви можете відстоювати свою позицію, якщо вони заявлять, що ваш запит не виправданий.

Окрім коментарів інших людей:

1. Так, нормально, щоб працівник початкового рівня отримав роботу, яку ніхто більше не хоче робити.

2. Ви повинні бачити це як основний елемент вашої майбутньої кар’єри.

То що ж робити? Для того, щоб зарекомендувати себе професійним розробником, вам потрібно забезпечити структурованість та планування вашої роботи, інакше вам може бути важко розвиватись на хороших речах, які ви зараз робите - тому вам слід спробувати робити такі дії, як наступні (якщо ти вже не).

1. Точно записуйте свою роботу для кожного проекту. Тож якщо ви витратили одну годину на виправлення помилки на проекті A, увійдіть цей час. Це буде корисно показати вашому менеджеру, якщо ви хочете обговорити навантаження.

2. Напишіть одиничні тести. Ви згадуєте про деякі проекти, якими ви керуєтесь, повні помилок, тому я гадаю, що тестів на одиницю (якщо такі є) є мало. Для кожного звіту про помилку напишіть одиничний тест, який повторює помилку, а потім виправте помилку. Це допоможе забезпечити відсутність регресій, покращить якість коду та послужить платформою, на якій можна перефактурувати код, якщо вам нададуть можливість (наприклад, це може допомогти вам переконати зацікавлених сторін у тому, що перезапис деяких частин може покращитись якість без введення нових помилок, завдяки наборі тестових пакетів).

3. Шукайте нову роботу - ви працюєте над багатьма проектами одночасно, ви написали код з нуля, і ви, мабуть, пережили весь життєвий цикл проекту - все це хороший досвід для застосування в інших місцях.

Ваша ситуація трохи невиразна, але все ще нормальна. Але спосіб поводження з ним дуже поганий. Ось що вам потрібно зробити:

• Спробуйте протистояти своєму начальнику. Ви повинні мати доказ (цифри) того, скільки часу насправді коштує база поганого коду. Якщо він не розуміє таких речей, як технічна заборгованість, припиніть згадувати про це. Це зірве вам голову, і вас можуть позначити як хлопця "поганого ставлення". Це не ваша робота навчити свого начальника робити свою справу.

• Підтримуйте власні відсталі (канбани). Коли з’являються нові завдання, поставте їх у кінці та повідомте передбачуваний час їх виконання.

• Збільшити час відповіді, перевіряти електронну пошту лише два рази на день. Зазвичай до обіду і безпосередньо перед відходом. (Перевірка електронної пошти не повинна супроводжуватися кодуванням, оскільки вона може зірвати вашу голову).

• Зробіть невелике вдосконалення коду як частину кожного завдання. Удосконалити код, навички та інструменти, якими ви користуєтесь, це просто ваша робота. Це також підвищить вашу моральність у довгостроковій перспективі.

• Протягом дня немає комутації проектів. Сьогодні ви просто працюєте над проектом X, а завтра розпочнете інше завдання Y.

• Виділіть одну годину на день для утримання воріт. Мається на увазі невеликі завдання, які тривіально робити. Якщо це завдання займає більше 10 хвилин (не важливо, в чому причина), воно переходить у відставання, і ви повідомляєте менеджера, що воно буде відкладено.

Тепер настає важка частина. Наразі менеджери не спілкуються один з одним, а просто припускають, що ви закінчите власний проект з максимальним пріоритетом. Це приносить великий стрес вашій голові, тому що ви перебуваєте в середині аргументів. Потрібно змусити менеджерів почати координувати вашу роботу. Зрештою, у вас повинен бути хороший і простий відставання, і менеджери повинні знущатися один над одним без вас.

Тож давайте зробимо кілька простих рольових ігор. Є три менеджери та проекти (Xavier з проектом X, Yvonne з проектом Y та Zed з проектом Z). У вас є відставання протягом двох тижнів, 5 днів для X та 5 днів для Y.

• Z просить виконати якесь завдання (1 день)
• Ви відповідаєте, що це буде зроблено через 11 днів.
• Z відповідає, що це проста задача і не повинна займати більше одного дня (зауважте, що Z чинить малий тиск).
• Ви відповідаєте, що зараз працюєте на X, а останні на Z. Ви можете зробити її роботу після цього.
• Z відповідає, що ви повинні негайно виконати його завдання (посилений тиск, пряме порушення території X та Y).
• Ви відповідаєте, що виконання її завдання затягне роботу для X та Y. Він повинен їх попросити спочатку. Ви також CC X і Y.

Зараз є два кінці:

• Менеджери почнуть лаяти один одного, багато електронних листів, напевно, якісь зустрічі ... Ви повинні триматися подалі і нехай переможець призначить вам завдання.

• Нічого не станеться, Z попросить вас два дні, де його завдання. Ви відповідаєте, що зараз працюєте на X, і він нічого не згадував про проект Z. Знову CC X.

Тепер такий тип поведінки може звільнити вас. Але ваша ситуація нестійка, і ви, швидше за все, незабаром кинете. Це рішення працює лише в тому випадку, якщо менеджери конкурують один з одним (дуже звичайно). Ви також повинні вести облік вашої роботи (відставання), якщо хтось поскаржиться, що ви збиваєтесь.

Сім років тому я деякий час робив 100% роботи з технічного обслуговування і написав статтю про це: «Мистецтво програмування технічного обслуговування» . Одну частину ви можете виявити корисною:

1. Отримай подобається

Як комусь подобається програмування технічного обслуговування? Розробники мріють бути головними архітекторами у своїх колективах, і коли вони закінчують підтримувати наявне програмне забезпечення, це виглядає майже як покарання. Це не повинно бути: програмування технічного обслуговування має власний набір завдань і вимагає великої кількості творчості, адаптивності, терпіння, дисциплінованості та хорошого спілкування. Це може бути корисним і для вашої кар’єри: ​​наявність у вашому резюме вибухових записів на кшталт «Архітектонізована n-ярусна програма для клієнтів 24/7» виглядає приємно, але роботодавці насправді цінують людей, які вирішують проблеми; та програмування технічного обслуговування може стати хорошим шансом продемонструвати свої навички вирішення проблем.

Ваша проблема звучить як щось, про що ви частіше чуєте. Здається, це робота, яка легко може поміститися на The Daily WTF .

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

Ви також можете прочитати Стіва МакКоннел про технічну заборгованість . У нього є кілька цікавих моментів. У технічній розмові Google Кен Субер розповідає про гнучку розробку програмного забезпечення . Гарна частина - це історія, схожа на вашу. Він розповідає про програмний проект, який після 10 років програмування різними програмістами став "розумним", не робивши жодного рефакторингу . Я думаю, що якщо ви побачите це відео, ви побачите багато подібності до того, що описуєте.

Будь-яка програмна система погіршить якість при її розширенні. Насправді, щоб вислужити це, доведеться. У Леман закони пояснюють цей принцип досить добре. Зрештою, це зводиться до наступного питання: "Як я переконаю вашого начальника зробити рефакторинг?" .

Як я підійшов до подібної проблеми:

• Я зіткнувся зі своїм начальником і пояснив, що якість коду погіршується, коли ми продовжуємо розвиватися ( Закони Лемана ).
• Я спробував пояснити своєму начальнику поняття технічної заборгованості . І те, що він дозволяє вам працювати - це спосіб, який у довгостроковій перспективі коштуватиме йому грошей.
• Для того, щоб фактично показати йому, наскільки серйозна проблема, я (свого часу) зробив аналіз статичного коду. Боси не розуміють програмне забезпечення, але вони розуміють цифри. Хоча показники коду мають свої вади , добре мати щось вимірне, про яке можна говорити. Спробуйте дізнатися, що таке нормальні показання для цих показників, і ви здивуєтеся, порівнявши це зі своєю власною базою кодів.
• Якщо нічого не допомагає і нічого не змінюється, єдине, що ви можете зробити - це пояснити, що певна нова функція потребує певної переробки інших частин вашої кодової бази. Поясніть, що якщо у вас є дублікат коду, і вони хочуть щось змінити, то витрати на зміну також дублюються.
• Загальною відповіддю на попередній пункт буде те, що ніхто не просив і, таким чином, не платив за цю переробку. Що "можливо" ця переробка зайва. Вам доведеться пояснити, що програмне забезпечення завжди доведеться міняти. Як кажуть закони Лемана ; це доведеться змінити, щоб залишатися у використанні. Якщо ні, то інші програми, які змінилися, завжди застаріли. Саме ті, хто очікує змін і можуть пристосуватися до змін, переживуть. Це те, про що йдеться з гнучким розробкою програмного забезпечення . ( Вікіпедія )

Зараз мій начальник використовує поняття технічної заборгованості, щоб пояснити нашим клієнтам, що нам іноді потрібно переробляти частину програмного забезпечення, яке ми будуємо. Просто щоб довести це - якщо у вас розумний начальник, можна змінити речі на краще.

Ситуація, з якою ви стикаєтесь, майже (якщо не зовсім) однакова для багатьох свіжих.

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

На мою думку, компанія, яка забороняє рефакторинг, не варто працювати. Рефакторинг є одним з найважливіших навичок розробки програмного забезпечення, а також інструменти управління версіями роблять його дуже легко розробляти зміни в ізоляції без розбещує «ствол» (в разі рефакторинг фактично робить що - небудь зламати). Як каже дядько Боб (перефразувавши): "Ви не повинні просити бути професіоналом і правильно робити свою роботу".

Програмування технічного обслуговування ніколи не повинно означати увічнення поганого коду.

Я отримав цей електронний лист п'ять років тому від одного свого друга.

Email body:    

Нещодавно приєднаний стажист-інженер запитує у свого начальника, "який сенс оцінювання?"

Бос: "Чи знаєте ви значення відставки?"

Стажист: "Так, я"

Бос: "Тож дозвольте мені зрозуміти, що таке оцінка, порівнюючи її з відставкою"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Стажер: "Так, бос, досить, я зрозумів своє майбутнє. Для оцінки мені доведеться подати у відставку ... !!!"

Якби я був ти, я би витратив кілька пізніх годин після роботи, переробивши програму безкоштовно. Це, мабуть, було б цікавим завданням. Коли ви закінчите це, покажіть це своєму начальнику. Якщо він працює, а ви займаєтесь його технічним обслуговуванням, йому не повинно турбуватися. Це значно полегшить вашу роботу і відкриє очі вищим здібностям на ваш потенціал в компанії.

Я штатний студент коледжу, який працює стажування за сумісництвом за 10 доларів на годину. Я роблю QA речі, які нудні, повторювані та прості. Я вважаю себе надзвичайно щасливчиком, бо знаю, що одного дня це відкриє двері у більші та кращі місця.

Так, вам завжди доведеться підтримувати програми, написані вами та іншими людьми. Єдиний виняток - якщо ви пишете програму, яка ніколи і ніколи не потребує обслуговування. Тож вам краще зайнятися обслуговуванням.

Я думаю, що у вашому питанні є тонкий натяк на недолік у вашому підході. Тобто, виправлення помилок не передбачає вдосконалення коду.

Але тоді я почув, що мені не було дозволено покращувати існуючий код і зосередитися на виправленнях помилок лише тоді, коли повідомляється про помилку.

Я не можу повірити, що хтось сказав вам "ви повинні виправляти помилки, не покращуючи код". Це і важко, і неможливо. Що ви не можете зробити, це переписати програму лише тому, що вам не подобається чи важко зрозуміти підхід, який використовується в існуючій кодовій базі.

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

Деякі помилки насправді виправляються просто рефакторингом, а іноді корисно переробляти, щоб допомогти вам зрозуміти код . Це пояснюється тим, що рефакторинг повинен покращити збереження та узгодженість коду.

Коли я оціню виправлення помилок, я зазвичай прийматиму рішення про те, чи буде основний рефактор найкращим способом це зробити, і врахую це. Те саме з одиничними тестами. Обидві ці речі повинні бути частиною способу написання коду, а не чимось необов'язковим, що передбачає додатковий час.

Тож ви не повинні запитувати "чи можу я покращити код, коли я виправляю помилку?" Тому що ви все одно повинні бути. Ви не повинні запитувати "чи можна використовувати рефакторинг, щоб виправити помилку?" Тому що якщо код, який викликає помилку програми, гостро потребує рефакторингу, ви все одно повинні це зробити. Ви не повинні запитувати "чи можу я писати одиничні тести, коли я виправляю цю помилку?" Тому що ви повинні написати тест на регресію, перш ніж ви навіть почнете намагатися виправити помилку.

NB: Я відчуваю, що певна відповідь на цю відповідь повинна перейти до Джеффа Етвуда, коли я пов’язував 3 його статті.

Це все про гроші. Я здогадуюсь, що ви, як починаючи, ви, мабуть, занадто добрі до клієнтів, які вже отримали більше, ніж заплатили.

Навчіться цінувати нові запити. Це далеко не просто, і клієнти часто випробують вас. Якщо можете, зверніться за допомогою до досвідченого менеджера проекту / продукту.

Коли ви думаєте, що стосується грошей, спілкування з керівництвом стає набагато простіше. Якщо ваші поточні клієнти надають гроші на повний робочий день, вам не слід збирати нові проекти. Але ви зрозумієте, що керівництво все одно намагатиметься змусити вас їх виконувати.

Якщо ви справді цінні для компанії, ви отримаєте переговорну силу. Ви можете попросити їх найняти більше людей, отримати менше нових проектів, допомогти зменшити навантаження на обслуговування або збільшити зарплату.

Це не повинно бути рішенням вашого роботодавця мікромініструвати вас настільки, наскільки вам заборонено вдосконалювати існуючий код. Використовуйте власне професійне судження. Коли ви оцінюєте роботу, я б врахував додатковий час, щоб передбачити деякий рефакторинг, якщо це підвищить продуктивність у майбутньому.

У будь-якому випадку, здається, ви не ефективно спілкуєтесь зі своїм роботодавцем.

1. У вас є докази того, що рефакторинг заощадить гроші. Складіть пропозицію щодо проекту рефакторингу та продемонструйте, скільки часу та грошей може заощадити бізнес. Точно окресліть, які зміни ви внесете до коду та скільки часу це займе.

2. Ведіть точний журнал, щоб записувати, скільки часу ви витрачаєте на кодування, зустрічі та відповіді на електронні листи. Це захистить вас, якщо ви відстаєте від графіка.

3. Уповільнитись. Це може здатися трохи протилежним інтуїтивно зрозумілим, але ваш час буде зловживати лише тоді, коли ви все зробите швидко. Люди поважатимуть ваш час більше, якщо ви зробите менше. Наприклад, я перевіряв би електронну пошту лише один раз або двічі на день. В іншому випадку ви ризикуєте вигоріти.

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

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

Удачі.

На мій досвід, академічний світ чи перші 6-12 місяців технічно орієнтованого старту - це єдині дві надійні області, де ви зіткнетесь із справжнім порожнім сланцем. Вони обидва несуть власні витрати, але якщо ви любите кодувати і часто жахаєтеся за якість коду, який ви дізнаєтесь у дикій природі, вам слід почати вказувати свою кар’єру в одному з цих напрямків.

Спробуйте поговорити зі своїми роботодавцями та подивіться, чи зможете ви вирішити це. Це здається, що ти переживаєш це над головою, і це не має нічого спільного з тим, що ти поганий програміст.

У менших веб-компаній, як правило, відбувається багато проектів одночасно, що багато в чому залишає вас хоч і місце. Або намагайтеся максимально використати свою ситуацію, або намагайтеся знайти нову роботу, якщо вважаєте, що можете. Я обіцяю, що там є кращі завдання з кодування, тому не дозволяйте цьому першим вас налякати.

Удачі, і я сподіваюся, що і ви, і ваші колеги розумієте серйозність або ваші зусилля!

Особистий досвід

Як і багато хто тут, я також визнаю вашу ситуацію. Я в основному отримав свою першу роботу з кодування з низькою зарплатою і повинен був підтримувати багато вбудованого коду з поганою структурою. Спочатку мені було смішно вивчати нові речі, але коли в кінцевому підсумку було багато проектів для підтримки, нових проектів для створення та білої дошки, яка з кожним днем ​​зростала та збільшувалася, я не розумів, це не працювало.

Після того, як мирилися з цим протягом двох років, я відмовився від роботи і через пару місяців знайшов іншу роботу з кодування, яка мені ідеально підходить.

У будь-якому випадку, багато разів це може бути не тільки вашими проектами. Мені зручніше на робочому місці, коли мене визнають і поважають за свою роботу. Проблема з ситуацією, в якій ви знаходитесь, полягає в тому, що ваші роботодавці можуть помічати лише помилки, які виникають у результаті створених проектів, а не час, який ви потребуєте для видалення всіх інших помилок.

Зарплата

Якщо ви хочете більше грошей, часто можете їх отримати. Мені вдалося домовитись про свою зарплату за два роки до підвищення на 33%.

В основному подумайте про цінність вашої роботи та про те, наскільки компанія вам потрібна. Якщо вони не можуть дозволити собі видати зарплату, яку ви заробили, то компанії або потрібно переглянути свої витрати або зрозуміти, що їхній бізнес не працює.

І, як багато хто згадує тут, і я згоден, ви дуже цінний фрагмент загадки компанії. Чорт, ти, мабуть, єдиний, хто може вирішити цю головоломку. :)

Оскільки я поки не можу коментувати, тому що я ховаюсь на цьому сайті Stack Exchange, я просто додам інформацію тут.

1. Оскільки ви тільки починаєте, ваша зарплата не буде зоряною, якщо ви не поїхали працювати у велику компанію, як Microsoft, Amazon чи щось подібне. Але це не повинно бути продуктовим працівником! Не довго мирись з цим, набирайся досвіду, роблячи те, що робиш, і рухайся далі, коли з’являється краща можливість.

2. Для концерту початкового рівня це нормально. Ваша завантаженість зависока, але тип роботи очікується. Щоб стати кращим розробником, ви повинні вчитися на чужих помилках. Чим більше бачиш, тим краще стаєш. Але це означає, що ви шукаєте речі, чому навчитися, а не навчитися шкідливим звичкам ...

3. Співвідношення обслуговування та проектних робіт повинно змінюватися з часом. Якщо це не так, це означає, що компанія, для якої ви працюєте, не розуміє, як зберегти хорошого розробника; вони мають намір змусити вас робити те саме, що день у день. Складіть для себе щорічну мету щодо того, де ви хочете бути, очікуйте зарплату та роботу, і рухайтеся відповідно.

4) Якщо ви не задоволені, залишайте! Життя занадто коротке, щоб мати справу з дурними людьми.

Все найкраще.

Ви починаєте використовувати трекер випуску для відстеження списку тодо.

Це не тільки допоможе вам відстежувати, що є найважливішим, але й допоможе користувачам та вашому начальникові побачити, яке ваше поточне навантаження.

Крім того, якщо вони коли-небудь найнять другого розробника (або ви кинете, і ваша заміна зараз займає ваше навантаження), це допоможе в управлінні навантаженням, і ви зможете уникнути наступу один на одного.

Єдиний спосіб розірвати цей ланцюг - це розробити нові інфраструктури, розроблені для гнучкості та перевірені на повну одиницю + інтеграцію.

Якщо вам вдасться продати це керівництву (підпишіть інших розробників та менеджерів на цю концепцію на зустрічах 1: 1), тоді ви можете повільно дійти до стану, коли більшість кодів програм знаходиться в інфраструктурі, і це легко розширювати та підтримувати, тоді як фактичні додатки мають невелику вагу і їх можна писати досить швидко.

Розвиток інфраструктури може дати можливість спочатку замінити частини існуючих додатків і через деякий час (може зайняти кілька років) замінити цілі програми.

У перспективі це може значно скоротити час розробки нових програм та час обслуговування майбутніх існуючих додатків.

Нова розробка вимагатиме щонайменше 80% відданості (бажано більше) з командою з більш ніж одного розробника (кілька розумів краще одного). Усі розробники повинні мати можливість творчо мислити та порушувати існуючі передумови.

Спробуйте визначити та на високому рівні створити таку нову інфраструктуру, а потім представіть це визначення своїм колегам та керівництву.

Що стосується ваших умов роботи, попросіть очолити нову команду інфраструктури, яка займається цими питаннями (виходячи з ваших визначень та дизайну) та залучіть нових розробників для підтримки старих речей, а ви допомагаєте їм у разі потреби (до 10-20% час). Якщо керівництво погодиться з цією ідеєю, ви можете попросити переговорити свої умови. Будьте готові знайти іншу роботу, якщо вони відмовляться. (Пам'ятайте, що ваша робота вимагає навичок, знань та досвіду. Вас замінити не так просто, як вони вам платять, щоб повірити.)

Чи знає ваш менеджер про всі ці запити на зміни (запити на обслуговування)? Чи усвідомлює він, що ваш час займає просіювання через такі прохання, що ви не маєте повноважень санкціонувати? Або ви просто вносите зміни щоразу, коли вас запитає менеджер?

Мені здається, що ваш перший порт дзвінка - це помістити все на стіл вашого менеджера. Ніхто не повинен прямувати до вас безпосередньо. Питання повинні надходити через когось такого поля - зазвичай це команда підтримки. Звичайно, ви підтримуєте свій код протягом короткого періоду передачі - зазвичай тиждень або близько того. Зміни повинні коштувати та стягувати плату (трансфертна оплата) в будь-якій компанії, яка б класифікувала себе як "середнього розміру", і це, здається, минає сторону (недарма вони вас заполоняють - ви як повія на випускному вечорі).

Повинна бути належна процедура запиту як для підняття питань, так і для зміни запитів. Підтримка / обслуговування - це виправлення помилок та проблем (які відповідають оригінальній специфікації, але не вдається через помилку в коді або зовнішню подію - наприклад, вимкнення живлення або пошкодження системи вгору за течією тощо).

Якщо ваша компанія нічого з цього не пропонує і очікує, що ви впораєтеся і несете відповідальність за це безліч випадкових запитів, то серйозно вам потрібно задуматися про те, щоб рухатися далі. Заробітна плата завжди бідна внизу - в першій роботі з програмування (майже 25 років тому) я витратив 8 років на одну компанію, і моя зарплата зросла мало (хоча вона завжди була набагато вищою за касир!). Протягом 2-х років після від'їзду я подвоїв це - і через два роки я повернувся додому в десять разів більше, ніж я починав (але тоді був незалежним підрядником). Як завжди, заробляйте ви шпорами, вивчайте свою торгівлю і стрибайте з судном у тепліші околиці.

Можливо, ти можеш зайти до менеджера і сказати: "Дивись, я буду відвертий з тобою. Моя оплата жахлива, я міг би отримати N разів більше, ніж програміст початкового рівня в X.

Я роблю занадто багато речей з A, B і C. Я не можу цього підтримувати. Чесно кажучи, і жодних злочинів не маю на меті, я збираюся піти з цієї кімнати з цим виправленим, або з листом, який залишив у вас. Тепер, коли це все в повітрі, як ми можемо працювати разом, щоб зробити це правильно? "

Відповідь - спробувати і пояснити це термінами, які можна зрозуміти;

• Це як зміна масла. Вони не є терміновими .... але все-таки це потрібно робити регулярно
• зафарбуйте іржу, і це буде чудово виглядати. Поки вона не проковтне
• побудувати новий письмовий стіл на даху без кріплення, не підтримуючи опори. Це може працювати деякий час, можливо. Тоді воно розвалиться і зашкодить людям, і ви будете нести відповідальність.
• а / с - це чудово. Віконний блок відмінно підходить для однієї або двох кімнат. Якщо ви поставите 146 кондиціонерів віконного блоку в будинок, у вас виникнуть проблеми.
• Навчити 5 дітей добре. 10 не надто погано. Але існують обмеження. Спробуйте неофіційно навчати 75 дітей, і ви це побачите.

Якщо вони не резонують. Залишайте - ДЕНЬ, ЩО ВИ ПРАЦЮЄТЕ ПРОПОНУ НА ПИСМУ, не наступного дня! Як тільки у вас є нова робота, залиште повідомлення про ZERO. Буквально просто не приходьте в цей день. Але переконайтеся, що у вас є колега чи двоє, які знають, що ви робили. Це фактично допоможе компанії вийти, якщо компанії можна допомогти, показавши їм, що їх неповага та зарозумілість приносять свою ціну. Остання компанія, в якій я був у ТРИХ ЧАСТИХ ЧЕТВЕРХ ТЕХНІЧНИХ ВІДПОВІДІВ, ВІД 6 МЕСЯТІВ, БЕЗ РОБОТИ НА ДІЯЛЬНІСТЬ. Принаймні, вона зробила заяву і дала людині, що покидає людину, один раз хороший шанс сказати: "Так, приємно, що ви говорите щодня, але ви так наповнені цим, я навіть не даю вам задоволення від мого повідомлення.

Нарешті, знайте, що ця ситуація була НОРМ і стандарт 20 років тому, перш ніж спритний, tdd, bdd та рефакторинг стали більше нормою. Ви можете розмовляти зі старшими людьми, які негайно відповідають: "добре, я це зробив сам, і це спрацювало чудово, бла, бла, бла". Добре, коні та вагони добре працювали 150 років тому. У галузях технологій техніка 20 років тому застаріла, як і перевезення, як 150 років тому. Якщо вони відхиляють цей штраф. Тільки знайте, що вони ніколи не наймуть гідних сучасних розробників технологій, які будуть триматися. Вони отримають найгірше і найгірше, і це страшенно зашкодить їхньому бізнесу. Якщо вони залежать від технології і не зможуть адаптуватися, вони вийдуть з ладу, і в кінцевому підсумку це може бути найкращою нагородою для вас. Це '

Здається, ваше керівництво принципово не поважає вас і не розуміє вашої навантаження на роботу.

Ви не повинні реалізовувати кожен запит на функцію, який надходить. Ваш менеджер повинен діяти як буфер між вами та вхідними запитами (крім, мабуть, найпростіших запитів на розрив / виправлення). Тоді він повинен сісти з вами та визначити доцільність та пріоритетність будь-яких схвалених запитів.

Крім того, ви повинні, мабуть, робити 2x (принаймні) те, що вони вам платять.

Це здається, що їм, мабуть, справді потрібен принаймні ще один розробник, щоб працювати поруч з вами, але з тим, що вони вам платять, це здається дуже малоймовірним.

Якщо вони не бажають адекватно платити вам або допомогти вам керувати вашим навантаженням, я б шукав нову роботу. Ви хочете працювати там, де ви є частиною команди , і де ваше керівництво працює з вами, щоб завершити ваші проекти. Зійдіть з того потопленого корабля, як тільки зможете.

Бути героєм у команді одного лише випалить вас.

Я лише студент (все ще), але це цілком нормально (зі свого стажування). Ось що ви отримуєте, працюючи в службі підтримки та веб-додатків.

Я б порадив вам зрозуміти, що хоче клієнт (менеджер), перш ніж розпочати кодування. Це може бути хитро, бо іноді вони самі цього не знають, тому працюють з ними, поки не домовляться про щось. Переконайтеся, що ви обоє погодилися на остаточне рішення, перш ніж його кодувати.

Крім того, якщо ви є обслуговувачем, ви можете значно змінити що-небудь у коді - просто переконайтеся, що це не змінить поведінку або вводить помилки. Я очікую, що менеджери не дозволяють вам щось змінити, оскільки вони звикли і задоволені тим, як зараз, і вони не хочуть платити за будь-які нові зміни.

Нарешті, не хвилюйтеся, якщо ви не можете щось впоратися, тому що ви робите щось інше. Я б радив повідомити людям, що ви перевантажені роботою, і їхнє прохання потребує часу. Якщо ви не менеджери, просто подумаєте, що ви ліниві. Дайте їм знати, що у вас вже є робота, і вони можуть найняти більше людей. Немає іншого способу зрозуміти, що роботи надто багато для однієї людини.

Це проблема управління проектами. Використовуйте якесь управління проектами, щоб вирішити, над чим найвищий пріоритет.

а) Вам потрібні відставання елементів, над якими можна працювати. Ви розміщуєте свій план вдосконалення коду у відставанні.

б) Усі помилки переходять у відставання

c) Відставання стає пріоритетним.

г) Ви робите це все в пріоритетному порядку.

Помилки можуть бути вищим пріоритетом, але якщо ви виправите все, що у вас є цикли, витратити їх на нові функції або на дизайн рефакторингу.

Найпростіше, якщо ви просто робите вдосконалення рефакторингу поступово, переходячи через розділи, які мають вирішити проблеми / помилки. Тоді ви можете сказати керівництву: "Мені довелося виправити A, але B принципово порушено, і я повинен був зробити рішення C, щоб виправити все це, щоб D було в майбутньому легше / дешевше" Де A = помилка, B = антидіаграма, C = рішення, D = прибуток у майбутньому

Якщо ви не можете виправдати роботу як інвестицію, яку варто зробити, ділові люди її ніколи не приймуть.

Це бізнес як завжди. Ви будете експлуатуватися до тих пір, поки будете продовжувати працювати там, як здається. В інтересах компанії продовжувати рухатися з цією моделлю, а не робити так, щоб ви відчували себе щасливими у тому, що робите. Коли справа доходить до цього, вони насправді не хвилюються. Йдеться про те, щоб створити для них надійний код, і якщо ви людина-група, вони, безумовно, зроблять з вас банк. Чому вони міняться?

Хороша новина у всьому цьому, що ти VIP для них, навіть якщо вони цього не знають. Я пропоную зробити ще кілька можливостей перед стрибком корабля, а потім захопити їх за кульки та вимагати більшу зарплату. Якщо не перейти до кращої можливості. На мою думку, незабаром вам слід знайти якусь цікаву роботу. Прагніть якомога вище. Потрапивши до магазину розробників, ви будете набагато щасливішими, як Google або веселий стартап, де є культура спільної роботи для розробників, де ви будете справді відчувати себе щасливими.

Що я особисто зробив, це використовувати організацію підрядника на підрядника і швидко отримав багато чудових вражень під своїм поясом, переходячи від одного до іншого, зберігаючи стабільну зайнятість у мого підрядника. Це не дає вам нудьгувати і кидає вам виклик. Врешті-решт, у вільний час я створив невеликий бізнес, який перетворився на справжній бізнес, і тоді я стрибнув судно з виконання контрактних робіт.