От куда человек не знающий технических деталей сможет понять куда приведет его этот технический специалист через год, два, три или пять? Он может только надеятся на то, что его не обманули и человек действительно знает, что он делает. Часто дело в потраченном времени, которое уже не вернуть. Конкуренты не дремлят, и пока кто-то играется, другие забивают рынки.
То что бизнес принимает неправильные решения - это его право. Такое же право есть у покупателя на возможность разбить свою машину из салона. Но машину он свою должен получить такую, как написано в техническом описании.
Человек заказавший разработку ПО, как покупатель в магазине. Он дал деньги - получил продукт. Хороший технический специалист должен обьяснить все подводные камни замысла клиента, предложить несколько вариантов решения его задачи и выбрать с ним наиболее подходящий. Когда машину покупают, вам расскажут о ней все что можно и обьяснять почему одна лучше другой. Здесь также должно быть.
Я имею небольшое производство и постоянно отвечаю за качество предоставляемого товара. Я не могу выпустить сегодня товар по одному рецепту, а завтра по другому. Есть четкие технические карты, по которых работают сотрудники и никто не имеет права от них отклонятся. Да, это скучно в какой-то степени, делать каждый раз одно и то же. Но также это является определенным показателем профессионализма. Будет странно покупать в магазине один и тот же товар, каждый раз с разным вкусом или визуальным оформлением. Со временем технология производства стает более простой за счет нового оборудования и практик. Но это не приходит с бухты барахты - это отдельный процесс, требующий внимания и понимания всей команды.
Вы пытаетесь оправдать такое себе "экспериментальное программирование" тем, что если через 5 лет таких экспериментов проект не закрылся - все хорошо. Но это значит только то, что бизнес сумел пережить трудности, которые вы ему доставили. Например, урезанием бюджета на тот же маркетинг, дополнительным ограничением функциональности ПО из-за нехватки времени и тд.
Я не оправдываю любое поведение вашего "босса". Я лишь говорю о том, что каждый должен делать свою работу четко с планом без лишних издержек.
Согласен. Можно даже с квадратными колесами на велосипеде ехать не туда, куда надо. Но с круглыми колесами явно по-приятней и безопасней. Социальные сети так устроены, что мы видим только истории успехов, а провалы и падения - нет. Сколько людей начинающие свое дело не дошли до заветной мечты ? У скольких не хватило терпения?
Я расцениваю положение дел с двух сторон: и со стороны исполнителя, и со стороны клиента. Если рассматривать со стороны клиента - мне тут повезло наверное больше чем многим, потому что я могу дать качественную оценку работы. Но многие не могут.
Исполнители моих задач никогда не будут фантазировать в своих решениях, потому что это пустая трата моих денег. С каждой свистоперделкой я буду тратить бюджет непонятно на что и откладывать свои цели в длинный ящик просто потому, что кому-то стало немного скучно или он слишком творческая личность. Это не университет и не исследовательский центр. Мой приоритет - скорость развития проекта и стоимость поддержания.
Но не каждый может позволить себе дать эту качественную оценку. Многие начинают создавать свои проекты за последние деньги рискуя всем. Они платят ХОРОШИЕ деньги и надеятся найти тех, кто сможет ПРОСТО ХОРОШО СДЕЛАТЬ ТО, ЧТО ОНИ ПРОСЯТ. Но находят мечтателей, которые делают красивые кнопки и просто развлекаются как могут. Проходит год - проект не сделал. Прощание. Поиск нового. Приходит другой - говорит тут все говно, надо все переписывать, и говорит это убедительно, так как он меняет проекты каждый месяц и уже научился лапшу вешать, а человек, который деньги платит - раз в год. Через год тоже самое. Проект умирает. Результат - убитая мечта и куча потерянных денег.
Вы же сами писали, что работу нужно делать хорошо. Хорошо - значит подход изначально правильный. Вы же кабеля, которые прокладывали, не скручивали в лошадок или зайчиков, как надувные шарики? Правильно. Делали все строго по четко намеченому плану.
То что вы описали - это разбазаривание корпоративных ресурсов. Просто в средних и больших компаниях это мало заметно. Но это плохо в любом размере компании. Для маленьких компаний это может быть фатальной ошибкой закрывшей бизнес (свесят потом все как обычно на менеджеров, что не приняли нужных решений по развитию, хотя когда-то надо было фичу сделать за неделю - делали ее почему 2 месяца), а для больших - удар по репутации (будет кусок работать медленно, иметь уязвимость в коде публично освещенную потом в социальных сетях и тд).
Я согласен с тем, что такая крупная компания не могла допустить такое по-умолчанию. И проблема оказалось на всех уровнях. Но первый, кто отвечает за написаный код, тот кто написал его.
Если человек написал приложение, он должен сам его и проверить, как конечный пользователь, и потом уж отдать для команды тестирования для выявления нестандартного поведения. Но код должен до них добраться уже рабочий. Более того, только человек, который написал приложение, знает все тонкости его работы и обязан уведомить о возможных критических нюансах команду тестирования.
Семьи и кредиты не оправдывают смерть почти четырех сотен людей.
В любом случае, я хотел показать пример, где работа - это не место для мечтаний. Один из предыдущих топовых менеджеров сравнивал производство ПО с производством автомобилей на заводе. И лично я с ним полностью согласен. Почему машины можно выпускать по чертежах, а ПО строится как попало? Каждый лепит, что ему захочется. Если следовать таким путем, тогда в автосалонах были бы одни буханки где-то подбитые молотком, а где-то брусочком подпирающие каркас машины. И каждый раз выглядели бы по-разному. Единственное, чтобы их обьединяло - возможность ездить.
От части слишком низкий порог входа. Каждый может начать писать код на каком-то питоне просто почитав описание на википедии или посмотрев пару каких-то туториалов. Ваш пример с кабелями очень хороший. Для работы же в медицинских учреждениях нужно сначала много лег учить теории, чтобы потом можно было хотя бы уточки менять лежачим.
С другой стороны - отсутствующий менеджмент. Каждый может создать свой проект и вести его так, как они считает нужным. Все любят пощеголять друг перед другом, потому нанимают хороших для этого специалистов не все.
И как следствие - отсутствие четких регламентов. Может это и слишком старомодно, но дисциплина какая-то должна быть в команде. Тогда и команда работает сплоченней. Профессиональность команды часто можно увидеть, когда наступает критическая ситуация и решать вопрос надо уже прямо сейчас. Пример тому - службы быстрого реагирования, которые годами оттачивают свои навыки. Ну или если далеко не ходить - футбол, баскетбол или другой командный вид спорта.
Я это все к тому, что ваш посыл о творении - он очень хороший и правильный, но к сожалению, это не про работу. Я лично это вижу как научное исследование, где нету никаких ограничений, лимитов по времени, рисков и тд. Но многие обычно недооценивают серьезности происходящего или того, что они делают. А в реальных продуктах это всегда касается в той или иной степени жизни других людей. Если не ваших коллег, тогда конечного потребителя.
Работа - это не место для экспериментов. Если там такое проходит - пусть. Но лучше пусть такого не будет. Место для своих фантазий, романтики и тд скорее подходит для своих личных дел или какого-то научного кружка.
Технологичные проекты действительно требуют нестандартных решений. Но даже нестандартные решения будут написаны стандартными методами. ОС так и пишут на С, хотя прошло уже сколько лет? А там принципы сильно не изменились за все это время.
Если работа доставляет удовольствие и хочется "творить" - это замечательно, но и про риски забывать не надо. Можно начать писать проект на своем языке, но скорее всего долго он не проживет. А от этого решения будет зависеть зарплата других сотрудников и частично их будущее (особенно если много людей семейных и с детьми). Не только конечные пользователи.
Само по себе программирование - это вероятно и творческое занятие. Но коммерческая разработка затрагивает человеческие жизни. Возможно, человек, которые написал программное обеспечение для упавшего боинга, тоже любил эксперименты. И вместо того чтобы сосредоточится на решении конкретной задачи и считывания показателей с двух приборов, забил голову красивыми мыслями и просто забыл о парных компонентах системы.
просто != тупо. Я думаю даже в вашем случае это все равно было лучше, потому что переписать запутанный код намного сложнее, чем то что у вас получилось. Ну и видимо разработка все таки велась достаточно оперативно. Если с другими проектами угадали - ребята возможно более опытные делали или просто угадали. Если в конце ничего не переписывали, значит вначале хватало гибкости для каких-то серьезных изменений. Тупой код - он тоже плохой, но лучше запутанного. Бизнесу нужна гибкость - куда ветер дует, то и делаем. Если сходу заложить что-что сложное и прибить гвоздями, потом тяжело будет следовать за ветром и будут те же костыли, что и с тупым кодом, только покрыты кучей слоев абстракций. Есть крупные проекты, которые стоят миллиарды долларов и скорее всего выглядят как ваш пример. Никто просто не знает об этом. Дело в том, что они может и стоят столько, потому что в начале было более правильно распределение ресурсов внутри компании между всеми проектами и это сыграло определенную роль в таком вот росте.
абсолютно правильное замечания. Иногда заведомо задача усложняется до максимума, чтобы подольше ничего не делать, и побольше "лить воды" для создания продуктивной работы. Это, кстати, часто прослеживается и за аутсорсинговыми компаниями, которые специально таким образом больше стараются вымыть денег из клиента
Жизнь - она одна. Если боятся что-то сделать не так, можно пропустить все. Когда есть семья или какие-то факторы требующие стабильность, средств для маневра мало. Описанные ребята в статьи как раз таки не боятся экспериментировать, просто это надо делать под присмотром и не увлекаться.
Но если не пробовать, тогда никогда и не получится. Риск всегда есть. Можно попробовать найти себе "вторую" работу, если обе на удаленке. В таких проектах, о которых я писал, многие умудряются работать на несколько компаний не подавая виду. Это некрасиво от слова "совсем", но реальность это позволяет делать. Если качество твоей работы будет удовлетворять "начальство", тогда пусть этих работ хоть 5 будет. Иногда нужно просто найти "свою" компанию и это не обязательно значит, что там собеседования проходит намного сложнее или требования выше.
У меня был один пример, где человек работал в достаточно крупной региональной аутсорсинговой компании, где ему на позиции "тим.лида" платили около 100к рублей. Он даже и не думал, что мог получать больше. В итоге он случайно попал в другую компанию на "сеньйора", где ему сходу платили 200к за намного меньшие требования, а еще через полгода он в этой компании понял, что на самом деле его зарплата должна быть около 300к. А все просто потому, что первый работодатель оказался полным мудаком и специально вешал ему лапшу на уши. В итоге за год он "прокачался" от 100к до 300к фактически ничего не делая, а просто найдя "свою" компанию.
Каждая компания сама определяет кто такой "мидл", "сеньйор" и тд. Цены все формируют тоже как хотят. Нету единого стандартна. Это все условности. Просто попробуй что-то другое, только подойти с умом к этому. Возможно будет проект, где надо будет как раз из твоего старья переписать на новое - вот и практика и деньги. А таких проектов достаточно, просто нужно мониторить вакансии. За полгода-год это вполне вероятно найти, а это такое время, которое можно потратить как "инвестицию в будущее".
П.С. Если что, суммы были актуальны где-то лет 6-7 назад
это не про рефакторинг. Рефакторинг - это когда что-то давно упустили и теперь не знаете что с этим делать. В следующий раз, когда надо будет добавить что-то новое - посмотри на старый код, возможно его как-то можно объединить или переиспользовать. Изменения должны происходить постоянно. Это определенный навык красноречия должен еще быть. Нужно уметь обьяснить менеджеру, тил.лиду или вообще об этом не сказать, а сделать как должное (это некрасиво, но если уверенность 120%, тогда иногда можно). Для этого нужно знать хорошо кодовую базу либо не лениться шерстить по проекту. Ревью кода в теории должно помогать избегать таких проблем.
по-этому я и побывал в большом кол-ве разных проектов, включая такие вот второсортные - меняй работу. И не стесняйся делать это столько раз, сколько нужно. Нужно только учесть тот факт, что если в резюме обо всех написать - это мало кому понравится, потому нужно немного прибегнуть к хитростям. Пет-проекты дают возможность где-то набить шишки, а вот реально скилы прокачать можно только на сложных проектах. Для этого конечно нужно иметь какой-то опыт за спиной, но в первую очередь - просто много проходить собеседований. Если ты будешь очень часто пробовать себя на позиции, которые тебе "недоступны", со временем будешь знать спектр всех их вопросов, отвечать как на экзамене и в какой-то один да пройдешь. А там, если поднажмешь и не облажаешься, выйдешь на целый пласт подобных контор и проектов
я в профессиональных беседах веду нейтральный диалог и вообще никогда не перехожу на личности. Лучше сказать "существуют еще вот такие методы решения этой задачи" без привязки к себе или кому-то другому
ну вот это типичный среднестатистический стартап о котором я писал) половина этих приложений наверное может работать на aws t2.micro, но "исторически сложилось", что для этого проекта теперь нужна инфраструктура на тыщи баксов и еще целая команда для обслуживания
да, еще лучше это отражается в современном веб-фронте. Там обычно можно удалить процентов 80 кода. Для меня когда-то было открытием, что какой-то начинающий фронт мог собрать приложение на Vue.js, но не понимал, что можно сделать в html блок с кодом и что-то в нем выполнить... ???
для этого нужно писать свои проекты. Сообрази себе на досуг простую онлайн игру и тренируйся сколько влезет. На роботе учись КАК ДЕЛАТЬ НЕ НАДО, просто выполняя свои задачи, я думаю на любом проекте можно найти места, которые открывать страшно. А вот в домашнем проекте делай так, как считаешь нужным. Все равно ты потом перепишешь это 5 раз так и не найдя того самого идеального решения. Но зато попробуешь много других способов и будешь опять знать КАК ДЕЛАТЬ НЕ НАДО
качественная оценка должна быть. Сколько полезных функций в приложение ты можешь добавить за единицу времени? Если немного, тогда проблема не в том, что ты долго разбирался, а в том, что это написано сложно. Разработчик разработчику рознь. Если ему 40 лет и он уже 20 лет пишет код - это еще ничего не значит. Может он все это время на пыхе шаблоны для Wordpress настраивал
как я и написал в статье - где иначе сделать невозможно. Маленькие проекты, если хорошо идут, становятся рано или поздно большими. Обрастают определенным кол-вом полезных функций для конечно пользователя. Будь-то веб-приложение или та же ОС. На определенном этапе появляются похожие структуры, поддержание каких-то простых вещей становится с каждым разом сложнее. Вот тогда, ПО МОЕМУ МНЕНИЮ, ТОЧЕЧНО пора использовать определенные паттерны и другие подходы. Иногда частично это может проявлять себя и в простых проектах, например модульный подход к написанию веб-приложений часто себя оправдывает на достаточно большом интервале времени даже если сразу начать его применять, но, к сожалению, даже такой распространенный подход очень часто реализовываеться неправильно и многие начинают запутывать модули между собой вызовами API или на уровне хранения данных сложными запросами с джоинами (которые надо будет переписывать, если модуль действительно надо будет в будущем отделить в полноценный сервис)
Я был в десятке разных проектов совсем разного направления. Почему меня туда занесло ? Потому что платят нормально, а мне без разницы где говно чистить. Если говорить конкретно про такие стартапы, тогда общее число разработчиков там доходило наверное до 50. Но реально их там должно было быть 5. Все как один делали свою идеальную архитектуру. Часто бывало, что наступал день Х, приходил жирный инвестор, предлагал дать денег, но либо 100500 сервисов еле тянули онлайн в 100 человек, либо делали анализ кода и говорили потом "до свидания"
Ошибаешься, браток. Я всегда все говорю в глаза как есть. Просто зумеров так много, что со всеми по-отдельности времени не хватит поговорить. Я один раз указал одному на ошибки, так он решил ПОЖАЛОВАТЬСЯ менеджеру, типа как мамку позвать и сказать, что его раскритиковали. Волна лавандовых лате
От куда человек не знающий технических деталей сможет понять куда приведет его этот технический специалист через год, два, три или пять? Он может только надеятся на то, что его не обманули и человек действительно знает, что он делает. Часто дело в потраченном времени, которое уже не вернуть. Конкуренты не дремлят, и пока кто-то играется, другие забивают рынки.
То что бизнес принимает неправильные решения - это его право. Такое же право есть у покупателя на возможность разбить свою машину из салона. Но машину он свою должен получить такую, как написано в техническом описании.
Человек заказавший разработку ПО, как покупатель в магазине. Он дал деньги - получил продукт. Хороший технический специалист должен обьяснить все подводные камни замысла клиента, предложить несколько вариантов решения его задачи и выбрать с ним наиболее подходящий. Когда машину покупают, вам расскажут о ней все что можно и обьяснять почему одна лучше другой. Здесь также должно быть.
Я имею небольшое производство и постоянно отвечаю за качество предоставляемого товара. Я не могу выпустить сегодня товар по одному рецепту, а завтра по другому. Есть четкие технические карты, по которых работают сотрудники и никто не имеет права от них отклонятся. Да, это скучно в какой-то степени, делать каждый раз одно и то же. Но также это является определенным показателем профессионализма. Будет странно покупать в магазине один и тот же товар, каждый раз с разным вкусом или визуальным оформлением. Со временем технология производства стает более простой за счет нового оборудования и практик. Но это не приходит с бухты барахты - это отдельный процесс, требующий внимания и понимания всей команды.
Вы пытаетесь оправдать такое себе "экспериментальное программирование" тем, что если через 5 лет таких экспериментов проект не закрылся - все хорошо. Но это значит только то, что бизнес сумел пережить трудности, которые вы ему доставили. Например, урезанием бюджета на тот же маркетинг, дополнительным ограничением функциональности ПО из-за нехватки времени и тд.
Я не оправдываю любое поведение вашего "босса". Я лишь говорю о том, что каждый должен делать свою работу четко с планом без лишних издержек.
Согласен. Можно даже с квадратными колесами на велосипеде ехать не туда, куда надо. Но с круглыми колесами явно по-приятней и безопасней. Социальные сети так устроены, что мы видим только истории успехов, а провалы и падения - нет. Сколько людей начинающие свое дело не дошли до заветной мечты ? У скольких не хватило терпения?
Я расцениваю положение дел с двух сторон: и со стороны исполнителя, и со стороны клиента. Если рассматривать со стороны клиента - мне тут повезло наверное больше чем многим, потому что я могу дать качественную оценку работы. Но многие не могут.
Исполнители моих задач никогда не будут фантазировать в своих решениях, потому что это пустая трата моих денег. С каждой свистоперделкой я буду тратить бюджет непонятно на что и откладывать свои цели в длинный ящик просто потому, что кому-то стало немного скучно или он слишком творческая личность. Это не университет и не исследовательский центр. Мой приоритет - скорость развития проекта и стоимость поддержания.
Но не каждый может позволить себе дать эту качественную оценку. Многие начинают создавать свои проекты за последние деньги рискуя всем. Они платят ХОРОШИЕ деньги и надеятся найти тех, кто сможет ПРОСТО ХОРОШО СДЕЛАТЬ ТО, ЧТО ОНИ ПРОСЯТ. Но находят мечтателей, которые делают красивые кнопки и просто развлекаются как могут. Проходит год - проект не сделал. Прощание. Поиск нового. Приходит другой - говорит тут все говно, надо все переписывать, и говорит это убедительно, так как он меняет проекты каждый месяц и уже научился лапшу вешать, а человек, который деньги платит - раз в год. Через год тоже самое. Проект умирает. Результат - убитая мечта и куча потерянных денег.
Вы же сами писали, что работу нужно делать хорошо. Хорошо - значит подход изначально правильный. Вы же кабеля, которые прокладывали, не скручивали в лошадок или зайчиков, как надувные шарики? Правильно. Делали все строго по четко намеченому плану.
То что вы описали - это разбазаривание корпоративных ресурсов. Просто в средних и больших компаниях это мало заметно. Но это плохо в любом размере компании. Для маленьких компаний это может быть фатальной ошибкой закрывшей бизнес (свесят потом все как обычно на менеджеров, что не приняли нужных решений по развитию, хотя когда-то надо было фичу сделать за неделю - делали ее почему 2 месяца), а для больших - удар по репутации (будет кусок работать медленно, иметь уязвимость в коде публично освещенную потом в социальных сетях и тд).
Я согласен с тем, что такая крупная компания не могла допустить такое по-умолчанию. И проблема оказалось на всех уровнях. Но первый, кто отвечает за написаный код, тот кто написал его.
Если человек написал приложение, он должен сам его и проверить, как конечный пользователь, и потом уж отдать для команды тестирования для выявления нестандартного поведения. Но код должен до них добраться уже рабочий. Более того, только человек, который написал приложение, знает все тонкости его работы и обязан уведомить о возможных критических нюансах команду тестирования.
Семьи и кредиты не оправдывают смерть почти четырех сотен людей.
В любом случае, я хотел показать пример, где работа - это не место для мечтаний. Один из предыдущих топовых менеджеров сравнивал производство ПО с производством автомобилей на заводе. И лично я с ним полностью согласен. Почему машины можно выпускать по чертежах, а ПО строится как попало? Каждый лепит, что ему захочется. Если следовать таким путем, тогда в автосалонах были бы одни буханки где-то подбитые молотком, а где-то брусочком подпирающие каркас машины. И каждый раз выглядели бы по-разному. Единственное, чтобы их обьединяло - возможность ездить.
От части слишком низкий порог входа. Каждый может начать писать код на каком-то питоне просто почитав описание на википедии или посмотрев пару каких-то туториалов. Ваш пример с кабелями очень хороший. Для работы же в медицинских учреждениях нужно сначала много лег учить теории, чтобы потом можно было хотя бы уточки менять лежачим.
С другой стороны - отсутствующий менеджмент. Каждый может создать свой проект и вести его так, как они считает нужным. Все любят пощеголять друг перед другом, потому нанимают хороших для этого специалистов не все.
И как следствие - отсутствие четких регламентов. Может это и слишком старомодно, но дисциплина какая-то должна быть в команде. Тогда и команда работает сплоченней. Профессиональность команды часто можно увидеть, когда наступает критическая ситуация и решать вопрос надо уже прямо сейчас. Пример тому - службы быстрого реагирования, которые годами оттачивают свои навыки. Ну или если далеко не ходить - футбол, баскетбол или другой командный вид спорта.
Я это все к тому, что ваш посыл о творении - он очень хороший и правильный, но к сожалению, это не про работу. Я лично это вижу как научное исследование, где нету никаких ограничений, лимитов по времени, рисков и тд. Но многие обычно недооценивают серьезности происходящего или того, что они делают. А в реальных продуктах это всегда касается в той или иной степени жизни других людей. Если не ваших коллег, тогда конечного потребителя.
Работа - это не место для экспериментов. Если там такое проходит - пусть. Но лучше пусть такого не будет. Место для своих фантазий, романтики и тд скорее подходит для своих личных дел или какого-то научного кружка.
Технологичные проекты действительно требуют нестандартных решений. Но даже нестандартные решения будут написаны стандартными методами. ОС так и пишут на С, хотя прошло уже сколько лет? А там принципы сильно не изменились за все это время.
Если работа доставляет удовольствие и хочется "творить" - это замечательно, но и про риски забывать не надо. Можно начать писать проект на своем языке, но скорее всего долго он не проживет. А от этого решения будет зависеть зарплата других сотрудников и частично их будущее (особенно если много людей семейных и с детьми). Не только конечные пользователи.
Само по себе программирование - это вероятно и творческое занятие. Но коммерческая разработка затрагивает человеческие жизни. Возможно, человек, которые написал программное обеспечение для упавшего боинга, тоже любил эксперименты. И вместо того чтобы сосредоточится на решении конкретной задачи и считывания показателей с двух приборов, забил голову красивыми мыслями и просто забыл о парных компонентах системы.
просто != тупо. Я думаю даже в вашем случае это все равно было лучше, потому что переписать запутанный код намного сложнее, чем то что у вас получилось. Ну и видимо разработка все таки велась достаточно оперативно. Если с другими проектами угадали - ребята возможно более опытные делали или просто угадали. Если в конце ничего не переписывали, значит вначале хватало гибкости для каких-то серьезных изменений. Тупой код - он тоже плохой, но лучше запутанного. Бизнесу нужна гибкость - куда ветер дует, то и делаем. Если сходу заложить что-что сложное и прибить гвоздями, потом тяжело будет следовать за ветром и будут те же костыли, что и с тупым кодом, только покрыты кучей слоев абстракций. Есть крупные проекты, которые стоят миллиарды долларов и скорее всего выглядят как ваш пример. Никто просто не знает об этом. Дело в том, что они может и стоят столько, потому что в начале было более правильно распределение ресурсов внутри компании между всеми проектами и это сыграло определенную роль в таком вот росте.
абсолютно правильное замечания. Иногда заведомо задача усложняется до максимума, чтобы подольше ничего не делать, и побольше "лить воды" для создания продуктивной работы. Это, кстати, часто прослеживается и за аутсорсинговыми компаниями, которые специально таким образом больше стараются вымыть денег из клиента
Жизнь - она одна. Если боятся что-то сделать не так, можно пропустить все. Когда есть семья или какие-то факторы требующие стабильность, средств для маневра мало. Описанные ребята в статьи как раз таки не боятся экспериментировать, просто это надо делать под присмотром и не увлекаться.
Но если не пробовать, тогда никогда и не получится. Риск всегда есть. Можно попробовать найти себе "вторую" работу, если обе на удаленке. В таких проектах, о которых я писал, многие умудряются работать на несколько компаний не подавая виду. Это некрасиво от слова "совсем", но реальность это позволяет делать. Если качество твоей работы будет удовлетворять "начальство", тогда пусть этих работ хоть 5 будет. Иногда нужно просто найти "свою" компанию и это не обязательно значит, что там собеседования проходит намного сложнее или требования выше.
У меня был один пример, где человек работал в достаточно крупной региональной аутсорсинговой компании, где ему на позиции "тим.лида" платили около 100к рублей. Он даже и не думал, что мог получать больше. В итоге он случайно попал в другую компанию на "сеньйора", где ему сходу платили 200к за намного меньшие требования, а еще через полгода он в этой компании понял, что на самом деле его зарплата должна быть около 300к. А все просто потому, что первый работодатель оказался полным мудаком и специально вешал ему лапшу на уши. В итоге за год он "прокачался" от 100к до 300к фактически ничего не делая, а просто найдя "свою" компанию.
Каждая компания сама определяет кто такой "мидл", "сеньйор" и тд. Цены все формируют тоже как хотят. Нету единого стандартна. Это все условности. Просто попробуй что-то другое, только подойти с умом к этому. Возможно будет проект, где надо будет как раз из твоего старья переписать на новое - вот и практика и деньги. А таких проектов достаточно, просто нужно мониторить вакансии. За полгода-год это вполне вероятно найти, а это такое время, которое можно потратить как "инвестицию в будущее".
П.С. Если что, суммы были актуальны где-то лет 6-7 назад
это не про рефакторинг. Рефакторинг - это когда что-то давно упустили и теперь не знаете что с этим делать. В следующий раз, когда надо будет добавить что-то новое - посмотри на старый код, возможно его как-то можно объединить или переиспользовать. Изменения должны происходить постоянно. Это определенный навык красноречия должен еще быть. Нужно уметь обьяснить менеджеру, тил.лиду или вообще об этом не сказать, а сделать как должное (это некрасиво, но если уверенность 120%, тогда иногда можно). Для этого нужно знать хорошо кодовую базу либо не лениться шерстить по проекту. Ревью кода в теории должно помогать избегать таких проблем.
по-этому я и побывал в большом кол-ве разных проектов, включая такие вот второсортные - меняй работу. И не стесняйся делать это столько раз, сколько нужно. Нужно только учесть тот факт, что если в резюме обо всех написать - это мало кому понравится, потому нужно немного прибегнуть к хитростям. Пет-проекты дают возможность где-то набить шишки, а вот реально скилы прокачать можно только на сложных проектах. Для этого конечно нужно иметь какой-то опыт за спиной, но в первую очередь - просто много проходить собеседований. Если ты будешь очень часто пробовать себя на позиции, которые тебе "недоступны", со временем будешь знать спектр всех их вопросов, отвечать как на экзамене и в какой-то один да пройдешь. А там, если поднажмешь и не облажаешься, выйдешь на целый пласт подобных контор и проектов
я в профессиональных беседах веду нейтральный диалог и вообще никогда не перехожу на личности. Лучше сказать "существуют еще вот такие методы решения этой задачи" без привязки к себе или кому-то другому
ну вот это типичный среднестатистический стартап о котором я писал) половина этих приложений наверное может работать на aws t2.micro, но "исторически сложилось", что для этого проекта теперь нужна инфраструктура на тыщи баксов и еще целая команда для обслуживания
ну он обиделся, к такому видимо жизнь его не готовила) но да, что-то типа харрасмента)
да, еще лучше это отражается в современном веб-фронте. Там обычно можно удалить процентов 80 кода. Для меня когда-то было открытием, что какой-то начинающий фронт мог собрать приложение на Vue.js, но не понимал, что можно сделать в html блок с кодом и что-то в нем выполнить... ???
для этого нужно писать свои проекты. Сообрази себе на досуг простую онлайн игру и тренируйся сколько влезет. На роботе учись КАК ДЕЛАТЬ НЕ НАДО, просто выполняя свои задачи, я думаю на любом проекте можно найти места, которые открывать страшно. А вот в домашнем проекте делай так, как считаешь нужным. Все равно ты потом перепишешь это 5 раз так и не найдя того самого идеального решения. Но зато попробуешь много других способов и будешь опять знать КАК ДЕЛАТЬ НЕ НАДО
качественная оценка должна быть. Сколько полезных функций в приложение ты можешь добавить за единицу времени? Если немного, тогда проблема не в том, что ты долго разбирался, а в том, что это написано сложно. Разработчик разработчику рознь. Если ему 40 лет и он уже 20 лет пишет код - это еще ничего не значит. Может он все это время на пыхе шаблоны для Wordpress настраивал
как я и написал в статье - где иначе сделать невозможно. Маленькие проекты, если хорошо идут, становятся рано или поздно большими. Обрастают определенным кол-вом полезных функций для конечно пользователя. Будь-то веб-приложение или та же ОС. На определенном этапе появляются похожие структуры, поддержание каких-то простых вещей становится с каждым разом сложнее. Вот тогда, ПО МОЕМУ МНЕНИЮ, ТОЧЕЧНО пора использовать определенные паттерны и другие подходы. Иногда частично это может проявлять себя и в простых проектах, например модульный подход к написанию веб-приложений часто себя оправдывает на достаточно большом интервале времени даже если сразу начать его применять, но, к сожалению, даже такой распространенный подход очень часто реализовываеться неправильно и многие начинают запутывать модули между собой вызовами API или на уровне хранения данных сложными запросами с джоинами (которые надо будет переписывать, если модуль действительно надо будет в будущем отделить в полноценный сервис)
Я был в десятке разных проектов совсем разного направления. Почему меня туда занесло ? Потому что платят нормально, а мне без разницы где говно чистить. Если говорить конкретно про такие стартапы, тогда общее число разработчиков там доходило наверное до 50. Но реально их там должно было быть 5. Все как один делали свою идеальную архитектуру. Часто бывало, что наступал день Х, приходил жирный инвестор, предлагал дать денег, но либо 100500 сервисов еле тянули онлайн в 100 человек, либо делали анализ кода и говорили потом "до свидания"
Ошибаешься, браток. Я всегда все говорю в глаза как есть. Просто зумеров так много, что со всеми по-отдельности времени не хватит поговорить. Я один раз указал одному на ошибки, так он решил ПОЖАЛОВАТЬСЯ менеджеру, типа как мамку позвать и сказать, что его раскритиковали. Волна лавандовых лате
Нейросеть тут ничего не писала. Сверху указана длительность чтения. Если твой мозг не усваивае больше одного абзаца, мог не читать вообще.
Так и есть, но удаленка открывает в этом плане безграничные возможности