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

Work Hard & be nice to pplОтож, що таке веб технології для мене:

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

Вже один пост про моє відношення до роботи є: Work’n’Me. З того часу не багато змінилось: я як був трудоголіком, так і далі успішно продовжую це робити. Але все ж таки, пару свіжих думок назбиралось і треба оформити їх у формі набору чарівних букв кирилиці 🙂

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

It’s Time Management baby

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

В певній мірі мотиватором до цього допису був допис іншого ІТ-працівника про те як зібратись і написати документ коли то дуже треба але нема натхнення. Там правильні свого роду речі пишуться, але в мене воно не користується попитом. Чому саме, ось власне і пишу:
Відколи я, мене будь-які обмеження в часі дуже демотивують тому ні “помідори” ні інші часові техніки мені не допомогають. А допомогає усвідомлення потреби виконання роботи. Я не пошкодую ночі і посиджу в екселі чи у ворді чи пптшку оформлю хоч до 6 ранку чи до 12 ночі на роботі. Найдивніше, що такі випадки мене більше мотивують до роботи, аніж обмеження в часі.
Але все ж таки один із моїх документів (правда не по роботі) на 100 ст, я писав десь 3 роки (то постійні апдейти з оверал ревю), і в процесі я завжди вчився як краще описувати, як краще пам’ятати нотатки, як не забути зв’язки між секціями і таке інше.

Перемикання мене теж демотивують. Не те щоб мені важко переключатись, аж ніяк – деколи по 5 задач одночасно роблю. Недавно писав в твітері:

Підчас білда мого #maven #java #jsp #liferay#javascript #css #sass проекту, я встигаю глянути соціалки 🙂 А інші курять та пють каву 🙂

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

Я відчуваю втому, тоді коли в мене нема бажання щось робити, навіть музику слухати не хочеться. Але це буває в мене 1-2 рази на місяць. Після роботи, мені завжди щось хочеться ще робити, якщо не читати блоги технічні, то писати про це самому. Це я до того, що робота не вимучує, якщо вона тобі подобається, якщо вона тебе драйвить. Але не приховаю, бувають і моменти ліності – приходжу з роботи, як вижатий лимон, ледь дойшов. І як пише Оля, теж провтикую важливі речі в житті 🙂

Self-Organization and Self-Motivation

От що що, це в мене було ще з перших класів. Мене ніколи не треба було заставляти вчитись. Я см приходив з школи, робив задачі, і йшов гуляти, чи щось читати, чи робив задачі на наступний день (останнє було найбільш поширене в мене :))
Таке й в роботі. Мені не треба інших мотивацій – я їх вдосталь маю – робота як процес, вже є мотиватор. Я ставлю собі цілі, задачі, виконую їх, і не шкодую ні часу ні самого себе. А гроші? Вони й так будуть, куди дінуться.
Я завжди зможу організувати свою роботу згідно поставлених мною чи кимось цілей. Якщо не маю задач, я собі находжу. Були навіть випадки – коли мене звинувачували – “Чувак, нема роботи, забий, не шукай собі гемора”. А я так не можу, я за 8 год робочого дня працюю, мені за це платять гроші, я не маю права халявити, я маю вкалувати, і то по страшній силі. Гроші то не маленькі. На мене покладають надії, відповідальність.

Trouble-Shooting

Я люблю покопатись в коді. Навіть який би JRE не був страшний, і всі Java-фрейморки, мені завжди було цікаво робити навігацію по зв’язках між класами. Це якщо хочете – “Броділка” по лісі чи по лабіринті, коли ти не знаєш що тебе очікує в кінці.

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

Я не полінуюсь написати #bash скріпт щоб автоматизувати мою будь яку роботу.
І результати такої моєї роботи мене будуть більше мотивувати ніж будь що (ні спортзал, ні ЗП, ні корпоративні бухаловки, etc.)

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

 

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

– про детейл орієнтед гіка.

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

  • Одні кажуть інші – “А що це якось впливає на проект?”
  • А інші кажуть – “Воно ж працює всьо!”.
  • Треті кажуть – “Та забий, то фігня!”
  • А я ж кажу – “Є правило – дотримання подібності середовищ у всій в команді, щоб зменшити кількість різних помилок”. І я знаю що я 100% правий, бо вже багато раз приходилось після таких героїв підфіксувати їхні ж трабли.

Приклад 2: Не раз стикався. Є проект, на ньому признана офіційно ІДЕ (чи то Eclipse чи то Netbeans, чи IDEA). Приходять нові люди в команду, і використовують свої ІДЕ, свої конфігурації робочих енвайрментів. І що, знову ж я кажу – правило для всіх має бути однакове. Навіть якщо я хочу щось інше, я то використаю тільки після того, як офіційно всі погодяться – на рівні проекту це затвердити.

Приклад 3: Я ніколи не поспішу і не скажу – “Та що там того робити – перейти з SVN-а на GIT. Фігня”. Я завжди знаю, є правило – ГЛОБАЛЬНІ зміни на будь якому рівні вимагають ретельної підготовки, імплементації та тестування. І такі да 🙂 Потім задача яку героїчно хотіли подолати за пару хв, розтягнулась на тижні.

