Alexey Evdokimov @PastorGL
Software engineer. Practicioner, not a theorist.
Information
- Rating
- 1,362-nd
- Location
- Ижевск, Удмуртия, Россия
- Registered
- Activity
Specialization
Backend Developer, Software Architect
Lead
Big data
Spark
Java
Database
Geoinformation systems
Software development
Algorithms and data structures
Development management
Automation of processes
ETL
Программирование — лучшая профессия на свете, зачем же чувствовать вину за то, что ты в неё вляпался по эти самые?
Помнится, ещё на защите диплома мне задали первый вопрос: вот вы говорите, что внедрили свой проект, а сколько денег он принёс вашей фирме? Я назвал точную сумму, благо я её знал. Больше вопросов не было. Четвёрка, потому что в комиссии никто не понял, о чём вообще я рассказывал. Хмм, однако.
С тех пор прошло почти два десятка лет. Я прошёл все степени разочарования в идеалах и отрицания собственной компетентности. Но я по-прежнему ориентируюсь на те суммы, которые мои проекты приносят фирмам, в которых я работаю. Из них платятся зарплаты моим коллегам, и те не бедствуют. Не говоря уже о том, сколько зарабатывают сами заказчики с помощью тех инструментов, к созданию которых я прилагаю свои кучерявые, даже если прикладываю их не приходя в сознание.
Тэйк ит изи. Даже в кровавом энтерпрайзе нет ровным счётом ничего такого, чтобы чувствовать себя виноватым. Ты можешь сто раз не верить в себя, но пока ты приносишь пользу людям по их мнению — ты приносишь пользу людям, даже если по твоему собственному ты ничего, кроме фигни по приколу, и не делаешь.
Например: повторяющиеся просрочки в задачах одного типа, задокументированные в трекере; количество повторных замечаний с одинаковой ошибкой в ревью кода; количество вопросов, заданных по теме, которая входит в базовую квалификацию — в письменном виде (в устном предъявить невозможно, поэтому общайтесь письменно). Любые другие вещи, которые можно свести к показателям с циферками.
За пару месяцев обычно можно собрать достаточно доказательной базы, чтобы не быть голословным. Если в конторе есть хоть какая-то бюрократия, то это всё наберётся само собой, а ваше дело просто собрать циферки в письмо, и описать риски в терминах бизнеса.
Попадись мне такой перец в команду, я бы поднял на уши HR (первым делом — потому что просмотрели мудака при найме) и проектное начальство, а если бы оно не пожелало решать проблему, то начальство начальства, и если потребовалось бы, дошёл бы хоть до самого главного. С уведомлением всех подчинённых и причастных в Cc:. И никуда бы они все от разговора по душам с подробнейшим разбором полётов не ушли — каким угодно способом, но он состоялся бы. Я проверял на практике, это работает.
У вас, как у непосредственных исполнителей есть железный аргумент: мудак на проекте повышает риски по его delivery, а ни один вменяемый бизнес не толерантен к росту вероятности провала.
И чем раньше и громче вы вскинете флаг, тем проще будет решить проблему. Не надо ждать, надо действовать.
Или дата аналитик как-то сам подготавливает портянку аутлайнов в geojson с метаданными по адресам, или ячейками грида, или чем-то другим, что нужно для текущей карты. Откуда он их берёт, кроме OSM, я, если честно, не интересовался.
Ваша задача звучит посложнее.
Довольно здорово дела упрощает ещё алгоритмическая сетка — заказчик был из Токио, там у них есть такая Japan Mesh. Она иерархическая, зависит только от координат, и её можно использовать сразу как индекс. В будущем планируем заюзать что-то такое же, только для всего мира.
Порядка десятка задач в неделю — это хорошая производительность. А апдейт версии апи и ревью кода — это задачи уже для уровня middle. Вы в самом деле большой молодец, респект.
Получается примерно по 8-9 заявок в день. То есть, по одной меньше чем на час рабочего времени.
Я бы сказал, интересненько. Либо все заявки уровня «поправить опечатку в сообщении», либо тут затесался лишний ноль, либо автор настоящий стахановец и талант, каких мало, но почему-то скромничает.
Вы не могли бы привести пример типичной задачи, чтобы развеять мои сомнения?
Но я стараюсь не упускать возможности пройти лишние несколько тысяч шагов, или проявить какую-нибудь другую физическую активность.
следующее после моего поколение админят из 204 я встретил в ЕПАМе почти в полном составе. только почему-то все они оказались перебежчиками в стан дотнета.
знаете, люди существа довольно разные. на мой вот взгляд, дурдом как раз в столицах. в детстве я часто гостил у тёток на Новом Арбате, и мне ещё тогда не понравился московский ритм жизни. шумно, люди вокруг вечно куда-то опаздывающие, давка в метро. неуютно. и успеть можно только в какое-то одно место за целый день.
в каком-нибудь совсем маленьком сонном городишке типа Воткинска (есть тут под боком такой, меньше ста тыщ населения, и тоже бывший заводской посёлок) мне тоже будет скучно и некуда себя девать, а Ижевск — вот он в самый раз.
опять же, что хорошо мне, вам может быть маловато.
сейчас уже о спорте думать несколько поздно. мне известно несколько примеров, когда чуваки моего возраста вдруг становились айронмэнами, но мне здоровье такого и в юности особо не позволяло. ну, стараюсь хотя бы пешком побольше ходить, чтоб не скиснуть.
1. любое новое должно быть оправданно.
либо по новому стэку должны быть наработаны best practices, либо по нему должна быть живая поддержка от вендора. в противном случае именно вы будете тем первопроходцем, который соберёт все грабли, и здорово потеряете в сроках и качестве.
я довольно консервативен в выборе инструментов, и позволяю эксперименты только для тех проектов, которые не являются критичными для бизнеса. и если в таких игрушечных проектах не возникает неожиданной фигни, то можно брать для чего-то посерьёзнее. и новое — не обязательно лучшее.
но сам я стараюсь быть в курсе всех новых веяний, конечно. читаю все блоги тому же .net core или typescript с популярными фреймворками, хотя не использую в своих работах вообще. это нужно, чтобы моя картина мира не теряла актуальности.
2. просто мыслите о софте как о части экосистемы. любая программа живёт не в вакууме, а в окружении, и является частью какого-то процесса из реального мира, решает какие-то задачи из реального мира. это единственный фундаментальный принцип, о котором нельзя забывать. софт не существует сам по себе, он всегда часть какой-то цепочки, в конце которой — прибыль какого-то бизнеса.
допустим, вы плотник, и умеете забивать гвозди молотком, и вам надо освоить лобзик для распила фанеры. у вас ведь не должно возникать больших затруднений? так почему должны возникать затруднения с языками программирования? это совершенно та же фигня.
3. всё фундаментальное по программированию как науке было написано ещё в восьмидесятые. не могу порекомендовать ничего, кроме классики. Дейкстра, Страуструп и т.п.
«архитектурные» же решения возникают, когда вам приходится делать three-way tradeoff оптимизации (скорость/память/стоимость — можно выбрать только одно), и вы начинаете применять классическую алгоритмику к задачам из реального мира. по книжкам этому научиться невозможно.