Data Science fwdays сonference — few-shot learning, snorkel, black box and more! Kyiv, Sep 7

Вопрос о переход в софт из геймдева

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

Как вы думаете на сколько возможно сменить род деятельности? И, если возможно, то как?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А в чем проблема? Специалисты везде нужны!

Ох, а у меня наоборот — 4 года Java, но хочу в геймдев...

дык хотеть же не вредно, не ушел же в геймдев еще и не факт что уйдет

Геймдев как работа дерьмо: платят мало, работать много

если ты на юнити фигачил все это время, тогда, наверное, да — проблема, но легко решаемая, надо просто подтянуть шарп чтобы в книжке Рихтера не было белых пятен, ну и всякие хендлеры/модули, спаны/дивы, индексы, солид и т.д.

если полноценный шарп, то проблема надуманная, предметная область не имеет значения

P.S.: и из программиста в программиста переход — не смена рода деятельности, то если бы ты барменом был, тогда другой разговор :)))

На юнити в основном да, и если я работаю на юнити это не значит что у меня плохой шарп. И Рихтера я тоже читал и с солид принципами знаком. Я вот тоже думал что не будет ни какой проблемы, а вот оказалось есть проблема.

читал и знаком это знаю и всегда следую? если да, то нет проблемы, только в каких-то лютых компаниях могут забраковать за такое, просто сходи в нормальную

Твой шанс: это найти тех кому нужны разработчики прямо на сейчас, и желательно с очень тонкой прослойкой между заказчиком и тобой. Конторы типа «нам вообще никто не нужен, но если очень понравится — возьмем» — будут футболить, среди аутсорсеров таких выше крыши.

Да, скорее всего так и есть

У Вас +500 конекшенов на линкедине и хороший профиль — оповестите HR -ов что вы хотите перейти и выберете подходящее предложение. все.

Я сейчас так и пробую, к сожалению в основном получаю ответ что вы не достаточно работали с нашей технологией, увы.

Добавьте HR-ов из моего профиля — они возможно поактивнее )))

Послушайте, но это ж такая игра: HR говорит, что нужно столько-то лет работы. Вы говорите, что вы именно столько и работали. И меняете резюме. И шлете его. На собеседование берете честное и говорите «Ой, что-то у вас какое-то не то резюме, старое. Вот новое.»

ну, это уже из разряда лайфхаков мне кажется)

Думаю, вопрос не в опыте программирования вообще, а именно в знаниях конкретных технологий и соответствии знаний запрлатным ожиданиям. Вопрос в том, что Вы уже знаете/умеете на текущий момент и чем именно хотите заниматься в софте. Пытаться стать Jack-of-all-trades явно не стоит, лучше выбрать специализацию, которая будет Вам интересна и сфокусироваться на ней, а уже после расширять спектр знаний. Набор наиболее востребованных технологий, это:
Entity Framework
ASP.Net MVC
WCF
WebAPI
MS SQL
AngularJS/KnockoutJS
Azure
Если можете сформулировать, что конкретно Вы ищете и в чем проблемы с поиском, возможно смогу что-то еще подсказать.

На счёт зарплатных ожиданий: я чётко понимаю что при смене стека технологий будет понижение и я к этому готов. На счёт стека и направленности: я как вы и сказали смотрю на веб, не из-за востребованности, а скорее из интереса и перспектив. У меня скорее проблема в том что даже не готовы рассматривать мою кандидатуру из-за отсутствия опыта в технологии.. Хотя я готов выучить все необходимые технологии на проект в свободное от работы время.

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

Я это прекрасно понимаю и сейчас как раз и занимаюсь изучением.

Порог очень высокий. Как от беллетристики перейти в юриспруденцию, зная русский. Вроде и язык один, но де-факто язык разный.

Иными словами, нужен АРГУМЕНТ — зачем ты собираешься понести транзакционные издержки на переход. Если только деньги — аргумент сомнительный, лучше ищи куда прыгнуть в геймдеве. Переезд в другую страну вероятно выйдет дешевле.

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

