Какое-то количество задач предлагают учебные материалы, какое-то количество задач можно найти в гугле (и, например, в одной из ссылок из футера статьи), какое-то количество можно придумать самому.
Поначалу задачи будут не особо интересными, но тут должен быть перевес за счет энтузиазма и новизны области. Чем дальше — тем больше знаний, и тем более интересными станут задачи.
Так что да, без начального «толчка» вкатиться не получится, изначально нужно тащить на энтузиазме. А дальше уже должно стать интереснее.
Да, вероятно, сгорел. И, как мне кажется, тут все индивидуально, и парой-тройкой комментариев помочь будет сложно.
Тем не менее, я бы не оставлял все как есть, но и не рубил бы мосты.
Начать можно с отпуска (желательно — продолжительного и без интернета, чтобы ограничить гиперпоток информации и дать мозгу отдохнуть), консультации у психотерапевта (провериться никогда лишним не бывает, особенно когда есть стабильное чувство дискомфорта), смены проекта (возможно, новые задачи откроют новое дыхание), смены вида деятельности в рамках профессии (стать тимлидом, меньше кодить, больше разговаривать).
Это все банальные советы, разумеется. Но — а вдруг поможет?
Если же нет, то всё грустно — деятельность менять всё же придется, чтобы не калечить самого себя. Областей, куда программист с незначительными усилиями может перекатиться в зависимости от темперамента и личных интересов, на самом деле, довольно много — бизнес-консульт, внедрение CRM, дизайн, итд итп. Читал где-то историю программиста, который стал поваром и был доволен :)
Единственное — с даунгрейдом по ЗП придется смириться, скорее всего. Как минимум на какой-то относительно длительный срок.
Тем не менее, искренне надеюсь, что до этого не дойдет.
А чтобы, если всё-таки дойдет, это не стало катастрофой — копите финансовую подушку.
Люди, стоявшие на заре современных технологий, вызывают восхищение.
Порой я жалею, что не застал этого.
Сейчас меньше романтики и больше задач бизнеса. Технологии не ради прогресса, но ради монетизации.
Разумеется, это логичное развитие любой технологии, но… «В нас пропал дух авантюризма».
А почитаешь истории о разработке в каких-нибудь советских НИИ — и теплее на душе становится.
Не согласен. Эмоциональное (профессиональное) истощение — это вполне себе диагностируемая вещь. О ней даже пишут в рецензируемых журналах. Фразы в духе «эмоциональное истощение придумали чтобы удержать ценный кадр» эквивалентны фразам «депрессия — это просто блажь, ты все придумал».
Выгорание — это не то, что тебе говорят эйчары, а то, что ты чувствуешь сам. Когда уже просто не можешь работать.
И говорить, что его кто-то зачем-то придумал — оскорбление для выгоревших людей.
Честно говоря, если вы находитесь на грани выгорания, и вам при этом нужно помогать выгорающей команде, то с вашим местом работы что-то не так. Бегите оттуда, восстанавливайтесь, и не работайте больше в местах, где могут довести до выгорания целую команду.
Выгорание одного человека может быть проблемой человека — устроился на слишком сложную для него работу, пошел работать на неинтересный проект за большие деньги, просто получил переизбыток стресса.
Выгорание (даже потенциальное) целой команды — это проблема места, и никак иначе. И бросаться грудью на амбразуру, «спасать команду» в подобном месте — дело неблагодарное.
Не стоит.
Не автор, но отвечу. Лучший вариант: подтянуть матчасть (алгоритмы, структуры данных, язык, все основные технологии, умение писать код на бумажке, git, базы данных), и затем устроиться в крупную фирму (Luxoft, EPAM, etc) на мидла. Собеседование сначала будет удаленное, потом тебе оплатят поездку в офис на очное интервью.
Крупные фирмы как правило предлагают релокационный пакет: оплатят билеты, риелтора, перевоз вещей. Зарплата, однако, скорее всего будет несколько ниже рынка.
За год-два в энтерпрайзе скиллы подрастут достаточно, чтобы иметь возможность устроиться уже почти в любую компанию.
А по поводу наличия или отстутствия экзотики — это ж всё относительно. Мне показалось, что раз информации на хабре о MPT нет, то это достаточно экзотично.
Справедливо. Однако, я, вроде бы, не указывал, что кроме как в Ethereum эта структура данных не используется нигде. Ethereum — насколько мне известно — источник, не более. Просто так вышло, что лично я познакомился с ней благодаря данному проекту. Именно поэтому в повествовании упоминается Ethereum.
В exonum, например, Merkle Patricia Trie тоже используется — однако там оно несколько видоизменено. В частности, ветвление там именно бинарное, а также не используется RLP.
Тем не менее, идея в основе лежит та же: бинарное KV-хранилище, имеющее возможность подтвердить наличие тех или иных данных.
В итоге именно тот факт, что это не one-shot структура, целиком и полностью направленная на нужды сугубо одного проекта, и побудил меня написать эту статью. Кто знает — возможно в будущем кто-то решит, что и для его проекта нужно нечто подобное, и моя статья станет ему подспорьем в этом нелегком деле :)
Нормальным работодателям, как правило, пофиг на форму обучения и даже наличие диплома. Главное — показать скилл.
Я начал работать на 2 курсе и сейчас работаю уже в третьей фирме. Принести диплом ни разу не просили. Максимум — спрашивали, учусь ли я/заканчивал ли какой-либо универ.
Так что забей, работу можно найти и без корочек.
Я бы рекомендовал 6502 assembly (тот самый, который для NES).
Он не простой, он элементарный. Набор команд учится за час.
Если изучать его в связке с архитектурой NES (тоже крайне простой), то в качестве дополнения придет понимание многих концептов, которые в современных процессорах стали в сотни раз сложнее, но содержат ту же самую идею.
Ну и бонусом — возможность поковыряться в сорцах игр из детства :)
Хм. Так rvalue я все-таки указал. Я имел в виду, что из перечисленных в статье (и, соответственно, в стандарте) терминов в повседневном программировании наиболее важны только два. А ссылки на rvalue, move-семантика, perfect forwarding, вот это вот всё — разумеется, важно, т.к. имеет строго прикладной характер.
Для себя я пришел к выводу, что для комфортной работы с плюсами достаточно понимать lvalue и rvalue. Остальное, по факту, промежуточные категории для удобного объяснения тех или иных моментов в стандарте.
И я с трудом включил внимание только тогда, когда фонолектор перешел уже к основной теме: к нашей музыке, к математической композиции (математик — причина, музыка — следствие), к описанию недавно изобретенного музыкометра.
— "… Просто вращая вот эту ручку, любой из вас производит до трех сонат в час. А с каким трудом давалось это вашим предкам. Они могли творить, только доведя себя до припадков «вдохновения» — неизвестная форма эпилепсии. И вот вам забавнейшая иллюстрация того, что у них получалось, — музыка Скрябина — двадцатый век. Этот черный ящик (на эстраде раздвинули занавес и там — их древнейший инструмент) — этот ящик они называли «рояльным» или «королевским», что лишний раз доказывает, насколько вся их музыка..."
Пусть дана булева функция f и о ней априорно известно, что она или константна, то есть для любого из своих аргументов всегда возвращает либо 0, либо 1, или сбалансирована, то есть ровно на половине своих аргументов возвращает 0, а ровно на половине 1.
Логическое И не проходит по предусловию. Соответственно, если больше чем на половине входов возвращается одно значение, то функция может быть только константной.
Поначалу задачи будут не особо интересными, но тут должен быть перевес за счет энтузиазма и новизны области. Чем дальше — тем больше знаний, и тем более интересными станут задачи.
Так что да, без начального «толчка» вкатиться не получится, изначально нужно тащить на энтузиазме. А дальше уже должно стать интереснее.
Тем не менее, я бы не оставлял все как есть, но и не рубил бы мосты.
Начать можно с отпуска (желательно — продолжительного и без интернета, чтобы ограничить гиперпоток информации и дать мозгу отдохнуть), консультации у психотерапевта (провериться никогда лишним не бывает, особенно когда есть стабильное чувство дискомфорта), смены проекта (возможно, новые задачи откроют новое дыхание), смены вида деятельности в рамках профессии (стать тимлидом, меньше кодить, больше разговаривать).
Это все банальные советы, разумеется. Но — а вдруг поможет?
Если же нет, то всё грустно — деятельность менять всё же придется, чтобы не калечить самого себя. Областей, куда программист с незначительными усилиями может перекатиться в зависимости от темперамента и личных интересов, на самом деле, довольно много — бизнес-консульт, внедрение CRM, дизайн, итд итп. Читал где-то историю программиста, который стал поваром и был доволен :)
Единственное — с даунгрейдом по ЗП придется смириться, скорее всего. Как минимум на какой-то относительно длительный срок.
Тем не менее, искренне надеюсь, что до этого не дойдет.
А чтобы, если всё-таки дойдет, это не стало катастрофой — копите финансовую подушку.
Порой я жалею, что не застал этого.
Сейчас меньше романтики и больше задач бизнеса. Технологии не ради прогресса, но ради монетизации.
Разумеется, это логичное развитие любой технологии, но… «В нас пропал дух авантюризма».
А почитаешь истории о разработке в каких-нибудь советских НИИ — и теплее на душе становится.
Выгорание — это не то, что тебе говорят эйчары, а то, что ты чувствуешь сам. Когда уже просто не можешь работать.
И говорить, что его кто-то зачем-то придумал — оскорбление для выгоревших людей.
Выгорание одного человека может быть проблемой человека — устроился на слишком сложную для него работу, пошел работать на неинтересный проект за большие деньги, просто получил переизбыток стресса.
Выгорание (даже потенциальное) целой команды — это проблема места, и никак иначе. И бросаться грудью на амбразуру, «спасать команду» в подобном месте — дело неблагодарное.
Не стоит.
Крупные фирмы как правило предлагают релокационный пакет: оплатят билеты, риелтора, перевоз вещей. Зарплата, однако, скорее всего будет несколько ниже рынка.
За год-два в энтерпрайзе скиллы подрастут достаточно, чтобы иметь возможность устроиться уже почти в любую компанию.
А по поводу наличия или отстутствия экзотики — это ж всё относительно. Мне показалось, что раз информации на хабре о MPT нет, то это достаточно экзотично.
В exonum, например, Merkle Patricia Trie тоже используется — однако там оно несколько видоизменено. В частности, ветвление там именно бинарное, а также не используется RLP.
Тем не менее, идея в основе лежит та же: бинарное KV-хранилище, имеющее возможность подтвердить наличие тех или иных данных.
В итоге именно тот факт, что это не one-shot структура, целиком и полностью направленная на нужды сугубо одного проекта, и побудил меня написать эту статью. Кто знает — возможно в будущем кто-то решит, что и для его проекта нужно нечто подобное, и моя статья станет ему подспорьем в этом нелегком деле :)
Я начал работать на 2 курсе и сейчас работаю уже в третьей фирме. Принести диплом ни разу не просили. Максимум — спрашивали, учусь ли я/заканчивал ли какой-либо универ.
Так что забей, работу можно найти и без корочек.
Он не простой, он элементарный. Набор команд учится за час.
Если изучать его в связке с архитектурой NES (тоже крайне простой), то в качестве дополнения придет понимание многих концептов, которые в современных процессорах стали в сотни раз сложнее, но содержат ту же самую идею.
Ну и бонусом — возможность поковыряться в сорцах игр из детства :)
Евгений Замятин, «Мы», 1920.
Логическое И не проходит по предусловию. Соответственно, если больше чем на половине входов возвращается одно значение, то функция может быть только константной.