З моєї точки зору є дві об’єктивні метрики — defect leakage, release time.
Якщо багато багів на проді — фігня, якщо реліз триває дні і тижні ще більша фігня.

Тобто від моменту
PR merge до моменту deploy to prod має бути максимум 1 день
При цьому кількість дефектів не має рости по мірі розвитку продукту, все інше то суб’єктивне і залежить від проекту і продукту

Маю на увазі user facing issue. Кількість внутрішніх взагалі не важлива

Це шалений триндьож. Середня зп в Україні все ще на рівні 700 баксів, у людей з досвідом по 10 років. Це по суті зп джуна в перші пару років в ІТ

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

Ми вирішували так — один домен то accounts, щоб користувач не створював окремо для кожної апки профіль, і він API для всіх
А далі по мірі того як кількість edge cases росте команди виділяються під окремий домен і переходять на свої сервіси навіть через копіювання. Бо це зберігає release time на рівні годин, а не днів і дає чітке розуміння хто краще в хто гірше розвиває свою частину

Доречі прикольно, хоч і мають preply.com/ru але якщо пошукати викладача по країні то Рашки навіть в списку нема. Повага за принциповість

Молодці. Бачу основний виклик в маштабуванні, якщо додати до платформи наприкладд математику і ще щось географічно близьке буде цілком Uber за розмірами.
Мене ніхто не питає але я б пропонував повістю ділити, починаючи з апки, наприклад preply music, preply math etc.
З одного боку росте бренд з іншого можна вирубити щось без шкоди для компанії.

Якось бачив рекламу як маленьке звірятко загортає шоколад у фольгу, чи ще потрібен Рошен?

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

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

На рахунок reusable components vs screen/page я б в світі АІ не парився написанням власних компонент. Бо створити, переробити, сторінку зараз дуже просто. А якщо ви не працюєте безпосередньо в реакті то ваші компоненти нафіг нікому не треба, бо як раз вони будуть максимально гальмувати генерацію за допомогою АІ

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

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

І скільки MAANG інженерів можуть на себе працювати? І якщо знаєш як маштабувати 10 мільйонів транакцій на годину вже можна свій банк відкривати?

ризики їх втрати, пошкодження чи підробки.

Тепер тупо update/delete в базі може знизити всі документи, супер захищено

Цікаве інтерв’ю. Дуже практичний підхід

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

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

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

А ще мама директор і папа з шахтою

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

Ярослав — борець, Кожаєв — баксьор. Міша, Гриша й Опанас просто щоб згадати класика.

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

Прикольно, але тут постає event-driven архітектура і все стає зрозумілим. Бо start/stop це чудові івенти