Спільното, у всіх же бували ситуації, коли виконана колегами робота вас дивувала — в нехорошому сенсі цього слова. Як ви казали про це?
«Я думаю, що ми повинні переглянути рішення», «З усією повагою...», «На жаль, це не відповідає нашим цілям» — знайома історія?
Пишіть у коментарях, як зазвичай ви «підбираєте слова» у таких випадках? 😄
— мда, хто це таку хрінь написав
*перевіряєш git blame*
— oh shit
Якось довелося одному тупому джуну відправити ось приблизно таке посилання:
www.youtube.com/shorts/cAT2ryLVIuk
Це був просто епічний чювак: таке враження що він останні 3 роки сидів у в’язниці і вивчав програмування по книжках на комп’ютері зліпленому з хліба. Він добре відповідав на теорію — його узяли, але на комп’ютері він тупо не знав що і як робити. Одного разу він у системний PATH насував якоїсь херні. Два робочих дні уся команда намагалася зрозуміти чому на його комп’ютері навіть калькулятор та блокнот крешилися.
Випробувальний термін зазвичай два тижні. За ці два тижні він не зміг навіть налаштувати свою робочу машину! Йому подовжили випробувальний термін і дали просту задачу — прибрати мертвий код. До кінця другого тижня він вже з роботи не виходив — ночував в офісі. І ніщо не допомагало! Йому можна було показати на своїй машині що і як треба зробити — а він потім приходив і казав що у нього не працює — і кожен раз з різними помилками. Кажуть що є люди, від самої присутності яких техніка виходить з ладу — про нього я б у таке повірив.
Останній день йому сказали: або він робить таску, або — до побачення. І він ЗРОБИВ — і запушив відразу у майстер.
Наступного дня було саме як у відео. Пікантності додало що менеджер продав цього джуна клієнту як синьйора (клієнт хотів команду одних синьйорів). Після цього наступних «синьорів» спів-бесідували вже люди з боку клієнта.
якщо код ревью — то просто комент чому це не підходить, максимально сухо, з прикладом як треба. Або посиланя на частину документації де описано як треба робити чи як не треба. Колись бісився і пробував доказати, мітинги проводили. Але для багатьох це марні витрати часу. якщо дизайнер намальював щось дивне — якщо можна швидко навесрати і показами МВП- то так і роблю, і після оцінки зі сторони менеджері — дизайнер переробляє як треба. мінімум слів, в технічних задачах вони лише заважають
Найгірше, якщо колеги чи особи, які працюють над проектом, іноземці. На і так жорстке формулювання фраз, яке в українців дуже важко і довго правиться, накладається потреба висловлювати критичні зауваження. В таких випадках, здається, краще вже бути щиро грубим, щоб списали на культурну різницю, ніж пробувати пробігтися між краплинками неписаних правил і забобонів.
В мене був випадок, коли колега формально абсолютно вірно вирішив задачу, але зробив це в такому стилі, що код залишався крихким і не дуже так щоб сильно maintainable. Причому він не погіршив якості коду, просто не зробив рефакторинг, який я зазвичай робив в подібних випадках. Я йому повідомив, що я не дуже хочу апрувити його PR, оскільки не хочу бачити такий код в production. Він сказав, що не хоче ніяких конфліктів. Я сказав, що теж не хочу конфліктів, тим не менш, PR апрувити теж не хочу. Врешті решт втрутився менеджер і ми домовилися, що я знайду приклад «гарного» вирішення подібної задачі. Приклад, на щастя, знайшовся доволі легко і ситуація була розв’язана відносно швидко.
На мій погляд, у подібних випадках важливо дотримуватися трьох правил.
1. Ні в якому разі не погоджуватися на додання погано зробленої роботи в головну гілку. Принаймні не брати на себе відповідальність за це. Звісно, з будь-якого правила можуть бути виключення. Якщо, наприклад, це фікс бага, який знайдено на проді і яким клієнт вельми незадоволений і чекає на фікс якомога скоріше, проте фікс формально вірний, можна і треба зробити виключення. Проте повернутися до питання пізніше.
2. Бути максимально ввічливим і не припускати найменшої неповаги до колег. Навіть якщо работа зроблена відверто погано, критикувати можна тільки конкретий кейс/підхід/рішення, ні в якому разі не колегу.
3. Критика має бути максимально конструктивною мати ціллю допомогти колезі прийти до кращого рішення. Можна щось підказати, поставити слушне питання, можливо навіть надати приклад кращого рішення. Залежить від обставин.
PS Мене також дико бісить коли колеги починають критикувати мою роботу. Принаймні раніше діко бісило. Проте, бувало таке і не раз, коли така критика допомогала зробити роботу краще. Тому намагаюсь в таких випадках також бути максимально конструктивним. Якщо недоліки дійсно є, краще їх виправити і подякувати колезі, що помітив. За допомогу завжди варто дякувати. Якщо критика не виглядає конструктивною, треба з’ясувати всі деталі і докопатися до істини. Найкращий способ вчитися у колег — обговорення складних і неоднозначних кейсів. Якось так.
Зазвичай кажу чому треба щось змінити чи доробити, але був кейс, який я досі пам’ятаю:
була в мене команда з 25 розробників і QA, вона зросла з 5ти і я вже запромоутив лідів, розбивав на підкоманди і було таке коли лід йшов у відпустку — то я вже менеджив команду, там зазвичай було десь 2 джуна на 5 людей.
Так от ці джуни «зробили» таску і хотіли показати, там треба було добавити якийсь функціонал з кнопкою до форми у стилі проекту. Добавили, поряд еталонна кнопка, і їх франкінштейн з рандомними відступами, інший «зелений» колір, коса крива і т.п.
Я їх запитав — «Шо це? Де ваше відчуття прекрасного?»
З часом розмовляв з їх лідом і він сказав що вони образились і почали уникати мене :) Я звісно трохи перегнув, але і якщо завжди гладити по голові за відверте гівняну роботу — то дійдемо до медалей за дропнуті БД у продакшені (до речі я таке теж бачив від американського сінйора у своїй команді, потім займався дізазстер рекавері, бо дропнутий БД аккаунт в Ажурі відновити займає деякий час через сапорт)
то дійдемо до медалей за дропнуті БД у продакшені (до речі я таке теж бачив від американського сінйора у своїй команді, потім займався дізазстер рекавері,
I know that feel, bro! :)
дропнуті БД у продакшені
Можливі лише, якщо ти вносиш правки напряму на продакшн. Що по факту, — вина людини, яка задизайнила процеси.
було значно цікавіше і воно не пов’язано з процесами.
Є така штука Azure CosmosDB, вона живе у своєму БД аккаунті в Ажурі, в нас був проект пов’язаний з генерацією ПДФ в який люди пхали емодзі, ті хто працював з емодзі розуміють усю біль бо там є багато комбінованих і якщо вони один за одним йдуть і їх багато — то могли бути баги і треба було регенерувати ПДФкі власноруч поки відлагоджували логіку. Коротше кажучи доступ до прод БД мали тільки топ тір інженери, і саме цей хто дропнув користувався плагіном для ВС код для роботи з Ажуром, і коли ми перестали займатися активною підтримкою цього проекту він хотів видалити прод БД із списку в плагіні фор секюріті сейк, і нажав видалити Аккаунт (що логічно), прав в нього на видалення акаунту не було то він робив це спокійно, але плагін був з багою і байпасив пермішени і тому видалив саме Ажур БД Аккаунт, з усіма прод БД на тому аккаунті =) Тобто тут 2 глюки, перший те що ти можеш видаляти Ажур Аккаунти з плагіну (нашо воно) і другий те що він байпасив пермішени (це ми зарепортили Майкам).
БД відновили, я написав інтеграційну логіку відновлення заказів (типу ПДФ були згенеровані, але записів ордерів в БД не було, тому ордери брав з іншої системи яка вижила, контент з ПДФок, мапив це все і відновив втрачені дані з періоду «даунтайму», але фактично даунтайму не було, бо спроектували ми систему накшталт фуул-пруф), тому закінчилося це лише нашим стресом без втрат для бізнесу. А, ну і по класиці це сталося у п’ятницю в штатах, тому я пів Української ночі це все витягував.
Ну гівнокод, і шо далі? Не апрувати його чи шо? чи писати самому? Аппрув а далі хай ку ібуцця с гівнокодером. Все одно до прода декілька енвів те тестується по кілька раз. А іще білд з тестами і якщо падє то не заливається нічого, та завжди можна залти стару гілку.
Можна подумать оте вилизування клін коду дяді боба якись сенс має)))
Ну гівнокод, і шо далі?
И всё.
Не апрувати його чи шо?
Нет
чи писати самому?
нет
Аппрув а далі хай ку ібуцця с гівнокодером
так жырно, что даже мезим не поможет
Все одно до прода декілька енвів те тестується по кілька раз.
ПРоблема говнокода в том что он благополучно пройдет тестирование, которое при таком подходе «а что, не апрувить что ли?» и уйдет в прод
Ну і пофіг, шо той гівнокод зробить на проді? Особлико коли вже відтестили та він робить те що треба.
Ну і пофіг, шо той гівнокод зробить на проді? Особлико коли вже відтестили та він робить те що треба.
да что угодно, собственно
например, неправильно посчитает скидки на товары, и вместо «нет скидо», посчитает «120% скидок»
Знижок не існує.
если ваш код «прошел тестирование на отъебись» — то вполне возможно :)
А большего и не нужно, есть система, у нее есть поведение, поведение можно описывать бесконечно в мега экозтических кейсах, но по факту кейсы которые действительно важны и стоят денег потраченых будет довольно ограничено. Так что залил, оттестили, подрпавил и отличненько. Никому ваш идеальный код и нах не упал. Все равно лет через 5 будут переписывать или выкинуть вовсе.
А большего и не нужно, есть система, у нее есть поведение, поведение можно описывать бесконечно в мега экозтических кейсах, но по факту кейсы которые действительно важны и стоят денег потраченых будет довольно ограничено. Так что залил, оттестили, подрпавил и отличненько. Никому ваш идеальный код и нах не упал. Все равно лет через 5 будут переписывать или выкинуть вовсе.
Вовка в тридевятом царстве, «и так сойдёёёт!» :)
Для этого есть требования к работе, а шлифовать можно бесконечно. Так что если говнокод всех устривает то зачем париться? Особенно если за это(париться) не платят.
Для этого есть требования к работе, а шлифовать можно бесконечно. Так что если говнокод всех устривает то зачем париться? Особенно если за это(париться) не платят.
Ну наверное потому что говнокод приносит проблем больше, чем не-говнокод, и усилий, зачастую, требует или столько же, или на кроху больше
на практике говнокод понятие абстрактное и крайне относительное. было б так легко не говнкодить и говнокода бы не было.
на практике говнокод понятие абстрактное и крайне относительное.
Это да, во многих случаях. то, что допустимо для одних типов проектов — то недоспустимо для других
Хотя, конечно, существуют некоторые базовые стандарты кода, отступление от которых делают код говнокодом
Відокремлювати і розробляти тільки те що важливо це правильно, але це не означає автоматично говнокодіти.
Говнокод — це проблема, тому що як би ти не виділив тільки головне із того що треба, його через якийсь час доведеться підтримувати, розширювати і багфіксити. І чим більше говнокоду, тим складніше це все буде робити.
Звичайно, що для якогось мамкіного токсіка-задрота все що не він написав то все говнокод і він може не апрувіти пулреквест через свою хронічну незайманість. Але це вже інша історія.
Звичайно, що для якогось мамкіного токсіка-задрота все що не він написав то все говнокод і він може не апрувіти пулреквест через свою хронічну незайманість.
И вот такой простой фразой человек одним махом перечеркнул всё то правильное, что до этого успел сказать про говнокод....
Ну так це теж правильне. Тому що ну різні люди зустрічаються :)
Тому довелося відокремити токсичну поведінку від дійсно розуміння чому говнокод не треба пропускати в мастер.
Ну так це теж правильне. Тому що ну різні люди зустрічаються :)Тому довелося відокремити токсичну поведінку від дійсно розуміння чому говнокод не треба пропускати в мастер.
если у вас ревьювером работает «задрот, катораму нидайуть, бугага!» — вам, скорее всего, надо работать охранником на парковке
Всьо то ви знаєте, який молодець!
Всьо то ви знаєте,
Да
який молодець!
єто я тоже знаю
«Задача автора — писать код, который как будто будет поддерживать маньяк, который знает где живет автор.»
В какой-то мере єто шутка, конечно, но в целом — нет
Подход «гуд єнаф», или, что значительно хуже, «и так сойдет!» — со временем, из-за накопления мелких ошибок, косяков, текникал дебта, побочек и так далее — приводит к огромному факапу.
Я прекрасно понимаю, как бесят придирки к незначительнім мелочам во время ревью кода, я сам из тех, кого они бесят. но я не первій год в профессии, и я знаю, к чему приводит накопление мелочей.
зі пикрелатед i.redd.it/roarn2njlx871.jpg
Я б взагалі поставив би питання інакше. Всі ці наслідки технічного борга через гівнокод — це на поверхні і зрозуміло кожному.
Що більш важливо вже лежить в площині філософській. Набагато корисніше для менталочки, а відповідно на довгострокову перспективу, відчуття що ти робиш хорошу роботу, а не займаєшься тяп-ляп і в продакшн. Вигорання від беззмістовної або систематично неякісної роботи б’є набагато сильніше, ніж складнощі підримки погано написаного кода.
А багфіксити гівнокод — це можливість в той момент трохи відрефакторити і отримати задоволення що ти своєю роботою зробив щось корисне і змінив на краще.
абагато корисніше для менталочки, а відповідно на довгострокову перспективу, відчуття що ти робиш хорошу роботу, а не займаєшься тяп-ляп і в продакшн.
Вот тут я уже поспорю. Если ты профессиональ — то твоя менталочка будет в порядке пока тебе платят за работу.
а если ты — «токсик-задрот» — тогда да, будешь страдать в перфекционизьм :)
А багфіксити гівнокод — це можливість в той момент трохи відрефакторити і отримати задоволення що ти своєю роботою зробив щось корисне і змінив на краще.
Тогда лучше пойти покормить котиков или лес поубирать — это будет полезно и к лучшему.
Вважати себе професіоналом, якщо систематично робиш роботу гівняноі якості — занадто самонадіяно, або просто нерозуміння що означає слово професіонал
Вважати себе професіоналом, якщо систематично робиш роботу гівняноі якості — занадто самонадіяно, або просто нерозуміння що означає слово професіонал
И чо? профи делает ту работу, за которую ему плотют.
раз плотют и не гонют — значит работа достаточного качества, менталочка профи страдать не должна, пусть даже ті как профи считаешь что качество твоего когда — говно. но раз такое надо — ну ок.
раз плотют и не гонют — значит работа достаточного качества
або не мають потрібної компетенції щоб оцінити. Саме тому часто і звертаються до професіоналів. А то інакше будь-якого спартака-суботу і подібних шнирєй можна вважати професіоналом — йому платили і не гнали. Все те ж саме.
пусть даже ті как профи считаешь что качество твоего когда — говно.
Ну так я тому і казав
або просто нерозуміння що означає слово професіонал
Це саме той випадок.
Виходить що будь-який рукожопий сантехник, електрик, лікар, дантист, автомеханік який наробив якусь хуйню — він професіонал. І єдиний критерій його професійності — це чи заплатили йому за роботу.
А скільки в україні говнофотографів «профессіоналів», ой.... :)
або не мають потрібної компетенції щоб оцінити.
если плотют — значит есть деньги — значит товар продается — значит качество норм.
Це саме той випадок.
Нет. єто тот самій случай когда «покупатель всегда прав». если покупатель покупает ЄТО — кто я ему такой чтобі рассказівать «как надо по правильному»? Покупатель хотет 7 шапок из кошки? окей, я профи, я сделаю ему 7 шапок из кошки. а уму его пусть мама и няни учат, мне за такое не платят
Виходить що будь-який рукожопий сантехник, електрик, лікар, дантист, автомеханік який наробив якусь хуйню — він професіонал.
Если ему платят и не вігоняют — да
Вообще, «профессионал — Человек, сделавший какое-н. занятие своей постоянной профессией.», а не «вісококлассній специалист», если уж на то пошло :)
А скільки в україні говнофотографів «профессіоналів», ой....
Им платят? єто их профессия? какие вопросі?
Вообще, "профессионал — Человек, сделавший какое-н. занятие своей постоянной профессией
ЛОЛ. Питань більше не маю :)))
ЛОЛ. Питань більше не маю :)))
Обращайтесь. Поиск определений в справочниках — єто моя супер сила, я всегда готов помочь.
Ага, по справочникам написаним таким же професіоналом як із вашого визначення. Ведь кожен, хто отримав свою першу зарплату автоматично вже стають професіоналами. Навіть якщо не мають профільної освіти і ще ніхуя робити толком не навчилися. Ясно-понятно.
Вибрали 73% таких же «професіоналів» в президенти, отримав першу зп — все, вже президент-професіонал.
Ага, по справочникам написаним таким же професіоналом як із вашого визначення.
Ну, справочники которіми пользуюсь я — написані признанніми специалистами
ваше упорное нежелание различать термині «профессионал» и «специалист» — не делает вам чести
особенно тот факт, что ві не хотите признать что «профессионал» — єто человек, которій делает свою работу за деньги, независимо от своих чуйств и капризов.
Вибрали 73% таких же «професіоналів» в президенти, отримав першу зп — все, вже президент-професіонал.
Да, так оно, к сожалению, и есть.
Можете закатиться в истерике, а можете, как профи, отнестись к єтом фалософически.
Дибіли твої спеціалісти, дядя. Людина не стає професіоналом в чомусь після отримання своєї першої зарплати. Хоч обкладись своїми справочниками зі всіх сторін.
Дибіли твої спеціалісти, дядя.
Само собой, дебили, куда им
Хоч обкладись своїми справочниками зі всіх сторін.
Єто да, справочники всегда пишут дебили для дураков.
Вот тут я уже поспорю. Если ты профессиональ — то твоя менталочка будет в порядке пока тебе платят за работу.
А если ты видишь, что тебя принуждают сделать решение, которое заведомо неадекватно?
А если потом обвинят тебя же?
А если ты видишь, что тебя принуждают сделать решение, которое заведомо неадекватно?
А если потом обвинят тебя же?
В первый раз.жпг?
1. Потребую значительную премию
2. Если я профи, то пусть обвиняют, я всё равно отобьюсь
В первый раз.жпг?
Этого не понял.
2. Если я профи, то пусть обвиняют, я всё равно отобьюсь
Тебя не будут слушать. Или будут, но аргументы будут проигнорированы.
Ответ «уйду из такого места» очевиден, но неинтересен.
Тебя не будут слушать. Или будут, но аргументы будут проигнорированы.
Да и ради бога
Они же всё это сделают письменно, в переписке, в тикетах, в документации
как профи я скажу: «Моё дело прокукарекать, а там хоть не рассветай» :)
А если ты видишь, что тебя принуждают сделать решение, которое заведомо неадекватно?
А если потом обвинят тебя же?
«Больше бумаги — чище жопа» (стара мудрість)
Особисто я би навів аргументи, бажано у письмовому вигляді, чому рішення неадекватне, а далі — любе кіно за ваші гроші.
Буває так, що можна запропонувати декілька варіантів, різних по естімейтах, коли неадекватне рішення дорожче (іноді навіть суттєво — чисто компенсація за гемор). І буває, що таке допомагає.
Якщо потім звинуватять, то є переписка — працює навіть з «легковажними» людьми.
Якщо навіть таке не допоможе, то це 100% знак, що треба припиняти співпрацю.
«Больше бумаги — чище жопа» (стара мудрість)
Особисто я би навів аргументи, бажано у письмовому вигляді, чому рішення неадекватне, а далі — любе кіно за ваші гроші.
Якщо потім звинуватять, то є переписка — працює навіть з «легковажними» людьми.
Якщо навіть таке не допоможе, то це 100% знак, що треба припиняти співпрацю.
Блин, это настолько очевидное действие, что я даже забыл его упомянуть, а следовало бы
Документирование всего процесс — отлично защищает жопу.
ну и в целом вести подробную документацию — это очень полезно
Документирование всего процесс — отлично защищает жопу.
Повторю соседние комментарии, но представь себе, что документировать тебе просто не дают.
У тебя есть wiki, в которой всё что ты пишешь снесут нах, ибо не соответствует полиси, email, на который всем плевать, slack/teams, которые забудутся завтра.
Ты при этом работаешь через прокладку (Epam/GL/Ciklum/etc.) и формально ты вообще просто «консультант», от которого даже официальное письмо... ну скорее всего приведёт к разрыву с тобой как с неадекватом. А в лучшем случае прокладка скажет «наше полиси не позволяет передавать такое заказчику, но мы просуммируем плачи и в течение ближайших
Твой ход в этом случае?
Повторю соседние комментарии, но представь себе, что документировать тебе просто не дают.
Мне не дают создавать тикеты, писать письма, отвечать на них и так дале? Да, охотно верю :)
У тебя есть wiki, в которой всё что ты пишешь снесут нах,
Включая историю.
email, на который всем плевать,
Ты не поверишь — мне тоже плевать на мыло. Мне единственно что нужно — чтобы письмо было, от меня, с описанием
А отреагируют на него, не отреагируют — меня не колышит
Ты при этом работаешь через прокладку (Epam/GL/Ciklum/etc.) и формально ты вообще просто «консультант», от которого даже официальное письмо...
В этом случае мне вообще наплевать что происходит :)
Деньги платят, вовремя? Меня устраивает
ну скорее всего приведёт к разрыву с тобой как с неадекватом
Пойду в другу контору, в которой платят деньги.
А в лучшем случае прокладка скажет «наше полиси не позволяет передавать такое заказчику, но мы просуммируем плачи и в течение ближайших1-2 лет постараемся убедить его быть более внимательным к подобным деталям».Твой ход в этом случае?
Меня устраивает. Деньги же всё равно заплатят, верно?
Меня устраивает. Деньги же всё равно заплатят, верно?
В этом месяце — да. А в следующем решат, что ты слишком проблемный, им нужны простые гребцы.
В этом месяце — да. А в следующем решат, что ты слишком проблемный, им нужны простые гребцы.
Не вопрос. Главное чтобі деньги заплатили
Особисто я би навів аргументи, бажано у письмовому вигляді, чому рішення неадекватне,
Проблема в тому, що є місця, де «письмового вигляду» не існує або він несуттєвий.
Це типовий варіант, наприклад, з «консультантом» найнятим в аутсорс/аутстаф конторі. Він може писати що завгодно — бюрократія галери не пропустить письмову заяву, а навіть email в системі замовника може бути проігнорований.
Має значення тільки те, що кажуть власні співробітники (причому не «консультанти», а в штаті). А їх ти можеш навіть не знати, настільки вони високо у ієрархії.
Якщо скажеш «звільнятись» — ну да, це рішення завжди працює для конкретного виконавця в цьому проекті... а в наступному буде те ж саме знову.
Це типовий варіант, наприклад, з «консультантом» найнятим в аутсорс/аутстаф конторі. Він може писати що завгодно — бюрократія галери не пропустить письмову заяву, а навіть email в системі замовника може бути проігнорований.
но деньги же консультанту заплатят, правильно?
Дело консультанта — проконсультировать, а там уже заказчик пусть сам принимает решение
я вам больше скажу — ситуация, когда я могу делать что угодно, это «что угодно» будут игнорировать и просто платить мне деньги — меня офигенно устраивает :)
Проекты от говнокода не закрываются, закрываются когда нет клиентов и инвесторов, все остальное вторично. Потому тех долг или де говнкод в простонародье, всегда есть и будет.
Проекты от говнокода не закрываются, закрываются когда нет клиентов и инвесторов, все остальное вторично. Потому тех долг или де говнкод в простонародье, всегда есть и будет.
Ну, давайте вспомним Netscape Navigator....
Не можете? :) вот именно.
А ведь он пал жертвой говнокода (ну, не только его, а еще и жертвой одного очень тупого административного решения), но говнокод, на мой взгляд, послужил спусковім крючком для той лавині, которая накріла навигатор меднім тазом
Мужик глаза разбуй, тимс, постман, нереальное количествой сайтов и софта на мобилках кривое, убогое, тормознутое и никто его не закрывает. Никому твой идеальный код не нужен.
Никому твой идеальный код не нужен.
Я где-то писал про «идеальный код»? :)
Учись читать не жопой, фрайер :)
Я писал о том что «говнокод приводит к проблемам».
Ты понимаешь разницу между «говнокодом», «обычным кодом» и «идеальным кодом»? Если нет — тебе давно пора нахер из профессии
Зашивай пукан ))) Говнокод в упомянутых платформах живет и здравствует и похер все на твой навигатор, времен когда большинство туташних еще даже писать не умело, а то и вовсе не родилось.
Зашивай пукан ))
малолетка в чате. ну фу!
Учись читать не жопой, фрайер :)
Отвечал в твоем стиле, так шо сорян что порвался так быстро )))))
т и похер все на твой навигатор, времен когда большинство туташних еще даже писать не умело, а то и вовсе не родилось.
:)
Знаешь почему «похер на тот навигатор»? Почитай историю — что єто біло, какую часть рінка занимало — и куда и почему делось
а потом пиходи, обсудим «как при помощи говнокода проебать афигенній бізнес»
Лел, ну если б твой навигатор когото там учил то не было бы столько говнокода и говнокодских програм. так шо ты дедуля уже противоречишь сам себе, может уже пора по днепру сплавляться, за навигатором своим? ))))
Лел, ну если б твой навигатор когото там учил то не было бы столько говнокода и говнокодских програм.
ну, СТОЛЬКО говнокода уже и правда нету
так шо ты дедуля уже противоречишь сам себе, может уже пора по днепру сплавляться, за навигатором своим? ))))
Ндя.... Школота никогда ничему не учится.....
ну, СТОЛЬКО говнокода
Досі є, і буде завжди. Коли знову зміняться стандарти, введуть якісь нові парадигми як ввели OOP, SOLID, MVC, патерни, мікроснрвіси, серверлес код свого часу, — весь сучасний код перетвориться в гарбуз.
Скоріше не стандарти розробки і кодування, а цільові технології.
Досі є, і буде завжди. Коли знову зміняться стандарти, введуть якісь нові парадигми як ввели OOP, SOLID, MVC, патерни, мікроснрвіси, серверлес код свого часу, — весь сучасний код перетвориться в гарбуз.
Говнокод — это не парадигма. Говнокод — это код, который в условиях существующих парадигм и знаний работает ненадёжно, нестабильно, трудно обслуживается и приводит к массе ошибок и проблем
в условиях существующих парадигм и знаний работает ненадёжно, нестабильно, трудно обслуживается
перетвориться в гарбуз
Взагалі то Навігатор був вбитим спочатку MS агресивним маркетингом, потмів IE вбив FF, а потім Гуголь засрав всім мізки агресивним маркетингом ще раз та прибив вже FF. Якість коду тут не грає ніякої ролі. Взагалі.
Взагалі то Навігатор був вбитим спочатку MS агресивним маркетингом, потмів IE вбив FF, а потім Гуголь засрав всім мізки агресивним маркетингом ще раз та прибив вже FF. Якість коду тут не грає ніякої ролі. Взагалі.
Да, согласен.
и идея менеджмента выпустить совершено сырой продукт на рынок, чтобы «юзера провели тестирование», в результате чего были посланы миллионы одинаковых баг-репортов на совершенно очевидные ошибки, которые полностью «убили» обратную связь и баг фиксинг- тут совершенно ни причем.
А совершенное очевидные баги в товарных количествах появились именно потому что что код был очень качественным
Зараз про який браузер йшла мова?
Зараз про який браузер йшла мова?
Netscape Navigator 4.0
и никто его не закрывает
Одна из причин — пример навигатора их многому научил.
Никому ничего твой браузер не научил, ну разве что гавнокодить.
Никому ничего твой браузер не научил, ну разве что гавнокодить.
Подход «гуд єнаф», или, что значительно хуже, «и так сойдет!» — со временем, из-за накопления мелких ошибок, косяков, текникал дебта, побочек и так далее — приводит к огромному факапу.
Если не закладывают ресурсы на исправление, то любой код будет страдать, потому что принятые при его написании решения теряют актуальность. Например, заложили регулировку НДС, а потом оказалось, что на разные товары она разная, упс... один параметр на всех не подходит. (Не хочу показывать примеры из своей области, там долго объяснять детали, а тут должно быть общепонятно.)
А если есть ресурс на исправление в виде %% от общего времени, и его не забывают применять — то и «good enough» на этапе первичного написания не будет критической проблемой.
А если есть ресурс на исправление в виде %% от общего времени, и его не забывают применять — то и «good enough» на этапе первичного написания не будет критической проблемой.
/
Ситуация: на разработку заложили 100 часов + 20 на исправление. Разработка завершилась в срок и в бюджет
через год после внедрения вышел закон о 18% НДС.
Вопрос: как 20 часов заложенных в разработку на исправления помогут в этой ситуации, если разработка закончена, контракт закрыт, проект закончен.
если разработка закончена, контракт закрыт, проект закончен.
Контракт закрыт — это другая ситуация. Я, естественно, имел в виду непрерывную разработку и поддержку.
Контракт закрыт — это другая ситуация. Я, естественно, имел в виду непрерывную разработку и поддержку.
ок. рассмотрим «бесконечный проект»
В этом случае «Бесконечность+20% от бесконечности на доработку» = «Бесконечность».
Ничего не нужно закладывать в сроки, нужно будет просто по ходу дела дорабатывать.
таке відчуття, що ви гівна в житті не бачили =)
ось вам кейс — наче непоганий код, але є але, це вайл луп. Далі треба продовжувати?) Така фігня вам ваш прод покладе за мілісекунди у еджкейсах, які можна не відловити, бо QA не панацея, бізнес втратить гроші з незавершених продажів. Далі інвестігейшн і дивимось хто апрувив, далі ван ту ван з вами і ставимо вас на персонал імпрувмент план, і якщо гусей не зберете, то знайдемо того, хто буде ставитись до своєї роботи з більшою відповідальністю. І це ікомерс, а що казати про ембедед, де мова може йти про життя та здоров’я людей?
Така фігня вам ваш прод покладе за мілісекунди у еджкейсах, які можна не відловити, бо QA не панацея, бізнес втратить гроші з незавершених продажів.
Кстати, вы мне напомнили. Была книжка одного американского манагера, на тему «аварии и их причины», где рассматривался, в т.ч. случай, когда люди погибали от излучения аппарата для радиотерапии.
причем тесты оно всё отлично проходило, куа реально плотно и хорошо тестировали. но медленно
А говнокод лажал когда данные вводили быстро.
А если бы это был не говнокод, а просто код, который следует шаблонам многопоточного программирования — то всё было бы ок.
багатопоточність — то шось на умнам, треба усе процедурнєнько фігачить :)
до речі, моє перше знайомство з багами багатопоточності пішло від він формз у бородатих роках, де деякі кадри фігачили логіку у UI потоці, чого робити ніколи не можна, бо тим самим вішається весь респонсівнес він формз аплікухі, так от мені як джуну давали задачу знайти чому аплікуха подекуди «підвисає» :)
так що так, гівнокод не даремно називають саме "гівно"кодом :)
ось вам кейс — наче непоганий код, але є але, це вайл луп. Далі треба продовжувати?)
Ну я не зрозумів, який такий «while loop» може щось покласти. У мене таких багато і вони нічого не кладуть:))
вже відтестили та він робить те що треба
Учителе, а віршами викласте? А то на мантру не дуже.
кстати
я вот лично ОЧЕНЬ не люблю и страшно бешусь (внутри) когда мне коллеги, особенно не по отделу, указываются на ошибки
но это очень сильно помогает а) не зазвездится и б) найди системную проблему, т.к. у меня то глаз уже замылен, и свежий человек свежим взглядом может узреть реальную проблему.
Поэтому приходится негодудеть сугубо внутри а внешне смиренно слушать на указания на пройобы. но бесит, конечно, страшно :)
Коли я написав що хлопці (індуси) не компетентні, мене звільнили через годину. Компанія втратила десь мільйон $, але звісно що прямо казати про проблеми це табу, поки бізнес не розвалиться.
Коли я написав що хлопці (індуси) не компетентні, мене звільнили через годину
Да ну, звучить типу — коли я зробив харакірі, мені стало дуже погано. BTW Японській метода показати начальнику, що він не правий — зробити харакірі.
Японській метода показати начальнику, що він не правий — зробити харакірі.
О, допомогти начальнику зробити собі харакірі — це ми завжди залюбки.
Не для того вони на співбесідах либлячись повторюють не індусам «ок», «гуд», «ітс файн», а потім тобі рекрутер пише в зворотньому зв’язку що ти ледь не джун, а вони в свою чергу беруть своїх же індусів, щоб потім звільняти своїх же некомпетентів
працюючи з індо-паками і деякими амерами я розвив в собі скіл, який рекомендував моєму брату (він зараз директор оф інжинірінг) та можу рекомендувати будь кому хто хоче досягти чогось у компанії без ризику для себе:
головне правило — let them fail
друге правило — communication is the key. (допомогаєте тим хто фейлть, якщо вони не прислуховуються — кажете про це їх менеджменту, якщо їх менеджер закриває очі, або каже «так так, я знаю, ми все зробимо» і потім знову той самий фейл — йдете з цим до їх директора і на цьому все, далі працюєте собі і чекаєте коли вони зафейлять і тепер топ менеджмент згадає ваші слова, у результаті їх посунуть, а вас мають запромоутити, головне щоб менеджмент був у курсі ваших бажань. А у комунікації треба уникати прямих характеристик ваших колег.
Після того як я пішов до їх менеджера(тих індусів, що доступи зламали), він ескальнув на свого директора і ранком я був звільнений. Тобто менеджменту легше вбити контрактора, аніж визнавати власні помилки....
Манагери та директор були індусами?
Є така особливість у індусів — у них завжди винні форегінери але не вони самі особисто. Тут хтось про це писав не одноразово.
Одне з головних правил — якщо бачиш що хтось зробив щось невірно, показуєш доказ цього, без будь якої оцінки компетентності, а далі хай вже менеджмент вирішує
Якщо менеджмент не вирішує, бо лячно шось казати найвищому менеджменту? ( В мене був цей випадок )
горить сарай — гори і хата. Ваш випадок показав що компанії важливіше
Байдуже. Не цікавить та не звертаю увагу на якість та рівень праці колег. Це їх проблеми. Їм з ними жити.
Якщо це підлеглі (які звітують), то, імхо, потрібно об’єктивно (наскільки це можливо та реально) проаналізувати та зрозуміти причинно-наслідкові зв’язки.
Наприклад, низька якість — це нормально, якщо персонаж (джун, новачок) вчиться, отримує досвід, професійно зростає, при цьому професійно ставиться до виконання своїх обов’язків та змінюється (розвивається) як фахівець в кращу сторону в наступних бізнес-процесах.
Це їх проблеми. Їм з ними жити.
Що будете робити коли їх або вони самі звільняться й вас посадять дебажити їх код?
В вопросе твоём уже ответ содержиться.(Голосом Йоды)
Це вже буде моєю проблемою.
Але якщо розглянути будь-яку проблему як власний тренажер, то проблема не є проблемою.
Вирішення та пошук рішень проблем — це є частина життя.
Чим проблемніший колектив — тим краще себе можна прокачати.
Імхо, от наприклад Україна — це напевно найкращий тренажер в світі (як держава, як суспільство), бо тут така кількість та такий діапазон проблем, що кожен може знайти щось для себе, щоб прокачати та натренувати себе.
Наприклад, Швейцарія, Монако, ОАЕ або Люксембург — це слабенький тренажер, там мало тренажерних, випробувальних майданчиків, бо мало проблем та вузький їх спектр.
Тобто будете медитувати ? Бо що робити в усіх незрозумілих ситуаціях — звісно медитувати, корень усіх твоїх проблем в твоїх страстях. Попався кусман індійського коду включаєш мантру www.youtube.com/watch?v=sG8NDw3Tv6c і за дебагер. Як не дивно не сприймати емоційно дійсно часто допомагає розібратись в ситуації, а от емоційно частіше за усе потрапиш в заздалегідь підставлений капкан та підніжки. Головна проблема спагетті гомнокоду в тому, що ви вже не розумієте — що він робить. Головна проблема з людьми така сама — ви не розумієте як вони мислять.
Але якщо розглянути будь-яку проблему як власний тренажер, то проблема не є проблемою.
І не набридить тренуватись усякій херні якої б не було, якби доклали на крихту більше розуму?
Мужик, ты слишком много на себя берешь. Тебя наняли устанавливать унитаз в отсеке 891 на огромном межпланетном корабле.
Ліл, ну сяду та віддебажу, і шо далі? Гівнокод це поняття відносне, ота мутота що ти пишеш може буди гівнокодом для іншого.
радіти що цей етап закінчився і робити далі по нормальному
у меня в слаке есть эмоджи с добкином «всё фигня, давай по новой» и эмоджи «ну фу!»
Коротка інструкція:
— старайтеся ніколи не робити будь-які робочі коменти токсичними і завжди слідкуйте за tone of voice як у pull-requests так і у просто професійному спілкуванні (не допускайте оціночних суджень типу «твій код лайно» ітд)
— розділяйте фідбек по формулам, наприклад проблема — наслідки — як фіксити — приклади з інших проектів (гарно працюють історії публічних проблем, наприклад CPU time planner на linux core)
— автоматизуйте максимум можливого у ваших ПР, автокоррект стайлу, лінтери, юніт тести, попередження через code coverage і errors на absent unit tests, etc
— якщо у вас немає загальної доки про процес (code style, code guide, PRs style, review approach, etc), створіть її зсилаючись на best practices from opensource projects
— завжди апелюйте на загальноприйняті best practices як DRY, SOLID, FIRST
— якщо зовсім тяжко зідзвонюйтесь і розповідайте чому і як (тут залежить від рівня ваших колег, це все ж не дитсадок і не богодєльня)
— не бійтеся прощатися з токсичними але кваліфікованими членами команди
— старайтеся ніколи не бути токсичним, бо ви втратите авторитет у команді в будь якому випадку, навіть якщо ви 10 разів праві
«Токсичность» это выдуманный ярлык — инфантильными либо имбецылами.
Примером подобного «творчества» также может служить ярлык: «душнила». Неспособные понять, обесценивают всё и всех. Главное: плыть по течению.
Обьективно, это не моё дело, кто насколько ментально развит.
Просто, если поднатужить своё понимание причинно-следственных связей приходит понимание, что: обиженные дети, с противогазами в котрых розовые линзы. Безсмысленно бродящие по колено в дерьме на очередном тимбилдинге, в результате влияют на твою зп. А что важнее, на квалификацию: носить помои — ведрами, за нерадивыми сантехниками, не повышает скил у сварщика.
Так что если кто-то «обосрался» стоит поступить конструктивно:
розділяйте фідбек по формулам, наприклад проблема — наслідки — як фіксити — приклади з інших проектів
Единствнное замечание, нужно понять причину: халатность, профанство, злой умысел(например: пасивная агресия), стечение обстоятельств, третье лицо.
Якщо щось капець критичне — то спершу особисто делікатно, потім по старшинству вище і вище до максимально доступного вам менеджера. Бажано не даючи цьому всьому потрапити на прод, якщо є можливість на це вплинути.
Якщо не критичне, а просто терпимо галімо — запропонувати можливо кращий варіант особисто, але не сильно наполягати. Не подіє — забити і надалі не звертати увагу на некритичний терпимогалімий код цього колеги. Бо результату всеодно не буде, а ваш час і сили підуть.
Якщо код таки галімий був — то час це покаже, а як ні — ну то може і з кодом все ок.
Ну і «лайно бо лайно» — не аргумент.
PS. За аргументовані свої косяки на які вказали колеги — дякувати, і розбирати чому саме так сталось.
Як є так і кажу — www.youtube.com/watch?v=qVMfHnSxlGk
Колегам повідомляють ті, хто вище мене. Я повідомляю тим, хто нижче мене
В свое время пытался говорить коллегам что сделано не фонтан. Была жалоба руководству после этого, что давлю на людей. Ок, я закрыл рот. Потом это все выкатили на прод. Потом сделали перформенс тесты и то что они писали — упало хорошо. Этого было мало. Потом пошли баги с прода. И вот только после этого задумались. Если руководство нетехнические люди — то они не смогут оценить хорошо или плохо, они могут воспринимать это как буллинг коллег. Поэтому понимают только проблемы с прода, вот тогда выясняется кто писал и почему (и то, если этот человек еще работает в компании).
Бизнес похож на эволюцию — слабые и неприспособленные проигрывают. А вы, уверенны что в такой ситуации стоит что-то менять? У вас акции?
Я просто сторонний наблюдатель. Чтобы что -то менять в этой ситуации, необходим рычаг влияния на людей или авторитет в команде, чтобы к твоему мнению прислушивались. Обычно когда человек говорит, что сделано плохо — то он аргументирует к чему это приведет. В моей ситуации ко мне после второго такого случая просто стали прислушиваться, но не более.
Если руководство нетехнические люди — то они не смогут оценить хорошо или плохо
Вообще-то «нетехнические манагері» за нехер делать понимают — «хорошо єто или плохо» — причем, если манагер нормальній — они понимают єто лучше технических спецов :)
Объясни мне, как не технический манагер может самостоятельно оценить качество решения до попадания на продакшин.
Объясни мне, как не технический манагер может самостоятельно оценить качество решения до попадания на продакшин.
а) по формальнім признакам — тесті, заключения, етк
б) по статистическим признакам — путем анализа результатов предідущих спринтов.
почитайте об успешніх манагерах (успешніх — без кавічек) — у них, как правило — специализированное манагерское образование, и они более чем успешно управляют проектами — техническими, не техническими, переходят из отрасли в отрасль и так далее.
Ты наверно путаешь менеджера проекта в ИТ с каким то другим менеджером из другой отрасли. В жизни не поверю, что так легко это. Без специального образования и навыков тебе твои подчинённые будут лапшу вешать и ты даже не поймёшь этого.
Ты наверно путаешь менеджера проекта в ИТ с каким то другим менеджером из другой отрасли.
Не путаю.
В жизни не поверю, что так легко это.
это не «лекго», а «возможно»
Без специального образования и навыков тебе твои подчинённые будут лапшу вешать и ты даже не поймёшь этого.
Согдасен, будут. но очень недолго.
Потому что я, как хороший менеджер — могу оценить результаты труда.
и если продукт «не взлетает», много багов, жалоб, отстаем от графика и так далее, а подчиненнёые говорят как все у нас классно — то явно они мне вешают лапшу на уши.
а що б було якщо б ви прокомунікували вашу думку із «нетіхнічними людьми» їх мовою таким чином щоб донести її, типу якщо була скарга — ок, давайте проговоримо та виявимо де і коли я був не правий і чому саме я так говорив? якщо ми займаємо лідові позиції — потрібно вміти спілкуватись з нашими точками контакту (бізнесом)
на мою думку — 90% непорозумінь є через відсутність достатньої комунікації. Завжди треба налагуваджувати контакт з вашим менеджментом і колегами, інакше буде silo, котре буде руйнувати роботу і вам і усім навколо
в мене були похожі проблеми на одному з місць де в ітозі я доріс до в.о. СТО саме через те що в ітозі став мостом між інженерами та топ менеджментом
Для цього придумали Пулл Реквести
Пулл Реквести
Это дерьмо есть только в гите. Гит не нужен в разработке в 99% случаев.
сильно, угорнул
в 99% случаев люди обходятся без vcs, записал
SVN же
Он еще маленький, кроме гита вообще ни с чем не работал.
SVN же
Та ну нафіг. Перехід на гіт з свн це як з жаваскрипта на тайпскрипт перейти :)
Ще є цей, як його, меркуріал. Рекомендую спробувати — після кількох заходів на three-way merge conflict починаєш цінувати гіт з усіма його недоліками. І це не згадуючи про те що меркуріал майже повністю на пайтоні з відповідною швидкістю роботи навіть на середніх розмірів проектах.
Ты же дотнет дев. У нас был потрясающий по своей простоте tfvc, пока его не перестали поддерживать. Это лучшее с чем я сталкивался.
У нас был потрясающий по своей простоте tfvc,
был, и у него были свои плюсы, согласен
что у него не было — это распределённой оффлайн разработки, что есть в гите
И у тфс есть один радикальный недостаток — его перестали поддерживать
а сам мс перешел на гит, как ни странно
Були, знаєм, на здоровенних солюшенах воно завжди працювало, м’яко кажучи, через сраку. Сам кайф в тому що воно невіддільне від IDE, тому якщо на якійсь операції студія крашиться — tough shit, видаляй папочку і витягуй все наново в надії що пройде. По спогадах, «TFS витягується» було у нас десь як у плюсовиків «код компілиться».
зато транзишены работали как надо, а не как блин в гите :(
Гит не нужен в разработке в 99% случаев.
Не совсем так
даже при единоличной разработке ПР помогают
Хотя да, у гита есть масса недостатков, к сожалению
imgs.xkcd.com/comics/git.png
это все про овер 90% юзеров гита. и только остальные 10% крейзи терпил сидят тайпают ключики в консоле и разбираються в гите. тут тупо сразу видно что король настолько голый и не дает никаких преимуществ, а только один сплошной головняк. гит — это отличная ВНУТРЕННЯЯ тулза, для того чтобы управляться с линексом (ОС для терпил — тут все сходится).
95% (виндовых) юзеров гита используют SourceTree/Git Extensions/Visual Studio-Code или аналогичніе ИДЕ с плагинами для гита и процесс разработки вообще не спотыкается на этом. для того чтобы сделать коммит/пуш — много ума не надо
Если взять гитхабовский десктоп — так там вообще всё упрощено до предела.
5% — єто билд-админі, которіе настраивают билд процессі и которіе бай дефолт всё делают в команд лайне
наибольшая (с моей т.з.) проблема гита — это отвязка от джиры, из-за которой падают транзишены (это большой гемор, но что поделать)
GitHub, Gitlab, BitBucket своим подходом доказали, что 90% хотят не распределённую VCS, а централизованную с имитацией распределённости. Распределённую они просто не умеют.
Так что тут безусловно согласен, им большинство полезных возможностей излишни.
со мной работал чел которому дали все права на мердж, поэтому выглядело так — напушил что хотел, тесты что попадали закомментировал или вообще с файлика удалил расширение, чтоб компилятор не видел, и смерджил все сам в мастер
Please add a test that covers %scenario%
Code-Review -2
вопрос как это сообщить руководсту — не колеги вам харплату платят
який в коментарях такий і на робочому місці
Насправді абсолютно нормальна ідея. Можна взяти сокиру та піти розбиратись із тими хто тобі там, десь якось не подобається. А можна звернутись до керівництва чи будь якого іншого авторитетного посередника з питань вирішення конфліктної ситуації. З досвіду ви підете наїзджати на пряму, а колегам прямо поставили задачу зробити бігом та як вийде якраз те саме керівництво, там ніхто і не збирався робити якось якісно там чи узгоджувати з іншими відліками і т.п. — там збирались заробляти гроші.
От колеги перше що зроблять підуть і пожаліються начальству і проблеми з рештою будуть у вас! Конфлікт вирішиться повністю не на вашу користь. Воно вам треба таке ?
Інша справа — що інколи і справді треба, бо це може бути схема де вас відпочатку це саме керівництво поставило під розмін, та вирішило надурити і реальний конфлікт у вас якраз із керівництвом, а може ще і між вашим керівництвом і керівництвом колег.
трохи адекватніший брат Леоніда підключився) купа кейсів та все зводиться до того що хто перший прибіг до начальника той і в дамках
Дивлячись який начальник. А може і не бути ніяких начальників і у тебе наприклад клієнт кричить, або відмовляється платити ти наприклад не зробиш додаткову якусь роботу на яку ви від початку не домовлялись тощо. Що робити в такому випадку ? А буває коли один одному претензії викатають списком в декілька сторінок. Так є ситуації — де не пішло би усе до дідька, де піжони і аферисти і хай йдуть лісом, домовитись неможливо.
На міжнародному рівні теж як бачиш то до Сі Цзіньпін йдуть в посередники, то Ердогана, вірмени з азербайджанцями до путлера і Пашиняну мало допомогло, що він звернувся перший. Тут часто таке, що той хто звертається до посередника першим має слабшу позицію в переговорах, тому цій стороні важливіше швидше домовитись. От для прикладу youtu.be/LlGN4_rxQY8?t=230
Добре що є такі люди як ти в яких є багатсько часу, щоб строчити кілометрові коменти на абсолютно різні теми, головне з експертним душком насипати думки. Ааа так в тебе +8к коментів і це за 7 років, хороший темп взяв)
Мені колеги кажуть прямо в чому проблема, дзвонять мені, пояснюють чому і шарять свій ноуледж та бачення. Жодного спаму
Мені на минулому проекті теж з чудовими колегами з В`єтнаму поталанило, в яких ми забрали проект який вони писали три роки. Клієнт був такий зовсім не хитрий араб якому подобався естімейт колег із В’єтнаму і їх пропозиція додати до проекту ще 5 людей. Коментарів до мого MR-у було усього нічого, лише 50 і усі були усього лише про кодстайл, про те що на їх думку треба перейменувати зміцнінні та функції згідно традицій тощо, після того як перейменування було зроблено ніхто не міняв свою думку і не додавав ще один коментарій. Для того щоб це виправити і узгодити знадобився усього лише півтора тижня. Вдалось навіть нічого не казати менеджеру програми, після того як менеджер проекту зробив вигляд, що усе зрозумів і не точив зуб бо довелось компенсувати відпустку, що він обіцяв зробити.
Цей «спам» дуже корисний для навчання і для історії розробки.
Если это ваш лид — скажите ему об этом прямо, как ваше нижестоящее мнение, а там пусть сам решает, надо это переделывать или нет, ваша совесть чиста. Адекватный лид нормально воспринимает критику, потому что нельзя объять необъятное.
Если это ваш подчиненный, просто тыкаете в код пальцем и говорите, что надо переделать. Важный момент: обязательно объясняете почему, и чтобы он понял. «Мне не нравится» не аргумент. Самодурство от указаний отличается именно этим.
Если это ваш коллега равный по уровню, можете вежливо указать ему на проблему и пронаблюдать над реакцией. Поблагодарит и исправит впоследствии — хорошо, так и поступайте, но только по серьезным поводам, придирщиков никто не любит. Проигнорирует или начнет искать оправдания, тогда постарайтесь в рамках проекта работать над разными частями системы, чтобы не пересекаться в рамках одного и того же кода.
Вообще львиная доля проблем в написании кода возникает оттого, что куча формально равноправных людей топчутся по общей кодовой базе. Имхо, секуляризация зон ответственности ключ к успешной совместной работе.
Якщо це PR, то просто залишаєте коменти і не апрувите. В загальному випадку наводите свої доводи чому так чи інакше добре/не добре. Якщо консенсусу все ще немає, то робите ре саме з іншими девами, бажано залучити когось «старшого», якогось ліда/ архітекта, залучаєте також PO. Як в ітогє порішаєте, так і робіть. Головне щоб для усіх було зрозуміло, що ви попереджали, а вас не слухали. А там як буде, так буде. Якщо що, ви молодець, а відповідальність на тих, хто пушив лайно-рішення.
Звісно, якщо мова про колегу, що того самого рівня, що і ви по документах
Якось довелося одному тупому джуну відправити ось приблизно таке посилання:
www.youtube.com/shorts/cAT2ryLVIuk
Це був просто епічний чювак: таке враження що він останні 3 роки сидів у в’язниці і вивчав програмування по книжках на комп’ютері зліпленому з хліба. Він добре відповідав на теорію — його узяли, але на комп’ютері він тупо не знав що і як робити. Одного разу він у системний PATH насував якоїсь херні. Два робочих дні уся команда намагалася зрозуміти чому на його комп’ютері навіть калькулятор та блокнот крешилися.
Випробувальний термін зазвичай два тижні. За ці два тижні він не зміг навіть налаштувати свою робочу машину! Йому подовжили випробувальний термін і дали просту задачу — прибрати мертвий код. До кінця другого тижня він вже з роботи не виходив — ночував в офісі. І ніщо не допомагало! Йому можна було показати на своїй машині що і як треба зробити — а він потім приходив і казав що у нього не працює — і кожен раз з різними помилками. Кажуть що є люди, від самої присутності яких техніка виходить з ладу — про нього я б у таке повірив.
Останній день йому сказали: або він робить таску, або — до побачення. І він ЗРОБИВ — і запушив відразу у майстер.
Наступного дня було саме як у відео. Пікантності додало що менеджер продав цього джуна клієнту як синьйора (клієнт хотів команду одних синьйорів). Після цього наступних «синьорів» спів-бесідували вже люди з боку клієнта.
але на комп’ютері він тупо не знав що і як робити
Як і 75% усіх джуніорів, частіше за усе проблеми мають саме в налаштуваннях енву і користуванні профейсійним софтом, особливі поблеми з системами контроля версій. Завжди з’ясовується на стажуванні. Насправді і профі теж мають такі проблеми, особливо в проектах де прогресує фольклерний метод розробки — тобто нічого не документується, та передається у виді балад один одному. Скажімо може десь і є інструкція, та вона і ніколи не була повною (причому навмисно) — а по друге застаріла ще підчас свого створення. Якщо для когось це сюрприз людей треба на проект онбордити.
Усім хто робить курси, та стажує джуніорів дуже рекомендую звернути увагу в першу чергу три речі : набір на клавіатурі, налаштування робочого софту — IDE та робочий софт, системні змінні і таке інше — з поясненням як працюють базові принципи операціної системи і т.д. (Енрю Тандурбаум , далі для вінди Джефрі Ріхтер і що небудь по Linux дуже багато доброго матерілу поганого майже нічого), та системам контроля версій.
Останні 25% як правило геймери, тому як вам треба відібрати отих 25% досвідченних користувачів ПК поцікавтсь чи грає в що, і чи сам/сама налаштовує, що та як. Ті хто осилив наприклад підняти сервер Mine Craft чи чогось подібного — буде дуже рішуче відрізнятись від загальної маси джуніорів.
Пікантності додало що менеджер продав цього джуна клієнту як синьйора
Сам собі буратіно, набрехав обом — винуватий джуніор, а клієнт який після цього не закрив контракта — а просто почав робити вхідний контроль якості, чистий же фашист. І взагалі іноді проблеми можна вирішувати словами через рот, в тому числі сказати клієнту, що старший розробник тому і старший, що є наставником для молодших. А люди з великим досвідом роботи, це не ті які дуже швидко закривають тікети — це ті які виконують реалістичний проект в строки та бюджет. Але навіщо бо «Чем просить и унижаться, лучше сп***ить и молчать».
і запушив відразу у майстер.
Епічно, що джуну на випробовувальному терміні можна було пушити в мастер
джуну на випробовувальному терміні
Але ж клієнт бачив його як синьйора з великим досвідом і вже повноцінного члена команди (бо за випробувальний термін клієнт би не став платити).
То це був не джуніор я так розумію ? Просто вам хтось так сильно не подобався, чи швидше той факт — що начальство вам його підсунуло, що ви почали називати колегу джуніором ?
На загал «розумні» українці там чи індуси і т.п. які думають — що можуть надурити «дурних» клієнтів насправді і зі сторони і для самих клієнтів, які на бізнесі вже собаку з’їли власне тому і винаймають, а не навпаки — виглядають жалюгідно, як школяри які намагаються обдурити дорослого.
Не знаю, що там з джуном, але судячи з вашого опису — вашій говноконторі самій би не завадило «підвчитись» створювати нормальні тестові середовища, налаштовувати права доступу на гітхабі/лабі і ЯК ПИСАТИ/ОНОВЛЮВАТИ ДОКУМЕНТАЦІЮ, тому що це єдина адекватна причина, чого людина не змогла налаштувати проект аж за дві неділі, раз ніхто не зміг йому з цим допомогти. Я не один раз стикався з аналогічними проблемами, коли налаштування проекту треба було випрошувати у половини команди — один одне підказав, другий друге, а документація була на одну половину застаріла, а на іншу — не закінчена.
Мене продавали як аутстаф — вендора у компанії класу Microsoft та Salesforce. Як ти гадаєш — коли ми до них приєдналися нам надали документацію, провели онбордінг, їх співробітники усе показали і розповіли ... чи просто дали доступ до репозиторія з кодом і накинули багів у джирі?
Те, що MS пише книги як організувати процес розробки з документацією, тестами, обміном знаннями і такім іншим — це не означає що самі вони працюють по такому процесу. З мого досвіду у американських компаніях найбільш популярний «ковбой кодінг», який вони чомусь називають аджайлом.
А хто сказав — що по америках не існує пасивно агресивної поведінки ? В тому числі колективної. Токсичність це же їх термін навіть. BTW Саме у американських компаніях аджайл дійсно зовсім погано йде, без компаній консалтерв які можуть поставити процес. В першу чергу що процеси з загально Японського менеджменту зокрема Кайдзен, колективні. Тобто результат є командним відповідно і працюємо командно — так означає що з людьми певним чином поділяться, зокрема найвища зарплатня в Японії в людей перед пенсійного віку, які пропрацювали понад 30 років і при цьому можуть навіть займати номінальні посади і нічого не робити. Це повністю не відповідає американській суспільній і безнес індивідуальній моделям. Тобто результат є виключно індивідуальний, ніхто не з ким і нічим не ділиться і партнери мені можуть бути лише тимчасово вигідні, якщо вони мені не вигідні, це взагалі не партнери — а конкуренти. І скажімо 50+ річний ІТ шник має усі шанси опинились в наметовому містечку яке організує мерія Санфранциско для «ІТ бомжів» тобто людей які займались технологіями які вийшли з експлуатації, типу дротових телефонів, якихось автоматів і т.п. — а тепер не можуть знайти ніякої роботи їх ніде не беруть. В такій системі «Винуватий мамонт», вона дуже не любе приймати будь яких новачків із зовні. У MS така політика як Гейца так Балмера обох привела до ганьби, щоправда це ганьба із мільярдними статками і позиціями в списку Forbes в першій десятці.
В Україні та по інших колишніх караїнах СРСР — повний мікс. Є організації, типу Сберьанку де різні Грефи — будують повністю японську модель (власне вона і раньо радянська). В більшості же випадків взагалі ніякої моделі — в одному відділку так в іншому повністю усе по іншому. І якщо розбиратись чому ? Відповідь проста то було дві чи три різних фірми яких більш крупна корпорація поглинула. Або тут клієнт такий — в нього от так, тут інший і у нього кардинально все по іншому.
P.S. Зокрема коли американські аджайл кручі приїздили в нульових сюди ставити процеси і спілкувались із своїми колегами, вони дуже дивувались, що в нас інші проблеми. Головна американська проблема була в тому — що люди один з одним не спілкуються. Останні років
Вітя, ти такі тексти по всим темам пишеш. У тебе є особисте життя?
Кому завидно, опануйте 10пальцевий набір.
З того що ви розповіли проблема з вашим процесом онборднінга а не з людиною. А факт що можна пушити одразу в мастер це окрема премія для вашого тех ліда
Тобто у вас коміти прямо у мастер, немає технічної документації як налаштувати робоче середовище для розробки, лід мабуть якому на все наплювати, а винна людина яка не змогла налаштувати це за 2 тижні. Онбордінг судячи зі всього на вашому «говнопроекті» тоже не дуже. Я думаю що це навіть краще що людина не залишилась працювати на такому проекті. Я з такого проекта пішов би сам на другий же день роботи. Якщо комусь тут треба і повчитись, так це вашому клієнту і розібратись як налаштувати мерж нормально в мастер, що таке технічна документація і як проводити онбордінг на проект.
Цікаво що таке, що тут описав Бобер — ти можеш побачити у клієнтів — мульті-мільярдних компаній зі світовим HR брендом, чиї акції котуються в списку S&P 500. Там де ніби такого не мало би бути взагалі, бо ж бо процеси стандарти, імперія має стандарти — тим не менше в повний зріст. Як так ? Та дуже просто — будь-яка велика корпорація, це набір відділків, проектів тощо. Тобто по факту різні організації, часто стартапи, які якось один з одним пов’язані а може і взагалі не мають один до одного жодного відношення, по типу як відділки які займались Mac чи IBM PC були фактично жодним чином не пов’язані з рештою компанії і мали повіністю іншу ситсему робочих відносин і керування. Умовно там де Apple 2 або мейнфрейми IBM System/360 — креатив і іновації суворо заборонені, працює не лізь — і усе згідно плану та розпорядку, твоя задача крути гайки звідси та до обіду. Тоді як в інноваційних відділках повний креатив — брейнстормінги, переговори коротше движ йде. Десь на хабрі писали — «Нет никаого Яндекса — есть : Вася, Коля, Настя и вы работаете у них в отделе».
А за великим рахункам обом типам організацій є чого один в одного повчитись. Цим би мали займатись якісь окремі треті віділки типу PMO, та як я знаю толком таке створювали лише IBM — де Фредерік Брукс робив, та IBM захлиснула внутрішньо політична боротьба і сучасна IBM це бліда тінь минулої компанії.
Буває) я якось, пару місяців, як отримав мідла, закінчував роботу на проекті, а замовник взяв індуса-сіньйора на цю посаду. Я коли задавав справи, то тому індусу показував, як користуватись гітом
Коментар — лайк, лінк — лайно.
Залежить від того, від кого цей косяк і в яких відносинах я з цією людиною.
Якщо це робота джуна за 1000$ грос і я в нейтральних/нормальних відносинах з людиною, то швидше всього просто скажу що і як краще переробити, і в разі чого, до мене можна звернутися в будь-який час, можливо ще дам якісь рекомендації по літературі/open source проектам.
Якщо це робота людини з мінімум декадою років досвіду і я в нейтральних/нормальних з нею відносинах, то швидше всього запитаю щось типу «як можна так накосячить? — чи може тут є якийсь сакральний смисл в якому я сам не розбираюсь?».
Якщо це людина до якої я ставлюся швидше негативно (хоча за роки мого досвіду таких було десь півтора людини), то просто не заапрувлю рев’ю і дуже коротко напишу що мені не подобається
Ніяк, ніщо мене не забов’язує це робити. Це буде тільки безстроковий і безтолковий срач. Процес має завертати те, що не працює. Також в 99% випадків воно не має працювати ідеально, а має просто працювати.
Даю таку наводку, коли тебе додають до проекту то кажуть — що від когось там з верху (клієнта, керівництва, аудиту і т.д.) була скарга на низьку якість чогось, саме того що колеги роблять не так. І тебе додають саме з ціллю це виправити, про це кажуть. Одразу кажу, що люди так влаштовані, що далеко не завжди кажуть правду, а можуть просто свідомо на брехати із мотиваційними і корисливими цілями щоб банально когось там залучити на 996, та на інші його ресурси — час, гроші на обладнання, матеріали, частину прибутку, зарплатню нижче за ринок тощо. Таким чином будуть гасити за його рахунок системні косяки, щоб на цьому заробити собі — грошенят підвищення тощо. Тобто модель співробітництва чистий Win-Loose, банально хочуть на...бать, або вже це роблять.
При цьому ти зробив не дуже розумно і не затребував ультимативно у тих хто додає тебе до проекту, відповідних повноважень на зміну процесу, наявність бюджетів, обладнання, тренінгів і таке інше. Відповідно настає така ситуація — продовжують робити щось не так, винуватий в цьому виходиш ти. Тобто закривати ці косяки ти маєш власним рахунком. Умовно фіксити код, писати юніт тести, релізити тощо — по ночах та вихідних, купити власним коштом — якесь обладнання наприклад мобільні телефони, компьютери Mac, аренда серверів тощо.
І питання таке з ким на справді в тебе є конфліктна ситуація та що з цим робити ?
Теж ситуація — просто вийдеш із угоди по тихому і підеш в іншу, це нічого не гарантує, там з 90% буде така сама ситуація. Бо там де бізнес — там конфлікт інтересів.
Не станеш рішати конфлікт — на тобі прокатяться.
От тут для прикладу якраз таких відносин youtu.be/...LbIuM?si=BAI3kLAuK6OUaM9g
«Ніяк, ніщо мене не забов’язує це робити» — в нормальних компаніях, скіл давати свій фідбек і гайдити джунів вважається частиною ваших обовязків і необхіними мінумумом для того, щоб стати сініор розробником.
Спільното, у всіх же бували ситуації, коли виконана колегами робота вас дивувала — в нехорошому сенсі цього слова. Як ви казали про це?
Не понимаю о чем речь. QA разве не возвратит таску с комментариями что не так выполнено? Что значит «работа»? Что значит «коллеги»? HR, уборщица?
Це якось врятує від говно-коду, який пройшов ревю і був змерджений?
Якщо тестують гілку на окремому енві, а аппрув тестера серед обов’язкових на мердж, то врятує
Не врятує: якщо говно-код проходить ревю у девів, а єдина надія на умовного тестера, то у команді однозначно проблеми.
Та що ви відповідаєте, видно, что автор злосний троль.
В 95 процентах случаев говнокода, архитектуры, тестов, тдд, бдд и других фокусов не существует. В подавляющем большинстве случаев есть просто выполненная работа в срок на 3+ путем дописывания методов в год-обжекты. Это ценнее для карьеры, для менеджера, для проекта, да для всех. Обсуждение говнокода это приколы для не повзрослевших детей на кухне.
Існує нескінченна множина можливого коду котрий буде працювати правильно, але при цьому його буде неможливо підтримувати. Ну і інколи буває навпаки — в збиток розуміння коду — писати код котрий швидше працює
Дивись, цією задачею ми хотіли вирішити проблему N. Таке рішення не допоможе із цією проблемою, тому що ...
Що можеш тут змінити, щоб все ж таки вирішити її?
Часто зустрічається варіант, коли рішення таки допоможе з проблемою N, просто воно, мʼяко кажучи, виглядає не дуже.
В мене колега якраз любить наліпити костилів — умовну проблему N, на яку відкритий тікет, вони вирішують, але виглядають неоптимально.
А що ви говорите цьому колезі?
Що до мене, то у мене такий код з костилями не проходить код рев’ю й в рев’ю коментах я пишу свої зауваження до коду.
Я якраз є людиною, що проводить у нього код ревʼю, тому, роблю так, як і ви — пишу, що переробити, як саме і чому. Він ще чомусь постійно намагається шукати поверхневі рішення і не зовсім розуміє, що і як працює на більш глибокому рівні — наприклад, замість того, щоб пофіксити невеликий баг (на день-два роботи в розслабленому темпі) в певній фічі, пропонує наліпити зверху якесь кастомне рішення, яке вирішить проблему тут і зараз, але буде важко підтримуватись в майбутньому. Певно, це якесь специфічне відношення до роботи, бо проект у нас маленький, і колега працює на ньому майже рік — часу розібратись було більш, ніж достатньо.
наприклад, замість того, щоб пофіксити невеликий баг (на день-два роботи в розслабленому темпі) в певній фічі, пропонує наліпити зверху якесь кастомне рішення, яке вирішить проблему тут і зараз, але буде важко підтримуватись в майбутньому.
Напевно погано розуміє проект, ви звістно можете розмалювати йому архітектуру — заодно самі зєясуєте, що воно то там то сям зроблено не найкращім чином. А можете пояснити бізнес процеси, чому зроблено саме так. І в цілому на ваше рішення могли подивитись зі сторони і щось в ньому побачити не логічне — а такого буває придостатньо в усіх бойових програмних проектах. А там може бути і щось розумне, бо пояснення в нас тут брудно томущо мало часу, це таке собі — може ще довше бути з рештою.
Тут ще є момент такий, щоб не врубати дріл сержанта якого просто доведеться в певний момент часу, з розряду «я начальниця — ти дурак, викокнуй». Є люди які практикують наступне замість довгово код ревью, де як щось зроблено не так вже треба переробляти — краше питайте його пред тим як візьме задачу, що та як він робитиме — зяєсуєте чи він вірно зрозумів та оцінив задачу, разом з тим зможете проконсольтувати раніше.
Тут є таке розумне старе відео youtu.be/zrtSHem_24E?t=1095
Розумію :) У такому випадку розмовляємо про те, які наслідки може мати саме таке рішення в майбутньому, і чому це не ок.
Якщо це потрібно, потім в наступних задачах окремо це підіймаю ще до початку роботи.
Мабуть, найважливіше у фідбеку — це те, що рішення не ок не для мене, а для роботи проєкту/продукту/бізнесу/користувачів. І чому саме.
Не думаю що варто чекати аж до фінішу щоб давати фідбек, є код рев’ю, бізнес рев’ю і інші процеси які дають змогу обговорювати ці всі речі поступово. Є різні стандарти які мають для всіх у продукті бути зрозумілими. Потрібно працювати командою.
в любому випадку треба шукати і опиратись на конструктів.
Якщо те що було зроблено не дуже, то треба зрозуміти що саме
не так, та чому і більше так не робити.
Якщо підходити зі сторони все погано без можливості покращити то це
продукує нездорову атмосферу і нищить продуктивність.
Я довго загонялась з тім що я некомпетентна, і мабуть це
так і є, але я завжди намагаюсь вислухати що саме я роблю не так,
як робити краще, і в цілому, якщо прийдеш і спитаєш то багато нового
можна узнати.
А якщо не спитаєш то так і будеш не знати що можна робити краще.
Одного разу мені повідомили про погану роботу на зустрічі, де мене звільнили. Не робіть так
Все чудово але треба трошки переробити.
— мда, хто це таку хрінь написав
*перевіряєш git blame*
— oh shit
Говорю:
1. «Я ж не лох» © Зе
2. «Кто ты есть такой — ты кнопка бл**ь» © Кернес
3. «Вопросы есть у тебя еще или языки в ж**у засунул» © Коломойский
4. — ждём его ответ —
5. «А менi до пi**и» © Ляшко
6. «Давай по новой, < colleague’s name >, все ***ня!» © Добкин
«Я маленький гвинтик гвінтік» © Ківа
гвинтік* ))
точно!
Для такого якраз є ретроспектива-мітинг, де можна і треба про таке говорити. Але, звісно, без переходу на особистості. Просто факти, які можна обговорити всією командою, без переходу на імена і емоції.
Цікаво, а ви б менеджеру сказали на такому мітингу, що він щось робить не так? Або що він ВСЕ робить не так (а так теж буває)?
Перед тим, а щось критикувати, на прєкті повинен бути contributing guide і coding style guide. Без цього більшість боків вилізає через відсутність спільного розуміння «задовільного» рішення.
Якщо дійсно треба переробити, а не просто підфіксити — краще це голосом, пояснити що не так.
Розумієш коли ти кажеш : треба те, терба се — це вже конфлікт інтересів. А от колеги наприклад вважають, що не треба і так все добре, а от ти чи уся твоя команда тут явно лишні і ще і розумнічають тут, книжок по начитались десь по наробились і понавчались якоїсь херні. Йдіть звідси тут наша пісочниця ми тут заробляємо, якихось невідомо кого нам тут не треба. От ти і отримав продовження конфлікту, тільки ще дущего. Усе що завгодно може піти в діло, навіть клівета, підстави і т.д. На харасмент можуть подати і тому подібне.
— Я не врубаюсь, BMW — чужой ?
— Да
— Медведь чужой ?
— Ну
— И баба чужая ?
— Ага
— Так — а че мы тогда за ними гоняемся ?
— Ну бизнес !
— ААА !!! Комерция !
youtu.be/1-X4cqzaaZM?t=3112
Том Демарко Dadline — там написано як вирішувати конфлікти інтересів, якщо не хочете драки і вам треба далі з цими людьми працювати зверніться до посередника.
В цілому же купа книг типу www.yakaboo.ua/...hnij-zakon-liderstva.html принципи Макіавеллі кажуть не наїжджати на пряму, якщо вам треба далі працювати, або якось не потрібно конфліктувати. Хоча в реальному житті інколи треба бити аперкотом в нижню щелепу, поставити статичний код аналіз наприклад та затребувати стайлгайд, скажімо з гопником на вулиці нема про що домовлятись, більше за те не будеш швидко та точно діяти — відлупцюють та пограбують, єдиний компроміс в цьому — можуть не відлупцювати. На роботі те саме — з конкурентами ціль яких вас потопити, підставити, відібрати клієнта чи підвищення, шахраї які намагаються кинути і тому подібне, особливо нема про що балакати. Win-Win з гопником неможливий. Тобто спочатку треба дивитись хто є хто.
У Демарко там теж є такий містер Бредлок, інтриган та політикан — але по морді йому не даси, треба якось викручуватись, написали як.
Ти, султан, чорт турецький і проклятого чорта брат і товариш, самого Люцифера секретар. Який ти в чорта лицар, коли голою сракою їжака не вб’єш. Чорт висирає, а твоє військо пожирає. Не будеш ти, сукин ти сину, синів христіянських під собою мати, твого війська ми не боїмось. Землею і водою будем битися з тобою, распроїб твою мать. Вавилонський ти кухар, Македонський колесник, Єрусалимський броварник, Александрійський козолуп, Великого і Малого Єгипта свинар, Вірменська свиня, Татарський сагайдак, Каменецький кат, всього світу блазень, самого гаспида внук і нашого *** крюк. Свиняча ти морда, кобиляча срака, різницька собака, нехрещений лоб, мать твою в’їб. Отак тобі запорожці висказали, плюгавче. Не будеш ти і свиней христіянських пасти. Тепер кінчаємо, бо числа не знаємо і календаря не маємо, місяць на небі, рік у книзі, а день у нас, який і у вас, за це поцілуй в сраку нас!
ох як же хочеться іноді так повідомити про результати праці... але ..... прийдеться потім тренінги по софт скілам проходити
Результати вашої праці дуже важливі для нас!
Але я помітив що результати не є оптимальними та можуть бути значно покращені ... список з
Доповнити список «що треба зробити та що неможна робити» і закріпити його у тімз чаті
Розробник має знати як і що робити — джуну ті мідлу треба щось накшталт Статуту у армії щоб мозок можна було не «увівмкнути» та помилок не робити — і вони справді цим користуються!!!
Та це просто fit4brain.com/5676 Результат усе одно конфліктний буде, так само як і youtu.be/xBfsnqaGCWw?t=107 Реально часто ніяких варіантів крім второго нема.
ну в мене якось виходило так підштовхувати їх на «світлу сторону сили»
Це точно не IT. В IT дизайн лайна має бути цукеркою.
Відповідає ChatGPT
Start with a positive: Begin by mentioning something positive about their work or efforts. This can help set a cooperative tone.“I’ve noticed you’ve put a lot of effort into this project, and I appreciate your commitment to getting things done.”
Be specific and objective: Instead of generalizing that the code is “awful,” pinpoint specific areas that need improvement and why. Focus on the code, not the person.“I’ve been reviewing the module for booking appointments, and I noticed a few areas where we could improve the error handling and the overall structure to align more with our coding standards.”
Suggest improvements and be helpful: Offer clear, constructive suggestions and, if possible, help or resources to improve the situation.“Perhaps we could refactor this section using the strategy pattern to make it easier to extend in the future. I can show you some examples that might help.”
Invite their perspective: Encourage a dialogue, rather than a monologue. They might have reasons for their approach or could benefit from clarifying their understanding.“What do you think? Your perspective might also help us find a better approach together.”
Focus on the benefits of changes: Emphasize how the changes can benefit the project or the team as a whole.“By making these adjustments, we can significantly improve the performance and maintainability of the system, which will help us a lot in the long run.”
Use tools and standards as references: Referencing coding standards, style guides, or automated linting tools can depersonalize the feedback. It’s easier to accept criticism when it’s coming from a neutral, agreed-upon standard rather than feeling like personal judgment.
Be empathetic: Recognize that everyone, at every skill level, can make mistakes or overlook things, especially in complex domains like software development. Show understanding and empathy, which can make the other person more receptive to feedback.
Я чекав подібну відповідь від людей в чаті. Існує думка шо в Україні ***овий менеджмент і я чекав, що хтось її спростує. Але нажаль спростував лише чатЖПТ. Тут кожен пункт написаний кров"ю) Можливо варто розписати чому це важливо і коментатори неправі. Ой стоп, коментатори гарно написали, але є недолік, якшо не почати критику з хорошого, то людина займе до вас ворожу позицію і не буде робити так як ви скажете. Але нажаль ...
Та невже, це ж виключно в нас таке
www.youtube.com/watch?v=yPK6qlpJ_ug
youtu.be/pDwLsrmDBF0?t=577
www.youtube.com/watch?v=1LYEB6_MW04
Римський легіон напевно просто так 1000 років усіх перемагав.
В IT теж таке є і іноді діє, але не в креативних проектах. Це про сапорт і про новачків.
Щоправда Drill instructor перед тим як заступити на службу — проходить бейс тренінг (муштру) два рази www.youtube.com/watch?v=nPr-SIL6BiQ хоча там теж тенденція на «поліцейську академію» де Махоні підколює Гаріса.
Неодноразово бачив як таке використовують при масовій підготовці джуніорів, доки вони вже не попадуть на стажування, і сам проходив.
Думаєте шо програмісти не відрізняються від солдатів? Якшо солдату дадуть наказ чистити сортир — він піде і буде чистити, а спробуйте таке з програмістами) Тоді у вас більше не буде програмістів, компи здадуть в ломбард і напишуть статтю про вас на прекрасному айті
(Цей армійський вишкіл який ви навели в приклад, робиться ще і спеціально щоб відсіяти людей які люблять багато думати і задавати питання, а залишити тих які будуть лише виконувати накази)
В ІТ повно такої роботи як не дивно, з розряду задеплоїти багфікс на прод. Так я теж за скоріше за ігрові механіки, просто давити діє погано — ну як погано, якщо усі завдання стандартні то може і добре, як тільки треба думати головою то зовсім не діє. Так чи інакше інколи в систему яка не діє, треба вносити стрес, бо потім вам самим по шиї надають. При підготовці на стандартні завдання, з розряду написати пов’язаний список та навчитись користуватись git і коли студентів скажімо 50, от тоді оце використовують по повній.
Тому ви навели гарний приклад як залишити солдатів які всіх переможуть, але відсіяти джунів які стануть прекрасними програмістами. Саме тому такий підхід використовується в американській армії, а не в американськом МІТ
Та от ХЗ, як пам’ятаю перший курс перший семестр — так те саме. Хто не встиг, не зрозумів скажімо після бейсіку типи данних в паскалі, не залік на перездачу. Там де йде потік — там елітарна освіта з репетиторами не прокатує. Звісно гарні репетитори будь кого можуть навчити чому завгодно на дуже якісний рівень. Тільки в тому MIT чи сусідньму Гарварді, як і Прінстон із Стенфордом, чи Йель — скільки коштує рік навчання? Щось там виходе, що батьки Гейтца та Цукерберга вже були міліонерами, тоді як талановиті діти стали мільярдерами.
Прямо кажу якщо ван ту ван, або натякаю, якщо на загал. Якщо вже не доходить — тикну носом що не так. В команді всі рівні і коли запара — доробляти за кимось бо він полінувався чи натупив це не діло. ми не в дитячому садочку. Так само адекватно і сама реагую, якщо критикують.
А у вас точно запара?) хтось встановив якісь дедлайн може?
Просто кажу. Не завжди вдається без емоцій, особливо якщо я просив саме так не робити.
Міша, ето х"№ня давай по новому
www.youtube.com/...ab_channel=UkrainianMemes
«Немножко тест по дебильному написан».
Старая народная мудрость.
На попередньому місці роботи після отримання від тл ’що за х.. ти наробив’ - виникло бажання шукати роботу
А оце шо?
(в залежності від важливості питання — варіанти інтонації...)
Як і будь який фідбек.
Розповісти що сталося, чому. Який результат цього. А який би хотілося. А що змінити, щоб було так як хочеться.
Для форми можу використовувати ненасильницьку коммунікацію час від часу.
Потім парне чи моб-програмування, щоб закріпити.
Давай пановай, фсьо х-ня! © Геннадій Адольфович :)
все х**ня — давай по новому!
Конструктивно. Якщо щось не ок, пишу чому не ок, як мало б бути натомість, чому саме так, бажано з контектикою і прикладами. В кінці зажди пропоную обговорити більш детально, якщо щось незрозуміло або людина з чимось не погоджується. Звороти «з усією повагою» і т.д.б як на мене зайві, це те саме що говорити «шановний», коли висуваєш якісь претензій людині.
типу такого
---
привіт,
Є пара нюансів:
1 — <нюанс 1>
2 — <нюанс 2>
....
N — <нюанс N>
Якщо є питання, пищи
Саме так — ми не воюємо з людиною, ми воюємо з явищами
Олександр Шпак
NarutoUA
Beaver Green
Yevhenii Oliinyk
Viktor Cherniy
Alexander Levinson
Viktor Soltis
Oleksii Kovalov
Andriy Kutsynyak
Bot Bot
Bot Bot
Dmytro
Марк Сахарчук
Valentin Nechayev
Andy W
Oleksii Kovalov
Lev Pasichnyi
Vic
Maxim Deyneka
Yevhenii Oliinyk
Mykhailo Gordienko
Dmytro
Мамка Жука
Mykhailo Gordienko
Illia Kucheriavyi
Мамкин АЙПИшник
Олександр Доскіч
Dmytro Kopaev
Чорний Список Юджина
Oleg Artyomov
Alexander Pastukhov
Oleksandr Bereziuk
Alexander Vostres
юнит тест
Volodimir Nazarenko
Oleksandr Tishyn
Леонид Мартынюк
Дмитро Московченко
Александр Енотов
Віталік Ковальчук
Viktor Zhurbenko
Oleksandr Poliukhovych
Maxim Deyneka
Dmytro
Kateryna Borshchuk
Oleksii
Marina Zaytseva
Karina Kosenko
Nikola Utiuzhnikov
Emma Orlova
Afterlife
Котячій швейцар at home
Андрей Литвинов
Oleh Onufryk
KaterinaR
Sergiy Morenets
guest
Vic
Рахіт Срінавасович Кумар
Kai Owas
Olena Sharovar
Вячеслав Попіка
Ирина Ходачинская
Серж Фалінський
Yurii Didkovskyi
Hello fnckiug world
Evgeny Sergeev
Юра
Sergius von Bielersee
Oleksandr Ryzhkov
Oleksii Didenko
Kateryna Borshchuk
Andy W
Юрий Шморгун
Найкращі коментарі пропустити