Всю неделю я готовил фактуру и контексты для видео. Мы с Пашей, призером телеграм конкурсов и крутым разрабом, собрали плотную лекцию с кодом и замерами перфоманса:
Это первый доклад Паши, сейчас он делает сложный клон телеги и прям из печи принес пирожки.
Please open Telegram to view this post
VIEW IN TELEGRAM
Так, мы определились с форматом первой сходки. Это будут митапы с нетворкингом и играми. Камерный тимбилдинг.
Теперь уже нужна максимальная вовлеченность тех, кто реально хочет поучаствовать. Пройдите опрос для примерного понимания списка гостей, времени и моментов организации.
Всем заинтересованным спасибо!🙏🏻
https://forms.gle/UiciPysajTNBpfTy8
Теперь уже нужна максимальная вовлеченность тех, кто реально хочет поучаствовать. Пройдите опрос для примерного понимания списка гостей, времени и моментов организации.
Всем заинтересованным спасибо!🙏🏻
https://forms.gle/UiciPysajTNBpfTy8
Google Docs
Митап в Москве
С форматом мы определились - это будут технические митапы с нетворкингом и неформальной обстановкой.
Теперь нужно определиться с потенциальным количеством участников. Если ты собираешься участвовать, то ответь на вопросы
Теперь нужно определиться с потенциальным количеством участников. Если ты собираешься участвовать, то ответь на вопросы
Прелести Москвы это понять с переездом насколько же прикольное приложение золотого яблока. Разрабы и дизайнеры - молодцы
Туториал от Antropics по промт-инженерингу
ИИ нас не заменит. Заменят люди, кто эффективно пользуется ИИ. Поэтому эту тему надо развивать и не стоять на месте.
За год вся эта тема из крепкого скептицизма до слепой истерии дошла до +- здоровую позицию. Мертвые сгенерированные текста бросаются сразу, но и сделанные в ручную контенты в умелых руках становятся богаче и продуманнее.
Вот и создатели Claude.ai поделились туториалми как сделать свою работу лучше
ИИ нас не заменит. Заменят люди, кто эффективно пользуется ИИ. Поэтому эту тему надо развивать и не стоять на месте.
За год вся эта тема из крепкого скептицизма до слепой истерии дошла до +- здоровую позицию. Мертвые сгенерированные текста бросаются сразу, но и сделанные в ручную контенты в умелых руках становятся богаче и продуманнее.
Вот и создатели Claude.ai поделились туториалми как сделать свою работу лучше
GitHub
GitHub - anthropics/prompt-eng-interactive-tutorial: Anthropic's Interactive Prompt Engineering Tutorial
Anthropic's Interactive Prompt Engineering Tutorial - anthropics/prompt-eng-interactive-tutorial
Forwarded from Банки, деньги, два офшора
Путин обязал Apple предустанавливать RuStore на все новые iPhone и планшеты в России с 1 сентября. @bankrollo
Об алгоритмах на собеседовании
У меня, на первый взгляд, противоречивое мнение про алгоритмы. С одной стороны, я долго их решал и даже учавствовал в соревнованиях и шел "365 дней Богу Алгоритмов". С другой, я все также не умею проходить алгоритмические собеседования 😄
Опыт долгих тренировок определенно точно помог мне в кодинге, мышлении, какой-то базе. Но вот секции с алгосами для меня отдельный вид спорта 😂 Устно решать вслух != комфортненько молча за столом.
Но эти секции точно не стоит бояться. Мне нравится, как о них расписал наш руководитель отдела разработки Яндекс Еды Дима Александров @vit_ded
У нас во фронтендах часто не понимают зачем алгосы, а автор не редко сравнивает разные точки зрения и может найти сложные алгоритмы даже в нашей практике!
У меня, на первый взгляд, противоречивое мнение про алгоритмы. С одной стороны, я долго их решал и даже учавствовал в соревнованиях и шел "365 дней Богу Алгоритмов". С другой, я все также не умею проходить алгоритмические собеседования 😄
Опыт долгих тренировок определенно точно помог мне в кодинге, мышлении, какой-то базе. Но вот секции с алгосами для меня отдельный вид спорта 😂 Устно решать вслух != комфортненько молча за столом.
Но эти секции точно не стоит бояться. Мне нравится, как о них расписал наш руководитель отдела разработки Яндекс Еды Дима Александров @vit_ded
У нас во фронтендах часто не понимают зачем алгосы, а автор не редко сравнивает разные точки зрения и может найти сложные алгоритмы даже в нашей практике!
Telegram
Ворчливый IT-дед
28. Об алгоритмах на собеседованиях.
Многие не хотят проходить собеседования в Яндекс, потому что там 4 секции гоняют по алгоритмам, которые в работе совершенно не нужны. Миф это или реальность? Давайте разбираться.
Во-первых, уметь в алгоритмы правда…
Многие не хотят проходить собеседования в Яндекс, потому что там 4 секции гоняют по алгоритмам, которые в работе совершенно не нужны. Миф это или реальность? Давайте разбираться.
Во-первых, уметь в алгоритмы правда…
Действительно ли вы хорошо знаете SwiftUI?
Нашел супер крутую статью, о которой преступно умалчивают другие авторы.
В этой статье автор задает вопрос "А действительно ли вы хорошо знаете SwiftUI?".
Взяв самую популярную демо-задачу с Counter'ом он начинает подсвечивать самые частые заблуждения: начиная от использования незадокументированного _printChanges() заканчивая причинами зависаний экрана.
Ну и как бы очевидно другие могут сказать, что эту проблему можно решить разными манипуляциями LazyVStack. Но чтобы понять почему же у нас вообще возникает эта проблема, то нужно погрузиться глубже.
Автор круто подчеркивает, что SwiftUI лишь обманчив простотой. Чтобы сделать хороший по перфомансу лайаут нужно приложить много ресурсов и изучить много вещей, которые плохо задокументированы и требуют собрать мозаику знаний. Ну и главное, чтобы это все не сломал Apple со след версией iOS 🙂
Многие советы вам известные, но дают чуть контекста на проблему. Например, тема про POD vs Non-POD чуть лучше расскрывается.
P.S. Говорят, что одна из ключевых черт зрелого инженера — умение выбирать правильные инструменты. Ну и одно из моих любимых правил: Если слишком сложно, то возможно не ты тупой, а плохой дизайн и проектирование инструмента для этих задач. Попробуй взять или придумать другой инструмент.
Нашел супер крутую статью, о которой преступно умалчивают другие авторы.
В этой статье автор задает вопрос "А действительно ли вы хорошо знаете SwiftUI?".
Взяв самую популярную демо-задачу с Counter'ом он начинает подсвечивать самые частые заблуждения: начиная от использования незадокументированного _printChanges() заканчивая причинами зависаний экрана.
As you can see by adding .debugBackground() to every Text cell we can observe updating each cell whenever we click on theCounter +1 button. And as you remember we have 100_000 values🤯. That causes lagging! To be more precise — lagging is caused by the List cell creation behavior. Whenever List is created, it has to create all its inside items first because it needs to know how many items are on the screen. By clicking on the button we change the view state, and SwiftUI detects the state change and starts rebuilding the view, and because of the large number of values — this view rebuilds long.
Ну и как бы очевидно другие могут сказать, что эту проблему можно решить разными манипуляциями LazyVStack. Но чтобы понять почему же у нас вообще возникает эта проблема, то нужно погрузиться глубже.
Автор круто подчеркивает, что SwiftUI лишь обманчив простотой. Чтобы сделать хороший по перфомансу лайаут нужно приложить много ресурсов и изучить много вещей, которые плохо задокументированы и требуют собрать мозаику знаний. Ну и главное, чтобы это все не сломал Apple со след версией iOS 🙂
Многие советы вам известные, но дают чуть контекста на проблему. Например, тема про POD vs Non-POD чуть лучше расскрывается.
P.S. Говорят, что одна из ключевых черт зрелого инженера — умение выбирать правильные инструменты. Ну и одно из моих любимых правил: Если слишком сложно, то возможно не ты тупой, а плохой дизайн и проектирование инструмента для этих задач. Попробуй взять или придумать другой инструмент.
Medium
Mastering SwiftUI: Are You Really as Good as You Think?
How deep do you think you know what SwiftUI is and how it works? Have you ever wondered why…
Где бы вы использовали UIKit vs SwiftUI?
Anonymous Poll
17%
Пишу все на UIKit, не вижу пользы от SwiftUI
15%
Пишу все на SwiftUI, не вижу пользы от UIKit
34%
Пишу обычные коллекции на SwiftUI, а сложные на UIKit
2%
Пишу обычные коллекции на UIKit, а сложные на SwiftUI
22%
Писал только на UIKit, не знаю SwiftUI
5%
Писал только на SwiftUI, не знаю UIKit
16%
Другое
Swift Concurrency: что делает компилятор?
Я не считаю, что обучение по чужим статьям и твиторам — эффективно. Чаще это инфошум. Поэтому продолжаю структурировать и делым понятным то, что разбросано по кускам. Мы уже немного познакомились с Swift Concurrency по первоисточникам. Выяснили какие proposals почитать и какие wwdc посмотреть.
Теперь перейдем к кратким формулировкам и структурированию мозаик. Все абстракции и примерные мыслительные модели бесполезны, если мы не поймем как работает код.
Давайте по порядку. В теории, можно разделить все на такие ключевые слова:
- Компилятор ->
- State Machine ->
- suspension points ->
- Continuation ->
- Executor ->
- Co-operative thread pool
🟣 Компилятор и State Machine. Каждый раз, когда компилятор видит await, то он режет функцию на структуру с полем resumePoint. Разбивает код на блоки и вставляет переходы между ними.
🟣 Suspension points. Каждое await — это место приостановки. В интернете нет явной инфы, но общая формулировка такая: Функция приостанавливается и текущий стэк с переменными и позицией сохраняются в кучу. Создаётся continuation.
🟣 Continuation. Это объект, который хранит что делать дальше, после await. Он хранит в каком месте приостановилось выполнение, какие переменные были в контексте, что делать, когда результат будет готов.
🟣 Executor. Это условный планировщик, который решает, на каком потоке и когда выполнять async-код. Если continuation — это инструкция, то Executor — исполнитель. Сontinuation возобновляется и передаётся в executor, который решает где и когда продолжить выполнение.
🟣 Co-operative thread pool. Если Executor — это манагер задач, то Co-operative thread pool — это рабочие потоки, на которых Executor исполняет эти задачи. Это общий пул потоков, управляемый Swift Runtime. Потоки не создаются на каждую задачу, вместо этого задачи добровольно уступают выполнение, когда достигают await. Потоки переключаются на другие задачи, пока первая ждёт. Executor получает задачу, ставит ее в очередь и запускает на одном из потоков пулла.
Полезные ссылки:
- Apple Docs
- 0392-custom-actor-executors
- Swift concurrency: Behind the scenes
1/5
Я не считаю, что обучение по чужим статьям и твиторам — эффективно. Чаще это инфошум. Поэтому продолжаю структурировать и делым понятным то, что разбросано по кускам. Мы уже немного познакомились с Swift Concurrency по первоисточникам. Выяснили какие proposals почитать и какие wwdc посмотреть.
Теперь перейдем к кратким формулировкам и структурированию мозаик. Все абстракции и примерные мыслительные модели бесполезны, если мы не поймем как работает код.
Давайте по порядку. В теории, можно разделить все на такие ключевые слова:
- Компилятор ->
- State Machine ->
- suspension points ->
- Continuation ->
- Executor ->
- Co-operative thread pool
Swift implements asynchronous functions by transforming them into state machines. Each call to an asynchronous function and each await is a suspension point, where the function can suspend execution
“Continuations are the fundamental building block for suspending and resuming execution in Swift’s concurrency model.”
“The continuation resumes execution via an executor, which may be the same as the original or different, depending on actor context.”
Полезные ссылки:
- Apple Docs
- 0392-custom-actor-executors
- Swift concurrency: Behind the scenes
1/5
Please open Telegram to view this post
VIEW IN TELEGRAM
Swift Concurrency: Cooperative thread pool
Если затрагивать SC, то нельзя не остановиться отдельно на этой теме.
Для чего это придумали? GCD и DispatchQueue.global().async мог создавать на каждую задачу отдельный поток. Это приводит ко многим пролемам оптимизации, но главная — это thread explosion. Это когда создается слишком много потоков одновременно и врызваетсяжопа ОС.
Cooperative Thread Pool — это ключевая часть архитектуры Swift Concurrency. Если простыми словами, то это пул с потоками, которые делят CPU по договорённости. Swift Concurrency использует ограниченный пул потоков — примерно от 4 до 8, в зависимости от устройства и от кол-ва ядер в устройстве. Они уступают управление когда задача "приостанавливается" (await и Suspension points).
Swift runtime использует global concurrent executor. Этот executor основан на libdispatch (GCD), но с отдельной очередью с флагом COOPERATIVE. Это concurrent dispatch queue с названием com.apple.root.default-qos.cooperative. Даже если ты создашь тысячу Task { ... }, они не запустятся параллельно. Они будут ставиться в очередь и по очереди исполняться на тех же 8 потоках.
Чуть позже разберем пару НО и как Swift 6 помогает их избежать.
Полезные ссылки:
- How is the Cooperative Thread Pool integrated in Swift?
- Swift concurrency: Behind the scenes
- How does cooperative thread pool work?
- Limit Swift Concurrency's cooperative pool
2/5
Если затрагивать SC, то нельзя не остановиться отдельно на этой теме.
Для чего это придумали? GCD и DispatchQueue.global().async мог создавать на каждую задачу отдельный поток. Это приводит ко многим пролемам оптимизации, но главная — это thread explosion. Это когда создается слишком много потоков одновременно и врызвается
for _ in 0..<10_000 {
DispatchQueue.global().async {
// что-то делает
}
}
Cooperative Thread Pool — это ключевая часть архитектуры Swift Concurrency. Если простыми словами, то это пул с потоками, которые делят CPU по договорённости. Swift Concurrency использует ограниченный пул потоков — примерно от 4 до 8, в зависимости от устройства и от кол-ва ядер в устройстве. Они уступают управление когда задача "приостанавливается" (await и Suspension points).
Swift runtime использует global concurrent executor. Этот executor основан на libdispatch (GCD), но с отдельной очередью с флагом COOPERATIVE. Это concurrent dispatch queue с названием com.apple.root.default-qos.cooperative. Даже если ты создашь тысячу Task { ... }, они не запустятся параллельно. Они будут ставиться в очередь и по очереди исполняться на тех же 8 потоках.
Чуть позже разберем пару НО и как Swift 6 помогает их избежать.
Полезные ссылки:
- How is the Cooperative Thread Pool integrated in Swift?
- Swift concurrency: Behind the scenes
- How does cooperative thread pool work?
- Limit Swift Concurrency's cooperative pool
2/5
GitHub
swift/stdlib/public/Concurrency/GlobalExecutor.cpp at main · swiftlang/swift
The Swift Programming Language. Contribute to swiftlang/swift development by creating an account on GitHub.
Эстетика сырого текста в эпоху AI
Поговорим о важном культурном сдвиге. Я заметил, что в эпоху, когда ИИ умеет делать красиво, правильно и гладко это тупо перестаёт быть ценностью. Люди начинают искать неидеальность, трушность, эмоцию.
Очередной пересказ статьи, факт из доки, спор про интерпретации — перестали быть интересными. Люди начали искать живой опыт. Грубый, без ретуши и спецэффектов. Домашний, знакомый и понятный.
80% контента стало стерильным. Все утомились от «слишком правильного», которое не отличаешь от сотен других. Сырые же текста и контент стали более живыми.
Даже с играми и фильмами. Мне стали нравятся твердые четверки, кто не идеален. The Alters, expedition 33, tainted grail. Эти игры имеют уйму минусов, багов, но в них есть много плюсов, которые перевешивают. Они пахнут потом и любовью, а не пугающе белыми стенами больниц.
Я стал любить простоту. Ходить в самые обычные места. Есть самую обычную еду. Пить просто воду.
Мы стали будто жить по правилу «слишком идеально, чтобы быть настоящим».
Возможно, скоро неотредактированный текст станет новым жанром. Как raw photo в инсте или живой звук в музыке.
Люди захотят читать не идеальные тексты, а тексты с дыханием.
Поговорим о важном культурном сдвиге. Я заметил, что в эпоху, когда ИИ умеет делать красиво, правильно и гладко это тупо перестаёт быть ценностью. Люди начинают искать неидеальность, трушность, эмоцию.
Очередной пересказ статьи, факт из доки, спор про интерпретации — перестали быть интересными. Люди начали искать живой опыт. Грубый, без ретуши и спецэффектов. Домашний, знакомый и понятный.
80% контента стало стерильным. Все утомились от «слишком правильного», которое не отличаешь от сотен других. Сырые же текста и контент стали более живыми.
Даже с играми и фильмами. Мне стали нравятся твердые четверки, кто не идеален. The Alters, expedition 33, tainted grail. Эти игры имеют уйму минусов, багов, но в них есть много плюсов, которые перевешивают. Они пахнут потом и любовью, а не пугающе белыми стенами больниц.
Я стал любить простоту. Ходить в самые обычные места. Есть самую обычную еду. Пить просто воду.
Мы стали будто жить по правилу «слишком идеально, чтобы быть настоящим».
Возможно, скоро неотредактированный текст станет новым жанром. Как raw photo в инсте или живой звук в музыке.
Люди захотят читать не идеальные тексты, а тексты с дыханием.
Систем дизайн в деле
Есть огромное минное поле заблуждений по систем дизайну. От "это про нарисовать схему из интернета" до "это про знание паттернов проектирование и архитектур". От "бэкенд систем дизайн отличается от мобильного" до "весь систем дизайн можно зазубрить".
Грамотное проектирование — это впервую очередь диалог. Он не должен быть по шаблону и идет оценка условий. Их нужно менять. Как с ремонтом. Вот вроде решил поменять пол и стены, а вышло тысяча нюансов и мелочей.
У всех компаний свой процесс сисдиза, так он еще и отличается от интервьюера, его опыта, компетентности и задач. Ну невозможно только по статьям и пересказам учесть и сформулировать все нюансы. Даже недавно в чате мы обсуждали, что зацикленность на схеме и спам вопросами — это ред флаг для кандидата. Важна их уместность и точность. Иногда одним точным вопросом можно пройти все собеседование.
Нашел полезное видео, которое пусть и для бэкенда, но очень крутое.
Есть огромное минное поле заблуждений по систем дизайну. От "это про нарисовать схему из интернета" до "это про знание паттернов проектирование и архитектур". От "бэкенд систем дизайн отличается от мобильного" до "весь систем дизайн можно зазубрить".
Грамотное проектирование — это впервую очередь диалог. Он не должен быть по шаблону и идет оценка условий. Их нужно менять. Как с ремонтом. Вот вроде решил поменять пол и стены, а вышло тысяча нюансов и мелочей.
У всех компаний свой процесс сисдиза, так он еще и отличается от интервьюера, его опыта, компетентности и задач. Ну невозможно только по статьям и пересказам учесть и сформулировать все нюансы. Даже недавно в чате мы обсуждали, что зацикленность на схеме и спам вопросами — это ред флаг для кандидата. Важна их уместность и точность. Иногда одним точным вопросом можно пройти все собеседование.
Нашел полезное видео, которое пусть и для бэкенда, но очень крутое.
YouTube
Системный дизайн в деле. Выпуск 1.
Друзья, запускаю новую рубрику на канале - "Системный дизайн в деле"
В первом выпуске разбираем кейс эволюции платежной системы FakePaymentSystemFlow: от монолита до микросервисов.
Разберем:
— Почему монолит начал тормозить развитие
— Какие проблемы вылезли…
В первом выпуске разбираем кейс эволюции платежной системы FakePaymentSystemFlow: от монолита до микросервисов.
Разберем:
— Почему монолит начал тормозить развитие
— Какие проблемы вылезли…
Туториал по Container
Пока одни блогеры утверждают, что контейниризация — это не важно для иос-разрабов... Аудитория же с критическим и аналитическим мышлением уже делает туториалы и использует это в своих приложениях.
Мы уже разбирали в чем разница software developer vs software engineer. А также подробно проходили по виртуализации.
Инженер — это не только про покраску кнопок. Один ограничевается только в своей платформе, а другой использует любые инструменты за ее границами. Автор статьи рассказывает как Containter помогает настроить свое окружение. Статья чуть упрощенная, поэтому я добавлю от себя.
Когда это поможет:
- Ускоряет и упрощает CI/CD-процессы для ios‑разрабов. например, сразу fastlane, swiflint и тп с другими версиями
- изолировать версии в разных окружениях
- тестировать пуши, авторизацию, базы данных с быстрым запуском нужных сервисов.
- настраивать ручные и автотесты за счет мок-сервисов
- проще подготавливать окружение для новичков
- если баги воспроизводятся только на конкретной версии окружения, то ты можешь легко ее собрать
- запуск новых либ или сдк в "чистом" окружении
Полезно выходить за границы мобильных приложений, особенно когда это требует изменчивый рынок.
Пока одни блогеры утверждают, что контейниризация — это не важно для иос-разрабов... Аудитория же с критическим и аналитическим мышлением уже делает туториалы и использует это в своих приложениях.
Мы уже разбирали в чем разница software developer vs software engineer. А также подробно проходили по виртуализации.
Инженер — это не только про покраску кнопок. Один ограничевается только в своей платформе, а другой использует любые инструменты за ее границами. Автор статьи рассказывает как Containter помогает настроить свое окружение. Статья чуть упрощенная, поэтому я добавлю от себя.
Когда это поможет:
- Ускоряет и упрощает CI/CD-процессы для ios‑разрабов. например, сразу fastlane, swiflint и тп с другими версиями
- изолировать версии в разных окружениях
- тестировать пуши, авторизацию, базы данных с быстрым запуском нужных сервисов.
- настраивать ручные и автотесты за счет мок-сервисов
- проще подготавливать окружение для новичков
- если баги воспроизводятся только на конкретной версии окружения, то ты можешь легко ее собрать
- запуск новых либ или сдк в "чистом" окружении
Полезно выходить за границы мобильных приложений, особенно когда это требует изменчивый рынок.
swifttoolkit.dev
The New Container Tool: Docker-free Swift on Linux?
WWDC 2025 brings news also outside Apple platforms
Окей, все посты выше мы говорили о работе SC в общих мазках. Сейчас подойдем к более привычным и простым снарядам. Мы ведь говорили о каких-то компилятарах, ядрах и тп. Но не дошли до самой сути. Так как мой код исполняет на доступной мне абстракции? Зачем были эти прелюдии если мы так и не затронули common сущности и прикладной уровень?
Ну если простыми словами, то у нас есть три ключевых механизма, которые нужно хорошо понимать рядовому работяги:
🎶 Task — это задача, которую нужно выполнить. Я далек от музыки, но допустим это какая-то песня.
🎤 Actor — это объект для работы с задачами. Или же музыкант отдельного инструмента, который играет песню. Например, гитарист.
🧑⚖️ Executor — это механизм, который управляет порядком и исполнением задач. В той же аналогии это дирижер, который управляет, кто и когда играет. В какой момент подключится вокалист, гитарист, басист и тп.
И так: Task — это контейнер для асинхронного кода. Он создаёт фоновую задачу, которая не блокирует основной поток. Actor же это специальный тип изоляции и безопасности, который может гарантировать, что данные не будут меняться из разных задач.
actor Counter {
var value = 0
func increment() {
value += 1
}
}
А вот Executor — это внутренний механизм, который решает где и в каком порядке исполнять таски и акторы. Каждый actor имеет свой serial executor, то есть он выполняет задачи по очереди, одну за одной. Допустим у тебя 3 таски и каждая хочет что-то сделать внутри одного актора. Executor ставит их в очередь и выполняет по одной, даже если все они вызваны одновременно.
Вроде все понятно. Но так ли на самом деле просто и идеально? Не совсем. В след постах поговорим про Reentrancy, hops'ы и перфоманс, nonisolated и другие приколы, которые могут вам сломать исполнение
3/5
Please open Telegram to view this post
VIEW IN TELEGRAM
Блин, за ленивый пост извиняюсь. Набросал пост про «концентрированный опыт» и отдал его чатгпт, решил узнать че скажет. В целом получилось интересно и по содержанию почти так, как я хотел донести, но по подаче конечно супер пресно. Поделюсь ответом с вами, а нормальный пост как-нибудь позже напишу:
——————-
——————-
«Концентрированность опыта важнее количества лет и суммы в оффере»
или
«Где вырастает настоящий сеньор? В деньгах или в деле?»
⸻
💡 Ключевые идеи, которые можно раскрыть:
1. Концентрированность опыта vs Количество лет
• Пример: у двух людей по 5 лет опыта. Один — писал UI-фичи и фиксил баги, другой — запускал 3 проекта с нуля, внедрял CI/CD, строил архитектуру.
• 👉 Первый “набрал время”, второй — сжал опыт в концентрат.
• Формулировка: “Опыт – это не часы, проведённые в коде. Это задачи, которые требовали от тебя расти.”
⸻
2. Цена опыта и окупаемость
• Вставь понятие «опыт как инвестиция»:
• Проект без вызовов = “депозит под 2%” (низкий рост).
• Проект с болью, сложностями и ростом = “венчур” — сначала тяжело, потом x3.
Метафора: «Ты не на зарплату работаешь, а на апгрейд себя.»
⸻
3. Короткие фичи vs Большие системы
• Проекты на 1 спринт не дадут тебе знания работы с техническим долгом, масштабированием, поддержкой, интеграциями.
• Проекты на кварталы формируют скиллы, которые не прочитать в туториале.
👉 Задай вопрос читателю: «Вы когда-нибудь доживали до последствий собственных решений через 6–12 месяцев?»
⸻
4. Что такое “бесперспективный оффер”
• Деньги — не всегда сигнал “ты хорош”.
• Иногда это компенсация за рутину, токсичность, отсутствие роста, или необходимость “заткнуть дыру”.
• Идея: “Не каждая высокая зарплата — это признание. Иногда — это капкан.”
⸻
5. Продажа себя дороже
• Опиши идею: если сейчас ты работаешь на то, чтобы через год стоить дороже — ты на правильном пути.
• Пример: ты изучаешь GraphQL, учишь DevOps-практики, внедряешь архитектурные подходы — всё это капитал.
⸻
6. Роль ментальности и амбиций
• Некоторые “работают в IT”, а другие — “строят карьеру в инженерии”.
• Покажи разницу: первые просто кодят задачи, вторые — растут стратегически.
⸻
🧩 Завершающая мысль
Можно закончить вот так:
“Концентрированность опыта — это когда ты идёшь не по количеству строк кода, а по качеству вызовов, которые ты принял. Не каждый год делает тебя сильнее. Но каждый проект может — если ты выбрал его осознанно.”
This media is not supported in your browser
VIEW IN TELEGRAM
Кстати, завтра будет репортаж корпоратива Яндекса из БАНИ
Неоспоримая база от любимого автора
Наш любимый блогер, а также автор лучшей книги 2024 года для инженеров, дал инфу о базе базовой.
1. Чем больше кода, тем больше багов. Чем больше приложение, тем сложнее делать его качественно.
2. Код - это для людей. Писать код сложнее там, где его читают. Чем больше разрабов в проекте, тем важнее его читабельность и понятность.
3. Архитектура - это про удобство. Чем сложнее, тем хуже.
Даже во времена AI эти правила не меняются
Наш любимый блогер, а также автор лучшей книги 2024 года для инженеров, дал инфу о базе базовой.
1. Чем больше кода, тем больше багов. Чем больше приложение, тем сложнее делать его качественно.
2. Код - это для людей. Писать код сложнее там, где его читают. Чем больше разрабов в проекте, тем важнее его читабельность и понятность.
3. Архитектура - это про удобство. Чем сложнее, тем хуже.
Даже во времена AI эти правила не меняются
X (formerly Twitter)
Gergely Orosz (@GergelyOrosz) on X
"Fundamental" truths about software:
- Code is liability
- The more code you have, the more bugs you tend to have
- The more complex a system, the more important architecture becomes
- Writing maintainable code is a lot more effort than just getting it…
- Code is liability
- The more code you have, the more bugs you tend to have
- The more complex a system, the more important architecture becomes
- Writing maintainable code is a lot more effort than just getting it…