Pull to refresh
56
2.1
Alexey Evdokimov @PastorGL

Software engineer. Practicioner, not a theorist.

Send message
Жуть какая. Прям как будто из DC.

Программирование — лучшая профессия на свете, зачем же чувствовать вину за то, что ты в неё вляпался по эти самые?

Помнится, ещё на защите диплома мне задали первый вопрос: вот вы говорите, что внедрили свой проект, а сколько денег он принёс вашей фирме? Я назвал точную сумму, благо я её знал. Больше вопросов не было. Четвёрка, потому что в комиссии никто не понял, о чём вообще я рассказывал. Хмм, однако.

С тех пор прошло почти два десятка лет. Я прошёл все степени разочарования в идеалах и отрицания собственной компетентности. Но я по-прежнему ориентируюсь на те суммы, которые мои проекты приносят фирмам, в которых я работаю. Из них платятся зарплаты моим коллегам, и те не бедствуют. Не говоря уже о том, сколько зарабатывают сами заказчики с помощью тех инструментов, к созданию которых я прилагаю свои кучерявые, даже если прикладываю их не приходя в сознание.

Тэйк ит изи. Даже в кровавом энтерпрайзе нет ровным счётом ничего такого, чтобы чувствовать себя виноватым. Ты можешь сто раз не верить в себя, но пока ты приносишь пользу людям по их мнению — ты приносишь пользу людям, даже если по твоему собственному ты ничего, кроме фигни по приколу, и не делаешь.
Так никто и не спорит, что у дыры наблюдаемые физические параметры таки есть. Но у сингулярности, которая скрыта где-то внутри дыры, они теряют смысл.
Не вспомню где (к сожалению), но мне как-то попадалось утверждение, что сигнулярность нельзя пронаблюдать. Следовательно, физическим смыслом она обладать и не обязана, вполне может оставаться этаким математическим артефактом.
… и ещё неплохо бы повторить ось сверху графика. В ноутбучный экран они по высоте не влазят, приходится мотать туда-сюда :(
Ну так научитесь быть убедительной. Факты рулят, а эмоции нет — они обычно неконструктивны. Поэтому нужно уметь собирать вещи, которые можно измерять.

Например: повторяющиеся просрочки в задачах одного типа, задокументированные в трекере; количество повторных замечаний с одинаковой ошибкой в ревью кода; количество вопросов, заданных по теме, которая входит в базовую квалификацию — в письменном виде (в устном предъявить невозможно, поэтому общайтесь письменно). Любые другие вещи, которые можно свести к показателям с циферками.

За пару месяцев обычно можно собрать достаточно доказательной базы, чтобы не быть голословным. Если в конторе есть хоть какая-то бюрократия, то это всё наберётся само собой, а ваше дело просто собрать циферки в письмо, и описать риски в терминах бизнеса.
Интересно было почитать, но, как тут уже сказали, есть ощущение некоего детского сада. Особенно в области коммуникаций. Сеньор на то и сеньор, что его мнение должно учитываться менеджментом — и о проекте, и о людях, вне зависимости от того, нравится оно, или нет. А иначе, какой ты, нафиг, сеньор?

Попадись мне такой перец в команду, я бы поднял на уши HR (первым делом — потому что просмотрели мудака при найме) и проектное начальство, а если бы оно не пожелало решать проблему, то начальство начальства, и если потребовалось бы, дошёл бы хоть до самого главного. С уведомлением всех подчинённых и причастных в Cc:. И никуда бы они все от разговора по душам с подробнейшим разбором полётов не ушли — каким угодно способом, но он состоялся бы. Я проверял на практике, это работает.

У вас, как у непосредственных исполнителей есть железный аргумент: мудак на проекте повышает риски по его delivery, а ни один вменяемый бизнес не толерантен к росту вероятности провала.

И чем раньше и громче вы вскинете флаг, тем проще будет решить проблему. Не надо ждать, надо действовать.
Хм. Ну, в наших задачах чаще попадается либо сопоставление с postcode/zip/почтовым индексом (это всегда мозаика из аутлайнов конкретных участков, вплоть до 1 дома), либо в сильно ограниченной области, где не только город, но и район города заранее точно известен.

Или дата аналитик как-то сам подготавливает портянку аутлайнов в geojson с метаданными по адресам, или ячейками грида, или чем-то другим, что нужно для текущей карты. Откуда он их берёт, кроме OSM, я, если честно, не интересовался.

Ваша задача звучит посложнее.
Почему другая? Адрес — это разве не метаданные аутлайна?
Ну мы как-то сразу с MR, который дёргает st_чегоНибудь() из PostgreSQL с PostGIS, перешли на геоспарк с индексами по геохешу, без промежуточных шагов. Меньше чем за полгода техпроцесс перевели, а итоговое ускорение расчёта получилось в пару сотен раз. На изначальном стеке расчёт карты по десятку тысяч точек был тем ещё предприятием, теперь бывает до сотен миллионов обсчитываем в приемлемое время на кластере из пяти нод среднего размера.

Довольно здорово дела упрощает ещё алгоритмическая сетка — заказчик был из Токио, там у них есть такая Japan Mesh. Она иерархическая, зависит только от координат, и её можно использовать сразу как индекс. В будущем планируем заюзать что-то такое же, только для всего мира.
А геоспарк не пробовали? Вполне неплохо себя показывает. Если индекс а-ля геохэш запилить, то и вообще отлично. Мы вот юзаем, не жалуемся. У нас порядка миллионов точек на одну карту, карты считаются на потоке.
Теперь верю :)

