Ответ очень простой, тестирование и полировка в одиночку не оставили ни физических, ни моральных сил. И еще полгода я бы не выдержал.
Я тоже занимаюсь долгостроем (с 2016 года), но не понимаю всех этих "еще полгода я бы не выдержал" - а вам заниматься разработкой вообще нравится? Если для вас это мука - может ну нафиг этот геймдев?
Жизнь коротка (особенно молодость), чтобы тратить её на мазохизм.
На какой-то момент мне показалось, что главная проблема игры — это отсутствие рекламы.
На мой взгляд, главная ваша проблема, как и многих других - это восприятие релиза на стиме как какого-то финального экзамена без права перездачи. И типа если что-то зафейлилось (а первый раз всегда фейлится) - то все, конец, все пропало, все плохо.
Напрашивается вопрос - а вы слышали о такой штуке, как аналитике? Считайте конверсию, смотрите на каком уровне отваливаются игроки - доделывайте, вкладывайтесь в маркетинг, работайте с отзывами игроков - работы бесконечные просторы. Конечно, если в свой проект сами верите, и заниматься разработкой игр приносит удовольствие.
А то, со стороны выглядит так, будто вы ищите повод, чтобы забросить разработку.
Можно ли что-то изменить, упростить и улучшить не теряя при этом в качестве?
На мой взгляд, вопрос уже поставлен некорректно.
Нет никакого абстрактного «правильного и качественного» решения. Все зависит от поставленной задачи.
Если нам нужно API, которое на запрос GET / должно выдавать «Hello World», то мы просто пишем echo «Hello World» и все. Если на том же самом проекте требуется уже разный ответ по разным url + работа с базой — нужно уже использовать фреймворк.
Но использовать фреймворк для первой задачи — избыточно. А для второй задачи писать свой роутинг, свою работу с базой — это уже велосипеды, которые скорее всего окажутся костылями.
Нет никакого абстрактного хорошего и качественного решения. Все зависит от поставленной задачи.
А «все плохо» на проекте становится тогда, когда у команды хронически нет времени рефакторить старый код под новые задачи. Когда новые требования решаются по-быстрому, костылем.
Дальше тоже одни вопросы по тексту:
попытаться предварительно изучить на практике «с паяльником и осциллографом» в руках эти внешние источники и сделать минимально простой интеграционный модуль.
применение инструментов data science является идеальным
А я думал, что внешние источники изучаются чтением документации по ним…
Подобная интеграционная схема организуется и поддерживается в продуктиве в разы быстрее и легче средствами data science, чем Java/C++/SQL/php
Я думаю, главная причина непонимания — в том как мы, инженеры и разработчики, пытаемся объяснять бизнесу, почему важно избавляться от техдолга.
Бесполезно объяснять.
Есть два типа менеджеров: которые лично наблюдали смерть проекта под грузом техдолга, и те, которые такого опыта не имеют.
Объяснять вторым, что заниматься техдолгом важно — тоже самое, что объяснять человеку о необходимости чистить зубы, когда зубы у него никогда не болели — бесполезно. Вот заболят — поймет.
Через месяц сидения на таком кресле шея стала болеть только сильнее. Конечно, это может быть по разным причинам, но говорить, что поддержка головы у кресла решит все проблемы — нет.
Общий знаменатель — бэкенд / фуллстек разработчик с 6-8 годами опыта
«Немного» по разному проходит. С джуном никто разговаривать не будет, пока он не выполнит тестовое задание, предлагать же тестовое задание условным сеньерам перед собеседованием — значит отсеять 90% кандидатов. О чем говорят сами HR.
Нужно как минимум несколько штук для самого сервиса, и как минимум с дублированием всего
Вначале должна быть проблема, потом действия, потом проверка того, что сделанные действия решили проблему.
Уже не так чтобы копейки
Самый дешевый VPS у моего хостера — 157 рублей. 10 штук на месяц обойдется в 1570р. — на мой взгляд это не критичная сумма для it-специалиста.
а если мы вот тут возьмем сервер не на четыре, а на восемь процессоров, это поможет?
Почему бы не попробовать, и не посмотреть результат? К слову говоря, на конференциях hightLoad как раз про это и говорят — что если нагрузка растет не экспоненциально — просто увеличить мощность одного сервера — самый простой и дешевый вариант.
Плюс мне кажется, что навыки не масштабируются так просто
Начнем с того, что ~80% программистов в принципе не привыкли заменять Memory Cost и Runtime своего кода. И ~99% в принципе не пробовали настроить nginx balancer и сделать несколько кластеров под бек и несколько шардов базы, что делается локально, на докере.
попасть в контору, которая с такими работает
Да даже если попадешь — кто человека, который «не шарит» — допустит к важным бизнес процессам? Так, только если со стороны посмотреть.
Мне кажется, что можно многое сделать и «на коленке», а уже сделав это — вы будете выделяться на фоне 99% других соискателей, которые также «я хочу получить опыт, но не знаю как».
для реализации хайлоад-проектов нужен опыт, набраться его, не создавая такие самому, невозможно
Почему невозможно? На одной VPS поднимаете ваш сервис, с другой VPS начинаете спапить на первую запросами. Можно не с одной, а с нескольких, для увеличения масштаба.
С 99.99% вероятностью ваш сервис упадет — вот и просторы для творчества и практики.
Как и TDD, де-факто ставший стандартом в разработке модулей
Видимо в какой-то параллельной реальности. В реальности, в которой я живу — 80% компаний юнит-тесты или не пишет вообще или покрывает только очень-очень важный функционал.
Найти компанию, в которой бы все программисты ответственно относились к авто-тестам, и чтобы команда в целом стремилась к 100% покрытию тестами — это из разряда фантастики.
Многие уверены, что у инженерной должности есть «потолок»: однажды для дальнейшего профессионального роста нужно начинать управлять людьми и становиться руководителем. У нас это не так
Полностью согласен. Более того, подход «рост программиста только через переход в менеджмент» по-сути лишает рынок нормальных кадров.
А почему только на C++? Разве ООП не везде одинаковое?
К слову говорят, с 2016 года пилю свою MMORPG на php, и вот на очередном переписывании с нуля, году так в 2019 появился интересный подход к изменению сложных объектов (в конкретной ситуации — персонажа), не через бесконечные setHp(), setMana(), addEffect() и т.д., а через объекты-события и их обработку:
// Применяет к персонажу абстрактное событие
public function applyAction(ActionInterface $action)
Позволяет абстрагироваться от необходимости вне объекта думать о состоянии объекта. Просто говорим «примени к себе такое событие» и все.
Особенно удобно, если нужно сделать пошаговый бой между двумя персонажами — одному персонажу говорим «дай свою коллекцию событий» (в один ход персонаж может сделать сразу несколько действий), затем событию говорим «применись», оно само выбирает, к кому примениться — если это удар, то на противника, если лечение — на союзника, а потом к выбранной цели просто говорит «примени меня».
В общем, паттерн интересный, мне он нравится, применяю в сложных объектах, но нигде о подобном подходе не читал. Можно написать более подробную статейку, если сообществу интересно.
PM сейчас в четырех случаях из 5 тоже в общем то занимаются какойто херней, но доказать свою полезность очень очень надо, даже если ты просто играешь в передаста.
Вы ходили так интенсивно на собеседования с какой целью?
Да не сказал бы, что особо интенсивно — сейчас, когда 99% собеседований проходит онлайн — они много времени не занимают. Другое дело, что лично у меня на третьем собеседовании в день уже голова не соображала (да и пофиг, пускай по гитхабу меня оценивают, а не по словам) — у кого голова лучше соображает, может и по 5-7 собеседований в день проводить.
Искали работу? Искали «более лучшую» работу?
Да, искал более лучшую работу. Когда приходил на прошлую работу — офис был в Москва-сити, до которого мне ехать 30 минут, а потом офис переехал в жопудаль, дорога стала занимать более часа плюс новый офис был унылой конурой — в общем появилась мотивация.
В остальных случаях все на личных знакомствах.
С одной стороны, конечно, удобно, с другой стороны — вам самим не интересно, как вас оценят незнакомые вам люди?
К слову о эмоциях — когда станете крутым и востребованным специалистом, сделайте эксперимент — походите на собеседования в плохом настроении. Отказов будет 100%. Так что эмоциональный настрой очень важен, а люди, которые долго не могут найти работу попадают в замкнутый круг — постоянные отказы вводят в депресняк, а депресняк не позволяет получить оффер.
понял, что надо покупать весла и грести оттуда
Увольняться стоит только тогда, когда найдена новая работа. Не знаю в чем логика, но для HR соискатель, который нигде сейчас не работает — это сразу -50-70% ценности. Независимо от опыта и знаний.
Высунув язык, состряпал первое резюме и стал ждать
Так обычно опытные специалисты работу ищут)
я мол хочу мало денег, и это подозрительно
Да, подозрительно. Тут еще можно вспомнить классическую фразу «кто первый называет сумму — проигрывает», попробуйте не называть желаемой зарплаты вообще, если скромность не позволяет просить по рынку.
Так как у меня свободный английский
Тогда что вы забыли в СНГ?
Шутка, с долей шутки.
Собеседований было достаточно много, в сумме около 25
Я за последний 2-х недельный отпуск провел 15 собеседований, а 25 за полтора года — это очень мало.
Если это так и у вас есть истории похлеще при устройстве в топовые конторы
Нет никаких «топовых» контор. Есть расхайпанные, но работать там такое себе (очень много зависит от конкретного отдела/начальника, к которому попадете). Ну и отношение «да за дверью очередь из тысячи таких как ты стоит» не добавляет комфорта.
Все логично: любая новая технология на момент своего появления "какая-то еще одна непонятная штука", и только единицы из них, со временем, становятся стандартом разработки. Докер сейчас таким стандартом стал.
Ну и справедливости ради стоит сказать, что докер не панацея — если на актуализацию docker-compose.yml команда забивает, то он становится той самой "еще одной прослойкой, с которой надо возиться" банально, чтобы развернуть проект.
Думаю, многим приходилось сталкиваться с ситуацией, когда коллега увольняется, оставив за собой стрёмный код и недоделанные merge request-ы, в которых кроме него никто не разбирается.
Это он еще неопытный))
Опытный плохой программист внедряет редкую чудо-технологию (которая на словах «вхуж» и решит все проблемы), которая в итоге становится еще одной обязательной прослойкой в системе, в которой, никто кроме него не разбирается. А он специально не пишет никаких гайдов по развертыванию и поддержке, чтобы оставаться незаменимым.
Начальнику тебя выгодно повышать, ставить на свое место
Здесь возникает другой вопрос — а нужно ли это повышение, и должность «начальника»?
Область программирования позволяет получать хорошую (при работе на англоязычного работодателя) зарплату, оставаясь рядовым программистом.
Это не значит, что я не согласен с необходимостью документации — как раз поддерживаю, но, отвечать за других людей (если они не разделяют хороших подходов к разработке) — зачем оно мне?
Программист, который комментирует свой код, пишет документацию по бизнес процессам — это отличный и нужный сотрудник для компании (если в руководстве хоть немного соображают). Но практика 90% компаний показывает, что да, пока сотрудник на месте — на все эти комментарии и документации всем плевать. А вот когда он увольняется — за хорошим программистом (который описан в статье) легко перенять все процессы — потому что все расписано, а за программистом, который делал только тот минимум, который от него требовали (а это, часто, лишь «шобы работало») — начинается ад, из разряда «Что? Где? Когда?»
Более того, если в компании был один программист (или один бек-енд программист), то на этом продукт может и закончится — новый может банально не разобраться (особенно, если на момент прихода продукт уже сломался), как оно работает, и звучит классическая фраза «да тут все с нуля надо переписывать».
Я тоже занимаюсь долгостроем (с 2016 года), но не понимаю всех этих "еще полгода я бы не выдержал" - а вам заниматься разработкой вообще нравится? Если для вас это мука - может ну нафиг этот геймдев?
Жизнь коротка (особенно молодость), чтобы тратить её на мазохизм.
На мой взгляд, главная ваша проблема, как и многих других - это восприятие релиза на стиме как какого-то финального экзамена без права перездачи. И типа если что-то зафейлилось (а первый раз всегда фейлится) - то все, конец, все пропало, все плохо.
Напрашивается вопрос - а вы слышали о такой штуке, как аналитике? Считайте конверсию, смотрите на каком уровне отваливаются игроки - доделывайте, вкладывайтесь в маркетинг, работайте с отзывами игроков - работы бесконечные просторы. Конечно, если в свой проект сами верите, и заниматься разработкой игр приносит удовольствие.
А то, со стороны выглядит так, будто вы ищите повод, чтобы забросить разработку.
Готов поспорить, что 99% успеха — это не навык резать лишнее, а увлеченность своим делом.
По этому их опыт никак не поможет 90% сегодняшним продакт-менеджерам, для которых работа это просто работа.
На мой взгляд, вопрос уже поставлен некорректно.
Нет никакого абстрактного «правильного и качественного» решения. Все зависит от поставленной задачи.
Если нам нужно API, которое на запрос GET / должно выдавать «Hello World», то мы просто пишем echo «Hello World» и все. Если на том же самом проекте требуется уже разный ответ по разным url + работа с базой — нужно уже использовать фреймворк.
Но использовать фреймворк для первой задачи — избыточно. А для второй задачи писать свой роутинг, свою работу с базой — это уже велосипеды, которые скорее всего окажутся костылями.
Нет никакого абстрактного хорошего и качественного решения. Все зависит от поставленной задачи.
А «все плохо» на проекте становится тогда, когда у команды хронически нет времени рефакторить старый код под новые задачи. Когда новые требования решаются по-быстрому, костылем.
Дальше тоже одни вопросы по тексту:
А я думал, что внешние источники изучаются чтением документации по ним…
Можно реальный кейс?
Бесполезно объяснять.
Есть два типа менеджеров: которые лично наблюдали смерть проекта под грузом техдолга, и те, которые такого опыта не имеют.
Объяснять вторым, что заниматься техдолгом важно — тоже самое, что объяснять человеку о необходимости чистить зубы, когда зубы у него никогда не болели — бесполезно. Вот заболят — поймет.
Я не врач, но покупал как-то кресло Expert Fly:
Через месяц сидения на таком кресле шея стала болеть только сильнее. Конечно, это может быть по разным причинам, но говорить, что поддержка головы у кресла решит все проблемы — нет.
Почему же неизвестной? Вполне себе известной, даже фильм сняли и обзор на фильм есть хороший.
«Немного» по разному проходит. С джуном никто разговаривать не будет, пока он не выполнит тестовое задание, предлагать же тестовое задание условным сеньерам перед собеседованием — значит отсеять 90% кандидатов. О чем говорят сами HR.
Вначале должна быть проблема, потом действия, потом проверка того, что сделанные действия решили проблему.
Самый дешевый VPS у моего хостера — 157 рублей. 10 штук на месяц обойдется в 1570р. — на мой взгляд это не критичная сумма для it-специалиста.
Почему бы не попробовать, и не посмотреть результат? К слову говоря, на конференциях hightLoad как раз про это и говорят — что если нагрузка растет не экспоненциально — просто увеличить мощность одного сервера — самый простой и дешевый вариант.
Начнем с того, что ~80% программистов в принципе не привыкли заменять Memory Cost и Runtime своего кода. И ~99% в принципе не пробовали настроить nginx balancer и сделать несколько кластеров под бек и несколько шардов базы, что делается локально, на докере.
Да даже если попадешь — кто человека, который «не шарит» — допустит к важным бизнес процессам? Так, только если со стороны посмотреть.
Мне кажется, что можно многое сделать и «на коленке», а уже сделав это — вы будете выделяться на фоне 99% других соискателей, которые также «я хочу получить опыт, но не знаю как».
Почему невозможно? На одной VPS поднимаете ваш сервис, с другой VPS начинаете спапить на первую запросами. Можно не с одной, а с нескольких, для увеличения масштаба.
С 99.99% вероятностью ваш сервис упадет — вот и просторы для творчества и практики.
Видимо в какой-то параллельной реальности. В реальности, в которой я живу — 80% компаний юнит-тесты или не пишет вообще или покрывает только очень-очень важный функционал.
Найти компанию, в которой бы все программисты ответственно относились к авто-тестам, и чтобы команда в целом стремилась к 100% покрытию тестами — это из разряда фантастики.
Полностью согласен. Более того, подход «рост программиста только через переход в менеджмент» по-сути лишает рынок нормальных кадров.
А почему только на C++? Разве ООП не везде одинаковое?
К слову говорят, с 2016 года пилю свою MMORPG на php, и вот на очередном переписывании с нуля, году так в 2019 появился интересный подход к изменению сложных объектов (в конкретной ситуации — персонажа), не через бесконечные setHp(), setMana(), addEffect() и т.д., а через объекты-события и их обработку:
Позволяет абстрагироваться от необходимости вне объекта думать о состоянии объекта. Просто говорим «примени к себе такое событие» и все.
Особенно удобно, если нужно сделать пошаговый бой между двумя персонажами — одному персонажу говорим «дай свою коллекцию событий» (в один ход персонаж может сделать сразу несколько действий), затем событию говорим «применись», оно само выбирает, к кому примениться — если это удар, то на противника, если лечение — на союзника, а потом к выбранной цели просто говорит «примени меня».
В общем, паттерн интересный, мне он нравится, применяю в сложных объектах, но нигде о подобном подходе не читал. Можно написать более подробную статейку, если сообществу интересно.
Это точно. Иногда просто поражаешься, сколько людей банально не могут свои хотелки выразить в четких формулировках на бумаге.
Обвинять их в каких-то глобальных косяках (как некоторые любят, перекладывать на них ответственность за бизнес) — такое себе занятие…
Да не сказал бы, что особо интенсивно — сейчас, когда 99% собеседований проходит онлайн — они много времени не занимают. Другое дело, что лично у меня на третьем собеседовании в день уже голова не соображала (да и пофиг, пускай по гитхабу меня оценивают, а не по словам) — у кого голова лучше соображает, может и по 5-7 собеседований в день проводить.
Да, искал более лучшую работу. Когда приходил на прошлую работу — офис был в Москва-сити, до которого мне ехать 30 минут, а потом офис переехал в
жопудаль, дорога стала занимать более часа плюс новый офис был унылой конурой — в общем появилась мотивация.С одной стороны, конечно, удобно, с другой стороны — вам самим не интересно, как вас оценят незнакомые вам люди?
К слову о эмоциях — когда станете крутым и востребованным специалистом, сделайте эксперимент — походите на собеседования в плохом настроении. Отказов будет 100%. Так что эмоциональный настрой очень важен, а люди, которые долго не могут найти работу попадают в замкнутый круг — постоянные отказы вводят в депресняк, а депресняк не позволяет получить оффер.
Увольняться стоит только тогда, когда найдена новая работа. Не знаю в чем логика, но для HR соискатель, который нигде сейчас не работает — это сразу -50-70% ценности. Независимо от опыта и знаний.
Так обычно опытные специалисты работу ищут)
Да, подозрительно. Тут еще можно вспомнить классическую фразу «кто первый называет сумму — проигрывает», попробуйте не называть желаемой зарплаты вообще, если скромность не позволяет просить по рынку.
Тогда что вы забыли в СНГ?
Шутка, с долей шутки.
Я за последний 2-х недельный отпуск провел 15 собеседований, а 25 за полтора года — это очень мало.
Нет никаких «топовых» контор. Есть расхайпанные, но работать там такое себе (очень много зависит от конкретного отдела/начальника, к которому попадете). Ну и отношение «да за дверью очередь из тысячи таких как ты стоит» не добавляет комфорта.
Все логично: любая новая технология на момент своего появления "какая-то еще одна непонятная штука", и только единицы из них, со временем, становятся стандартом разработки. Докер сейчас таким стандартом стал.
Ну и справедливости ради стоит сказать, что докер не панацея — если на актуализацию docker-compose.yml команда забивает, то он становится той самой "еще одной прослойкой, с которой надо возиться" банально, чтобы развернуть проект.
Это он еще неопытный))
Опытный плохой программист внедряет редкую чудо-технологию (которая на словах «вхуж» и решит все проблемы), которая в итоге становится еще одной обязательной прослойкой в системе, в которой, никто кроме него не разбирается. А он специально не пишет никаких гайдов по развертыванию и поддержке, чтобы оставаться незаменимым.
Особенно хорошо работает в компаниях без докера.
Здесь возникает другой вопрос — а нужно ли это повышение, и должность «начальника»?
Область программирования позволяет получать хорошую (при работе на англоязычного работодателя) зарплату, оставаясь рядовым программистом.
Это не значит, что я не согласен с необходимостью документации — как раз поддерживаю, но, отвечать за других людей (если они не разделяют хороших подходов к разработке) — зачем оно мне?
Вы кажется не поняли, о чем речь.
Программист, который комментирует свой код, пишет документацию по бизнес процессам — это отличный и нужный сотрудник для компании (если в руководстве хоть немного соображают). Но практика 90% компаний показывает, что да, пока сотрудник на месте — на все эти комментарии и документации всем плевать. А вот когда он увольняется — за хорошим программистом (который описан в статье) легко перенять все процессы — потому что все расписано, а за программистом, который делал только тот минимум, который от него требовали (а это, часто, лишь «шобы работало») — начинается ад, из разряда «Что? Где? Когда?»
Более того, если в компании был один программист (или один бек-енд программист), то на этом продукт может и закончится — новый может банально не разобраться (особенно, если на момент прихода продукт уже сломался), как оно работает, и звучит классическая фраза «да тут все с нуля надо переписывать».