Цикл продуктовой разработки часто напоминает весы: с одной стороны, системное проектирование, подбор основополагающих инструментов, масштабные рефакторинги. С другой — совокупность локальных решений, принимаемых для точечных улучшений в системе. И самое сложное тут: соблюдать баланс. Как понять, когда имеет смысл вмешаться «хирургически», а когда — предпочесть вместо конкретной проблемы решить (или предотвратить) целый класс проблем?  

Иногда нащупать границу между «масштабом» и «целесообразностью» получается почти что случайно. Однажды мы в Сравни подступились к переделке чата в нашем мобильном приложении, и на старте расценивали задачу как «ещё один рядовой продуктовый кейс». Но планы по модификации фичи быстро переросли в создание универсального инструмента: конструктора сценариев на базе Backend Driven UI.

В итоге мы не просто заменили чат более удобной альтернативой, а в целом научились гибко управлять фронтендом приложения. Со всеми сопутствующими плюсами как для бизнеса, так и для самих разработчиков (теперь, чтобы реализовать некоторые изменения на экранах, даже не обязательно быть фронтендером или мобильным разработчиком!).

Подробности о нашем сценарном BDUI-движке — этапах его создания, вариантах использования и нюансах технического устройства — читайте под катом.

На конференции приходят за знаниями, а уходят — с контактами. Или не уходят — потому что ни с кем не заговорили. В этой статье — понятный гайд: зачем разработчику нетворкинг, как не чувствовать себя неловко и что делать, чтобы разговор продолжился и после мероприятия.

Привет, Хабр! Я Настя, редактор YouGile — мы делаем систему управления проектами. Когда-то мы выяснили, что первыми закрываются компании, где ставится много задач. Теперь поговорим, реально ли работать над несколькими задачами одновременно и что об этом говорят исследования.

Все компании попадают в такую ловушку: кажется, что по любому вопросу проще собрать онлайн-совещание. Но часто от онлайн-встреч не так много пользы - собирается больше сотрудников чем нужно, а по итогу - все расходятся, так и не поняв, к чему пришли за пару часов. Мы тоже там были, но придумали, как проводить видеоконференции эффективнее и быстрее.

Почему люди не используют типы чаще? Возможно все связано с тем, что опытные разработчики перестали использовать нерабочие паттерны, не оставляя за собой следов для новичков. В этой статье более детально разбирается недавно удаленный мной код с паттерном, который я называю «утка‑дублер». Вы сможете проследить процесс разработки типа, а также причину его удаления. Также мне хотелось бы попросить разработчиков на Rust документировать и делиться своими ошибками, чтобы мы все могли на них учиться.

Привет, Хабр!

Сегодня разберём, как устроен reflect.Value изнутри и что на происходит, когда вы вызываете .Field(i).

... вопрос оказался настолько глубоким, что стал этой статьей.

Итак, это ответ на вопрос в комментарии к моему предыдущему статье-мнению: https://habr.com/ru/articles/913720/comments/#comment_28375568 Вопрос / комментарий от victor_1212

В этой заметке я расскажу, почему я больше не хочу иметь отношения к современному интернету и попыткам вырваться из него

Долгих дней и приятных ночей! Меня зовут Натали, я IT Project Manager со стажем 10+ лет. В данной статье хочу поднять вопрос негативного влияния добровольно‑принудительных командировок удаленщиков в офис как на сотрудников, так и на компанию вцелом. Особенно первый раз. Особенно для интровертов. Статья будет полезна руководителям, проджектам, HR и любому it‑специалисту (возможно вы узнаете себя, и убедитесь что вы такой не один). Поехали!

Представим, что вы — руководитель (тимлид, ПМ, Head of PMO, не столь важно). Работаете в крупной компании в Москве, следите за финансовыми метриками успешности проекта/компании. Под вашим руководством распределенная команда — многие работают в Москве на гибриде, кто‑то всегда из дома, кто‑то из других городов. В какой то момент вы раздумываете над вопросом — а как увеличить эффективность команды? Часто на этом этапе руководители приходят к мысли, что нужно, как это сейчас модно, «сплотить» команду — и все сразу станут более производительными, чаще будут писать друг другу, просить и оказывать помощь, охотнее говорить о проблемах и быстрее придумывать решения.

Меня зовут Артём, я занимаюсь коммерческой разработкой с 2019 года. Последние несколько лет я активно использовал Spring Boot для создания backend-сервисов на Java и Kotlin.

Но в какой-то момент захотелось попробовать что-то новое. Не потому что Spring надоел, а просто чтобы выйти из зоны комфорта и узнать, как чувствует себя проект на другом языке. Я решил: возьму уже начатый pet-проект, перепишу его на Go — и посмотрю, как изменится подход, скорость разработки, ощущения.

Всем привет! В данной статье я поделюсь своим опытом написания сервиса. Я не являюсь опытным или профессиональным разработчиком, я пишу свой проект и мои решения могут быть не самыми оптимальными. Эта статья состоит в основном из ошибок, которые я совершил. Мой путь не является правильным и потому - судите "строго".

