Кваліфікація колег-програмістів: очікування і реальність

«Кращі програмісти не трохи краще хороших. Вони на порядок краще за будь-якими мірками: концептуальне мислення, швидкість, зображальність і здатність знаходити рішення. »
– Rendall E. Stross

Напевно ця цитата добре відображає поняття кваліфікований програміст. Але в світі не все так чудово. Кількість років роботи програмістом не завжди прямо пропорційно наявності відповідного досвіду і знань.


Далі розглянемо (з життєвими прикладами), на що потрібно звертати увагу, щоб наблизитися до мети стати «кращим» програмістом.

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

Коли потрапляєш в колектив, мимоволі починаєш оцінювати здібності оточуючих, особливо старших колег. Це буває корисно, якщо видасться можливість самому вибрати, в чиєму проекті прийняти участь. Отже, отримавши керівну посаду (минаючи етап становлення хорошим розробником, тобто майже відразу після універу), хтось може вирішити, що все, від нього більше нічого не потрібно у професійному зростанні, можна задовольнятися знаннями, отриманими під час навчання в універі і досвідом роботи 2 роки, до того ж з неповною зайнятістю. Подальший саморозвиток таких людей обмежується знаннями і навичками, отриманими по ходу необхідності для проекту і з курсів, оплачуваних фірмою. Працювати з такими людьми взагалі ніякого бажання немає. Адже в той час, як ти прокачиваешь свої скіли, керівник неохоче щось вивчає, коли доводиться. І це в кращому випадку, а то «я керівник», тому напружу кого-небудь іншого, а мені нехай перекажуть в двох словах, про що там «Війна і мир». А ще напевно майже у кожному колективі є люди типу «OK Google», тому навіщо паритися. Адже мотивації для підтримки і підвищення професійного рівня майже не залишилося: керівну посаду отримав(а), грошової мотивації відповідно теж немає, ну про професійному відповідно такі люди мабуть взагалі не замислюються. Та й не особливо-то вони прагнуть навчати когось, що власне є їх обов'язком. Пам'ятаю, коли ще вчилася в інституті, знайомий (старше мене ) сказав, що його підвищили до начальника відділу (у 25 років). На питання, скільки людей у нього в підпорядкуванні, він посміхнувся. Фактично в його відділі ще 2 людини, але вони не його підлеглі. Через рік у цієї людини ситуація не особливо змінилася.

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

Потрібно знати про програми, якими користуєтеся
Сподіваюся, що у всіх компаніях використовуються системи контролю версій. Ми використовуємо SVN. Один із сумних фактів, що багато хто не знають в загальних рисах, як працюють системи контролю версій, чим відрізняються розподілені від централізованих систем. У деяких проектах у нас задіяна робота з базами даних (використовується Postgres). І ось одного разу чую від одного товариша, що Postgres використовується для зберігання комітів. Людина навіть і не підозрює, що в SVN своя структура зберігання інформації. Ось сказали йому, що є команди add, ignore, commit, update і checkout і все, на цьому його знайомство з продуктом закінчено. Коли потрібно просто викачати якусь конкретну версію проекту (без історії всіх фіксацій), деякі навіть і не підозрюють, що є export (одного разу я наткнулася на збіговисько з чотирьох осіб, які вирішують це питання).

Але сама безглузда ситуація складається, коли кілька людей змінюють одні і ті ж файли. І як же тепер закоммитить !? І чуєш: «Як? ти теж щось змінював у файлі x.cpp і Y.cpp? Стій поки не коммить! Хтось один зробить це, а відсутню інший додасть». Виникає зустрічне питання: а навіщо тоді створювалася можливість розв'язання конфліктів? Все одно, якщо хтось зробив комміт, ти спочатку выкачиваешь його, а потім занести свої зміни. Не треба думати, що система контролю версій – це просто звалище внесених змін, у якої відбувається присвоєння версії конкретному станом файлу/проекту. Якщо при спробі зробити комміт виникає конфліктна ситуація, то це не значить, що ви зробили фіксацію і проблемні файли збереглися в системі контролю версій. Потрібно розуміти, які операції виконуються в робочій копії, а які в репозиторії. Тупо виконувати операції і вважати, що сталася «магія» не потрібно.

Потрібно мати уявлення про моделі OSI/ISO
Кожен хоч якось перетинався з якимись поняттями з мережевої моделі. Ось реальна історія, в якій необізнаність і наявність повного розуміння про деякі речі грає злий жарт. Як виникла задача роботи по інтерфейсах RS-422. Ну а чому б не взятися за це, адже робота буде з COM портом, залишилося почитати про особливості самого стандарту RS-422. І тут у мене запитує один із старших програмістів: «Вже був досвід роботи з RS422/485 ?» Відповідаю, що ні, все одно вже працювала з послідовними портами, так що розберуся. І тут я бачу здивоване обличчя людини, яка починає чомусь впарювати (для ясності: у нас до цього ніхто не працював з RS422), що обмін буде не по послідовному порту. Тобто у нього взагалі немає уявлення, що таке стандарт фізичного рівня і інтерфейс, використовуваний для здійснення обміну.

Можливо, не всі за свою кар'єру програмістом працювали з Bluetooth, pipe, share memory, RS-422, Ethernet і ін Але програміст повинен розуміти, що якщо він вміє працювати по послідовному порту, то зможе виконати обмін і по Bluetooth, і RS422/232. Потрібно розрізняти рівні ISO/OSI. Не потрібно робити проблему, коли виникає завдання написати програму для обміну по UDP, а ви раніше писали лише обмін по протоколу TCP.

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

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

Звичайно, цей список може продовжуватися, а перераховувати виникають безглузді ситуації можна досить довго, але я не про це. Мені здається, що дуже важливо бути обраним в якості керівника проекту, щоб Вас поважали як програміста і керівника. Коли видається вільний час, не потрібно з півдня тупо сидіти в телефоні/планшеті, щоб пограти або подивитися серіал. Все знати не можна, але в тій чи іншій мірі потрібно бути освіченим у технологіях, архітектури та ін. Адже дуже нерозумно виглядає, коли 2-3-річний досвід роботи молодих затуляє 10-річний стаж простого просиджування штанів. Я зустрічала різних програмістів, і ця стаття відноситься до меншості з них. Але тим ні менш пам'ятайте, ви повинні бути(або хоча б прагнути бути прикладом для молодого покоління.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.