Порядка десятка задач в неделю — это хорошая производительность. А апдейт версии апи и ревью кода — это задачи уже для уровня middle. Вы в самом деле большой молодец, респект.
За эти 6 месяцев работы в качестве разработчика я закрыл более 1000 заявок на разработку, доработку и исправление ошибок в коде совершенно разных подсистем и модулей

не надо думать, что я очень умный. Я самый простой парень

Получается примерно по 8-9 заявок в день. То есть, по одной меньше чем на час рабочего времени.


Я бы сказал, интересненько. Либо все заявки уровня «поправить опечатку в сообщении», либо тут затесался лишний ноль, либо автор настоящий стахановец и талант, каких мало, но почему-то скромничает.


Вы не могли бы привести пример типичной задачи, чтобы развеять мои сомнения?

Ну, для меня физические нагрузки исключены по объективной причине — у меня попросту не хватает нескольких отростков у пары позвонков. Родился с таким дефектом, и всю жизнь периодически мучился со спиной, но узнал о причине только пару лет назад, когда наконец проверился на современном томографе. Когда позвонок смещается, это, поверьте, более чем неприятно, так что весь спорт мимо. Слишком опасно, и возраст тут имеет значение — из-за естественного износа получить межпозвоночную грыжу куда проще.

Но я стараюсь не упускать возможности пройти лишние несколько тысяч шагов, или проявить какую-нибудь другую физическую активность.
ха, 204 :)

следующее после моего поколение админят из 204 я встретил в ЕПАМе почти в полном составе. только почему-то все они оказались перебежчиками в стан дотнета.
ну, у нас он есть в плане где-нибудь на послезавтра. если, конечно, предыдущие пункты воплотим.
спасибо и вам.

знаете, люди существа довольно разные. на мой вот взгляд, дурдом как раз в столицах. в детстве я часто гостил у тёток на Новом Арбате, и мне ещё тогда не понравился московский ритм жизни. шумно, люди вокруг вечно куда-то опаздывающие, давка в метро. неуютно. и успеть можно только в какое-то одно место за целый день.

в каком-нибудь совсем маленьком сонном городишке типа Воткинска (есть тут под боком такой, меньше ста тыщ населения, и тоже бывший заводской посёлок) мне тоже будет скучно и некуда себя девать, а Ижевск — вот он в самый раз.

опять же, что хорошо мне, вам может быть маловато.
да, я тогда так считал, и зря.

сейчас уже о спорте думать несколько поздно. мне известно несколько примеров, когда чуваки моего возраста вдруг становились айронмэнами, но мне здоровье такого и в юности особо не позволяло. ну, стараюсь хотя бы пешком побольше ходить, чтоб не скиснуть.
у вас три вопроса, значит, дам три ответа.

1. любое новое должно быть оправданно.

либо по новому стэку должны быть наработаны best practices, либо по нему должна быть живая поддержка от вендора. в противном случае именно вы будете тем первопроходцем, который соберёт все грабли, и здорово потеряете в сроках и качестве.

я довольно консервативен в выборе инструментов, и позволяю эксперименты только для тех проектов, которые не являются критичными для бизнеса. и если в таких игрушечных проектах не возникает неожиданной фигни, то можно брать для чего-то посерьёзнее. и новое — не обязательно лучшее.

но сам я стараюсь быть в курсе всех новых веяний, конечно. читаю все блоги тому же .net core или typescript с популярными фреймворками, хотя не использую в своих работах вообще. это нужно, чтобы моя картина мира не теряла актуальности.

2. просто мыслите о софте как о части экосистемы. любая программа живёт не в вакууме, а в окружении, и является частью какого-то процесса из реального мира, решает какие-то задачи из реального мира. это единственный фундаментальный принцип, о котором нельзя забывать. софт не существует сам по себе, он всегда часть какой-то цепочки, в конце которой — прибыль какого-то бизнеса.

допустим, вы плотник, и умеете забивать гвозди молотком, и вам надо освоить лобзик для распила фанеры. у вас ведь не должно возникать больших затруднений? так почему должны возникать затруднения с языками программирования? это совершенно та же фигня.

3. всё фундаментальное по программированию как науке было написано ещё в восьмидесятые. не могу порекомендовать ничего, кроме классики. Дейкстра, Страуструп и т.п.

«архитектурные» же решения возникают, когда вам приходится делать three-way tradeoff оптимизации (скорость/память/стоимость — можно выбрать только одно), и вы начинаете применять классическую алгоритмику к задачам из реального мира. по книжкам этому научиться невозможно.
а когда-то он был совсем другим. у меня даже где-то архив валяется со старым ламповым ижмото :)

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