Comments 183
Даже не узнал сходу статью от короля разработки, потому что нет фирменной картинки с кодом. Начал читать — что-то подозрительно, пришлось проверить автора...
Когда у тебя высокий грейд, ты можешь не писать код.
А можешь писать, да такой, который целые индустрии переворачивает. Например, Торвальдс не только ядро для ОС написал, но и git. Что важнее?
Важнее иметь громкое имя, например. Тогда и кривая поделка (git) задавит более продуманного конкурента (hg).
Я думал как ответить на это.
- Проигнорировать.
- Сказать, что hg — кривая поделка, а гит — хорош.
- Пожурить за обесценивание.
- Сказать, что люди, выбиравшие межу git и hg, сказали своё слово.
- Рассказать про взрыв мозга от branch model у hg.
- Запостить этот список "как есть".
Последний раз, когда я ребейзил свой фичебранч относительно убежавшего вперёд master'а, бранчи были на месте и ими можно было пользоваться.
… С другой строны, вас кто-то заставляет использовать git для своих проектов? Вы автор — какую систему хотите, такую и используйте.
Ну, вот у вас в голове какие-то альтернативные бранчи, которе в мою голову просто не помещаются. Меня вполне устраивает модель гита, она базируется на простых примитивах и весьма универсальна.
выбирайте любой: https://www.mercurial-scm.org/wiki/MercurialHosting
Зачем вам "популярность" сервиса, если вы там свой код храните?
А как выглядит тогда rebase на более свежий "родительский" бранч?
В меркуриале этим маразмом не страдают и используют мерж. Ну а ребейз — это просто переписывание истории, меняешь как хочешь.
Я хочу менять не как попало, а так, чтобы оно доставило наименьший wtf при мерже.
Мерж при коммите возможен, если нет конфликтов. А они могут возникать, и чем крупнее проект, тем более нежелательны лишние мержи. Идеально, каждая фича делается как набор нескольких коммитов по-делу (с осмысленными описаниями), без рандомных мержей и фиксов где попало чего попало.
В mercurial не страдают, вас это устраивает и вы используете mercurial. Те, кто хочет иметь более читаемую историю кода (не личных заслуг отдельных бранчей) используют git.
Все счастливы. В чём ваша претензия к git'у? Вас кто-то заставляет использовать git? В соседней конторе зарплата на +800 евро больше, но дресс-код. Я к ним не хочу. Что вас держит в компании, которая заставляет вас использовать git?
Git сейчас практически стандарт де-факто. В подавляющем количестве вакансий или git, или вообще VCS нет.Крайне-крайне редко SVN встречается ещё.
Для переписывания истории там не один инструмент (rebase, histedit, mq, evolve), но, в отличие от git (а может и вообще всех остальных) позволяет делать это безопасно (evolve). Более того, существуют даже официально переписываемые публично ветки (topic). Попробуйте переписать публичную ветку в git, когда вы в ней не один. А в меркуриал это не приносит проблем.
Ну а я страдаю переписыванием истории, по мне так понятней, т.к. меньше мусора. Что за плагин и насколько сложно им пользоваться?
Ага, осталось ещё CI уговорить быстро проходить. У меня много раз уже было — пишешь фичу, всё хорошо. Пока CI пройдёт, в мастере уже десяток коммитов и всё устарело. Сделал rebase, попушил, должно мержиться хорошо, но тут CI снова начал всё проверять, пока проверяет, опять конфликты.
Девопс это же не только про CI/CD
На деле у вас где-то есть узкое и тормозное звено, которое вполне возможно даже не обязательно к прохождению, но всё так сложилось…
Я смотрю, вы большой эксперт с CI/CD. Возможно, вы хотите помочь? Проект довольно маленький, несколько десятков тысяч программистов, под сотню репозиториев, несколько тысяч компаний, сотни разных CI серверов.
Вот примерный обзор проблемы:
https://zuul.openstack.org/status
У гита был гитхаб, у меркуриала — не было (
Битбакет и сейчас по многим параметрам не дотягивает до гитхаба даже не современного. :(
навскидку: сразу встроенный CID, Trello, Jira
Удобство код-ревью, например. Что по функциональности типа треккера задач, то в битбакете даже зачатков нет, только глубокие интеграции с другими продуктами Atlassian
Вот сразу навскидку: при просмотре кода в "raw"-режиме используется хз какая кодировка, из-за чего вместо кириллицы кракозябры.
Жутко бесит.
На то они raw, какую положили, та и показывается, нет? Я, кажется, уже много лет не встречал проблем с кодировками кириллицы в принципе. Может если ссылку дадите конкретную, проще будет.
Я на 100% уверен, что у меня в PyCharm выставлена UTF-8 кодировка.
Код: https://bitbucket.org/mastergroosha/bitbucket-raw-encoding-fail/src/master/app.py
Открываем в RAW: https://bitbucket.org/mastergroosha/bitbucket-raw-encoding-fail/raw/5919ee46ba00cebc9a3026577724e157b114b6bc/app.py
Ну и чтобы не было сомнений.
Вот тот же репозиторий на GitHub (сверьте хэш коммита)
https://github.com/MasterGroosha/Bitbucket-Raw-Encoding-Fail/blob/master/app.py
Он же в RAW: https://raw.githubusercontent.com/MasterGroosha/Bitbucket-Raw-Encoding-Fail/master/app.py
Имею все основания полагать, что это косяк Bitbucket, а не мой.
sumanai Вы неправы, всегда UTF-8
Ага, Bitbucket возвращает "content-type: text/plain", в то время как GitHub возвращает "Content-Type: text/plain; charset=utf-8".
Но я всё ещё не уверен, что это именно косяк. У гитхаба нет никаких оснований думать, что там именно Utf-8, а не что-то ещё.
На обывательском уровне у меня есть предположение, что при выставленном charset=utf-8 "попаданий" в кодировку будет больше, чем без него.
Собственно, это было одной из причин ухода от битбакета, т.к. их мобильный интерфейс уж очень неказистый, а в RAW-режиме невозможно читать комментарии и текст на русском. Увы.
Не вижу никакой разницы между гитхабом и битбакетом — везде русский читается. Браузер Chrome Version 84.0.4147.105 (Official Build) (64-bit) on Ubuntu 20.04.1 LTS Что я делаю не так?
Любопытно. На текущей машине (Windows 10):
Firefox 80: кириллица не читается
Chrome Portable 85.0.4183.83: кириллица не читается
На виртуалке (Kubuntu 18.04.5) в Firefox 79 кириллица тоже не читается.
Вы в raw-режиме открываете?
Да, по чётным ссылкам кликаю.
В Firefox 79.0 (64-bit) кириллица на битбакете не читается, на гитхабе читается.
P.S. Очередное косвенное указание на причины по которым bitbucket и firefox проигрывают конкуренцию. Для обычных людей, включая обычных программистов, UX важнее строгого следования спецификациям и/или выбора какого-то разумного дефолтного варианта в условиях неопределенности, пускай и иногда он будет ошибочным
На Google Code был выбор между svn и mercurial, но Google Code сам помер…
Не хватает пункта Прибегнуть к аргументации "Сперва добейся!" (ну типа, а где твоя некривая поделка, которую используют миллионы)
:)
Что я со своей колокольни вижу:
— изменения истории нет. Джун залил гигабайты мусора в репу — теперь живём с этим
— множество голов веток? — да пожалуйста,
Чего от Hg не отнять, так это простоты и отказоустойчивости. Отстрелить себе ногу не получится (примеры выше — это скорее навешивание гири).
Исходя из этих причин, на его примере хорошо обучать новичков концепциям контроля версий, а потом уже подпускать к гиту, на котором можно и ногу себе отстрелить, и голову (git push --force master) и другие интересные части тела.
Продолжая аналогии, Hg — пила, Git — пилорама, которую нужно знать как свои три пальца.
Да всем. Те же ветки являются объектами первого класса, а не воображаемыми. Человеческая система команд. Кроссплатформенные хуками, не зависящие от установленных на клиенте рантаймов. Явный трекинг истории перемещений/копирования файлов, а не угадывание при чтении.
Изменение истории есть, но по умолчанию отключено. Пассаж про головы не понял.
а не угадывание при чтении
Угадывание происходит также при rebase/merge. И если не угадал, то есть шанс, что он молча вольет левые изменения не туда. Спасает git только то, что у такой ситуации малая вероятность (нужно чтобы файлы были похожи и место вливания похожи).
Достаточно хороший и удобный
Вот только хорошим и удобным оказался не git, а GitHub, что и определило выбор. И выбирали не гит, а GitHub. А далее и вовсе не выбирали, ибо считать выбором «везде требуют гит, потому выбираем гит» просто наивно.
Но что рандомное или убогое средство
Если сравнивать гит с другими по принципу «давать программисту как можно больше, а мешать как можно меньше», то гит выглядит как любительская поделка. Но ко всему можно привыкнуть. Любой инструмент можно освоить и не стрелять себе в ногу. Вот и гит там же. И то что альтернативы проще (в освоении, а не в фичах), удобнее и безопаснее — роли уже не играет, ведь «уже освоился и привык, зачем мне альтернатива»
Проще осваивать инструмент когда есть рядом коллеги или люди его использующие. То есть возвращаемся, есть классный инструмент с крутой документацией и есть гит который используют коллеги, знакомые и по которому +100500 туториалов. Кому то проще доку почитать, а кому то коллегу спросить
оно достаточно хорошее что бы стать популярным.Вы действительно считаете, что тулз, для работы с которым нужно читать тонны документации, спрашивать коллег или на форумах и при всем при этом все равно иметь урезанные возможности (пресловутое «нам это не нужно») — это хороший тулз?
Это объективное мнение или субъективноеПервое конечно. Продуманный инструмент всегда проще в освоении, чем тот, где нужно тщательно читать много документации. Как по вашему, насколько интуитивен отсоединенный комит? Насколько интуитивно то, что ваши комиты считают мусором?
Концепт подхода гита к веткам отличается от привычного. Имеет право на жизнь, почему ж нет. Но в остальном косяки вызывают недоумение.
То что они вызывают дело второе. А доку или мануал какой бы крутой тула не была — читать надо, ну или коллегу спросить. Вот гит выиграл по этим пунктам в силу разных причин. Может и хуже, но выиграл.
- не запишет за мной имя ветки (да да оно не нужно. я слышал много раз)
- не позволит мне откатить неудачный ребейс (если я не сделал бекап в виде git push)
- не отследит переименования файлов, и, как минимум, может не помочь, а как максимум — вообще намусорить левым кодом в мерж/ребейс
- не подскажет мне в рамках какой ветки был комит в истории файла
- обманывает меня в истории с --follow, потому что играет в угадайку
- система поиска в истории достаточно примитивна
Остальное можно списать на «будь внимательнее», но «делай бэкапы» я за решение не считаю
Причём это к теме нашей дискуссии?
На этом предлагаю закруглиться. Почему? Вместо ответа я лучше скопипастю цитату с того же хабра
Не хвататься за оголенные провода несложно.
Понять, почему на обычном рабочем месте изоляция на проводах отсутствует, гораздо сложнее.
Еще сложнее понять тех, кто продает все это как достоинства инструмента.
Примечательно, что самый популярный хук для гита — добавляющий имя ветки в сообщение коммита.
Не очень понимаю в чём проблема с откатом ребейза.
git reflog
git reset --hard
Или вы про что?
Согласен, однако, что это довольно неинтуитивно( и работает практически только сразу после ребейза )
Ну вот для меня есть две конкурирующие (а, скорее, конкурировашие) достаточно хорошие и универсальные технологии: git и mercurial(hg). Но у первой случился github, а у второй — нет. Сам лично выбрал hg, но потом перёшел на git, потому что все нтересующие меня проекты хостились на гитхабе, а использовать две аналогичные (по крайней мере для меня) СКВ или заморачиваться с плагинами какими-то, обеспечивающими какую-то совместимость, не понравилось.
вот я об этом выше и говорил, а мне начали доказывать что гит хуже)))Ну вы даете. Товарищ явно написал, что его переход на git был обоснован не личными качествами git, а потому что гитхаб.
Перемотайте в начала ветки и посмотрите с чего начался наш спор )))
Так он и есть хуже для меня идеологически и по удобству непосредственного использования. Лучше только в одном — практически все интересные мне проекты за последние годы, зависимости моих проектов, в которые я даже контрибьючу иногда, хостятся на гитхабе.
Когда у тебя высокий грейд, ты можешь не писать код.
Чтобы не опозориться? :)
И даже самого важного: тега F# нет!
(del)
Не очень уловил зачем эта статья здесь? Она повторяет мысли из старых статей, не дает никакой морали, только лишь одно горькое сожаление, и вообще, смотрится как нытье.
Хотя, в конечном счете, умение хорошо делегировать тоже важный навык для лида, по сути они этим и занимаются, у них на глубокие познание не остается времени, но они имеют много поверхностных и от того знают куда что передать.
Вижу две причины, по которой люди стремятся развиваться — это деньги и признание. Как только человек получает и то, и другое, то стимул идти вперёд уже сложнее и сложнее получить. Я восхищаюсь людьми, которые делают сложные и крутые вещи, это всегда отличный пример, к чему надо стремиться. Но, к сожалению, их не так много, большинство, впрочем как и я, хочет просто хорошо жить и ни в чем не нуждаться. Благодаря таким текстам лично мне становится определённо ясно, что надо постоянно развиваться и делать что-то полезное, то, что можно применить в жизни.
Будем творить!
Вижу две причины, по которой люди стремятся развиваться — это деньги и признание. Как только человек получает и то, и другое, то стимул идти вперёд уже сложнее и сложнее получить.
Есть люди, которые не могут не делать что-то — им просто интересно копаться и узнавать новое, а вдобавок это еще приятные побочные эффекты имеет.
> Он мечтает стать крутым дядькой.
Крутой дядька в это время мечтает с точностью до наоборот, да.
Обычно нормальные сеньёры выкупают дутых синьёров довольно быстро. Особенно если был опыт работы с синьёрами-индусами.
Его же прособеседовал кто-то, правильно?
Автор привел интересную аналогию с билетами на экзамене — выучил один, но побывал на 10 экзаменах и прошел.
Мне кажется, что вполне реально на Н-ое собеседование встретить человека, который абсолютно не разбирается в вопросе, и просто да-кает, и принимает соискателя.
А вот быстро въехать в предметку и кучу кода — это уже сложнее, а уж делать там потом какие-то рациональные предложения совсем не просто.
В общем, через месяца 3 уже все поймут, кого наняли.
Ну… Многие прогеры так говорят, презрительно смотря в сторону спецов по переходу на +$500. Но, по факту, что-то очень уж редко не закрывают прогерам ИС. Вылететь по некомпетентности это тоже лотерея, причём шанс остаться сильно выше 50%
В общем, через месяца 3 уже все поймут, кого наняли.
Все проще и банальней.
Кто стоит между рядовыми программистами, которые пишут код, и владельцами бизнеса, которые ничего не понимают в разработке? Чаще всего — тот самый сеньер/тим-лид.
И, внезапно может оказаться, что главная задача такого тим-лида — не писать божественный код, а объединять программистов и владельцев бизнеса. Быть промежуточным слоем, адаптером, который абстрактные и оторванные от реальности хотелки «бизнеса» приводит во что-то похожее на ТЗ для программистов.
В моей компании именно так. Тим-лид не является для меня образцом для подражания в техническом плане, но он выполняет свою роль, и если его не станет (и мне предложат занять его место) — я сразу уволюсь, потому что ну нахрен общаться с этими далекими от разработки людьми с деньгами. Проходили, нервы дороже.
– Наш Директор совершенно не разбирается в ИТ. Я не могу ему объяснить. И его указания всегда такие нелепые.
Инь Фу Во ответил:
– Это нормальный порядок вещей. Его забота – люди и деньги. Твоя забота – техника и программы. Вы разговариваете на разных языках.
Сисадмин согласился и спросил:
– Как нам изучить язык друг друга?
– Это почти невозможно, – сказал Учитель. – Для этого Директору пришлось бы несколько лет проработать сисадмином, но он не пожелает. Для этого тебе пришлось бы несколько лет проработать руководителем, но тебя не допустят.
– Как же понять друг друга тем, кто говорит на разных языках? – спросил Сисадмин.
Инь Фу Во ответил:
– Специально для этих целей создан промежуточный язык, доступный обоим. Имя ему – «ГОСТ-17799».
– Как просто! – воскликнул Сисадмин и ушёл просветлённый.
Т.е. ты берешь простое и заметное, а следы своей жизнедеятельности и легаси оставляешь другим, при это ходишь и сокрушаешся как можно было так запустить проект. Все ты любимчик, ты сделал кнопку которую отдел разработки вафлил полгода и главбух Марииванна тебя уже обожает, а что после тебя три мидла неделю убирать должны, так у кого до этого рефакторинга когда руки доходили?
Пять лет, дальше, я сделал все что мог и в другую не ИТ компанию с повышением.
В компании, где я работаю, один фронтенд архитектор и непосредственно, один из моих начальников, имеет познания ниже чем у большинства средних джунов и с ним ничего не сделаешь, хотя все вокруг осознают его 'полезность', но у него хорошая крыша. Что он такой, я понял после 15 минут расспросов по тому, как мы планируем ядро проекта делать, что настраивать и тп.). Единственное, что можно с такими сделать, это минимизировать контакты с ними. Что у меня пока что, вроде выходит
В итоге все всё понимают, но ничего не меняется.
Это как классы, но хранятся на стеке, и работают не по ссылке, а по значению.
Вы походу и сейчас не знаете о работе структур :) Структуры не обязательно хранятся на стеке. Простой пример: куда запихнутся миллион инстансов структур? Никакого стека не хватит. К тому же структуры можно передать и по ссылке с помощью модификаторов ref и out, об этом тоже не стоит забывать. А еще структуры весят меньше, потому что не нужно хранить индекс синхронизации, который есть у объектов (из-за этого, кстати, нельзя делать lock на структурах).
Еще при передаче по ссылке структура не упаковывается.
Я к тому, что "хранятся на стеке" — это верно в определенных условиях, но не всегда.
Структура в куче может оказаться только при вызове инструкции упаковки box
Это не так.
public class Foo
{
public Guid Bar;
}
Или вы полагаете, что при создании объекта типа Foo его поле Bar будет упаковано, либо храниться на стеке?
public class Test {
public MyStruct ValueType {get;set;} = new MyStruct();
}
...
var t = new Test();
...
создаем экземпляр класса, смотрим в кучу и видим, что значение спокойно себе лежит прямо в ней.
docs.microsoft.com/ru-ru/archive/blogs/ericlippert/the-truth-about-value-types
Если коротко — вся эта дискуссия — треш и содомия.
То, что система типов имеет какое-либо отношение к стратегии выделения памяти — ошибочное утверждение.
То, что система типов имеет какое-либо отношение к стратегии выделения памяти — ошибочное утверждение.
Да, так написано по ссылке. И там же написано опровержение этого утверждения:
the storage locations of instances of reference types are always treated as though they are long-lived, even if they are provably short-lived. Therefore they always go on the heap.
очень смешно смотрится разводка в финале — "никогда уже не стану разработчиком, который определяет индустрию. А вот ты сможешь", потому что наивные дурачки не должны кончаться.
никто и никогда уже не будет "определять индустрию". лет 30 назад еще может быть, а сейчас время хайпа, и хорошо если не проплаченного хайпа.
Смотря что понимать под термином "определять индустрию". И сейчас можно определять, просто это будет не так заметно, как 30 лет назад, а работать, наоборот, надо будет больше. Впрочем, это касается и любой другой индустрии: попруйте сейчас в одиночку что-нибудь определить в математике или физике. В айти даже больше возможностей.
Хайп — тоже разновидность определения индустрии.
Поэтому ты, братец, никогда не определишь индустрию. И правильно, не пытайся.
Но на месте директора сервиса зачастую – вчерашний рихтовальщик, который в какой-то момент принял решение "замутить свою СТО-шку".
Самозванец-лотерейщик на месте директора? Ну, только если очень редкий случайный прецедент. И то сложно представить, какого фуагра он решил применить свой талант Остапа Бендера на таком уровне.
Ок.
Рассказал.
Рубаху на себе рванул.
Вскрыл и просигналил.
Ты прав, мы это видим вокруг.
Спасибо.
А ещё нам иногда на Хабре рассказывали сами люди с непростыми диагнозами, как они в крутые менеджеры выходили и добивались ролей с властью над многими людьми.
Всегда чиал с интересом к фактуре и уважением к авторам.
Теперь — просьба нижайшая — придумайте что и как с этим (весьма, кстати, распространенным) явлением делать?
Нам вскм, не обладающим. Иногда подчинённым, иногда — коллегам из соседнего отдела.
Огласите цифру. Какую сумму "кусок говна", по выражению автора, считает большими деньгами?
Я знал, что сорвал шальной куш, и одновременно был горд, что наконец стал синьором.
→2 years later←
перегорел… у меня синдром самозванца...
Executive producer
Stephen Hillenburg
вообще на самом деле конечно в статье сплошное утрирование
впрочем ничего нового
а с годами понимаешь что это потолок и тупик
т.к. силы и годы прошли, то разочаровываешься
играть в короткую — это специфика СНГ рынка,
где в основном спрос диктуется аутсорсом,
где нет разницы между обычным разрабом и энтузиастом в чем-то,
а чтобы стать экспертом, приходится сильно рисковать и быть неординарной самоосознанной личностью, и делать это не у всех есть возможность и сопособности
и системы образования у нас для этого нет, а есть только хайп
Возможно потому что на самом деле денег не куча.
Надо устраиваться на позицию по рангу
На позицию по рангу пусть устраиваются те, кого мама-папа кормят, а квартира от бабки внутри Садового кольца в наследство осталась.
Мне же приходится ПОКУШОЦ покупать, и квартиру мне тоже никто не подарит.
Тут и так морали едва хватает только на то, чтобы в «Единую Россию» не вступать, а мне рассказывают, что надо поголодать ради высших ценностей. Спасибо, не хочу. Вы уж там сами как-нибудь «определяйте индустрию», без меня.
Но если бы я мог отмотать время назад, я бы все сделал по другому. Стать действительно хорошим старшим специалистом можно не играя в 23-х летнего синьора. Надо устраиваться на позицию по рангу, причем желательно во всякие яндексы, где твой трехлетний джуновский опыт действительно сделает тебя мидлом, а трехлетний мидловый — начинающим синьором. Да, лет пять-шесть ты будешь получать меньше, чем я. Но. Даже низкая джуновская зп в айти — это хорошие деньги. У тебя все равно будет синдром самозванца, но в отличие от меня, самозванцем ты не будешь. А самое главное — я то уперся в свой потолок, и никогда уже не стану разработчиком, который определяет индустрию. А вот ты сможешь. Ты охренеть как сможешь.
Ну да, ну да… будешь пилить стопятьсот каких-либо унылых задачек по поддержке какого-либо внутрикорпоративного велосипеда, попутно заполнять стопятьсот анкет и отчетов, нужных местной бюрократии для того что-бы оправдывать свое собственное существование, и каждый день на
Если собеседование — это, как выразился автор, «лотерея», то пройдя 10 собеседований можно найти работу, которая позволит развиваться профессионально — например в живом нагруженном проекте, с большой аудиторией и командой опытных коллег, с перекрестным код-ревью, обменом опытом, и т.д.
Очевидно, что человеку, который выбирает сидеть на «велосипеде с отчетами», этот проф.рост нафиг и не сдался, иначе бы он выбрал другую работу. При этом не осуждаю выбор этих людей — каждый выбирает работу для себя самостоятельно, и хочет от работы разного.
Если хочется как-то круто проявить себя, то, я думаю, намного разумнее нацеливаться на какие-то стартапы и прочие небольшие проекты, там реально что-то может выстрелить.
Соглашусь что стартапы тоже хороши, как место получения нового опыта, но там можно скорее получить широту технической эрудиции, а не глубину, ибо все мы знаем про средний срок жизни «стартапа», и сколько из них доживает до сколь-либо большой аудитории, когда можно похвастаться успехами проекта.
Ну, и вы скорее всего знаете, какого уровня качества код подавляющего большинства стартапов (то что код далеко не идеальный — это не то что плохо, просто есть необходимость писать код быстро и «делать фичи», а не оптимизацию/рефакторинг/красивую архитектуру).
Разумеется, так не везде, у меня опыт работы в крупных фирмах сравнительно небольшой, и возможно, мне просто так «повезло». Недавно в стартапе работал — там с кодом все было отлично, хоть и писался он в сжатые строки — был очень высокий уровень разработчиков, по факту там были только синьоры (реальные, а не по регалиям). Проект не взлетел не из-за плохого кода, а из-за проблем с маркетингом — не сумели продать идею.
Иногда на собеседовании сложно понять проект и команду. На словах всё, что вы описали есть и даже больше, а по факту ожидания не оправдываются. А оффер они сделали на 500$ больше, а когда понял, что ловить на проекте в плане развития особо нечего, уходить на меньшую сумму уже как-то не хочется.
у меня друг работает в одной известной компании связанной с добычей богатств из природных недр на позиции тимлида, хороший программист с хорошими софтовыми скиллами, уважаем в группе, но работает по графику с 9:00 и до «первой звезды», но при этом третий год делает проект, которым _пользуется_ 10 топов внутри компании, при этом на нем задействовано около 15-ти разработчиков, и то что на предыдущем месте он бы сделал за два месяца — тут растягивается на полтора года согласований.
Плюется при личных беседах на всё это, но — машина-кредит, квартира-ипотека, маленький ребенок — и работает за зарплату на ~30-40% больше чем можно найти в Москве.
Прочел комменты.
Посмотрел автору в профиль. В профиле по прежнему написано «Король разработки». Странно, после такой статьи я бы поменял подпись на бастарда разработки, или там Лжедмитрия…
Древнее знание сделало его Избранным
Это совсем другая штука, переназначить такой конструктор нельзя, это везде написано сразу для начинающих. Однако, я в свое время экспериментировал и в результате максимум что можно сделать:
public struct ИмяСтруктуры{
public ИмяСтруктуры(bool костыль=true){}
}
и по идее его бы можно вызвать без параметров, но он естественно не переназначает конструктор без параметров, а чтоб его вызвать надо обязательно указывать параметр
ИмяСтруктуры МояСтруктура=new ИмяСтруктуры(true);
Я уже стал поздабывать эту тему, простите если что перепутал. Просто это было забавно )
Уже давно можно указать в структуре конструктор без параметров:
Parameterless struct constructors - C# 10.0 draft feature specifications
using System;
var x = new C();
Console.WriteLine(x.a); // 1
public struct C {
public int a ;
public C() {
a = 1;
}
}
Не идите по моему пути, а то разведется слишком много «самозванцев» и некому будет делегировать задачи по разработке и вообще практически по всему.
По хорошему, мне бы сгореть от стыда,
Некоторые вещи нужно планировать под рост так как отсутствие роста это очень плохо. За год -два вполне можно стать тем самым сеньором.
Когда ты прошел собес на позицию, до которой нужно дотягиваться
… то в итоге вы неизбежно увидите своими глазами (и будете частью) принцип Питера в действии. В software development принцип Питера обычно формулируется анекдотом "- Сколько нужно энтерпрайз-программистов, чтоб ввернуть лампочку? — Неизвестно, они всё еще спорят об архитектуре".
Разработка в целом так устроена, что когда ты недостаточно компетентен — да ничего не произойдет. Ты будешь незамечать кучу проблем, но от них никто не умрет.
Автор в целом прав, но все-таки в истории разработки есть примеры сильных последствий наподобие Therac-25. В наше время такие громкие провалы, конечно, редкость, но и гораздо более безобидные баги все равно могут приводить к неприятным последствиям. Хорошо, если такой разработчик не плодит баги в медицине, но вообще, если перебрать все отрасли, тяжело представить такую сферу, где описанный в статье персонаж не будет изредка приносить мелкий материальный или какой-то ещё ущерб. Разве что в индустрии игр (хотя многие и с этим не согласятся). Статья полезная в том плане, что вдохновляет новичка не быть самозванцем, несмотря на синдром оного.
Спасибо
Да вы будете зарабатывать меньше, чем в среднем по рынку, но вы получите огромный опыт))
Ну да, ну да, по факту единственное чему отлично учит Яндекс это как представить результаты своей работы, как что то великое и грандиозное, без этого о карьере можно забыть.
PS: Хотя хабр я читаю уже несколько лет, из-за этой публикации я зарегился, специально чтобы написать этот комментарий и выразить автору свою благодарность.
Ты прошел собес, и на новой работе никто не пытается доказать, что тебя взяли зря.
Автор мал и жизни не видал. Если место, на которое попал — синекура, то там найдется человек 5 минимум, желающих доказать что взяли такого-то зря и что они более достойны занять эту должность. Впрочем, такое и без синукуры получается, когда деньги в конторе на исходе, а руководству и другим кандидатам на выход надо найти легитимный повод кого-то другого выставить на мороз.
Очень точно описаны все бесполезные гипермегаопытные синьйоры, которые рубят бабло и ласкают своё чсв еженедельными мейлами команде со списком приоритетов и асапов
Не прыгайте выше головы — останетесь тупицей в плену больших денег