Тогда добро пожаловать в реальный мир! Теперь определяйся куда тебе — бодишопы или продуктовая разработка.
Ключевая дрянь бодишопов — что ты окажешься в том же геймдеве, но в другой игре — в бюрократию. То есть то что ты будешь делать, людям как правило не нужно.
Ключевая дрянь продукта/сервиса — то что они с огромной вероятностью пролетают. Твоя задача не попасть в те, которые пролетают с вероятностью 100%.
Ещё есть фриланс. Но тут уже тебе проще своими глазами глянуть на этот рынок. Если кратко, то дерьма неимоверное количество всех сортов и расцветок, ибо никто эти конюшни толком не чистит. Туда ходить не рекомендую.

Только исходя из этого решения будешь определяться, что тебе собственно нужно. Абсолютно разный набор требований. Даже за одними и теми же ключевыми словами стоят разные по сути задачи, и без прямого разговора ты не поймёшь, что из хотелок составляет 97-99% работы, а что просто красивые слова приписанные для понту.

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

Бодишопы или нет — сложный вопрос, конечно хотелось бы в продуктовой с хорошим продуктом. Но из своего опыта я вынес что скорее важен не тип компании и даже не продукт. При выборе лучше руководствоваться тем, на сколько тебе тебе хочется работать с людьми которые тебя собеседовали (в том числе и руководитель конечно).

Фриланс да, как-то пробовал, не для меня.

На счёт на сколько я готов смириться с тем что пользователей не слушают.. Не знаю готов ли)

Ну это ключевой выбор — НА КОГО ты работаешь, КОГО ты удовлетворяешь.
К примеру, если ты пишешь для клиентов, то покрываешь тестами 3-5% кода. Притом половину из них выбросишь на рефакторинге. Если для бюрократов — то и 100% не предел, и TDD наше всё.

Людей делает окружение, точно говорю. Какие стимулы — такие и люди. И человек попадая в бюрократию — становится бюрократом. Есть те кто наоборот — получает абсолютно противоположный навык, но таких всего 0.2%.

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

А почему для клиентов тесты пишут на 5%? Просто не уловил в чем тут суть, я думал наоборот все)

В теории нет разницы между теорией и практикой. На практике есть.

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

Против чего реально работают тесты — против человеческого фактора. Когда хочется побыстрее, а нельзя. Иными словами, это искусственный тормоз, для тех кому он необходим. А необходим он менеджерам, которые кричат «давай быстрее», и которым некому набить морду. Но работает такой подход слабо, поскольку написание тестов — это тоже код, и в результате количество багов только удваивается. Вспомни, сколько раз проблема была в самом тесте, а не в коде?

И главное, почему нужно отказываться от тестов всего и вся: чтобы потом изменить код, требуется в 2-3 раза БОЛЬШЕ человеческой памяти. А это крайне ограниченный ресурс. И если нет атмосферы глубокого погружения, то задача на 20 минут может запросто лечь в долгий ящик на 4 месяца. Просто потому что никто не хочет за неё браться, ведь версия-то стабильна.

Заканчивается тем, что в долгий ящик попадают багрепорты по сравнительно редко встречаемым багам. Но когда приходит пора выкатить новую версию, серьёзное обновление — тестеры в последний момент вспоминают о старых багах. Кому они попадают в результате? Джунам естественно! И новая версия летит в продакшен уже с багами джунов. Часть из этих багов — обязательно попадает в долгий ящик до новой серьёзной версии. Результат: обесценивание продукта, неимоверные затраты на его продажи, только потому что ВЫГОДУ по сравнению с РИСКОМ никто не оценивал — в результате боролись с риском, и потеряли выгоду.

Как происходит то же самое в сильном продукте: затраты идут не на написание уймы тестов, и соответственно кучу всякого тестирования, а на ОБРАТНУЮ СВЯЗЬ. Бета-тестеры оказываются куда лучше внутренних. Я не говорю, что внутренних иметь не нужно, но переоценивать их роль не стоит, и перенагружать ритуалами тоже. А вот обратная связь должна подниматься реальными профессионалами, которых вы готовы слушать сами, и фактически делегировать им тактическое руководство.

PS. Тесты начисто лишают всех преимуществ фреймворков. Прежде всего — ПОНИМАНИЯ кода.

Интересно, походу у меня все по-другому из-за особенностей платформы. Теперь понятно, как у людей))

Окей. Написал я каких-то пару методов. Ничего сверхсложного, но есть немного бизнес логики.

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

Позже оказывается, что были tricky moments в бизнес логике, и Вася своим рефакторингом поломал все к чертям.

