Дано: я живу ради удовольствий и в данный момент делаю активности приносящие мне моментарные (продукты со сладостями) и длительные (игры, сериалы) удовольствия.
Со мной все ок? Или я должен жить ради чего то другого чем удовольствия? Что не так с моими текущими удовольствиями? Как доказать себе что 50 лет этих удовольствий (и смерть) лучше 80 лет других удовольствий (минус время на переучивание на другие удовольствия и смерть)?
Похвалю тинькоф тут по части валютного контроля, уже год пользуюсь ими и процесс выглядит примерно так:
1) есть договор (довольно обычный в 2 колонки на русском и английском)
2) периодически отправляю инвойсы клиенту в пдфе
3) когда клиент пересылает деньги приходит пуш в телефоне от тинькоф
4) гружу этот же пдф в подтверждающие документы
5) часов 5-6 занимает валютный контроль и деньги приходят
Хотя конечно комиссии за пользование этими USD со счёта ИП и предлагаемые курсы не особо радуют у них.
Я бы сказал индустрия стала гораздо шире чем была раньше, но наполнилась более простыми позициями (для которых условно подходит самый способный упаковщик бургеров в макдаке), и есть те кто мечтали о хардкорном R&D программировании, а работают на этом новом огромном наросшем слое.
Ну и всё ещё по каким-то неведомым мне причинам распространено указывать "зп не указана" и поэтому приходится просить эти суммы самому, чтобы их получить.
Возможности=оппортьюнити 2мя преложениями выше. Условно одним конторам нужен запас сеньоров так сказать для релайабилити — если одного автобус собьёт там или рейдж квит у кого случится. Таким конторам зачастую нужны сеньоры со знаниями вглубь доменов чем в техническую глубь и в идеале с семьей и ипотекой чтобы не дергался. Это в основном банки или какие нибудь крупные стабильные сервисы. Там платят +- одинаково и эти цифры довольно часто циркулируют в статьях или каких нибудь ресерчах по зарплатам и это то что называют «в среднем по рынку»
Другие конторы / проекты фокусируются на развивающихся нишах на рынках где временные рамки для профитов очень ограничены. Вот там нужны программеры зачастую с бизнес скиллами, которым не нужен разжевывающий почти до кода требования за тебя. Это конторы типа слизывающие взлетевшие в США стартапы пока их в Россию не завезли например.
Ну и ещё есть ниши где нужны несколько разных сложных вышек (на ум приходит фин трейдинг или разработка чего нить нового типа первого ифона, гугл очков или хололенса, хбоха или пс4)
Мне кажется до сеньора шкала более менее линейная и известная на рынке, а после начинается привязка к бизнес-оппортьюнити.
Условно в Мск сеньор «про запас в организацию аля крупный банк с тысячей таких же программистов» получает в диапазоне 250-400к. Сеньор ищущий возможности и имеющий некоторую склонность к бизнесу вполне может получать в районе 400-1кк. Обычно вакансии по возможностям не особо публикуют публично на чем то типа хх и заполняют через нетворкинг, они не такие стабильные (условно сеньор в банк после устройства может быть уверен что у него джоб секурити лет на 5 теперь)
Сложно читать потому что ошибки не оценены на северити. Из-за этого постоянно думаешь «зачем я это читаю».
Но так вцелом надо это на гитхаб и пусть там микрософт триажит и сортирует по важности — их работа.
Хороший совет, и даже те кто пишут про СОЛИД и тестируемый код — всегда будет какой-нить ньюхайр, который придет в многолетний код и пофиксит баг и не покроет его новыми тестами или не подумает о каком-нибудь пограничном сценарии. И потом это упадёт в продакшне у клиента и удачи вам понимать почему это произошло.
В реальном продакшне производительность может страдать, поэтому флаг/опция на уровень логгирования обязателен.
Еще у всяких фреймворков типа NLog есть оверлоады на лямбды применимые даже к вашему примеру:
_log.Trace($«Privilege: {privilege} not added to User: {user}»);
user тут объект, т.е. ожидаю что в нём перекрыт ToString который может быть еще довольно большой строкой. Также довольно удобно просто писать что-нибудь типа JsonConvert.Serialize(user), чтобы в логах почитать можно было. Поэтому лучше писать это так:
_log.Trace(() => $«Privilege: {privilege} not added to User: {user}»);
Имхо такое годно для какого-нить пет-проекта на гитхабе, при этом не уверен что ссылка на такой проект пойдет даже в плюс в резюме. Т.е. чисто для себя или для какого-нить комьюнити любителей такого кода, обычно некоммерческого.
Но всё же если взять среднюю.нет кодбазу, то над ней больше часов проводят девелоперы, которые её не писали с нуля и которые не знают всю окружающую инфраструктуру. Девелоперы в среднем хорошо знают C#, встроенные апи .NET, самые популярные нугет пакеты и мб специализированные фреймворки.
Поддерживать, менять и профилировать такой код сложнее чем прямолинейный нативный C#, если ты работраешь с этим кодом раз в год.
И согласен с lair про скоп out параметров, он сделан довольно коряво из-за наследия C#, также как и is var x и case int x. Поэтому использовать хорошо и без неожиданных сюрпризов это можно в коротких узкоспециализированных методах в которых уже становится не очень важно насколько красиво они написаны.
вариант наверное рабочий, хотя я бы не уложился в 50$ на 3 недели на еду, скорее в 300-400$ :)
Стоит или нет вопрос подсчетов и наличия денег. Если плюхи окупают разницу в зп и мЕньшей базовой ЗП, то ок. Потому что условно если начинать со 100 у.е. в год, то в большинстве контор это будет 103, 106, 109, 112, 115 примерно рост за какое-то время. Если с 90, то это будет 93, 96, 99, 102, 105. Разница соотв. в половину годовой зп на интервале 4-5 лет может быть, просто за то что тебе дали 5к$ «плюшек» на переезд в начале и ты согласился на зп пониже.
Особенно если ехать на визе привязанной к работодателю.
Билет, виза, предоплата жилья, зачастую первые деньги от работодателя приходят через 30-45 дней только (даже если релокейшн/сайн-он бонус) так что еще еда, проезд на это время. Симка/интернет.
Можно конечно ужаться и жить в хостеле первое время и питаться дошираком…
У меня по опыту сложилось впечатление, что такие проблемы в коммуникациях возникают в конторах с совковым/военным/сильно иерархическом стилем управления (называйте как хотите). Условно когда у тебя есть насяльник и он определяет хороший ты или плохой и какой у тебя бонус и ничего больше в компании на это не влияет.
Это правится само собой когда в оценку перформанса сотрудника добавляют фидбеки от кого угодно и на уровне культуры компании считается нормально писать фидбеки на любых людей, с которыми ты контактировал по любой задаче, даже если это было полдня. Ну и этот фидбек должен быть реально весомым фактором в результате перформанс ревью.
Таким образом работа ПМа просто переходит в режим «Вася, там Петя из другой команды работает над тем же, вам бы надо с ним вместе поработать» и всё. Люди уходят в чатики или живое общение как им нравится, но главное что общаются напрямую между собой без пинков.
Возможно еще на это влияет менталитет — работая в разных компаниях с интернациональным составом мне стало казаться что среди свежих людей из СНГ, Китая, Индии процент таких, которые ставят своего лида в копию в каждом письме направленном за пределы своей команды гораздо больше, чем среди людей из чисто западных стран. Со временем почти все такие люди меняются и приходят больше к использованию своего лида как сервиса, нежели как начальника/главного.
Это норм когда релизы более менее редко, а не когда у тебя 5 релизов параллельно на такой поддержке и еще основная разработка идёт.
Ну и у нас другой вариант, кастомеры очень долго сидят и никуда не валят особо. В основном есть кастомеры, которые грозятся свалить если мы что-нибудь не выпустим в НОВОЙ версии.
Разброс кастомеров большой правда, есть такие, кто платит что-то в районе 10к$, а есть близкие к 10mln$, а продукт один.
а мне показалась сложная система крафтинга и я тупо даггером со спины в голову всю игру прошел, ниче не крафтил ни разу и заклинания только 2 — хил и +радиус зрения
я скорее всего работаю в другой компании по автоматизации кинобизнеса, но могу рассказать о своём недовольстве со стороны разработчика:
1. компания разрабатывает свой продукт уже больше 20 лет
2. у компании примерно 90 продуктов, но всего 7 баз данных
3. компания поддерживает по 5 версий каждого продукта параллельно (раз в 3 месяца большой релиз, 5 последних релизов на активной поддержке)
4. компания обещает что все версии будут работать друг с другом, просто некоторые фичы могут не работать
разработка фич происходит в той же мвп схеме:
1. выпускаем мвп под кастомера максимально простой, не заморачиваясь с архитектурой (настройки в локальных файлах, в базе данных еще какие-нить пара настроек)
2. приходит другой кастомер, хочет туже фичу но с перламутровыми пуговицами
3. решаем что настройки в локальных файлах уже не катят, в базе данных теперь надо 1:n и тут большое НО — у предыдущего кастомера не должно ничего сломаться после апгрейда и он не должен ничего делать
Получается надо делать пару фоллбеков на всё подряд.
Потом 1-3 повторяется ещё для одного кастомера, потом еще для одного но в другом продукте на той же БД и так код превращается в ад. Особенно когда встречаешь функциональность прошедшую этот путь в 2005-м и уже никого нет вокруг кто вообще знает почему и зачем делали так и кто как используют этот функционал.
Так вот с точки зрения программиста решение должно быть:
1. писать нормальные апгрейд скрипты, которые апгрейдят любую существующую конфигурацию на новую модель
2. заставлять кастомеров апгрейдить все продукты
С точки зрения продуктолога:
1. на 1й пункт — это затратно, это требует делать пункт 2 (потому что апгрейд схемы БД обычно ломает существующие аппы)
2. на 2й пункт — часто бывает что при апгрейде че то ломается или надо донастраивать, поэтому приходят к выводу, что лучше пусть программисты закодят в новом продукте 33 фоллбека, чем заапгрейдить кастомеров на более менее чистую и понятную архитектуру.
Вообщем заключение что я не против выпуска МВП, но когда продуктолог понимает косты развития этого МВП далее для других кастомеров в будущем и не игнорит эти косты наращивая технический долг до бесконечности. Потому что иначе 80% работы программиста над новой модификацией превращается в походы по этажам и разговоры со старичками в поисках всех возможных сценариев и очень хочется уволиться :)
Дано: я живу ради удовольствий и в данный момент делаю активности приносящие мне моментарные (продукты со сладостями) и длительные (игры, сериалы) удовольствия.
Со мной все ок? Или я должен жить ради чего то другого чем удовольствия? Что не так с моими текущими удовольствиями? Как доказать себе что 50 лет этих удовольствий (и смерть) лучше 80 лет других удовольствий (минус время на переучивание на другие удовольствия и смерть)?
1) есть договор (довольно обычный в 2 колонки на русском и английском)
2) периодически отправляю инвойсы клиенту в пдфе
3) когда клиент пересылает деньги приходит пуш в телефоне от тинькоф
4) гружу этот же пдф в подтверждающие документы
5) часов 5-6 занимает валютный контроль и деньги приходят
Хотя конечно комиссии за пользование этими USD со счёта ИП и предлагаемые курсы не особо радуют у них.
Обычно SaaS берут чтобы не создавать или сократить количество сисадминов у себя в конторе (каждый из которых стоит ~100k usd в год в сша например)
ну вот например нашел за 2 минуты на хабре:
https://hh.ru/vacancy/33435377
вот тут просто список где это более менее прямо указано (прямо сеньор девелопер там не так много, но они есть ~ 1 на страницу)
https://hh.ru/search/vacancy?L_is_autosearch=false&area=1&clusters=true&enable_snippets=true&no_magic=true&only_with_salary=true&salary=250000&specialization=1&page=2
Ну и всё ещё по каким-то неведомым мне причинам распространено указывать "зп не указана" и поэтому приходится просить эти суммы самому, чтобы их получить.
Возможности=оппортьюнити 2мя преложениями выше. Условно одним конторам нужен запас сеньоров так сказать для релайабилити — если одного автобус собьёт там или рейдж квит у кого случится. Таким конторам зачастую нужны сеньоры со знаниями вглубь доменов чем в техническую глубь и в идеале с семьей и ипотекой чтобы не дергался. Это в основном банки или какие нибудь крупные стабильные сервисы. Там платят +- одинаково и эти цифры довольно часто циркулируют в статьях или каких нибудь ресерчах по зарплатам и это то что называют «в среднем по рынку»
Другие конторы / проекты фокусируются на развивающихся нишах на рынках где временные рамки для профитов очень ограничены. Вот там нужны программеры зачастую с бизнес скиллами, которым не нужен разжевывающий почти до кода требования за тебя. Это конторы типа слизывающие взлетевшие в США стартапы пока их в Россию не завезли например.
Ну и ещё есть ниши где нужны несколько разных сложных вышек (на ум приходит фин трейдинг или разработка чего нить нового типа первого ифона, гугл очков или хололенса, хбоха или пс4)
Мне кажется до сеньора шкала более менее линейная и известная на рынке, а после начинается привязка к бизнес-оппортьюнити.
Условно в Мск сеньор «про запас в организацию аля крупный банк с тысячей таких же программистов» получает в диапазоне 250-400к. Сеньор ищущий возможности и имеющий некоторую склонность к бизнесу вполне может получать в районе 400-1кк. Обычно вакансии по возможностям не особо публикуют публично на чем то типа хх и заполняют через нетворкинг, они не такие стабильные (условно сеньор в банк после устройства может быть уверен что у него джоб секурити лет на 5 теперь)
Сложно читать потому что ошибки не оценены на северити. Из-за этого постоянно думаешь «зачем я это читаю».
Но так вцелом надо это на гитхаб и пусть там микрософт триажит и сортирует по важности — их работа.
В реальном продакшне производительность может страдать, поэтому флаг/опция на уровень логгирования обязателен.
Еще у всяких фреймворков типа NLog есть оверлоады на лямбды применимые даже к вашему примеру:
_log.Trace($«Privilege: {privilege} not added to User: {user}»);
user тут объект, т.е. ожидаю что в нём перекрыт ToString который может быть еще довольно большой строкой. Также довольно удобно просто писать что-нибудь типа JsonConvert.Serialize(user), чтобы в логах почитать можно было. Поэтому лучше писать это так:
_log.Trace(() => $«Privilege: {privilege} not added to User: {user}»);
Но всё же если взять среднюю.нет кодбазу, то над ней больше часов проводят девелоперы, которые её не писали с нуля и которые не знают всю окружающую инфраструктуру. Девелоперы в среднем хорошо знают C#, встроенные апи .NET, самые популярные нугет пакеты и мб специализированные фреймворки.
Поддерживать, менять и профилировать такой код сложнее чем прямолинейный нативный C#, если ты работраешь с этим кодом раз в год.
И согласен с lair про скоп out параметров, он сделан довольно коряво из-за наследия C#, также как и is var x и case int x. Поэтому использовать хорошо и без неожиданных сюрпризов это можно в коротких узкоспециализированных методах в которых уже становится не очень важно насколько красиво они написаны.
C# и .NET это в основном язык для кровавого энтерпрайза и для девелоперов с мат аппаратом ниже среднего.
Выше среднего идут в игроделанье или сток трейдинг какой-нить и фигачут все на С/С++ без границ.
Стоит или нет вопрос подсчетов и наличия денег. Если плюхи окупают разницу в зп и мЕньшей базовой ЗП, то ок. Потому что условно если начинать со 100 у.е. в год, то в большинстве контор это будет 103, 106, 109, 112, 115 примерно рост за какое-то время. Если с 90, то это будет 93, 96, 99, 102, 105. Разница соотв. в половину годовой зп на интервале 4-5 лет может быть, просто за то что тебе дали 5к$ «плюшек» на переезд в начале и ты согласился на зп пониже.
Особенно если ехать на визе привязанной к работодателю.
Можно конечно ужаться и жить в хостеле первое время и питаться дошираком…
Это правится само собой когда в оценку перформанса сотрудника добавляют фидбеки от кого угодно и на уровне культуры компании считается нормально писать фидбеки на любых людей, с которыми ты контактировал по любой задаче, даже если это было полдня. Ну и этот фидбек должен быть реально весомым фактором в результате перформанс ревью.
Таким образом работа ПМа просто переходит в режим «Вася, там Петя из другой команды работает над тем же, вам бы надо с ним вместе поработать» и всё. Люди уходят в чатики или живое общение как им нравится, но главное что общаются напрямую между собой без пинков.
Возможно еще на это влияет менталитет — работая в разных компаниях с интернациональным составом мне стало казаться что среди свежих людей из СНГ, Китая, Индии процент таких, которые ставят своего лида в копию в каждом письме направленном за пределы своей команды гораздо больше, чем среди людей из чисто западных стран. Со временем почти все такие люди меняются и приходят больше к использованию своего лида как сервиса, нежели как начальника/главного.
Ну и у нас другой вариант, кастомеры очень долго сидят и никуда не валят особо. В основном есть кастомеры, которые грозятся свалить если мы что-нибудь не выпустим в НОВОЙ версии.
Разброс кастомеров большой правда, есть такие, кто платит что-то в районе 10к$, а есть близкие к 10mln$, а продукт один.
1. компания разрабатывает свой продукт уже больше 20 лет
2. у компании примерно 90 продуктов, но всего 7 баз данных
3. компания поддерживает по 5 версий каждого продукта параллельно (раз в 3 месяца большой релиз, 5 последних релизов на активной поддержке)
4. компания обещает что все версии будут работать друг с другом, просто некоторые фичы могут не работать
разработка фич происходит в той же мвп схеме:
1. выпускаем мвп под кастомера максимально простой, не заморачиваясь с архитектурой (настройки в локальных файлах, в базе данных еще какие-нить пара настроек)
2. приходит другой кастомер, хочет туже фичу но с перламутровыми пуговицами
3. решаем что настройки в локальных файлах уже не катят, в базе данных теперь надо 1:n и тут большое НО — у предыдущего кастомера не должно ничего сломаться после апгрейда и он не должен ничего делать
Получается надо делать пару фоллбеков на всё подряд.
Потом 1-3 повторяется ещё для одного кастомера, потом еще для одного но в другом продукте на той же БД и так код превращается в ад. Особенно когда встречаешь функциональность прошедшую этот путь в 2005-м и уже никого нет вокруг кто вообще знает почему и зачем делали так и кто как используют этот функционал.
Так вот с точки зрения программиста решение должно быть:
1. писать нормальные апгрейд скрипты, которые апгрейдят любую существующую конфигурацию на новую модель
2. заставлять кастомеров апгрейдить все продукты
С точки зрения продуктолога:
1. на 1й пункт — это затратно, это требует делать пункт 2 (потому что апгрейд схемы БД обычно ломает существующие аппы)
2. на 2й пункт — часто бывает что при апгрейде че то ломается или надо донастраивать, поэтому приходят к выводу, что лучше пусть программисты закодят в новом продукте 33 фоллбека, чем заапгрейдить кастомеров на более менее чистую и понятную архитектуру.
Вообщем заключение что я не против выпуска МВП, но когда продуктолог понимает косты развития этого МВП далее для других кастомеров в будущем и не игнорит эти косты наращивая технический долг до бесконечности. Потому что иначе 80% работы программиста над новой модификацией превращается в походы по этажам и разговоры со старичками в поисках всех возможных сценариев и очень хочется уволиться :)