Комментарии 214
Рынок меня избаловал, раньше я ходил только на те собесы, куда меня позвали из-за статей — чтобы не пришлось никому ничего объяснять.Это статья чтобы опять позвали на интервью? Есть масса контор которые про Хабр вообще не слышали, так что можно париться по поводу блэклиста. Хотя конечно в таких конторах только за деньги и работать (и самое хреновое, что за небольшие деньги).
Ну и Хрюшек надо пожалеть, по сравнению с программистами, им реально будет плохо, но те кто останется, будут свой синдром вахтёра включать на полную.
В интересные времена живём. Куча стартапиков на жирных рынках схлопнулась (кричат SOS — Save Our Startups). Месяц назад, разработчиков с руками отрывали, а через пару недель по десятку на одно место будет стучаться.
Совсем не факт, инвесторы ждали что пузырь лопнет но большинство верило что это будет чуть позже, "после" будет детальный пересмотр, в том числе бизнес моделей того во что вкладываться и кто знает, вполне может оказаться что большинство признает ИТ стартапы зоной с
одним из самых высоки уровней риска.
«Взгляни! Я пресытился своей мудростью, как пчела, собравшая слишком много меду; мне нужны руки, простертые ко мне.»
Это пока харя партии позволяет «в нормальных деньгах» получать,
А можно валюту после ВК оставлять непроданной, на валютном счету и потом переводить на счет физлица? Как рассчитывают налог на доход в этом случае?
Это пока харя партии позволяет «в нормальных деньгах» получать, а не принудительно продать их в ВЭБ, а потом по курсу для электората физикам купить
Я предполагал, что конвертация валюты в рубль обязательна. Просто не интересовался этим вопросом.
им просто не нужен сотрудник, а собес проводят ради интереса.
Довольно дорогостоящее развлечение. Откуда такие выводы?
Почему бы компании не сделать то же самое? Например, перед открытием нового отдела или проекта — чтобы оценить, стоит или не стоит.
Это же не развлечение.
В локальной валюте по более-менее нормальному курсу тоже достаточно неплохо, чтоб не заморачиваться ВЭД. Кстати, в России сейчас можно с валютного счёта ИП выводить на валютный счёт физлица без двойной конвертации?
pnovikov
Разница, как вы можете видеть, РОВНО НА ПОРЯДОК. Ещё есть вопросы почему люди не пишут технические статьи?
А потом еще получить слив кармы за какую-нибудь субъективную мелочь в политсраче. Это, пожалуй, должно сильно мотивировать писать сложные технические статьи.
Если до кризиса найти работу занимало от ~30-40 собеседований по нескольку этапов каждый, то в кризис надо бегать еще быстрее и планировать 100 собеседований, не меньше. Такими темпами как на картинке можно надеяться на работу к концу пандемии.
Работа и раньше всем нужна была как воздух (если ты не сын Рокфеллера). Ничего не изменилось. Кроме желания выехать на хайпе еще разок.
Ну нет. Нужна вообще — да. Но немного разные жизненные условия — и вот уже нужна «как воздух», в то время как соседу — всего лишь «как еда», месяц можно перетоптаться (а сейчас как раз такое время, когда за месяц многое меняется). Да и когда ты ищешь норм работу, или же ты ищешь норм работу минимум за нехилый N денег (потому что уже набрал обязательств и меньше просто не можешь) — это две огромнейшие разницы.
Впрочем, я с вами согласен, что пока что в мире IT от силы немного сильнее дует и шторм где-то там на горизонте, но уж точно ничего особо страшного сейчас не происходит.
Молодец правду написал, у меня такое было несколько раз, Бог даст — не повторится больше. Однако выход лежит не области программирования, а кардинальной смене мировоззрения — учиться нужно много, сменить точку опоры в жизни радикально, чтобы больше не падать!
А если смотреть на ЕС? А на Австралию?
Не одними же Штатами живо IT.
По крайней мере, на порядок меньше чем в РФ.
10 резюме говорите? А 100 резюме без отклика не хотите?
forums.whirlpool.net.au/thread/9rpm2vv9
Такие ребята и в Штатах есть, но это не означает, что работы нет.
Если вы прочитаете вышеупомянутый thread и все аналогичные на австралийских форумах, то увидете что всё обсуждение идёт в ключе: «ну что же вы хотели, это же IT, надо в другую сферу переходить или переежать».
Вы делаете какие-то выводы основываясь на форумах.
Естественно, что рынок в Австралии меньше, но это не означает, что в Штатах нет таких же "счастливчиков", которым отказывают на сотнях резюме и предлагают переходить в другую сферу или валить куда подальше.
ИТ-это вообще не профиль Австралии. Основа экономики — это, прежде всего, майнинг, затем «образование», туризм и животноводство. ИТ тупо аутсорсится. Можно конечно попробовать найти снег в пустыне, но зачем?
Так что ответ на ваш вопрос пожалуй будет таким: да серьёзное ИТ это очень часто именно США. Есть ещё пожалуй оазисы в Китае, Израиле, Индии, Германии, Англии, Швейцарии…. Но ожидать что приехав в какой-нибудь Буркина-Фасо как тестер или разработчик будешь автоматом нарасхват по меньшей мере наивно.
Пик пандемии коронавирусной инфекции COVID-19 станет для США вторым Перл-Харбором и вторым 11 сентября. Об этом, как сообщает The New York Times, заявил генеральный хирург США Джером Адамс.
И 90% в РФ.
В процессе рефакторинга написал декоратор для репозитория валют, который кэширует результаты.
Это не рефакторинг а добавление новой фичи. Рефакторинг — это изменение структуры кода без изменения функциональности.
Кэширование с нормальной инвалидацией — это не изменение функциональности. Скорость работы — это не функциональные требования.
Да, мне надо было скопипастить из википедии:
"Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения "
Обычно в книжках по рефакторингу я видел "extract method" а не "introduce cache".
Кэширование с нормальной инвалидацией не затрагивает внешнего поведения.
Обычно при кешировании время повторного запроса тех же данных меньше, соответственно, внешний наблюдатель с секундомером это может заметить. Я бы назвал это изменением поведения (причем намеренным).
Я не помню, чтобы кто-то из авторов книжек называл рефакторингом введения кеша. Так же стоит учитывать что оно находится в связи со словом factoring — декомпозиция, разбиение на кусочки.
Такое прочтение слова refactoring имеет ценность, так как рекомендуют отделять реструктуризацию кода от значимых изменений.
Возможно в разных прочтениях слова таится не понимание между pnovikov и marvin255 — если это так, то с точки зрения первого необходимость рефакторинга означает плохой факторинг кода, а с точки зрения второго, нет, так как рефакторинг это просто любое изменение кроме изменения связанного с функциональными требованиями. Хорошая декомпозиция (факторинг) на репозитории позволила просто добавить кеш.
Репозитории и прочие известные паттерны (примененные к месту), скорее наоборот, идут против job-security driven development, уменьшают порог входа других разработчиков. И да, это нормально писать так, закладываясь, что потом придётся переписывать-дописывать. А "цель — выкинуть" это, скорее про прототип, а не MVP.
Знаете, по заветам Ильича: «формально правильно, а по существу — издевательство».
Я ж специально уточнил "примененное к месту"
Там, где имеет, уменьшает порог входа.
Статья же о том, что шаблоны зачастую тыкаются бездумно, без малейшей попытки подумать башкой, но при этом повышают применяющему чувство собственной важности.
С мнением вроде "Но объясните какого черта вы херачите эти репозитории без конца и края? Встраивание их друг в друга, делаете обёртки репозиториев над репозиториями, посыпаете это всё тоннами DTO для того чтобы просто передать базе данных свой проклятый «SELECT TOP 1 FROM… WHERE Id = 10»" я согласен лишь частично. В части обёртки репозиториев на репозиториями, если речь не о случайном совпадении имён какой-то библиотеки и собственных абстракций.
А так, я из тех, кто по умолчанию делает репозитории при работе с хранилищами данных, инжектит их с помощью IoC/DI-контейнеров в сервисы, которые наружу отдают DTO, которые используются только в контроллерах. И считаю это применением к месте. Будет внутри репозитория прямой вызов SELECT TOP 1 FROM… WHERE Id = 10 или обёртка над репозиторием какойто билиотеки, или над ActiveRecord — деталь реализации, не интересная для пользователей этого CRUD-сервиса. Не всегда получается обходиться без протечки абстракций, но к этому надо стремиться пока овчинка стоит выделки.
Есть три варианта.
1) нужно отрефакторить, но невозможно и все терпят узкое место.
2) нужно отрефакторить и это возможно, отлично.
3) рефакторинг не нужен, т.к. код выкинули.
Если вы не закладываетесь на вариант два, значит вы неявно закладываетесь на вариант один. Это намного хуже. Конечно мы не рассматриваем простые системы, которые сначала без изменений работают десять лет, а потом выкидываются, заменяясь новыми технологиями.
Я не считаю, что иок (по крайней мере в том виде сервислокаторов, как он сделать в популярных языках) это благо. Инверсия зависимостей — нужна, а вот DI контейнеры которые предлагают "решение" вместо ошибки компиляции вывалить "тип не зарегистрирован" или "не найдет конструктор, который принимает (Foo, Bar, Baz, Baz2, FooBar, Blah, BukBuk)". Бррр.
Способ конструировать его во время компиляции существует — называется TF энкодинг, и с ним достаточно удобно указывать зависимости. Но без нормальной системы типов (как минимум нужны HKT) удобно не получится.
Ну, я не писал такое на тайпскрипте. Вообще, там сравнительно мощная система типов, мощнее жабовской и сишарпной наверняка. Но там мне кажется не там распространена практика больших развесистых зависимостей в целом. Но я не фронтендер, могу ошибаться. А бек мы на тс не пишем.
По крайней мере, библиотеки сложных типов к TS люди уже начали делать, так что не везде надо делать всё самому.
Теперь вместе с arttom я веду подкаст «Мы обречены». Там все как в статьях — максимально напрямую о разработке, индустрии, бабле, собесах. Первый выпуск вотНо ведь подкаст это в первую очередь звук, т.е.: Apple Podcasts/Google Podcasts/Spotify и т.п.
Будет?
Сейчас лучше оставить в покое социопатию и литераторство, философские рассуждения, и написать любым знакомым эйчарам (незнакомым тоже). Потому что они 100% знают, что КСВ длится годами и не факт что заканчивается в +, поэтому прямо сейчас сильно рискуют с таким кандидатом. Нужно смотреть их глазами на ситуацию.
А потом, с успокоенной деньгами семьей, будет время заняться собой.
Часть статьи про то, какой автор известный и его публичные выяснения отношений с HR мне не понравилась.
А вот часть про архитектуру началась хорошо, но создалось впечатление, что автор джун: "я умнее, вы все лохи, щас напишу" *клац клац клац* "у меня крутая система где всё четко разделено, воу" (без подробностей) *npm start* "Ой ничо не работает. Ой всё плохо, перепишу как хотят злые сеньоры".
Не, я понимаю что это вообще не главное, главное было показать страдания и рассказать о подкасте, но техническую часть можно было бы и расширить.
Посмотрите на статьи автора, первую я еще по неопытности прочитал, вторую половину тоже, ну а дальше фраза "статья от 'короля' разработки" просто заставляет либо прокрутить к комментам, либо закрыть немедленно.
Кризис девальвирует все, и сеньор будет вынужден конкурировать за места мидлов, и при этом улыбаться.
Ну и даже если судья знаком с прыжками в длину на газоне, то он может не всегда адекватно оценить специалиста по прыжкам в сторону или назад на асфальте.
Если речь идёт именно о senior'e, то всегда есть крупные организации в которые стабильно нанимают на высокие позиции даже во время карантина. Но у некоторых возникает проблема, что «гадкие эйчары взяли мидла вместо меня» =)
Я провёл немало технических собеседований и нередко люди с претензией на senior позицию не могут даже простые вещи написать. А на senior претендуют потому что «в своей прошлой организации я делал кучу разных дел и был очень полезен».
Не могу разделить тревоги автора — эйчерары все равно довольно часто пишут или звонят, хотя работу не ищу.
А если как техлидов и т. п.? Я вот слабо представляю как лидить команду из, например, 2 фронтов, 2 бэков, 2 qa и девопса, если не обладать хотя бы миддловыми хардскилами в каждой области.
а те кто при этом успевают следить за рынком еще в 10 раз меньше.Чтобы поскорее от вас убежать? Зачем за рынком то следить?
Зависит от проекта, но в большинстве случаев синергетический эффект от знаний в смежных областях перекрывает преимущества от специализации как бык овцу.
синергетический эффект от знаний в смежных областях перекрывает преимущества от специализации как бык овцу.
Угу, осталось только в этом хрюшу корпоративную с 3 извилинами, ПМС и вахтеризмом головного мозга убедить что баззворды из резюме не обязаны 100% соответствовать баззвордам в тексте вакансии.
В чём проблема с fullstack-ами? То, что кандидат не может без google-а как следует сверстать на grid-ах layout? Пффф, тоже мне проблема. В том что человек не может с первого раза воткнуть правильный index в СУБД? Ой бедааа. Покажем, 5 сек, какие проблемы.
Если у человека голова хорошо работает, он достаточно дотошный, у него широкий кругозор, он легко придумывает и реализует нетривиальные неочевидные решения… Ну это ли не сказка? А то, что он там не трогал какой-нибудь React.js последние года 3, потому что переключился на scala Play, так это всё мелочи. За месяц всё вспомнит, что знал, чего не знал, тому научим.
Итого если команда фуллстеков чего-то делает, и так случайно вышло, что они все повернуты в одну сторону (или хотя бы большинство) — они эту сторону делают хорошо, а на другой — полнейшее «тушите свет», и потом надо звать профильных специалистов просто чтоб разгрести.
И дело тут не в лейауте на гридах. А в том, что берутся устаревшие технологии, потому что фуллстеки не особо в тренде (я сейчас и далее про плохой фронт буду, потому что это то, куда я потом прихожу разгребать) — как насчёт фронта на Polymer или Angular1.x, начатого уже после того, как и Polymer и первый ангуляр были не просто застрелены гуглом, но и сняты с техподдержки? Легко!
Берутся плохие практики, потому что фуллстекам некогда сильно глубоко вчитываться в документацию и раздумывать над архитектурой, у них там БД стынет и тому подобные вещи. Итого UI-код выглядит как одна большая куча всего, и даже если фреймворк навязывает компонентный подход — не факт, что это должным образом было принято во внимание. Кнопочка, сама лезущая куда-то делать fetch()? А чё бы и нет! Портянка css, размер которой пошел уже на десятки килобайт, половина содержимого — дубляж, а треть вообще не используется? Мелочи! Сотни случаев копипасты банальных компонент по проекту, потому что организовывать грамотное переиспользование с сохранением необходимой настройки — долго и не хочется? Да запросто! Возьмём альфа-релиз Bootstrap, нафигачим кода, и потом спустя год будем чесать репу, потому что над обновлениями никто не задумывался, в альфа-релизе многого нет, а теперь просто так обновить не выходит, потому что где-то как-то стили наезжают друг на друга и всё разваливается (помним про одну большую портянку стилей без начала и конца)? Не, ну мы ж не знали, что так выйдет!
А уж что там на беке творится, если команда фуллстекеров была в основном сильна во фронте — мне даже и воображать не хочется, кошмары на ночь будут.
При этом я нисколько не против, если фуллстекера нанимают для того, чтоб он 98% времени работал либо на фронте, либо на беке, а свою широту кругозора применял для того, чтоб читать код и быстрее находить общий язык с теми, кто работает на другой стороне. Но обычно нанимают как раз для того, что двух человек нанимать «чёт дорого», наймем-ка одного, который нам сделает свалку из фронта или из бека.
Практически все «обычные» фуллстеки (необычных я тоже видел, но они как единороги по распространенности) могут либо хорошо в бек и плохо во фронт, либо хорошо во фронт, и плохо в бек
Дык в чём проблема? Хотите сильного спеца в конкретной области? Скажем архитектора в области фронтенда — ищите или чистого фронта или фулстека с уклоном во фронт. Хотите бакенд джедая — наоборот. Хотите сразу и там и там джедая? Ну "хотите" дальше.
Более того, всё давно идёт в сторону того, чтобы бакенд был простым, а фронт сложным. Далеко не каждый сервис это high-load. А crud-ы писать сильно много ума не надо. Большинству web-проектов даже транзакции не нужны.
а на другой — полнейшее «тушите свет», и потом надо звать профильных специалистов просто чтоб разгрести.
Ну вот я не считаю, что на backend-части пишу "туши свет". В транзакции умею, в миграции умею, сам dockerfile грамотно напишу, модели нарисую, валидацию прикручу, накрудошлёпю сколько надо. Надо — воткну и graphQL. Будет нужно — полезу в шардирование. При том, что бакенд уже давно почти не трогаю, основной упор во frontend. Сильно выпадаю из вашей статистики? Ну ок, у меня нет опыта анализа производительности SQL-запросов, только читал про это, в деле не применял. Мало опыта в написании сложных SQL портянок с кучей хитрых join-ов и вложенных select-ов. Всё — беда? В утиль?
Берутся плохие практики, потому что фуллстекам некогда сильно глубоко вчитываться в документацию и раздумывать над архитектурой, у них там БД стынет и тому подобные вещи.
Come on!? О чём мы говорим? На проекте нет вообще ни 1-го чистого опытного frontend-а и туда отправили первого попавшегося фулстека писать архитектуру? Получилось плохо? Ну а что вы хотели. Это ж просто глупо. Если у человека этот skill прокачан слабо, то ему можно доверить архитектуру нового проекта только если проект не важный. Но это не проблема человека. Это проблема конторы которая не умеет распоряжаться своими кадрами. Fullstack как явление тут не причём.
Более того, всё давно идёт в сторону того, чтобы бакенд был простым, а фронт сложным.
Что именно «всё»? Если вы работаете там, где достаточно простого бека — это не значит, что к этому идёт «всё». Далеко не каждый сервис хайлоад, но это не означает, что хайлоад вдруг перестанет быть хайлоадом, потому что на ваш взгляд сейчас «всё» идёт к простоте. А есть еще сферы, где код реально сложный. Машинное зрение не станет проще от того, что «всё идёт в сторону того, чтоб бэкэнд был простым».
Ну вот я не считаю, что на backend-части пишу «туши свет».
И давно вы писали что-то нетривиальное на бэке, что не начинается и не заканчивается на БД и крудах? БД поднять и круды нафигачить и я смогу, да, на какой-нибудь ноде. При том, что я не то, чтоб большой спец в ноде и этом всём — просто это настолько не rocket science, что сильно обломаться человеку с нормальным объемом опыта тут просто негде. От силы протормозить немного, читая гугл. От силы будет немасштабируемо в определенных точках (но это может долго прокатывать, потому что не везде хайлоад, как вы правильно заметили). Но работать как-то будет. Собственно, как и работает фронт у людей, сильных в беке. «Как-то». Потом дело доходит до серьезных изменений, скажем, рестайлинга на фронте и шардирования на беке, и всё встаёт колом, потому что раньше об этом никто не задумывался и не предусмотрел (если вы сможете так сразу в шардирование, чтоб без проблем и переписывания старого — здорово, а вот я например в себе настолько не уверен, впрочем, я на фуллстека и не претендую).
Но это не значит, что задач гораздо большей сложности на беке не существует.
Come on!? О чём мы говорим? На проекте нет вообще ни 1-го чистого опытного frontend-а и туда отправили первого попавшегося фулстека писать архитектуру?
Почему «первого попавшегося»? Он может быть крутым фуллстеком с медалями. Вот только сильным в беке и слабым в фронте. Сильно лучше от этого не будет, код будет более-менее организован, но в частностях скорее всего будет всё плохо.
А чистых спецов в таких ситуациях может и не быть, да, потому что повальный найм фуллстекеров идёт от (часто мнимой) экономии денег.
Если вы работаете там, где достаточно простого бека — это не значит, что к этому идёт «всё»
Не-не, у нас как раз хайлоад. Я туда не суюсь. Только робко любопытствую. Но это не мешает мне признать, что high-load-а очень мало. А вот сложного фронтенда с каждым днём всё больше и больше.
А есть еще сферы, где код реально сложный
У нас как раз сложный код на беке. Scala, FP, high-load и пр. Но это не мешает мне признать, что это большое исключение.
Машинное зрение не станет проще от того, что «всё идёт в сторону того, чтоб бэкэнд был простым».
Это конечно спор терминологии, но я бы не стал относить машинное зрение к backend-у. Эта технология не про server-а. Даже не знаю куда её лучше отнести.
БД поднять и круды нафигачить и я смогу, да, на какой-нибудь ноде.
В подавляющем большинстве проектов больше и не надо. Бинго!
А чистых спецов в таких ситуациях может и не быть, да, потому что повальный найм фуллстекеров идёт от (часто мнимой) экономии денег.
Тут мне сложно спорить. Т.к. на руках статистики нет. Скажу лишь что мой опыт противоположный, в тех конторах где мне недавно доволилось работать, ищут как раз либо backend, либо frontend специалистов.
В любом случае, возвращаясь к сути спора, то что где-то кто-то ставит на позицию архитектора человека, который в это не умеет, нисколько не умаляет того, что опытные fullstack разработчики могут быть очень полезными.
Я бы ещё поспорил о том, что вообще техн. стэк далеко не главное, и можно взять хоть C++-ика, но это пожалуй лучше оставить для будущих холиваров.
Я собеседую регулярно народ. Обычно лет по 7-10 опыта. С трудом решают элементарные задачи и отвечают на элементарные вопросы. Не понимают основ того, на чём пишут. Тут волей не волей начинаешь ценить действительно ценные навыки, а не "писал ли ты на React последние 3 года". Мы вообще про React и пр. сопутствующие вопросы спрашиваем уже в самом конце.
Это конечно спор терминологии, но я бы не стал относить машинное зрение к backend-у. Эта технология не про server-а. Даже не знаю куда её лучше отнести.
Тут можно спорить, но всё, что не является непосредственно взаимодействующим с пользователем кодом — это «бек». Понятно, что ML и прочий датасотонизм — это штука, достойная своей собственной категории, но всё равно это всё бек: этому тоже надо скармливать вполне себе обычные причёсанные данные из всяких баз и прочего.
В любом случае, возвращаясь к сути спора, то что где-то кто-то ставит на позицию архитектора человека, который в это не умеет, нисколько не умаляет того, что опытные fullstack разработчики могут быть очень полезными.
Ну я с этим и не спорил. Я спорил с тем, что фуллстеков можно прям так брать и писать их руками весь проект, с этим часто случаются проблемы. А что они полезные — конечно полезные.
Тут волей не волей начинаешь ценить действительно ценные навыки, а не «писал ли ты на React последние 3 года». Мы вообще про React и пр. сопутствующие вопросы спрашиваем уже в самом конце.
Это здорово. Но где-то добрая треть контор (а может и больше, может мне просто неадекват удаётся раньше отсекать) всё равно с кандидатами беседует в ключе «у нас сложно, нам надо чтоб 3 года опыта на реакте, и ни днем меньше». Архитектура? Оптимизация рендера и презентации? Компонентная организация? Не, это всё фигня — главное чтоб на реакте много фигачил и хуки смог на техсобеседовании изобразить.
Недавно тоже пополнил ряды ищущих работу, так что еще только начинаю осознавать происходящее, так как в общем-то давно не занимался поисками. В принципе я считаю, что мне еще повезло, потому что сейчас еще все более менее благополучно с поисками работы, а найдя новую работу сейчас я буду более уверен в том, что не потеряю ее в самый пик кризиса. Эту уверенность мне придает тот факт, что если компания прямо сейчас ищет специалиста, то у нее явно еще много ресурсов осталось.
А если начнутся уже массовые увольнения, то конкуренция будет куда больше, чем сейчас.
Впрочем, как мне кажется, автор вот вообще не пытался изучать рынок, не пытался даже делать никаких прикидок, а просто начал наобум рассылать резюме. Но если так подумать, сейчас серьезно просела сфера услуг и в особенности туризм, причем если сфера услуг еще в каком-то виде сможет достаточно быстро восстановится, то насчет туризма не уверен.
Нет никаких свидетельств, что получится открыть границы быстро и что у людей вообще будет много свободных денег, чтобы путешествовать.
В результате наверное весь ИТ, который связан с этими сферами, тоже будет серьезно трясти. Но с другой стороны сейчас точно увеличатся вложения в средства для обеспечения удаленной работы, точно увеличатся вложения в сетевую инфраструктуру. И точно огромные деньги будут вливаться в медицину и биотехнологии, несмотря ни на что.
Но для начала автору я бы пожелал вырваться из пут негативного мышления, оно то конечно весело и драйвово как художественный стиль, но прямо сейчас может завести в такие места, куда свет никогда не заглядывает.
Какая, блин, реклама.
Количество неологизмов зашкаливает, если код такой же то это мрак.
Что касается тестового задания:
- Это чисто русский подход, сломать и построить заново
- Я знаю как лучше. Вопрос: для кого лучше? Для Вас?
- Хочу посмотреть на того парня кто будет работать с этим «лучше» после Вас. (Подсказка: сломать и построить заново, я знаю как лучше
Удачи
Я знаю как лучше. Вопрос: для кого лучше? Для Вас?
Конечно для меня. Я же тестовое делаю, что бы показать, какой я разработчик
Очень знакомо, тоже как-то прошлепал сроки ТЗ, когда решил сделать его в соответствии с лучшими практиками. Постепенно из простого веб-приложения вырастал какой-то монстр, который при своих чрезмерно больших объемах был крайне хрупок и неуклюж: добавил новое свойство — не забудь поддержать его на всех уровнях абстракций, тем паче если для Entity наделано несколько вариантов его отображения/редактирования, не забудь про все DTO и ViewModel-ы, добавь во все автомапперы, валидацию и там и сям — любое незначительное изменение сопровождается его поддержкой на всех уровнях, в процессе которой фокус внимания тонет в деталях реализации.
Модные паттерны и бест-практики классно смотрятся в простых примерах на страницах документации, а в реальных проектах частенько подтыкаются костылями, отчасти потому, что иначе либо никак, либо добавлять еще один уровень абстракции, а отчасти и потому, что некоторые коллеги используют их для галочки и подкрепления своей важности, а не потому что долго размышляли об их значении и смысле, и пришли к заключению, что в данном конкретном проекте они действительно нужны. Как итог, во многих небольших проектах, напичканных ненужными абстракциями и паттернами, смысл которых многим сотрудникам до конца не ясен, большая часть работы программиста, вместо того, чтобы стать благодаря им более эффективной, превращается в борьбу с этими самыми абстракциями. Но все молча продолжают лепить монстра, и никто не выскажет сомнения, чтобы не поставить под сомнение свою компетентность и свой статус. К тому же это укрепляет позиции разработчика на занимаемой должности – чем больше паттернов напичкано в проекте, тем сложнее будет найти ему замену.
В конце дня иногда пробивается ощущение, что работа идет медленно, что уже который год не растешь как профессионал, а просто освоился со всем этим хламом и сам активно его продвигаешь, особо не вникая в суть, а за свое молчаливое согласие получаешь хорошую з/п.
Правильное решение любого HR или тим-лида, который собеседует такого нереализованного страдальца — это отказ. Ибо он со своим «уникальным» подходом и проект попортит и ребятам мораль уронит.
Не переживайте так. Если в РФ начнется тоже самое, что сейчас происходит на Украине, то очень быстро под нож пойдут некомпетентные и «тяжелые». Так что это ваш личный выбор — остаться на работе или пойти на мороз.
То же самое хотел сказать про отказ. Неясно, какой он программист (хотя "король разработки" в профиле как бы намекает ;-)), а что людям с ним работать будет тяжело – заметно сразу.
Если в РФ начнется тоже самое, что сейчас происходит на Украине, то очень быстро под нож пойдут некомпетентные и «тяжелые».Раскажите что на Украине происходит, а то звучит уж очень нуарно.
Ну а «король разработки» в профиле это стёб/самоирония/троллинг (как мне кажется).
Любой опытный синьер проходил через это, через увольнение, через поиск, ситуации за годы работы были разные. Но большинство из них всегда держало себя в руках и не бежало ныть на хабр и блоги.
Качайся, ходи на собесы, понимай в чем проблема, где лажаешь, записывай все на листочке и после собеса не на хабр статьи писать, а за код и пытаться понять где ошибся, где не то сказал.
Если ты не живущий от зп до зп и имеешь голову на плечах, явно откладывал подушки на черный день, чего там совсем мало? Ну тогда хотелки поумерь. Окажись от икорки и лобстеров с омарами, кашка овсяная и 2 яблока теперь твой обед и ужин. Если есть ипотеки и кредиты — пиши в банк, проси отсрочки.
Как с английским? Ты уже удаленный кажется. Бомбардируй удаленных западных коллег, просись к ним. Если английский плохой — тоже вопрос — почему раньше не качал его, когда работал.
Вообще ситуация такая — это отличный трамплин, чтобы подумать и осознать что ты делаешь не так, где надо изменить свою жизнь и отличный способ чему-то научиться. Я не говорю, что чтобы что-то понять надо именно ошибаться и быть в таких ситуациях нет. Ибо умный и способный человек и без пинка под зад умеет правильно действовать. Но порой для некоторых силовой выход из зоны комфорта — способ стать лучше.
Уж прости, за строгость, с которой я написал. Просто выморозило это нытье, будто бы ты 1 в такой ситуации оказывался. Да большинство в таких было, но на хабр никто не бежал. Просто возьми себя в руки, сгоняй в парк, развейся, ты явно загнался по этой теме. Тебе надо расслабиться и отпустить ситуацию.
В ситуации "через месяц должен был стать лидом" разработчика могут уволить потому что решили, что есть лучший кандидат на лида, а отказ в обещанном повышении может быть плодородной почвой для конфиктов в том числе с новым лидом. Могут решить разрулить конфликт интересов, а могут решить разрубить его.
Да большинство в таких было, но на хабр никто не бежал
Мне кажется, общие проблемы имеет смысл проговаривать и обсуждать
Вам надо к психологу походить.
Если вы не вводите нас в заблуждение относительно вашего профессионального уровня, то вам необходимо брать на себя задачи сильно круче, чем тимлидство или просто разработка всякой фигни. Например, лидство в отделе с 20-40 разработчиками, а то и свой бизнес на какой-нибудь трудном рынке.
Иногда бывают позиции CTO даже без опыта собственно CTO. Реальный кейс, который мне лично предложили этой весной: 3 месяца испыталка в качестве лида одной команды, в случае успешного прохождения — CTO.
нужен вообще-то стартовый капитал
Множество компаний практикуют «внутренний стартапинг». Это когда тебе все дают, лишь бы деньги приносил.
Да и автор, судя по тектсу, не дурак, стартовый капитал имеет. Чтобы сделать MVP нужно два спринта, а два спринта — относительно не дорого. И даже после первого спринта все равно есть что показать. И даже до всяких спринтов ведь как-то удалось зажечь команду идеей.
Если вы такой же умный, как производите впечатление, вам должно хватить.
пол года не можем MVP сделать
Ну, надо разбираться. То ли он у вас не Minimal, то ли не Viable. И правильно ли вы понимаете «сделать». Если вы пока не готовы сделать релиз — это одно и не страшно. Но если у вас продукта не появилось — это другое.
что бы договорится с собой
Надо не с собой договариваться, а брать на себя обязательства перед другими людьми.
без малейших изменений
В плане реализации, или в смысле что фичи перепридумываете? Если реализацию — это даже хорошо. До тех пор, пока вы все-таки делаете коммит с работающей задачей и остается время его протестировать и поправить замечания. А если фичу перепридумываете — единственная причина — она у вас не достаточно провалидирована. Фичи берутся не из головы, а подтверждаются рынком. Метода называется «оторви жопу от стула и поговори с клиентом». Прежде, чем взять фичу в разработку, вы должны быть в ней достаточно уверены. И вот если вы знаете, что фича кому-то нужна и за нее готовы заплатит и все равно ее не делаете — у вас проблема.
Надо не с собой договариваться, а брать на себя обязательства перед другими людьми.
Мне этих обязательств на работе хватает. Это же пет проект. И я не очень то верю в то, что можно вот так сесть, и статистически высчитать формулу успешного проекта со всеми этими потребностями рынка и т.д. Так поступает большой бизнес, но когда сам делаешь продукт, который нужен тебе, и делаешь его для таких как ты — вместо рынка и потребностей есть ты сам.
Поэтому мы постоянно придумываем новые фичи, и выбрасываем старые
Нет, конечно. Есть метода, по ней все делается. Смысл в том, что вы вначале находите клиента, а уже для этого клиента делаете. Формулы там будут, конечно, но они очень простые. Там целая пирамида валидации. Вначале вы валидируете идею в разговоре с коллегами, потом выходите на потенциальных клиентов, с ними два вида интервью: проблемное и глубинное, и только потом уже валидация гипотезы масштабирования — идете в сеть или обзваниваете массу людей. В этом деле всякие там корреляции, критерии стьюдента не принципиальны — и так все понятно. Если вам несколько человек говорят одно и то же и готовы платить за решение проблемы, значит ее стоит попробовать решить.
Выглядит так, что проще запилить прототип, найти инвесторов, запилить MVP, зарелизиться и дать реальному рінку провалидировать гипотезу.
Ну, надо разбираться. То ли он у вас не Minimal, то ли не Viable.
За две недели сделать Minimal Viable Core Bank System (АБС) разве реально?
За две недели сделать Minimal Viable Core Bank System (АБС) разве реально?
Не знаю, может и реально. Зависит от много всего.
Просто вы себя заранее в ловушку загоняете терминологией. Может, вашему клиенту этот самый АБС даром не нужен, а ему нужно что-то другое. Проблемы начинаются, когда вы подтвердили ценность АБС, поняли что нужно делать только так и никак иначе и у вас не хватает денег.
"Нашему" клиенту нужна система для ведения банковских счетов всех видов, удовлетворяющая требованиям, если говорить про Россию, ЦБ РФ. Если умеет считать всё правильно, слать отчёты в ЦБ РФ, участвовать в платежных системах, межбанковских операциях, клирингах и прочем (уже довольно давно в этой системе не вращаюсь, что-то мог обязательное опустить), предоставляет API для интеграций с CRM, пользовательскими приложениями и т. п. — это Viable, чего-то одного нет — not Viable
Кто ваш клиент?
Банки. Одна из самых зарегулированных отраслей в мире, любой Viable продукт для них должен отвечать всем требованиям всех регуляторов.
Для того, чтобы показать клиенту и получить фидбек не обязательно соблюдать требования всех регуляторов. В релиз, конечно, с таким не уйти, но цель MVP — не улететь в бой, а проверить ключевую гипотезу.
Какая ключевая гипотеза вашего продукта?
У нас разные понимания MVP, продукт для "показать потрогать и получить фидбек" в моём мире называется прототип. С ним, прежде всего, бегаешь по потенциальным пользователям/клиентам/спонсорам/инвесторам, проверяешь нужно ли вообще что-то подобное хоть кому-то.
Если оказалось, что нужно, то тогда пилишь MVP, чтобы уже не просто показать или дать потрогать, а запустить реальных пользователей, вплоть до релиза в паблике. Может даже продукт ещё не будет приносить денег до следующей стадии, а наоборот каждое внедрение будет отнимать много ресурсов, но это уже будет опытная экплуатация, если сумеешь кого-то заинтересовать.
Ключевая гипотеза была "малые банки готовы платить меньше за более качественное ядро всех своих систем". К сожалению, с прототипом её проверить не получилось, а на MVP ресурсов не нашлось. Как оказалось постфактум, оно и к лучшему было: через относительно короткое время ЦБ РФ начал чистку банковской системы. И даже стали понятны некоторые намёки со стороны малых банков, почему их не интересует длительный горизонт планирования.
У нас разные понимания MVP, продукт для «показать потрогать и получить фидбек» в моём мире называется прототип.
Да. В каком-то смысле, MVP — это прототип для бизнес-идеи.
С ним, прежде всего, бегаешь по потенциальным пользователям/клиентам/спонсорам/инвесторам, проверяешь нужно ли вообще что-то подобное хоть кому-то.
Что-то вы не по тем бегаете. По-идее, если вы сделали MVP и подтвердили ценность, то все инвесторы будут рады вам дать денег — новые работающие идеи большая редкость. А если опровергли, значит расслабьтесь — это не нужно. Начинайте придумывать новую идею.
малые банки готовы платить меньше за более качественное ядро всех своих систем
Какие именно качества ядра проверялись?
Потому что вы не адекватны.
«Он адекватный» == «Он такой же, как я. Я всегда могу предсказать, что он сделает, подумает и скажет»
Нет уж, извините
«Он адекватный» == «Он действует исходя из объективных факторов и не додумывает ничего сам» == «Я ему доверяю, потому что он справедлив и рассудит по-существу».
«Я ему доверяю, потому что он справедлив и рассудит по-существу» => «Я ему доверяю, потому что он справедлив и рассудит по-существу с моей точки зрения, потому что только я знаю, какое существо адекватное».
Ну и кому тут надо к психологу по вопросу завышенного самомнения?
Соответственно и к вам обращаюсь с призывом написать несколько крепких технических статей, которые более детально отражали бы то, что в ваших статьях обычно называется чем то типа «правильного подхода».
Возможно это даст многим людям мотивацию писать лучше и вы не будете выгорать за три месяца на продуктах, и тем более вас будут принимать с распростертыми объятиями именно за хороший код.
Технические:
VDOM — 8 плюсов/7.5к просмотров
SQL в EF — 22 плюса/12.6к просмотров.
(намеренно не упоминаю статьи про свой фреймворк)
Развлекательные:
Сатира про JavaScript — 84 плюса/48.5к просмотров.
Типажи программистов — 216 плюсов/167к просмотров.
Разница, как вы можете видеть, РОВНО НА ПОРЯДОК. Ещё есть вопросы почему люди не пишут технические статьи?
Еще помни, что всех денег не заработать и к зарплатным ожиданиям нужно подходить осторожно (даже если работодатель прямо таки кидает в тебя пачки денег).
Как там про студента, который решил подготовиться к экзамену максимально возможным образом. Утром вырываясь из рук санитаров, он кричал что зовут его «лямбда Пи».
Если тебя не приперли к стенке кредиторы, то найди себе хобби (только не деструктивное), отправь всех говорящих про успех в жизни в далекое эротическое путешествие.
И еще обязательно каждые 3-5 лет меняй работу, вот прям так: Добил проект, получил премию и написал заявление об уходе (и прямо завтра дома сидишь — пока финансы или здоровье не закончатся).
Если есть возможность, то я иногда для таких тестовых делаю два, а то и три варианта:
- решение в лоб
- решение по "лучшим практикам"
- архитектурный оверинженеринг
Вариант «жрать захочешь — сделаешь» не рассматриваем, ибо на эту тему уже вся статья.
Филип, ты просто хреновый разраб и нытик.
Ты уже тысячу раз мог, вместо того что бы ставить f# в теги и ныть про несправедливость на хабре, просто выучить f# или окамл и найти себе удаленную работу.
Подобных проблем нет. За это время пришло куча предложений пообщаться, порядка 20-30. Интересных для меня из них штук 5-10 было. Собеседования прохожу вяло (в плане частоты). Получил 2 оффера и 1 отказ пока. Имеются в запасе еще пара собесов забитых. В принципе все как и год назад. Не заметил каких то проблем с кол-вом вакансий… а вот с фактическим устройством — да) Один оффер очень заинтересовал, вроде пошло дело. Но изза карантина «сори парень, физически не можем сейчас устроить, давай пообщаемся после карантина если ты не найдешь до этого работу».
ЗЫ Бэкенд, 2,5 года опыта.
Между тем…
Простых пахарей кода как искали, так и сейчас ищут, звездам сложно, да, на 20 пахарей нужны одна звезда.
Так же возможны завышенные финансовые ожидания, которые тоже сужают возможности поиска.
И зарабатывайте миллиарды, зная ТОЧНО БУДУЩЕЕ
У меня есть такой код. Если нужно, дам бесплатно. Пишите.
vk.com/id526958216
В кризис я потерял работу и теперь боюсь писать умный код, чтобы не распугать последние вакансии