А был бы тест — при сборке Вася бы увидел failed tests : N, пошел бы разобраться и понял свою ошибку. Возможно даже зарефакторил опять, но не упуская эти кейсы.

Потом решил подрефакторить и часть моего кода
а какого хера лезть в часть кода, которая работает и которую не надо менять для этих кейсов?

Иногда это улучшит читаемость, сократит количество кода, и тд.
В остальных 95% случаев да, не надо лезть. Но такие люди везде есть...

Иногда это улучшит читаемость, сократит количество кода, и тд.
даже если улучшит читаемость на какоето время, это не повод туда лезть.
Но такие люди везде есть...
и именно для этих кейсов есть код ревью

тесты не гарантируют защиту от этого, они сами могут быть с багами, 100% покрытие в целом недостижима, и пустая трата времени

Я не говорил о 100% покрытии. Но вовсе игнорить их, или написать пару штук, все же, как по мне, нельзя.

там была речь не про пару штук, а насколько я понял Алексея о покрытие ключевых участков — что абсолютно правильно

Не ключевых участков кода, а ключевых участков ВЗАИМОДЕЙСТИЯ. То есть те места, где ввод и вывод документированы.

А вот как раз те места где данные меняются — нужно вылизывать и рефакторить код. В том числе для того, чтобы его было потом легко менять, и так же легко найти виновника бага при очередном изменении.

В противном случае, когда тестом покрывается тривиальный код вместо API — получаем ситуацию Райикна «Кто сшил этот костюм?». В отдельности всё работает, а как целый продукт — никого не волнует.

Никто и не говорит про пару. Но про пару процентов — да.

И главное, почему нужно отказываться от тестов всего и вся

Видимо, я понял это как отказ от тестов в пользу фулл рефакторинга.

if(код читаешь) while(не понимаешь что он делает || с чем){ рефакторить;}

Но такие люди везде есть...
Это потому что их в ъезду посылают.

Абсолютно верно. И посылая по известному адресу идеологов «don’t repeat youself», если какому-то Васе понадобилась для своего кейза часть кода — так пусть берёт и копипастит. А не закладывает душу дьяволу ради каких-нить пары ништяков.

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

были tricky moments
1) Вот вместо того, чтобы писать тесты на примитивную логику — лучше бы как следует задокументировал «tricky moments».
2) Именно эти «tricky moments» практически никогда не покрываются тестами. По той уже причине, что они нетривиальны. И гораздо проще просто не давать «неправильных» данных тесту.

Если факты не соответствуют теории — от них избавляются.

Я и говорю о тестах на tricky moments. Покрывать тестами простые вещи не надо, а специфические места — вполне стоит.

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

Отдельный вопрос по регулярным выражениям. Я считаю, того кто их придумал следует посадить пожизненно с обязательством разгребать логи, прочитывая их вслух. Это дерьмо хуже самого страшного ассемблера или битового кодирования. И даже яростные его фанаты ошибаются в них просто песец как часто.

Ключевая гадость регулярки — что она отвратительно поддаётся дебагу. И лишь вопрос времени, когда к ней прилетит, то чем она подавится.

Регулярки — необходимое зло. И ничего плохого не случается, если использовать умеренно где нужно (парсить файлы/сайты/итд)

К сожалению, это «где нужно» выливается в настройки конечного пользователя. Которому предлагается [сюрпраайз] написать регулярку.

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

В общем, я не сторонник телесных наказаний, но этот тот случай когда они необходимое зло.

Одно дело когда ты что-то парсишь не особо важное, и если из 1000 сайтов 1 не распарсился, то хрен с ним. И совершенно другое — когда тебя принуждают той же регуляркой контролировать вопросы безопасности, ИЧСХ даже потестить некак.

Бюрократія == бодішоп == тдд???? А продукт != тдд або ~ тдд

Игры очень помогают людям в работе. Иначе рехнуться можно было бы, если бы была одна работа в жизни.

Рехнуться тоже помогает :)
Вот у тебя есть воображаемый енотик? Так давай подарю. (надоел сволочь, советует как чистый код писать)

Нет, у меня есть прист 102 уровня в PW :)

Меняешь на енотика? Он добрый и пушистый.

Нет, прист пока нужнее :)

Подписаться на комментарии