Приклад 4: Це просто пошесть якась, або я звихнений на правилах. Код треба оновляти завжди. Не важно чи це тобі треба, чи то якось з тобою повязано, чи взагалі пару мікро змін. Codebase завжди має триматись чистою, up-to-date, і такою, що в будь який момент твій тім мембер підійшов до тебе і спитав допомоги. А ти блін йому – “ой ще не апався”. І всьо – цікавість до співпраці пропала, момент упущений. Тепер тратиться час, і тд тп … лізуть незрозумілі баги-полтергейсти і тд тп знову.

Але я схильний ламати процеси на ходу.

Сам був дуже здивований, коли мав таку ситуацію: Замовник сайту думає про своє, про свій продукт, а ми йому “впароюємо” інфо згідно захмарних для нього методологій, метрик, апроачів, і тд тп. Замовник ніби фоловить всі ці правила, але це ж людина – вона хоче human readable content. І ось була ситуація коли Ми подали замовнику інфо згідно наших процесів, згідно “Як книжка пише”, а Він каже – “дайте мені по-простіше”. І якого ж великого рівня було моє здивування, що я усвідомив, що не процеси для людей, не процеси мають керувати людьми, а люди мають на все це закладати якесь значення своє. І людям процеси як мінімум мають бути вигідними, а не ускладнювати життя.

Здивований тим, що простішу версію представлення інформації запропонував я, і чисто випадково, чисто з підходу CPOW (Client Point of View). Тобто спробувавши стати на місце клієнта, бажано в першу чергу розглядати його як людину, яка лінива, і хоче все по простому.

Only Functionaly finished code

Страшенно не люблю кодати пів функціоналу. “Ви мені тут от заплатку поставте”, “Ви мені поки що це не робіть а зробіть це, а то потім”. Це тупо. Треба робити все зразу і все ідеально. Для прикладу – CRUD має бути завжди складатись з усіх 4-ох складових. А не – “Створення” зробили а “Видалення” забули, Створити щось можна,  відредагувати ні. І що? А код то пішов на продакшн до клієнта. І як клієнт видалить кривий запис? Ручками з Бази? навряд він такий розумний. Більше того – така методика подання роботи клієнту, портить лице компанії. Тому коли ви пишете код, подумайте в першу чергу про рейтинг вашого роботодавця, про те, як про нього будуть відкликатись клієнти і їх друзі.

Visualize ’em ol

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

No Freelance

Я не роблю іншої роботи окрім поточної роботи в поточній компанії. Я б сказав це як правило, як заповідь, як квінтесенція. Мені багато кажуть – “Та ти не шариш, то жінка хоче шубу, то діти тянуть, то це то сьо …”. А деякі кажуть “Мене ця компанія не влаштовує, то не компанія то х-ня, тут проекти не цікаві”. Я завжди звичайно знаходжу точки перетину з такими думками. Але загалом завжди собі кажу – Я можу вкалувати 8 год і більше, але я буду це робити НЕ ПОЗ-ЗА ГРОШЕЙ, вони мене не мотивують, а поз-за проекту, на якому я є. Якщо б мені не подобалось щось – я б сказав моєму Карєр Адвайзору і ми б найшли методи вдосконалення умов праці. А ні то б звалив з фірми.

First quality, then quantity.

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

Мав нагоду на днях проаналізувати онлайн магазини та їхні UI-ні баги 🙂
Як і завжди по сайтах, перше що я  бачу на них – це якість виконання, а потім вже зміст.
Випадок з багом в фільтрах на сайті – ти шукаєш продукцію, тобі це важливо, фільтр пошуку видає результати, ти на них надієшся, а вони потім виявляються різні, залежно від сайту. Добре що я спробував пару сайтів і порівняв їх. А що буде з людиною, яка перший раз побачила і вона ще крім того дуже довірлива?! Так вона буде базуватись вже на не точній інформації.

Або інший випадок на сайті з кредиткою. Йду собі такий впевнений по кроках реєстрації, потім в кінці каже: введіть кредитку, гроші зніматись не будуть, це для безпеки і гарантії букінга (бронювання). Я вводжу, думаючи що нікуди мене не кине, адже я вибрав оплату готівкою. І тут на моє здивування редіректає на сайт приват банку. Я ж звичайно вертаюсь назад – бо подумав, може я не правильно вибрав. І так 3 рази. Потім приходять мені 3 імейли про 3 букінга :). НУ ЩО ЦЕ ЗА ТУПІСТЬ програми? Чому не продумано такий простий приклад?

Тому пару таких випадків, і я прийшов до думки:

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

І як я завжди кажу – щоб там не було, який би замовник тебе не підганяв:

  • ПРАЦЮЙ ЯКІСНО, а не кількісно.
  • Вимагай деталей від логіки функціональності.
  • Піддавай сумніву всі технічні вимоги.
  • Задавайся питаннями, навіть якщо тобі здається, що вони тупі.

Testing

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

Знаєте, я таке відчуття коли ти боїшся доторкнутись до гарячого, і або схрещуєш пальці або молишся, щоб білд чи тести тільки пройшли б успішно. Ну так от в мене аткого нема 🙂 Як тільки білд пройшов, зразу ж за ним інший, ще і ще і ще і ще … нема коли молитись і надітись що буде успішно. ВСЕ БУДЕ ПОГАНО, і я готовий до цього, я жму, і йду далі, фіксаю, вирішую.і .. ставлю крапку. От тоді можна і молитись 🙂

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

Better with no trolling.

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

Recognition

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

Feedback #1
4
Feedback #2
1
Feedback #3
2
Feedback #4
3

Десь, так 🙂 Далі буде.

Advertisements