В статье есть расходы - это 3000 за жилье и 1000 на еду. Вряд ли это все в кредит каждый месяц. Итого минимум 4000 на руки, что дает порядка 80-100к в год до налогов. Это средняя зп. Ну то есть как в Москве зарабатывать айтишнику 100-150 тр/мес. Это не копейки. Жить можно, но без шика.
Насчет луковой, в более понятном виде, если ее разложить по вертикали:
1. Фундамент внизу — это платформа (Java/.NET/и т.п.)
2. [опционально] На фундаменте может стоять какой-то свой фреймворк-обертка, помогающая писать меньше кода
3. Далее стоит Domain (который нарисован в центре диаграммы луковой архитектуры). Эта сборка зависит только от фундамента. Так как базовые типы (int, string) определены именно в фундаменте. Содержит какие-то классы-реализации + интерфейсы, которые будут реализованы на слоях выше (дальше от центра)
4. Далее идут Domain/App Services, содержит классы-реализации для интерфейсов из Domain + другие интерфейсы, которые будут реализованы на слоях выше (дальше от центра), например IDb, ICache, IExternalApi и так далее.
5. Далее по аналогии для Controllers/Tests/UI
6. Еще выше (дальше от центра) — это всякие обертки над инфраструктурой (базами данных, внешними системами и так далее). Тут у нас например конкретная ORM.
7. И на самом верху уже конкретные инфраструктурные вещи (конкретная БД, MS SQL или Oracle)
Каждый слой для работы использует интерфейс, реализация которого лежит на более высоком уровне и на самом деле неважно где именно. Controller на уровне 5 будет использовать IDb, который определен на уровне 4, но реализация IDb будет на уровне 6. Все это относительно легко собирается IoC контейнером.
Проблемы тут следующие (касается платформы .NET):
1. Использование ORM (она у нас на 6 уровне) чем-нибудь да протекает вплоть до Domain (уровень 3). У EF например протекает DbSet (он порой нужен в IDb для обобщенных задач), маппинг классов domain на таблицы (хотя их можно переместить в сам контекст, просто будет god-метод) и предполагаю некоторые специфичные атрибуты (хотя пока что, все, которые я использовал, лежали в System.ComponentModel.DataAnnotations, т.е. в фундаменте). На 100% защититься интерфейсами мне пока что не удалось.
2. Некоторые проблемы с Identity. Сущности наследники от AppUser, AppRole находятся в Domain. Но они решаемы — можно выделить в отдельный домен или на уровне 6 сделать еще один слой сущностей для ORM и маппингом между ними и сущностями из Domain.
3. Меня так же смущают модели для UI и API и их маппинг с классами из Domain. Там в любом случае требуется зависимость сборки Models от Domain. Эта сборка у меня получилась между уровнем 3 и 4. Опять же проблема решаемая — перекладываем маппинги на более высокий уровень (4-ый или 5-ый), но тем самым мы порой будем тащить весь 4-ый уровень везде, даже туда, где требуются только модели.
Да, лично я этим управляю — когда время позволяет, говорю, чтоб копали сами (тогда им в плюс обучение идет), спрашиваю как дела через 1-2-3 дня. Иначе — либо говорю копаешь 1-2 часа потом идешь ко мне, либо сразу даю наброски или даже решение на 80-90% и обозначаю, что надо быстро, пускай даже с костылями.
С одной стороны — да маразм бывает. Лично я таким не страдал. Я либо давил — делаем так (рассказывал как) и никак иначе (тоже своего рода маразм), либо обсуждаем и приходим к некому компромиссу. Но с возрастом и опытом получилось так, что оппонент и сам уже начинает понимать мой ход мыслей, когда я начинаю раскладывать все по пунктам и проблемам, которые за этим последуют.
С другой стороны — меня тоже били по рукам в свое время. Но разве это не повод стать лучше?
Дело не в знании технологий, а в том что 30 летний «ребенок» бежит к мамке по любому поводу и без. Вы наверное просто не сталкивались именно с тем, о чем толкует автор.
Выглядит это примерно так:
Скидывает кусок кода - почему у меня тут null ref эксепшн? Ну зайди в отладку посмотри, сам же код писал, мне то в любом случае придется с твоим кодом разбираться
Скидывает кусок кода с вызовом стороннего апи - почему не работает? Ну доку почитай, мне же ведь тоже это придется сделать, этих интеграций миллионы разных
И так каждый час. Причем по хронологии событий - похоже что сам он вообще не пытается докопаться до истины. Или пасует после первого промаха. Он не может отладить и доку почитать, я не могу работать все время отвлекают. Из 10 таких вопросов найдется один реально нормальный. Сам же при этом сениор, проекты вел, командой рулил. Вот как так?
35 летний джун вошедший в айти - себе такого не позволял. Сидел копал, когда совсем уже закапывался, шел ко мне.
Местами сумбурно, но основная мысль понятна. И я тоже с таким столкнулся недавно. До этого я работал с людьми либо старше, либо ровесниками плюс минус. А вот довелось поработать с человеком лет на 5 младше - на каждый чих бежит ко мне с вопросами. Сам не делает и мое время еще тратит, хотя был сениором на своих предыдущих проектах. Но я думал, что это конкретный человек такой, а видимо нет...
Расскажу немного про свой опыт. Но прежде, следует уточнить, что в каждой компании роли тим-лида/тех-лида определяют по своему. И часто бывает — что это человек, который должен заткнуть все оставшиеся дыры.
В целом, на мой взгляд, тим-лид — это больше в сторону развития команды. И сейчас, наконец-то, по прошествии многих лет, стало появляется понимание этого. В последнее время я стал замечать, что в вакансиях тим-лидов все чаще встречаются требования, связанные именно с командной работой, решением межличностных конфликтов, развитием компетенций команды, планирование обучения и так далее и все меньше технических знаний.
А тех-лид — это больше в сторону технического развития. Мне в свое время предложили стать тех-лидом. Но как впрочем и всегда, это была мешанина обязанностей. Хотя именно развитием и обучением команды я не занимался. Конфликты не решал (хотя вроде их и не было).
То, что делал я — я бы назвал "ведущий программист". Я вел проект с технической точки зрения. С одной стороны у меня был Product Manager/Owner и BA, которые олицетворяли стейкхолдеров. Так как это был интегратор в банковской сфере — там было довольно много бумаг, в том числе и технические задания. Я же олицетворял весь технический проект целиком. Мне на входе "что надо сделать", а я думал "как это сделать" и делал вместе с командой. Выбирал технологии, продумывал архитектуру, оформлял и распределял задачи в жире, сам назначал созвоны для обсуждения рабочих вопросов с участниками команды (да это все еще было удаленно), проводил код-ревью и сам писал код и довольно много.
По распределению времени — процентов 60% на архитектуру и написание кода, 10-20% на ревью кода, остальное на остальное.
Собственно чего от меня ожидали:
Мне опишут, что надо сделать, а я найду решение и сделаю.
Оценка и корректировка времени.
В жире был виден прогресс по проекту, но ко мне могли прийти и спросить технических подробностей и текущих проблем, так как PM бывший технарь. Размер проекта позволял мне держать весь его в голове. Я сам погружался немного в каждую задачу, которую выдавал участникам команды, продумывая, что и как там надо сделать и как это состыковать с остальным проектом. Поэтому я мог рассказать обо всем.
Участие в принятии решений — в каком объеме надо сделать очередной этап проекта, чтобы и успеть в обещанный клиенту срок и показать действительно ценный функционал. Так однажды, мы не укладываясь в календарный срок, приняли решение о переработке, чтобы клиенту выдать полностью готовый один из воркфлоу. В противном случае, этот этап не принес бы никакого бизнес-валью конечному клиенту. Был бы бесполезен.
Распределения задач в команде, с учетом опыта (джунам попроще, мидлам посложнее, сеньорам с большей долей неопределенности и исследовательской работы).
Мне никто этого не говорил, но я сам наделил себя обязанностью отвечать за качество проекта. Отсюда следовало еще два пункта:
6.1. Ревью кода. Я успевал просмотреть код за каждым участником
6.2. Ближе к концу я с BA прошлись по коду и тех заданию. Сопоставили и каждый себе пометил то, что надо еще доработать. В итоге синхронизировали документацию и код. И я стал уверен в том, что проект делает именно то, что требовалось
Чего я не делал:
Не общался напрямую с клиентом
Не обучал команду (но как-то старался давать задачи по силам)
Не решал конфликты (вроде их не было, но сейчас уже понимаю — мне повезло с командой, все работали плотно и слаженно).
Я столкнулся с аналогичной проблемой во фронтенде, так как сам был (и остаюсь больше) бэкендером. Но, из-за того, что я мог сам выбирать технологии и UI был довольно простым — остановился на том, что я довольно хорошо знал (в те времена это был ASP.NET, даже еще не MVC) + взял подходящую демку из набора готовых компонентов. Сейчас, на крупных проектах, я бы ставил перед руководством вопрос разделения фронт-енда и бэк-енда и у каждого свой "ведущий программист". Фронт-енд довольно обширная и крайне зыбкая тема.
Сейчас уже, я замечаю, что замкнул на себе довольно много всего. Это было ручное управление. Но тогда мне нравилось так работать. Команда была продолжением моих рук. Я успевал делать проект (на это конечно влияет размер команды и проекта). Но мои те подходы нельзя было масштабировать. И сейчас бы я думал в сторону настройки процессов и показателей. Например чтобы ревью-кода проводилось между участниками команды, а не лично мной. И так далее.
А можно более подробно про минусы в долгосрочной перспективе? Я представил, что несколько лет спустя будет куча роботов между основными системами. Это начнет походить на сервисы/микросервисы. И может даже начнет конфликтовать в каких-то моментах. С этой точки зрения — архитектор из первой истории предлагал довольно рациональные вещи.
Вообще по-разному. Но лично я имел ввиду при полной равномерной загрузке. Я с 2015 года как раз на такой удаленке. Сначала на upwork, а потом напрямую. И те, кто работал со мной — аналогично 6-8 часов в день. 35-40 часов в неделю на протяжении нескольких лет.
Единственное, к чему приведет борьба за равноправие — снижение зп вообще для всех
Глобального снижения не будет, я вообще не уверен что будет хоть какое-то. Только если границы закроют и от свифта отключат. Но тогда плохо будет всем.
Программисты просто будут продолжать выходить на зарубежную удаленку и внутренние процессы в РФ заморским компаниям не указ. У них свой планетарный баланс спроса и предложения с учетом индусов.
Собственно многие так и сделали, когда у нас рубль рухнул в 2014. Думаю именно поэтому в стране постепенно возросли зарплаты до 350 тр — это как раз те же 5000$, что были до падения рубля.
Да, да, да, совок и есть совок. Насчет доступа к данным. Однажды (и это лет 10 назад, когда вакансий на удаленке можно было пересчитать на пальцах рук), лично я получал хардварный ключ на флешке с two factor для доступа в отдельный контур банковской системы для работы на проекте удаленно.
Я тоже не согласен, что жизнь дороже. В Москве дороже купить квартиру и больше соблазнов куда деньги потратить.
Съем в мск 40, в городе миллионнике 15-20. Разница в 20 тр.
В отпуск через Москву — это условно +10тыр за билет туда обратно на каждого члена семьи
Еда так же. Одежда так же. Хотя вру, в своем городе я не смог найти нормальную теплую куртку на зиму. В Москве нашел. Т.е. еще и за нормальной одеждой надо в Москву гонять. А это опять +10тыр за билет туда обратно.
Рано или поздно будет найден баланс спроса и предложения. Это уже давно наблюдается на рынке международной удаленки на фрилансерских биржах (с учетом индусов, филиппинцев и так далее). Основная суть — чем восточнее, тем меньше ставка (за исключением Австралии и Японии) в среднем примерно так:
* США/Австралия — >= 50$/час
* Западная Европа — 40$/час
* Восточная Европа (+ Россия и + пожалуй Израиль) — 30$/час
* Ближний Восток (Египет, Афганистан и так далее) — 20$/час
* Дальний Восток (Индия) — до 10-20$/час
* Островные государства (Филиппины, Индонезия и так далее) — 5-10$/час
Но это средние, в каждом случае есть отклонения. Я например работал:
* С египтянином, который начал с 20$, потом 30$, а потом он устроился в Майкрософт.
* С человеком из Австралии — 75$
* Со славянином, проживающим в Израиле 80-100$
* С инудсом (куда уж без них) 30$ в час.
И видел ребят из России 35-45$.
И на самом деле тут три фактора:
1. Да, первый это дороговизна жизни в стране проживания.
2. Второй — местонахождение «компании-нанимателя». Для компаний из США вложения в хорошего программиста из восточной Европы — в целом выгодные вложения. Но для компании из Пакистана — нет.
3. Третий — это знания, опыт и навыки и знание конкретного бизнеса (внутренней кухни самой компании-нанимателя). Подтянув их — компании будут платить больше. Но нужен минимальный уровень этих знаний, навыков и опыта. Грубо говоря, если Вася Иванов умеет тоже самое за 30$, что и Джон Смит за 50$ — возьмут Васю. Но если у Васи английский вообще никакой — то и за 30 не возьмут.
Аналогичный баланс настанет и внутри России, когда удаленщиков станет больше.
Но на этот баланс будет давить потенциальная возможность работать на рынке зарубежной удаленки, где для россиян — это давно устоявшаяся ставка в 30$ в час (или порядка 5000$ в месяц). Это ставка такого хорошего сениора с опытом плюс минус 10 лет или выше + с хорошими софт скилами + английский intermediate. Английский кстати дает больше бонусов. Fluent- это уже 35-40 для россиянина.
Да, уже не средняя. Давно не заглядывал сюда
https://www.bls.gov/oes/current/oes_nat.htm#15-0000 (по стране)
https://www.bls.gov/oes/current/oes_ny.htm#15-0000 (НЙ)
15-1256 Software Developers 114к и 122к в год, было в районе 100 плюс минус.
В статье есть расходы - это 3000 за жилье и 1000 на еду. Вряд ли это все в кредит каждый месяц. Итого минимум 4000 на руки, что дает порядка 80-100к в год до налогов. Это средняя зп. Ну то есть как в Москве зарабатывать айтишнику 100-150 тр/мес. Это не копейки. Жить можно, но без шика.
1. Фундамент внизу — это платформа (Java/.NET/и т.п.)
2. [опционально] На фундаменте может стоять какой-то свой фреймворк-обертка, помогающая писать меньше кода
3. Далее стоит Domain (который нарисован в центре диаграммы луковой архитектуры). Эта сборка зависит только от фундамента. Так как базовые типы (int, string) определены именно в фундаменте. Содержит какие-то классы-реализации + интерфейсы, которые будут реализованы на слоях выше (дальше от центра)
4. Далее идут Domain/App Services, содержит классы-реализации для интерфейсов из Domain + другие интерфейсы, которые будут реализованы на слоях выше (дальше от центра), например IDb, ICache, IExternalApi и так далее.
5. Далее по аналогии для Controllers/Tests/UI
6. Еще выше (дальше от центра) — это всякие обертки над инфраструктурой (базами данных, внешними системами и так далее). Тут у нас например конкретная ORM.
7. И на самом верху уже конкретные инфраструктурные вещи (конкретная БД, MS SQL или Oracle)
Каждый слой для работы использует интерфейс, реализация которого лежит на более высоком уровне и на самом деле неважно где именно. Controller на уровне 5 будет использовать IDb, который определен на уровне 4, но реализация IDb будет на уровне 6. Все это относительно легко собирается IoC контейнером.
Проблемы тут следующие (касается платформы .NET):
1. Использование ORM (она у нас на 6 уровне) чем-нибудь да протекает вплоть до Domain (уровень 3). У EF например протекает DbSet (он порой нужен в IDb для обобщенных задач), маппинг классов domain на таблицы (хотя их можно переместить в сам контекст, просто будет god-метод) и предполагаю некоторые специфичные атрибуты (хотя пока что, все, которые я использовал, лежали в System.ComponentModel.DataAnnotations, т.е. в фундаменте). На 100% защититься интерфейсами мне пока что не удалось.
2. Некоторые проблемы с Identity. Сущности наследники от AppUser, AppRole находятся в Domain. Но они решаемы — можно выделить в отдельный домен или на уровне 6 сделать еще один слой сущностей для ORM и маппингом между ними и сущностями из Domain.
3. Меня так же смущают модели для UI и API и их маппинг с классами из Domain. Там в любом случае требуется зависимость сборки Models от Domain. Эта сборка у меня получилась между уровнем 3 и 4. Опять же проблема решаемая — перекладываем маппинги на более высокий уровень (4-ый или 5-ый), но тем самым мы порой будем тащить весь 4-ый уровень везде, даже туда, где требуются только модели.
С одной стороны — да маразм бывает. Лично я таким не страдал. Я либо давил — делаем так (рассказывал как) и никак иначе (тоже своего рода маразм), либо обсуждаем и приходим к некому компромиссу. Но с возрастом и опытом получилось так, что оппонент и сам уже начинает понимать мой ход мыслей, когда я начинаю раскладывать все по пунктам и проблемам, которые за этим последуют.
С другой стороны — меня тоже били по рукам в свое время. Но разве это не повод стать лучше?
Дело не в знании технологий, а в том что 30 летний «ребенок» бежит к мамке по любому поводу и без. Вы наверное просто не сталкивались именно с тем, о чем толкует автор.
Выглядит это примерно так:
Скидывает кусок кода - почему у меня тут null ref эксепшн? Ну зайди в отладку посмотри, сам же код писал, мне то в любом случае придется с твоим кодом разбираться
Скидывает кусок кода с вызовом стороннего апи - почему не работает? Ну доку почитай, мне же ведь тоже это придется сделать, этих интеграций миллионы разных
И так каждый час. Причем по хронологии событий - похоже что сам он вообще не пытается докопаться до истины. Или пасует после первого промаха. Он не может отладить и доку почитать, я не могу работать все время отвлекают. Из 10 таких вопросов найдется один реально нормальный. Сам же при этом сениор, проекты вел, командой рулил. Вот как так?
35 летний джун вошедший в айти - себе такого не позволял. Сидел копал, когда совсем уже закапывался, шел ко мне.
Местами сумбурно, но основная мысль понятна. И я тоже с таким столкнулся недавно. До этого я работал с людьми либо старше, либо ровесниками плюс минус. А вот довелось поработать с человеком лет на 5 младше - на каждый чих бежит ко мне с вопросами. Сам не делает и мое время еще тратит, хотя был сениором на своих предыдущих проектах. Но я думал, что это конкретный человек такой, а видимо нет...
Раньше делали лучше
Вот, сел сегодня в машину — замените элемент питания. Я менял его в августе 2020, 8 месяцев продержалась.
Расскажу немного про свой опыт. Но прежде, следует уточнить, что в каждой компании роли тим-лида/тех-лида определяют по своему. И часто бывает — что это человек, который должен заткнуть все оставшиеся дыры.
В целом, на мой взгляд, тим-лид — это больше в сторону развития команды. И сейчас, наконец-то, по прошествии многих лет, стало появляется понимание этого. В последнее время я стал замечать, что в вакансиях тим-лидов все чаще встречаются требования, связанные именно с командной работой, решением межличностных конфликтов, развитием компетенций команды, планирование обучения и так далее и все меньше технических знаний.
А тех-лид — это больше в сторону технического развития. Мне в свое время предложили стать тех-лидом. Но как впрочем и всегда, это была мешанина обязанностей. Хотя именно развитием и обучением команды я не занимался. Конфликты не решал (хотя вроде их и не было).
То, что делал я — я бы назвал "ведущий программист". Я вел проект с технической точки зрения. С одной стороны у меня был Product Manager/Owner и BA, которые олицетворяли стейкхолдеров. Так как это был интегратор в банковской сфере — там было довольно много бумаг, в том числе и технические задания. Я же олицетворял весь технический проект целиком. Мне на входе "что надо сделать", а я думал "как это сделать" и делал вместе с командой. Выбирал технологии, продумывал архитектуру, оформлял и распределял задачи в жире, сам назначал созвоны для обсуждения рабочих вопросов с участниками команды (да это все еще было удаленно), проводил код-ревью и сам писал код и довольно много.
По распределению времени — процентов 60% на архитектуру и написание кода, 10-20% на ревью кода, остальное на остальное.
Собственно чего от меня ожидали:
6.1. Ревью кода. Я успевал просмотреть код за каждым участником
6.2. Ближе к концу я с BA прошлись по коду и тех заданию. Сопоставили и каждый себе пометил то, что надо еще доработать. В итоге синхронизировали документацию и код. И я стал уверен в том, что проект делает именно то, что требовалось
Чего я не делал:
Я столкнулся с аналогичной проблемой во фронтенде, так как сам был (и остаюсь больше) бэкендером. Но, из-за того, что я мог сам выбирать технологии и UI был довольно простым — остановился на том, что я довольно хорошо знал (в те времена это был ASP.NET, даже еще не MVC) + взял подходящую демку из набора готовых компонентов. Сейчас, на крупных проектах, я бы ставил перед руководством вопрос разделения фронт-енда и бэк-енда и у каждого свой "ведущий программист". Фронт-енд довольно обширная и крайне зыбкая тема.
Сейчас уже, я замечаю, что замкнул на себе довольно много всего. Это было ручное управление. Но тогда мне нравилось так работать. Команда была продолжением моих рук. Я успевал делать проект (на это конечно влияет размер команды и проекта). Но мои те подходы нельзя было масштабировать. И сейчас бы я думал в сторону настройки процессов и показателей. Например чтобы ревью-кода проводилось между участниками команды, а не лично мной. И так далее.
Фигня этот дюраселл. В автомобильном ключе родная продержалась года два. Поставил дюраселл — сдохла, полгода не прошло.
А можно более подробно про минусы в долгосрочной перспективе? Я представил, что несколько лет спустя будет куча роботов между основными системами. Это начнет походить на сервисы/микросервисы. И может даже начнет конфликтовать в каких-то моментах. С этой точки зрения — архитектор из первой истории предлагал довольно рациональные вещи.
Да, с отпуском там напряг.
Глобального снижения не будет, я вообще не уверен что будет хоть какое-то. Только если границы закроют и от свифта отключат. Но тогда плохо будет всем.
Программисты просто будут продолжать выходить на зарубежную удаленку и внутренние процессы в РФ заморским компаниям не указ. У них свой планетарный баланс спроса и предложения с учетом индусов.
Собственно многие так и сделали, когда у нас рубль рухнул в 2014. Думаю именно поэтому в стране постепенно возросли зарплаты до 350 тр — это как раз те же 5000$, что были до падения рубля.
Так что нет ничего не возможного.
Съем в мск 40, в городе миллионнике 15-20. Разница в 20 тр.
В отпуск через Москву — это условно +10тыр за билет туда обратно на каждого члена семьи
Еда так же. Одежда так же. Хотя вру, в своем городе я не смог найти нормальную теплую куртку на зиму. В Москве нашел. Т.е. еще и за нормальной одеждой надо в Москву гонять. А это опять +10тыр за билет туда обратно.
expertvagabond.com/digital-nomad-work-visas
(В статью бы добавить).
* США/Австралия — >= 50$/час
* Западная Европа — 40$/час
* Восточная Европа (+ Россия и + пожалуй Израиль) — 30$/час
* Ближний Восток (Египет, Афганистан и так далее) — 20$/час
* Дальний Восток (Индия) — до 10-20$/час
* Островные государства (Филиппины, Индонезия и так далее) — 5-10$/час
Но это средние, в каждом случае есть отклонения. Я например работал:
* С египтянином, который начал с 20$, потом 30$, а потом он устроился в Майкрософт.
* С человеком из Австралии — 75$
* Со славянином, проживающим в Израиле 80-100$
* С инудсом (куда уж без них) 30$ в час.
И видел ребят из России 35-45$.
И на самом деле тут три фактора:
1. Да, первый это дороговизна жизни в стране проживания.
2. Второй — местонахождение «компании-нанимателя». Для компаний из США вложения в хорошего программиста из восточной Европы — в целом выгодные вложения. Но для компании из Пакистана — нет.
3. Третий — это знания, опыт и навыки и знание конкретного бизнеса (внутренней кухни самой компании-нанимателя). Подтянув их — компании будут платить больше. Но нужен минимальный уровень этих знаний, навыков и опыта. Грубо говоря, если Вася Иванов умеет тоже самое за 30$, что и Джон Смит за 50$ — возьмут Васю. Но если у Васи английский вообще никакой — то и за 30 не возьмут.
Аналогичный баланс настанет и внутри России, когда удаленщиков станет больше.
Но на этот баланс будет давить потенциальная возможность работать на рынке зарубежной удаленки, где для россиян — это давно устоявшаяся ставка в 30$ в час (или порядка 5000$ в месяц). Это ставка такого хорошего сениора с опытом плюс минус 10 лет или выше + с хорошими софт скилами + английский intermediate. Английский кстати дает больше бонусов. Fluent- это уже 35-40 для россиянина.