Самооцінка програміста: три правильних і три хибних способи скласти собі ціну

Рано чи пізно це таки трапляється.

Тімлід призначає зустріч, на якій сором’язливо виставляє перед тобою папірчики з написом «Performance improvement plan». Або команді представляють нового техліда, і це зненацька не ти. Або СЕО ненароком кидає в курилці: «Певно, все ж треба було найняти професіонала на позицію СТО». А ти до цього конкретного моменту вважав, що ти і є професіонал!

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

Такі моменти завжди приходять, як грім на голову, і підготуватися до них неможливо. Апостеріорі, звісно, мозок підсуне тобі сотні причин, чому так сталося. Чому ж він ховав їх десь у глибині аж до цього моменту?

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

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

У вивченні будь-якої мови головне спочатку чітко сформулювати початковий рівень: дивитися японські серіали без субтитрів відразу після вивчення катакани — явно необачно. Так само, як і повторювати тисячу разів «май нейм із Вася» з різних підручників для початківців і вважати, що англійська тобі «просто не йде».

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

Перший хибний: авторефлексія

Нема нічого простішого, ніж сісти і подумати: «Хто я, який я і чи право маю?». І водночас нема нічого безглуздішого.

Людська пам’ять — дуже потужна система зберігання даних, але водночас дуже своєрідна. Зробити «SELECT *» тут не вийде, спогади виникають на позір абсолютно випадково, але насправді користуючись одним патерном — раціоналізацією фактів навколишнього світу.

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

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

Ілюстрації Каталіни Маєвської

Кожна подія в людській пам’яті, прямо як у мультику «Inside out», має аспекти, коли ти проявив себе круто, і аспекти, від яких рука тягнеться до фейспалму і хочеться сховатися під стіл від сорому. Залежно від теперішнього настрою, пам’ять підсовуватиме відповідну сторону всіх подій.

Модель, побудована на основі таких однобоких даних, буде як мінімум некоректною, а як максимум — не матиме нічого спільного з реальністю.

Є кращий спосіб.

Перший правильний: спостереження

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

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

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

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

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

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

Другий хибний: порівняння

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

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

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

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

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

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

Порівнювати себе з іншими — погана затія, зрозуміли. Натомість, кажуть, варто порівнювати себе із самим собою, тільки в минулому. Що ж, це, безумовно, краща ідея, але теж абсолютно безглузда. Двадцять років тому я, наприклад, трохи гірше програмував. Зате прекрасно лазив по деревах і підтягувався на перекладині двадцять разів. В мене нічого не боліло, я був безтурботним і насолоджувався кожним днем. І хто після цього в переможцях?

Найгірше працює «порівняння із собою» після виходу на плато. Коли швидке зростання тимчасово закінчується і починається важкий і довгий, але дуже важливий проект. Два роки тому Ілон Маск займався електричними машинами і космосом, і тепер Ілон Маск займається електричними машинами і космосом. Ніякого зростання і розвитку. Стагнація.

Другий правильний: вимірювання

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

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

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

Наразі це досі відкрита проблема. Компанії створюють різні «рівні», «треки», «потоки» з абсолютно розмитим набором вимог, спеціальні комісії для аналізу цих вимог і купу багатолюдних зустрічей виключно з метою зміни якоїсь циферки десь там в особистій справі. Добре ще, коли це робиться правильно і має якісь наслідки (збільшення рівня впливу, зростання зарплати, більша кількість підлеглих). Але часто циферки (чи безглузді лички) виставляють просто так, для імітації процесу «кар’єрного росту». Тоді біда.

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

Погані новини: перевести самооцінку в конкретні цифри не простіше.

Хороші новини: деякі способи таки є.

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

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

Головне, щоб будь-яке число мало сенс конкретно для вас і ви мали хоч якийсь вплив на його значення. Наприклад «кількість юзерів, які скористалися новою фічею» в даному контексті дає небагато. Адже від якості вашого коду популярність фічі не залежить практично ніяк. Зате критерієм «відсоток поламаних білдів через мою неуважність» вже можна керувати.

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

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

Третій хибний: фідбек

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

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

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

Ще складніше буде, якщо у вас немає регулярного зворотного зв’язку і ви просто вирішили про це спитати. По-перше, з наскоку, правди вам ніхто не скаже. Якщо ви не соціопат, ставлення команди і менеджера до вас буде як мінімум стримано-привітне. Тому максимум, що ви отримаєте — це відповідь в стилі «та нормально ти перформиш, забий».

А якщо ви продовжуватимете допит, на перше місце вийде вже саме формулювання питання.

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

Саме тому для отримання результату, максимально наближеного до реальності, і мінімізації подальших збитків треба формулювати все максимально нейтрально, підготувати набір минулих ситуацій, свої дії в них і питати щось у стилі: «що можна було зробити краще?», «що було зроблено добре?» і так далі. Тільки в такому випадку цінність такого фідбеку буде високою.

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

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

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

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

Тому для об’єктивності варто спробувати щось інше.

Третій правильний: експеримент

Тут як у старому анекдоті. «Ви вмієте грати на фортепіано? — Не знаю, ніколи не пробував».

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

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

Можна вважати, що «при потребі розберуся з тим проектом», але при першому завданні отримати шок і надовго загальмувати прогрес. А можна навпаки, пів життя вважати «я туди не полізу, там дуже складно», а потім, коли припече, розібратися за кілька днів. Те саме діє з керуванням командою, побудовою продукту з нуля, зміною стеку, ну і так далі. До того, як ми спробували вирішити проблему, її складність невизначена, і будь-які оцінки будуть мати нульовий зв’язок із реальністю.

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

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

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

Ну і в кінці все зовсім просто: ми цю гіпотезу перевіряємо і записуємо результати.

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

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

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

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

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

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

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

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

***

І наостанок. Серед спортивних психологів поширена практика формування у своїх підопічних двох абсолютно незалежних систем самооцінки. Одна, «повсякденна», знає про свої справжні можливості, обмеження, можливість помилитися.

Інша система, «змагальна», вважає себе непогрішним божеством. Тому, що тільки повністю повіривши у свою обраність, непереможність, неможливість програти, можна ламати незримі бар’єри і стрибати набагато вище голови.

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

Все ви зможете.

І все у вас вийде.