Проектирование масштабируемых и надёжных систем — это не просто технический процесс, а искусство создания инфраструктуры, которая способна эволюционировать вместе с растущими требованиями бизнеса. В этой статье мы разобрали ключевые принципы проектирования, которые помогут вам избежать ловушек при масштабировании, обеспечении доступности и стабильности работы в условиях постоянно меняющихся нагрузок.

_{"Предупрежден - значит вооружен"}
^{(© народная мудрость)}

Наверное все когда-нибудь сталкивались со звонками "старшего майора государственной безопасности" <имя неразборчиво>, объясняющего, что если не сделать то, что он скажет, то из свидетеля легко можно стать обвиняемым, или "службы безопасности банка" с предложением "перевести деньги на защищённый счет" для их сохранения, или "из пенсионного фонда" с просьбой "подтверждения рабочего стажа", для чего надо записаться на приём и продиктовать номер очереди из СМС, или другими случаями телефонного мошенничества.

Большинство при таких звонках сразу кладут трубку, а многие вообще не отвечают на звонки с незнакомых телефонных номеров, а то и просто блокируют их.

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

Мы часто шутим над нашими незадачливыми согражданами, вложивщимися в очередное Кэшберри, Финико или подобные пирамиды. Нет, серьёзно, люди вкладывали все свои сбережения и брали кредиты, чтобы воплотить в жизнь мечту о волшебном слове «халява» — в общем, можно только посочувствовать. И мы ведь часто думаем, что проблема наверняка в отсутствии финансовой грамотности — вот если бы на месте очередных пострадавших оказался какой‑нибудь еврейский финансист из Бруклина или просто человек с достаточно критическим мышлением, он бы наверняка сразу заметил обман.

Ага, щас. Стремление к халяве — интернационально, а эта история — о человеке, выстроившим величайшую в мире финансовую пирамиду и вошедший в историю как один из крупнейших американских аферистов начала 21 века. О человеке, без сомнения претендующем на звание самого бесславного финансиста Америки. Итак, встречайте — (ныне покойный) Берни Мэдофф.

Если грамотно тренироваться в зале, то мышцы будут расти. Если часами играть в КС, то научишься побеждать противников. А если перерабатывать в офисе, то твой мозг будет меняться, адаптируясь под нагрузку. Причем изменения буквально видны в структурах мозга.

Это история предпринимательского эксперимента из 2016 года: где я пытался выделиться на перегретом рынке телефонии, создав плагин для экономии времени при звонках. Но, как оказалось, экономия 12 секунд — не всегда весомый аргумент в мире корпоративных продаж. В статье нет технических деталей реализации, только отражение продажно-маркетинговых попыток. Некоторые символы и буквы в текущем контексте могут читаться как-то иначе, но тогда это были просто буквы.

Так получилось что большую часть своей экспертной технической деятельности я был связан с телефонией, корпоративными системами коммуникации, последнее звучит моднее. И вендоре по этой теме работал и потом когда сделал свою компанию тоже. Но, мне на давало покоя что я продаю (на самом деле перепродаю) чужие продукты. Маржинально, местами эксклюзивно, но не уникально. Короче, хотел что-то такое, что отлично от конкурентов. 

Тут важно сделать отсыл к структуре рынка телефонии. Проект состоит из двух частей. Первое - сама АТС, телефонная станция, та коробка, что творит магию и передает звук формата HD по проводам. Второе - телефонные аппараты. Последних в бюджете проекта могло быть до 80% и по сути заработок был на них. Работы, какие-то доработки-интеграции, вообще погрешность в плане денег. Но! Работы и какой-то эксклюзивный «допил» выгодно мог выделить проект на фоне конкурентов, потому что АТС и телефоны продавали все одинаковые. И в итоге, все сваливалось в цену. Все кто перепродает сталкивается с этими рассылками на 100500 адресов - Пришлите КП, или обоснуйте почему вы не шлете. Кстати, от этой схемы, вроде как, и закупщики сами страдают. Ну бог с ними. 

Нейросети («ИИ») больше не инструмент будущего — это активный участник рынка труда. От HR-отделов до бухгалтерии, от школ до юридических фирм — машины не только помогают, а кое-где заменяют. Эта статья — о том, какие профессии исчезают, а какие трансформируются, и что делать, чтобы остаться на плаву в эпоху алгоритмов.

Привет! Меня зовут Алексей Стратонов, я экс-техлид Авито Недвижимости. До Авито я 8 лет проработал в аутсорсе: управлял четырьмя отделами, успел нанять и уволить многих, в том числе руководителей. В аутсорсе есть специфика — зарплаты тут ниже, а задачи те же, что и в продукте. Поэтому тимлид должен уметь собирать команды под определенный проект и качественно собеседовать.

В статье рассказываю, какие моменты напрягают меня в кандидатах, а какие, наоборот, подкупают. Этот текст будет полезно прочитать молодым лидам, которые только начинают нанимать самостоятельно. Если вы уже уверенно чувствуете себя на собеседованиях, то все, что я упомянул, покажется вам знакомым. Но проверить свои знания не помешает :-)