Що потрібно, аби ви кодили на швидкості х10 і не думали ні про що інше? Діліться думками 💬

Спільното, поговорімо про інжиніринг продуктивності розробників.

У сьогоднішньому подкасті ми згадуємо про створення культури developer experience і про середовище комфортної роботи для розробників в Netflix.

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

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

А як виглядає ваше ідеальне середовище для якісної роботи? Що потрібно, аби ви кодили на швидкості х10 і не думали ні про що інше? Розповідайте 👇

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Найкращі коментарі пропустити

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

Що потрібно, аби ви кодили на швидкості х10 і не думали ні про що інше

Просте, звичайне повідомлення в Slack: «там твій функціонал поклав половину прода, треба швидко фіксить»

Згадався старий анекдот про машиністку (хто ще пам’ятає що це ;-)
— А ви можете друкувати зі швидкістю 300 слів на хвилину?
— Можу. Але така фігня виходить...

«вам пощітать бистро, ілі правільно?» (ц)

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Шуткаюмора: щоб кодити на швидкості х10 мені доведеться трохи притормозити 😂

Якщо буде щось пов`язане с математикою, фiзикою або ж електротехнiкою.

Та ви люто женете. Нашо мені така робота де в мене кукуха зʼїде і дим з вух піде

х10 порівняно з чим? Що таке х?

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

Але все таки, з чим ми порівнюємо?

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

Не бачив жодної людини яка кодить х10.

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

Ви не помічали на співбесідах (якщо є live coding) що деякі люди, навіть маючи 3-5 років досвіду, доволі довго шукають букви на клавіатурі. Може то від нервів, але швидкість набору іноді розрізняється в 2 рази у людей однакового рівня.

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

Олена, а знаєте шо йцукен — це завада швидкому набору?

Я більше вірю в архітектора х10 та СЕО х10, мають набагто більший вплив на time to market, ніж в 10 раз швидше писати круди та http клієнти на мікросервісах, реалізуючи непотрібні клієнтам фічі з ТЗ аля «7 червоних ліній, половина прозорим кольором, одну зеленим, й всі мають бути перпендикулярними»

Якщо виконувати це ТЗ послідовно, то можна. Зробив би декілька кнопок: на першій написав би «7 червоних ліній» на другій «дві зеленим» і т.д. Створив би захищені записи, розподіл прав. Кожен користувач побачив би тільки свій екран — всі б були задоволені.

Формошльопити одне й те саме впродовж років.

За великим рахунком воно усе одне і те саме. Тільки CRUD за допомогою ADO та VCL на Object Pascal чи Borland C++ в стандарті 98, або Visual C++ та MFC чи AVL, має інший синтаксис за Hibernate. Apache Struts трошки інший за Spring Framework або JBoss Seam. Angular, React чи Vue разом із Bootstrap, трошкі інші за JQuery з JQuery UI або Dojo, або GWT або JSF. J2EE трохи інший за мікросервіси Amazon 6 від AWS тощо.
Єдине що залишається — воно одне міняє інше, значно швидше ніж ти встигаєш усе це досконало вивчити.

Після Angular довелось трошки попрацювати з Android, потім був Vue, далі вже для себе потицяв GTK, тож так, то там, то тут є схожі підходи. Але я мав на увазі взагалі одне й те саме. На початку карʼєри трохи працював із компанією, що спеціалізується на розкрутці бізнесу в інтернеті, із ними працювали хлопці, кожен з яких за день робив один великий лендінг. Ось так можна прискоритись до х10, зʼїхавши з глузду :D

Згадався старий анекдот про машиністку (хто ще пам’ятає що це ;-)
— А ви можете друкувати зі швидкістю 300 слів на хвилину?
— Можу. Але така фігня виходить...

Х10 оплати наперед. А якщо правильно, то більше, бо х10 продуктивності досягається більше ніж х10 зусиль

Що потрібно, аби ви кодили на швидкості х10

Таке враження що автор питання взагалі не розуміє що ото ті айтішники роблять і за що їм гроші платять

А чому взагалі не x100, до чого ці обмеження?

Та легко. Нужно 10 машинисток посадить набирать код. Делов то.

Що треба щоб кодити на ентерпрайзі в 10 разів швидше? Це можливо насправді, треба просто одразу фігачити нову фічу, не дивтися шо там вже є, які данні вже є в системі, є така колонка може в іншій таблиці, немає, хєрячиш нову. Потрібна єнамка то не треба її шукать може така є, хєрячь нову. Розбиратися як влаштований сусідній компонент щоб робити в єдиному стилі і єдиній архітектурі теж не треба. Дев тестінг взагалі поле непахане для економії часу. Можна ще юнітів нахєрячить, не важливо які флоу вони перевіряють, не важливо як якісно вони замокані і скільки з них звалиться після найменших змін, головне їх має бути дуже багато , а значить дуже багато коду і великі пул реквести. А от якщо все ж хочеться більш якісно, то ловиш себе на тому що 80% часу займає не написання коду, а його читання, уточнення вимог, сінки з коллегами

Не виключено, що цей передовий досвід вже десь використовується.

Це взагалі провідний світовий метод з розробки програмного забезпечення ! Передається від гуру до просвітлених через з відповідних варн. Метод категорично забороняє описувати себе і будь що в проекті взагалі.

Та це ж стиснутий опис методології Бангалор Дрівен Девелопмент ! Що ж комбінацією images.app.goo.gl/aGM4oRsmwsafwws16 та www.pinterest.com/pin/627548529310474045

скорее LSD это для дизайнеров, кодеры это амфитаминовая группа)

От і розібралсь
LSD — дизайнерам
Мет — кодерам
Канабіс — QA
Кокс — менегерам

Все? Затверджуємо бюджет проекту?

Потрібно щоб ракети з шахедами не відволікали від роботи.

Искусственный интеллект пишет в 1000 раз быстрее, но потом отлаживать это ты будешь в 1000 раз медленнее.

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

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

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

Якщо на себе тотпрацюй
Якщо контрактом консультант — інвестуй висвій бренд і піднімай рент
Якщо робота класичний фултайм — налагоджує стосунки з командою і менеджером. Будуйте взаємовигідні відносини

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

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

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

Все просто. Якщо вам потрібно створити MVP — просто покладіться на досвід програміста в його попередніх проектах.
Якщо вам потрібно створити новий модуль — просто покладіться на досвід програміста у його поточному проекті. Якщо у нього з’являться питання — він вам їх задасть.

Якщо ви не впевнені у своєму баченні продукту і вам потрібні мітинги для обговорення — не чекайте високих показників продуктивності.

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

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

Та ні, не просто. Навіщо вони є, якщо вони не потрібні?

Часто томущо ніхто не хоче брати на себе відповідальність.

От-от. Мітинги це соціально-політичний аспект. Але інтроверти не завжди це розуміють.

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

Так. Наприклад, щодо дискотеки — це еволюційна оборона бажаного генома. Люди, у більшості є еволюційно правильно налаштованими. З точки зору екології та генезису планети Земля. Але! Не з точки зору survival. Чому так? Тому що еволюційні процеси це процеси збільшення ентропії систем. Тобто створення хаосу є первинним наслідком еволюційних процесів. Перебування у конфліктах є також наслідком ходіння еволюційно правильними шляхами.
І все це веде до виживання роду, але не виживання його частин.
Еволюції це ок, але не ок нам, розумним істотам.
Розум є еволюційною помилкою. Бо існування розумних починається з укреплення атомів. Тобто- якщо кожному окремому ок — всім буде краще жити.
Еволюційні процеси заперечують таку організацію систем у якій кожній окремій частині буде ок, або навіть добре.
Тобто еволюційність систем дорівнює їх нестабільності.
А стабільність не є основою для різних хаотично прогресуючих речей.
P.S.
Якось так, якщо я нічого не переплутав. Тобто легко бути тварюками, і це не добре, важко бути розумом власним керованими, хоча це добре.
Тварюки всесвіту до вподоби — бо дуже хаотичні,
Навпаки — розумом власним керовані люди — дуже впорядковані, створюють напрочуд стабільні things — таке всесвіт намагається зруйнувати бо воно схоже на кристали з гострими гранями що ранять всесвітній устрій.

Тут ще є парадокс, що найкращі з точки зору керованості системи створювали : Рамзес Другий, Александр Македонський, Цезар, Тімучин Чінгіз Хан, Наполеон Бонапарарт, Гітлер, Сталін тобто завойовники :) Виходить, що кінцевою ціллю доброї організації виявляється повністю деструктивна ціль. З іншого боку були Хрущов та Кеннеді, які зрозумівши, що прийшли до прірви вирішили змагатись в інший спосіб — економікою та наукою, власне по пропозиції Хрущова. Та як бачимо не довго музика грала.

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

найкращі з точки зору керованості системи створювали

і як ти це виміряв ? 🤔

І тобі цікава філософія? А як що до магії? Паралогіки?
У мене всього цього добра багато — тільки запитай.

У мене всього цього добра багато — тільки запитай

ви нашо Джордано Бруно спалили ? 🤔

Ну дійсно — нащо? Невже щоб оце він залишився навіки у пам яті людській?

що найкращі з точки зору керованості системи створювали

Про якість системи треба говорити після того, як вона хоча б 5 поколінь наступних керівників пропрацювала без зламів. У всіх названих воно розпалось, у деяких ще за їх життя. А ось США стоїть вже 200+ років (і стоятиме далі якщо переживе поточний кризис).

економікою та наукою, власне по пропозиції Хрущова

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

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

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

як мінімум перейти з кувертійцукена на дворака чи на двоблокову чи позитивну клавіатуру треба

О боже, воно й сюди просочилось!

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

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

Це цікаво для бюджету та прибутковості. В питанні розробки ПЗ час витрачений на цю розробку прямо пропорційний витраченим коштам. Якщо почитати будь яку книгу з бізнесу там буде надано лише два методи підвищення його прибутковості — перший це масштабування тобто : збільшення продажів, кількості оборуток, сум по чеках тощо, другий це зменшення собівартості.
Тому більшість компаній завжди будуть ставити два питання — як зрости в бізнесі і як витрачати на це меньше грошей. Відповідне головне питання яке ставить перед собою ІТ бізнес — як розробляти значно швидше і при цьому ще і якісніше. Насправді це вірно поставлене питання. Японські вчені поставили цю задачу в середені минулого століття на загал, почали вивчати методології які використовують успішні підприємства в самій Японії і поза її межами, разом з тим зібрали і перелік типових помилок які ведуть навпаки до поганих результатів. Це все призвело до створення системи управління Кайдзен. Ця науково розроблена система зокрема каже, що найкращі результати зі збільшення продуктивності праці — надає зміна або впровадження технології виробництва. Американська система бізнесу, це якраз та яка скажімо Netflix, ставиться навпаки в противагу.

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

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

Можна створити із власного мозку невеличку LLM — це може допомогти.
Як створити? А як створюють LLM? Ось і тут — вибираємо з документації проєкту найінформативніші словосполучення та їх сполучення. Та upload in brain
Через деякий час у brain утворяться нові синапси...
P.S. upload тут багатократне повторення. Саме цього дуже не любить людська свідомість і здогадайтеся — чому? Тому що це необхідно щоб навчатися. А хто любить чомусь вчитися? Ніхто. Це дискомфортно...
Так, LLM із людського мозку створити можливо. Там 100 млрд нейронів. Багацько.

аби ви кодили на швидкості х10

Кому это нахрен нужно? Меня нанимают, чтобы я изучал месяцами бизнес-логику и бизнес в целом и мог за разумные 1-2 недели найти и поправить нужную 1 строчку кода.

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

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

P.S. Згаданий в топіку Netflix — має найвищу плинність ІТ кадрів в Долині, за статистикою цілих 80%. Як відомо це бізнес стратегія, людей випалюють під нуль потім беруть інших. Щоправда, за той проміжок часу, доки людина там працює, платять найвищу зарплатню на ринку (Amazon робить мало не те саме, але платить менше), але без стоків і т.п. Гадки не маю як вони підтримують належний рівень експертизи при такому підході. Але із загальною дороговизною життя в Долині, багато хто вважає саме Netflix найкращім роботодавцем з FAANG. Хоча за сукупністю параметрів різні HR експерти вважають — що таким роботодавцем насправді є Apple.

Ходити по воді та розробляти програмне забезпечення по специфікаціям дуже просто, якщо перше і друге заморожено. Едвард Берард
Закон Хофстеда каже — що це відніме більше часу ніж ви вважаєте, навіть у випадку коли ви берете до у ваги закон Хофстеда
Наладка коду вдвічі важча за його написання. Тому якщо ви пишете код настільки розумно, наскільки можете — ви недостатньо розумний щоб його налагодити Брайан Керніган
Написання перших 90% коду віднімає 90% часу розробки, написання останніх 10% віднімає інші 90% часу розробки Том Каргіл
Якщо ви хочете розробити якусь круту нову штуку, вам не потрібні мільйони доларів капіталізації — вам потрібно холодильник забитий піцою та дієтичною колою і дешевий PC разом з виділеним часом для роботи на ньому Джон Карлмарк (P.S. Сам Джон коли робив Doom і т.д. завжди працював на топовому обладнанні типу легендарного Qube від Next Step, 27 дюймових моніторах тощо).https://gist.github.com/Potherca/b6a6676a84b51c8200d0673a5b4a87c5

Щодо останнього параграфу — якщо треба швидкість 10х то відшкодування витрачених на це калорій потрібно десь біля 20х.

Карлмарк

Карлмаркс

Щоб швидко кодити треба:
1. Кодити з помилками.
2. Виправляти помилки.
P.S.
До речі, з помилками круто кодить ШІ. Тому кодинг зводиться до конструювання промптів до ШІ та виправлення помилок у результатах такої співпраці.

багфікс: Читати не «круто кодить», а «швидко кодить» — трохи помилився.

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

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

LLM який прочитав весь код проекту

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

Про це стара книжка Peopleware. Ще у 80х писана, здається.

Прибрати в офісі опенспейси.

Можливо краще взагалі прибрати офіси?

В нас тестувальник тікав з дому до офісу поспати, коли друга дитина народилась

За 4 роки поза офісами, маю визнати це не найкращі ідея. Інша справа — що воно за офіс, велика конюшня опенспейсу набита людьми як оселедцем в діжці — значно гірша за роботу вдома. Достатньо простору для невеликих креативних команд на максимум 7 людей в одній команді — що може бути краще?
Тим не меньше той самий Linux від початку створювався при повному ремоуті, це між іншим призвело до необхідності створити Git та низку інших інструментів для забеспечення процесу. «Команда» періодично збирається на різних конференціях, деяким командам з розробки керівник показує середній палець і посилає туди де російський корабель — усе в кращіх традиціях розробки.

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

Ти тільки-но сказав роботодавцю, що тебе можна зайняти на ще один проект до ще одного замовника, або до якихось інших ініціатив припахати наприклад менторити новачків або там вести якісь освітні заняття, долучити до розробки якихось престижних маркетингових активностей типу розробки опенсурсних проектів типу Go lang, організацій хакатонв, сертифікації з усього що можна тощо. Бо ти пів дня за свою зарплатню валяєш дурня, тобто не завантажений. З іншого боку коли воно так, як я описав (окрім 5 аутстафінгових проектів одночасно) то більшість народу назвало би таку роботу вкрай цікавою. Щоправда так вже давно не роблять інженерінг менеджери, не хочуть ризикувати мати проблем із клієнтами коли на двох чи більше проектах одночасно завал буде, чи робітник відкладає нецікавий багфікси і т.п. на комерційному проекті десь в дуже довгу скриню. Також хаотичний менеджмент на стороні клієнта — це норма, спочатку дурня валяють потім аврал. Ну і в інженерінг менеджменті, як на мене, через масову еміграцію спеціалістів такого рівня за кордон, десь з 2014 року, відбулась конкретна деградація.

В інтернетах пишуть, що потрібно розуміти кодову базу та реквайрменти.
Себто, щось на зразок strict code ownership + канбан з розписаними задачами (або отримувати хотілку від продактів і самому її перетворювати на задачу).

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

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

Всё просто — нужно начинать стартап:

“Economically, you can think of a startup as a way to compress your whole working life into a few years. Instead of working at a low intensity for forty years, you work as hard as you possibly can for four. [...]
If you’re a good hacker in your mid twenties, you can get a job paying about $80,000 per year. So on average such a hacker must be able to do at least $80,000 worth of work per year for the company just to break even. You could probably work twice as many hours as a corporate employee, and if you focus you can probably get three times as much done in an hour. You should get another multiple of two, at least, by eliminating the drag of the pointy-haired middle manager who would be your boss in a big company. Then there is one more multiple: how much smarter are you than your job description expects you to be? Suppose another multiple of three. Combine all these multipliers, and I’m claiming you could be 36 times more productive than you’re expected to be in a random corporate job.”
— Hackers and Painters, PG

Грінфілд проект з 1 девелопером і повним розумінням бізнесу. Без тікетів, джири, повна доступнійсть і довіра бізнесу, ковбой кодинг.

що потрібно, щоб жінка народила дитину за 1 місяць і не думала ні про що інше?

Звісно 9 жінок і фалос Шиви.
А фредеріка Брукса з його законом Брукса, треба спалити на вогнищі. Міфічний людиномісяць має бути визнаний не канонічною єрессю.

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

Але навіть це все в купі не гарантуватиме успіху проекту і успіху продукту.
Для успіху треба ще додатково:
— аби маркетинг працював у 10 разів краще
— юзери залучались в 10 разів легше і залишали у нас в 10 разів більше грошей

В общем-то секретов тут нет. Чтобы кодить много и продуктивно надо:

Хорошо выспаться.
Подтянутся, пройтись утром, чтобы запустить обмен веществ.
Выпить кофе а лучше зеленый чай. Можно еще Л-Теанин, ГАБА и Ашваганду закинуть.
Не бухать минимум пару недель.
Отсутствие стресса и отвлечений.
Хорошо поставленная задача, и вообще знание кодовой базы. Я пока задачу не пойму, вообще не могу ничего делать.
Послушать какую-то бордую музыку типа Wardruna, Danaheim, или просто мотивирующие видео.

И самое важное — feedback loop в виде тестов или любой другой возможности сразу тестировать. Поэтому на проектах где, я например внедрял качественный CI/CD, продуктивность вырастала в разы. Мне в епаме за это даже бонус дали, ведь команды начали деливирить каждый спринт что-то новое, а не раз в полгода до полуночи релизить новую версию) Тот самый developer experience :D

Программисты такие же биологические существа как и все остальные, а кодинг с точки зрения биологии это экстремальная когнитивная нагрузка, поэтому организму нужны ресурсы это раз, а во вторых организм должен быть в состоянии силы, а не выживания (стресс вводит в состояние выживания).

Те кто под сиренами и обстрелами могут еще и что-то кодить это вообще железные люди, у которых нервы как канаты.

Не бухать минимум пару недель.
Отсутствие стресса и отвлечений.

ось це вже складно

Что то ты много хочешь. Может тебе ещё и ракеты убрать летающие над головой?

. Я пока задачу не пойму, вообще не могу ничего делать.

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

Що потрібно, аби ви кодили на швидкості х10 і не думали ні про що інше

Просте, звичайне повідомлення в Slack: «там твій функціонал поклав половину прода, треба швидко фіксить»

А що кодинг це про друкування? Я думав copy paste.

чомусь пригадався старий анекдот про кандидатку в секретарки яка тайпала тексти 600 символів на хвилину..

Знов хтось хоче зробити неможливий трикутник гроші-час-якість? :)

Мені от завжди було цікаво, при яких обставинах можливий варіант довго, але якісно і дешево?

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

переробляючи те, що не подобається

Знаємо, проходили. В результаті ще досі цей код переписується 😅

Справа в тому — що як і у випадку з будівництвом, напевно найближчою до нас галуззю в плані управління, чим довше йде розробка тим вона дорожче.
По цій же аналогії — переважна кількість ІТ проектів, це будівля традиційних азіатських мазанок з гімна та палок, групою погано освічених ремісників без : гео дослідів, проектування, документування і планування на базі фольклору і національних традицій.
Разом з тим невелика кількість мислителів розробила технологією яка дозволила побудувати : Шумерські Зіккурати, Єгипетські піраміди, Велику Китайську стіну тощо — що стоять тисячоліттями. Коли це роблять в ІТ про цей дизайн і технологію як то : Unix, Excel, Oracle теж знають усі, але в більшості випадків продовжують національне зодчество.

Оракл зсередини здається набагато більшим аніж ззовні news.ycombinator.com/item?id=18442941

Робота із будь якою великою і відносно старою кодбазою така. Робота із Mozilla скіжімо, жодним чином не простіше. Дядько Боб — Роберт Мартін, рекомедує модульну архітектуру, слої тощо, тобто Multix/Unix. Java з 9-ї версії так переробили.

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

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

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

Як я знаю за Томасом Кайтом, це котрий Ask Tom — там архітектура та насправді є і вона дуже цікава. Хоча те що за роки кодова база піддалась ентропії тут напевно нема чого зауважити. В сенсі ентропії коду — еталонним проектом вважається Trident (Internet Explorer), нова команда після чисельних спроб рефакторінгу вирішила просто почати з нуля і створили Edge, бо так дешевше. Тим не менше серед усього різноманіття RDBMS з якими я колись працював в продакшені саме Orale показував себе з найліпшої сторони, при умові вміння ним користатись (так він складний з порогом входу і вимагає навчання, на дурака сів та почав прокатує слабо). Трохи гірше по функціоналу, але теж дуже достойно PostgreSQL. А скажімо : Neo4, DynamoBD, Casandra, BigTable — це усе дуже специфічні штуки, в якихось хитрих алгоритмах мають перевагу. А коли їх використовують замість реляційної моделі даних — виходе бознашо.

Ну так є ж зато трикутник Лебедєва : Дорого-Довго-3.14здато

ото ж згадали... як це уточнив тінькоф, який шось замовляв у лєбєдєва:
довго та 3,14зда як дорого

«вам пощітать бистро, ілі правільно?» (ц)

Підписатись на коментарі