Hot Positions, Cool Company! NeoGames
×Закрыть

О некомпетентности в ІТ, или Как сеньора Сеню хинкали погубили

Я Руслан Дмитракович, разработчик ПО и предприниматель. За моей спиной множество программных проектов в различных областях. В настоящее время занимаю должность программного архитектора. Уделяю особое внимание нетехническим аспектам разработки ПО.

Индустрия ІТ очень разнообразна, существует немало сегментов, требующих обширных знаний. И чем больше знает специалист, тем больше у него поводов сомневаться в самом себе. Ведь он понимает, как много того, что еще можно узнать. Как говорил Сократ: «Я знаю, что ничего не знаю». И эта статья именно для тех, кто постоянно учится, но все же сомневается в себе.

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

«Смерть Сократа», Жак Луи Давид

Сеньоры, которые все знают

Недавно общался с группой программистов примерно одной квалификации и опыта. В ходе беседы задавались два стандартных вопроса:

  • Как вы оцениваете свою квалификацию?
  • Как вы учитесь и чего планируете достичь?

Группа разделилась на Senior и Middle. И ответы на второй вопрос четко коррелировали с ответом на первый.

Middle-разработчики рассказали, какие книги читают, что изучают и какого прогресса хотят достичь. Senior на второй вопрос отвечали расплывчато, а уточнения по поводу литературы вызывали затруднения.

Уровень знаний оставлял желать лучшего, но наши герои не стремились что-то изучать. «Совпадение? Не думаю». Довольно логично, если ты уже достиг наивысшего уровня мастерства, то зачем еще учиться?

«Я — король!»

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

Себя он считал профессионалом с большой буквы и с большим опытом (потому как человек уже не молодой). На обсуждениях технических вопросов частенько звучало: «Делаем так, потому что я архитектор», и резонные замечания не принимались. Такое происходило не в момент решения критических проблем, когда кто-то должен быстро взять на себя ответственность. Нет, это были вполне обычные, регулярные собрания для обсуждения технических вопросов. Аргументы и желание понять точку зрения оппонента в споре заменялось директивным указанием.

Источник

В этот момент в комнате явно не хватало Тайвина Ланнистера, чтобы сказать: «Обычно „Я — король“ заявляют те, кто королем не являются».

Детали реализации архитектора не интересовали, и то, что было сделано, не проверялось на соответствие принятым решениям. Нередко программная система и архитектурная картинка отличались. Однако финансовые ресурсы компании позволяли сглаживать дополнительным «железом» или людьми все недочеты.

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

Должность и квалификация должны соответствовать друг другу. А что если человек попал на должность случайно или по знакомству? Или человек, решающий вопрос о принятии на работу, сам не является профессионалом?

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

Эффект хинкали

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

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

Дело в том, что в ходе исправления Сеня одно чинил, а другое ломал. Помню, как, решая проблему, которая возникла в модуле B, зависящем от модуля А, он изменил А. Потом появилась ошибка в модуле С. Во время поисков выяснилось, что так как С зависит от А, то новая проблема возникла после данного изменения. Система была написана не идеально, и, внося правки, нужно было отслеживать, на что именно они влияют.

Однако наш герой сильно в подробности не вникал. И если фирме он приносил деньги, то коллегам — головную боль. Приходилось тщательно подбирать ему задачи — с минимальным риском что-то поломать.

Разговоры с руководством о том, что Сеня, мягко говоря, не дотягивает, результата не давали.

«Если вас ударят в глаз, вы вначале вскрикнете. Раз ударят, два ударят, а потом привыкнете». Вот так и коллеги привыкли, что надо мириться с обстоятельствами в лице Сени.

Однако на очередном тимбилдинге произошел казус, который сломал Сене карьеру. Команда пошла в грузинский ресторан, и несколько человек, в том числе и наш герой, заказали хинкали. То ли обслуживал Junior-официант, то ли кто-то чего-то недопонял. В результате все хинкали были насыпаны в одну миску, и счастливчиком, которому эту миску принесли, оказался Сеня. Не заметив несоответствия между ТЗ и тем, что ему досталось, Сеня с аппетитом уминал одно хинкали за другим. Коллеги же, не получившие свой заказ, начали роптать.

Баг системы обслуживания всплыл, но Сеня откровенно заявил, что просто не заметил разницы. Это было последней каплей. Как может человек замечать какие-то несоответствия в программном коде, если он не может сосчитать хинкали в собственной тарелке?!

В итоге руководство согласилось отправить Сеню в свободное плавание...

Но, что самое замечательное, наш герой искренне считал себя Senior-разработчиком. И он так же ничему не учился в рамках своей специальности.

Даннинг — Крюгер против самозванца

Об эффекте Даннинга — Крюгера слышали многие, и мои истории именно об этом. Но есть отклонение и в другую сторону — синдром самозванца. В этом случае специалист, наоборот, себя недооценивает. Такое наблюдается у большого количества людей в ІТ-индустрии.

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

Данная статья в первую очередь для тех, что считает себя «самозванцем», чтобы рассказать о самозванцах настоящих.

Выводы

Если вы не уверены в себе, то больше общайтесь. Попытайтесь узнать, что думают о вас окружающие. Это должны быть разные люди, вполне вероятно, что, попав в общество «профессионалов» из моих историй, вы почувствуете себя не в своей тарелке и будете вести себя как герои научно-популярного фильма «Я и другие».

Если же так случилось, то вспоминайте изречение: «Если вы самый умный человек в комнате, то вы не в той комнате, где должны находиться». Меняйте свое окружение. Участвуйте в конференциях и тусовках. Благо, что для того, чтобы общаться с коллегами, достаточно подключится к дискуссионной группе в мессенджере. Это поможет вам как получить новые знания, так и «откалиброваться» относительно коллег.

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

Кавалерия династии Мин

И еще один неочевидный вывод. По компетенции и адекватности специалистов вы можете судить о руководстве компании. «Скажи мне, кто твой друг, и я скажу, кто ты». В данном случае эта поговорка отлично работает. Ее можно перефразировать так: «Посмотри на персонал компании, и ты поймешь, кем является ее руководитель».

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

👍НравитсяПонравилось23
В избранноеВ избранном8
Подписаться на тему «soft skills»
LinkedIn

Похожие статьи




Підписуйтесь: iTunes | Google Podcast | YouTube


Лучшие комментарии пропустить

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

Вот к примеру, в истории с последним:
— я что-то плохо понял, а что тестов не было ? или % покрытия был плохой ?
или сами тесты были плохие ?
Потому что если бы было нормальное покрытие и нормальные бы тесты, то гениальный патч отправил был в мусор на уровне прогонки
Но вместо того, чтобы заниматься свои делом управленца — а именно, что навести порядок в команде и обеспечить минимальное к-во изготавливаемых продуктов кто-то занимался непонятно чем — от подбором задач и подсчетом хинкалий ?

совершенно аналогичная ситуация с архитектором.
Если он так себя ведет, то:
— команду не слушают на review и one-to-one сессиях
— никто не обращает внимание на то, что сей гражданин на совещаниях не спорит а говорит — я так сказал
— и самое главное всех устраивает вопиющий бардак, когда архитектура в теории — одна, а в реальности — другая, то есть грубо говоря каждый месяц маржа проекта ниже на раходы на так называемого архитектора
И так далее — вопиющая бездеятельность лиц, принимающих управленческие решения.

Про хинкали не понял.
То есть уволить за откровенно плохую работу почему-то не могли, а вот за то что «съел на тимбилдинге чужую еду» — сразу же?
И рубаха-парень на его месте и дальше бы бракоделил?

Про Сеню очень зашло.
1) Посадить сениор разработчика фиксить баги в системе с кривой архитектурой — это само по себе зачёт. Человек, поскольку новый, объективно не может знать, где у вас там костыли понатыканы. И такую систему, в которой при исправлении багов в одном модуле, ломается другой, давно пора просто переписать.
Просто для инфы — сениор разработчик отличается от джуна тем, что его код создаёт на порядок меньше проблем на будущее. А не тем, что не ломает какие-то другие костыли, написанные джунам, которых в проекте быть было не должно в таком виде.
2) С хинкали поржал в голос. На то он и сениор, что должен точно знать, кому сколько хинкали должны принести в ресторане. Что ещё он должен знать? Может, почему у автомобиля CEO расход увеличился?

потому что это мешает личной жизни

Какой подлый гребец, не одной работой живет, видите ли. Вы человека брали определенной квалификации, под определенные задачи. Если человек развивается — сам молодец, если нет — это его личное дело. Кроме задекларированных рабочих часов, человек не должен вам ни секунды своего времени.

Данная статья в первую очередь для тех, что считает себя «самозванцем», чтобы рассказать о самозванцах настоящих.

Я недавно гортаючи простори фб наткнувся на чудовий пост на цю тематику:

«Сьогодні мені ставили двері і вчили мене стоїцизму. Два по ціні одного.

Їх було двоє, батько і син. Я їх покликав бо мені треба було швидко, а нормальні бригади розібрані на місяці наперед. Вони і справді приїхали швидко, практично на наступний день.

Синові було років чотирнадцять, але він працював не гірше за батька. Куди вже гірше.

Вони рознесли мені півстіни, заляпали монтажною піною все навколо, криво вкрутили замок і два рази їздили по матеріали, хоч перед тим прислали мені список що їм буде треба. Але я не про це.

Вони бачили, що виходить повний швах. Вони розуміли, що те, що вони роблять — погано. Неправильно, непрофесійно, жахливо. Але їм це ні разу не зіпсувало настрій. Весь час, поки доламували залишки мого коридору, вони посміхалися і обмінювалися своїми, тільки у їхній сім‘ї зрозумілими жартами.

А під кінець, коли отвір між стіною і дверима вже набув чіткої трикутної форми, батько ще й попросив надбавку. За те, що «демонтаж виявився складнішим, ніж він очікував». З посмішкою і нерозумінням, чому б я мав не погодитися. І знаєте, я погодився.

Не за зіпсовану стіну, не за розкидану всюди штукатурку, а за гарний урок.

Про те, що синдром самозванця можна побороти, навіть коли ти і є самозванець. Що перфекціонізм, який вгризається в кістки за кожен промах, це не природній стан. Можна просто робити погано і цим насолоджуватися. Ну, чи принаймні не звертати на це уваги.

У цей дивний час, коли мільйони білих комірців сидять на віддаленій роботі, намагаючись концентруватися і картаючи себе за те, що не можуть. Коли кожна несподівана зустріч ввижається звільненням за якісь ілюзорні промахи, коли мозок усоте прокручує власні репліки у провальних переговорах, провокуючи бажання більше ніколи не вмикати мікрофон.

Коли увесь світ зійшов з розуму, тільки батько і син, які ще здатні насолоджуватися життям попри все, дають мені надію на майбутнє. Завтра знову зійде сонце. Завтра знову народяться нові люди. І батько і син завтра так само будуть розбивати в друзки чийсь коридор. При цьому задоволено посміхаючись і перекидаючись одним їм зрозумілими жартами.

За таке просвітлення, вважай, ще мало заплатив."

www.facebook.com/...​ka/posts/3857424334280483

147 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Винить работягу это последнее дело и обычно показывает плохого руководителя. Не умение отстаивать свою правоту — плохого спеца.

В примере с Сеней, никто не попытался ему помочь, а просто тупо жаловались.
В примере про архитектора никто не смог донести это до руководства.
И т.д

Читать книги в 21м веке глупость, если только это не математика и физика
Ибо на публикацию книги надо 3-5года, а за это время все что в ней становиться бесполезным.
Читать нажно исследования, статьи, мануалы, это инфа с первых рук и свежак.

То есть читать классику, художественное достояние человечества и развивать абстрактное мышление не нужно?

1) мы говорили о тех литературе.
2) развитие абстрактного мышление художкой очень сомнительно и не было никем и никогда доказано, проще говоря верование народа.
3) художку можете читать любую, но умнее она вас не сделает. умнее делает работа и решение задач. Я понимаю это сильно обидет филологов, но таков он сцуко мозг.
Ну разве что вы прям останавливаетесь и жестко переосмысливаете сказанное пытаясь наложить его на вашу реальность. Но я чето ни одного такого человека за свою жизнь не встречал.

художку можете читать любую, но умнее она вас не сделает

Художка развивает словарный запас, как минимум, плюс добавляет темы для общения. И то, и другие прокачивает скилл переговоров и убеждения, что немаловажно для нас — технарей.

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

Потому как переговоры ведуться в домене на словарном запасе именно этого домена

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

Еще не виел ни одного математика или физика который смог бы лучше обьяснить что то из-за того что читает художку.

А я видел программистов, которые знают, как правильно, а объяснить почему — не могут. Даже тут в статье описан такой типаж «Я — архитектор».

Ну и интересно.. почему именно книги? а радио или кино типа словарный запас не развивают?)

Тоже развивают, конечно, правда писать грамотно не научат. Например, разницу между ться и тся увидишь только в чтении ;)

Та не вопрос. дайте хоть одну статью которая проводит исследование что мол художка что то там сильно развивает. Простите но то что вы говорите это вера в то чего нет. Базовый курс по нейробиологии сильно поможет вам это понять.
Для справки как минимум зоны мозга которые отвечают за речь и понимание очень разные. именно по этому есть куча людей которые понимают английский но говорить не могут. и чтение книг как не странно им не помогает, а помогает лишь живое общение. А есть люди которые спокойно общаются но не могут писать. Все это разбивает ваши доводы о чтении, потому как в отличии от них является реальными фактами с подтвержденными исследованиями.

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

опять 25)) когда спор заходит в тупик все почемуто начинают проверять грамматику коментов)) давайте вы мне расскажите по каким правилам в русском языке ставяться ударения в словах))) или о правиле с птичкой которая сидит на ногах а кот сидит на жопе, а тарелка на столе стоит а в сковородке лежит)
Язык увы лепят снова таки те кто с трудом произносит слово математика, хотя теория языка — исключительно математическая наука. Но так как язык пишут доморощенные филологи, то имеем то что имеем. а точнее полную дичь и ад.
И именно по этому так тяжело встретить нормальные решения в NLP, TTS, STT для словянских языков. Потому как грабли на граблях единственно возможное решение.
А посему перед тем как говорить о грамотности написания, давайте поговорим о грамотности составления языка)
Хотя уверен агрументировать свою позицию вы не сможете.

Вы отклоняетесь от предмета спора и пытаетесь меня втянуть в полемику, где я де-факто буду в проигрыше, так как вы используете веселые трюки.

Следите за руками.

Ситуация 1:
— Художественные книги читать бесполезно
— Не согласен, книги развивают словарный запас
— Докажи исследованиями, что они что-то развивают

То есть доказывать должен почему-то не тот, кто сделал утверждение, а тот, кто с ним не согласился. Это так не работает, даже в математике и физике это работает иначе.

Ситуация 2:
— Чтение книг позволяют лучше излагать свои мысли собеседнику и вести переговоры
— Ответ про зоны мозга и речь, английский и прочее

Ответ, конечно, правильный, но не имеет отношения к изначальному утверждению. Моё утверждение было о том, что благодаря речевым оборотам и словарному запасу, полученному через книги (как и через кино и радио), можно лучше донести свою мысль до собеседника.
К тому же, раз уж заговорили об исследованиях, то было исследование, показавшее связь между чтением художки и эмпатией: www.ncbi.nlm.nih.gov/pmc/articles/PMC4733342
Это в свою очередь влияет на социальные навыки и софт-скиллс, о которых я писал в своем изначальном утверждении.

Ситуация 3:
— Видел программистов, которые не могли понятно донести свои идеи
— Нет, программист — это не хилый очкарик и инвалид, который общаться не может.

Что к чему? Непонятно.

Ситуация 4:
— Чтение книг (в отличие от радио и видео) помогает правильно писать
— Стена текста об ударениях, языках, грамотности и т.д.

Опять уход от темы.

С удовольствием продолжу дискуссию, если она будет оставаться в конструктивном ключе.

1) словарный запас что угодно развивает где есть слова.
2) эмпатия не поможет в переговорах, так как она нацелена на сопереживание а в переговорах тебе нужно давить противника. Если же речь идет об обучении то тоже. тут помогает лишь обучение. потому как толко оно позволяет эффективно учить метод копресии информации(что и есть по сути обучение)
3) есть люди которым впринципе общение с людьми вызывает дискомфорт, я вот например один из них. и не потому что я не могу донести мысль а просто потому что люди по своей природе вызывают у меня лишь желание понижать их численность.
4) уход от темы у вас был про грамотность. но что делать если сама грамотность не грамотна?) Если пользоваться вашим подходом то самый умный чувак — который заучил словарь) Увы только это не так.

«Ну и интересно.. почему именно книги? а радио или кино типа словарный запас не развивают?)»
Вот вам художка явно необходимо, о чем вы с людьми разговариваете кроме математики и решения задач?
Книги в отличии от тех же фильмов именно развивают воображения, вы читаете какую то сцену и представляете ее в своей голове, вариантов бесконечное количество и каждый человек делает это по разному.
А фильмы (особенно всякие мстители) этого не дают, выливают уже готовую картину и ты лишь потребляешь.

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

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

Назовите пожалуйста названия художки, которые вы читаете, и которая развивает словарный запас? Вот не лучшее в классике, а просто 5-10 последних прочитанных вами книг?

Мда, как по мне интеллект развивает именнно абстракция, воображение, именно это дает художка. А не просто сухая математика в тех литературе

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

Ну да, в 2 + 2 = 4 очень много абстракции))0) (нет, а в том что бы описать закат солнца или падение снега да).
Вам никогда не стать художником или музыкантом, из той же серии

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

что бы стать музыкантом вообще нада ебошить от заката до рассвета. и вбивать на уровни рефлексов очень многое. а не художечку читать. Точно так же как и художнику.

Не смог пройти мимо (((

Уровень знаний оставлял желать лучшего, но наши герои не стремились что-то изучать. «Совпадение? Не думаю». Довольно логично, если ты уже достиг наивысшего уровня мастерства, то зачем еще учиться?

Кто сказал что прочтение книги о условном деплойменте в AWS с использованием CodeBuild/CodeDeploy — поможет мне стать более грамотным ? Я предпочитаю читать первичную документацию от производителя. У нее нет автора, а если и есть — я его имени не знаю. Когда меня спрашивают что ты последнее читал, я отвечу просто журнал Охота и Охот. хозяцство за 72 год, мне интересно как оно было тогда. Если технгические книги — то хз, тех. документацию по терраформу, хелму. В моей практике топовые специ как правило офигенно пригруженны тем, что исправляют гавно оставленное по «папередников», или генерят что то новое ASAP, как бы на книги не особо времени остается, а задачи решаются по ходу дела. Вопрос не правильно поставлен — не зачем учится, а когда учится, если тебе вешают задачи по багфиксу проекта, у которого нет документации, анализ связей как правило занимает черти сколько времени, а у тебя над душой стоит автор статьи с воросами — когда уже запилишь багфикс. Совпадение — не думаю, именно отсюда и такая работа.

К сожалению, возраст и должность часто вводят в заблуждение.

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

Дело в том, что в ходе исправления Сеня одно чинил, а другое ломал.

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

Попытайтесь узнать, что думают о вас окружающие.

Зачем ? Мне как бы на работе нужно работать — а не мнение спрашивать. Если что не так — HR подойдет и скажет. Я на работе работаю — а не хороводы вожу. Это упоротый подход на работе узнавать кто и что о тебе думает. Мнение домашних и друзей я о себе и так знаю, а на работе узнавать... Ну хз.

По компетенции и адекватности специалистов вы можете судить о руководстве компании.

Таки да, к вам уже не хочу, меня пугают такие статьи и рассказы про хинкали, я заказал — мне принесли, если мне не принесли я спрошу где и вопрос задач четко сразу после увиденной тарелки у коллеги, а не буду сопли жевать в ожидании и потом рассказывать еще об этом.
Ps: ну такое, говеный менеджмент отписался о говно синьерах. Как то упустили рассказы про сыры, а так же о том что «сисньер девопсы ваще ох..ли, компенсацию просят дикую — это фраза услышанная на одной девопс конференции в Харькове на перекуре».
Качайте софт скиллы и учитесь работать с людьми — может тогда вам улыбнется счачтье и вы будете в подобрых кейсах видеть не проблемы, а возможность научится чему то новому и не по книжкам, а по реальной жизни.

Навчання це комплексна справа. Треба і документацію читати, і практично щось робити і намагатися вивчити загальні речі, підходи. Наприклад системне мислення.
А один із софтскілів, це вміння і в першу чергу бажання зрозуміти іншу людину. Якщо ви майже по всім тезам не згодні, може ви чогось не зрозуміли? ;)

Якщо ви майже по всім тезам не згодні, може ви чогось не зрозуміли? ;)

Или вы не поняли того — о чем я писал, потому как присутствует с вашей стороны эффект Даннинга — Коюгера и вы по неопытности не понимаете сути проблем, описанных вами.
Кто же спорит что обуччение это комплексный подход ? Вы пишете в статье в таком духе — как обиженный джун или менеджер, при этом вы не вникаете в суть проблемы, то есть как по мне — поверхностное суждение, а это крайне плохо как для менеджера так и для технаря, в проблемы нужно смотреть глубже. По каждому из описанных кейсов есть вопросы и очень много, но вы их описали, я бы сказал — «как мне удобно». Но тут есть люди — которые не согласны и не потому — что у них проблемы с софт скиллами, а потому как каждый кейс имеет свой фундамент и люди понимают этот фундамент (эту боль), а вы или по не знанию (не опытности, специально) его опустили, а это не правильно.

архітектор який розуміє що в нього в проект спроектований на 3 з 10 не буде читати книги. Як тільки він підніме кваліфікацію оцінка проекту знизиться до 1 з 10 і буде геть сумно.

Мені здається, що ідеальних проектів не буває. От дивишся на свій код, який писав кілька років тому, і бачиш, що можна було написати краще. Все змінюється, і ви самі повинні змінюватись на краще. Тоді покращити поточний стан продукту, з яким ви працюєте буде для вас новим челенджем, а нові знання у цьому допоможуть.

Думаю как-то так можно данную ситуацию описать:

Топовый кандидат, это болид F1 (именно машина, а не человек) — очень дорогой, высокотехнологичный, «капризный» аппарат. За ним нужно ухаживать, мониторить состояние, обеспечить командой специалистов, заливать в него высокооктановый премиальный бензин и т.п. Он способен показать максимум на идеальной трассе, с отличным покрытием. И самое главное — ему нужны соперники. Такие же крутые «болиды», способные составить конкуренцию и делающие «гонки» интересными. Если все это есть, владельцы в восторге. Подиумы, пресса, слава.

Далее все понятно. По аналогии. Приобретая крутого топ-менеджера, не ждите, что он разовьет большую скорость на ухабистой двухполоске на Окружной. Заливая в него обычный бензин, максимум оборотов не покажет. С парой криворуких механиков чуда не сделает. Скорее всего просто развалится на части. Деньги выкинуты на ветер. Разочарование. Убежденность, что «все они такие» и работать не умеют.

Но и «болиды» должны адекватно оценивать шансы «конюшни». Даже если уже ну ооочень хочется продолжить гонку. Адаптивность это конечно замечательно, но если базовые условия на три ступени ниже того, где вам действительно можно «разогнаться», вряд ли случится чудо. Скорее наоборот — полный провал и испорченная репутация.

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

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

Здесь скорее вопрос в постановке задачи — вы же Феррари не покупаете что бы мешки с картошкой возить или гонять по бездорожью. Точно так же и задачи для сениоров должны быть соответствующего уровня.
По поводу команды — полностью согласен.

Точно так же и задачи для сениоров должны быть соответствующего уровня.

Скорее тут речь идет об использовании всех задействованных ресурсов по назначению. Возить картошку и кататься по бездорожью — тоже может быть задачей, требующей спец навыков и Феррари тут не справится, это да. Только вот вы привели пример машины, над которой работает много разных людей и при этом данная машина изнашивается и заменяется по несколько раз в сезон. С сеньором должно быть строго наоборот. Это сеньору надо бы сделать так, чтобы команда работала слаженно, чтобы каждый выполнял задачи соответствующей сложности. И при этом его должно хватать надолго, ведь найм нового человека скорее всего обойдется дороже.

идеальный болид должен прийти первым и развалиться сразу за финишной линией.

В современных гонках это жёстко регламентировано. В «Формуле-1», например, жёстко ограничено количество моторов, которые команда может использовать за сезон. Одно время было даже правило «закрытого парка», когда топ-10 болидов по итогам квалификации ставились в закрытый парк и на следующий день начинали гонку в том состоянии, в котором закончили квалификацию.
Так что неа, жёсткий work-life balance гоночному болиду обеспечен обязательно. Он дорогой, поэтому должен служить долго и выдавать не только высокий, но главное, стабильный результат. Титулы будут раздавать по итогам сезона и недостаточно выиграть какую-то одну гонку.

время было даже правило «закрытого парка», когда топ-10 болидов по итогам квалификации ставились в закрытый парк и на следующий день начинали гонку в том состоянии, в котором закончили квалификацию.

Так это после квалификации. А если брать сезон, то из постоянных составляющих там только монокок, все остальные узлы и агрегаты заменяемы. И то, за сезон этих монококов сменить придётся раза 3.

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

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

Так собі приклад. Я собі так думаю, що зірки Формули1 і в трофі на джипах серед бездоріжжя будуть якщо не в топах, то точно вище середніх результатів.
Аналогічно футбольні тренери — спершу Дніпро у вищу лігу СРСР і з Порту Лігу Чемпіонів і вже тоді топові клуби.

Я собі так думаю, що зірки Формули1 і в трофі на джипах серед бездоріжжя будуть якщо не в топах, то точно вище середніх результатів.

Речь не о гонщиках, а именно о болидах.

Хз, може хтось себе і бачить конем, а я якось скоріше вершником.

Ок.
Тогда поговорим о пилотах этих болидов.
Взять любого пилота из топ команды, который выигрывает гонки и запихнуть в команду последнего эшелона на пару сезонов, в надежде, что он «поднимет её уровень».
В результате, человеку, который годами оттачивал своё мастерство выжимать максимум из высокопроизводительных машин топовых команд дают не едущее ведро, в котором нет ни нормального двигателя, ни аэродинамики ни сбалансированной подвески, ни аэродинамической трубы, ни инженеров нужного уровня, ни менеджмента, способного руководить такими инженерами, ни производственной базы, ни должного финансирования, которое могло бы обеспечить всё это. И потом обвинить его в том, что он плохой пилот, потому что плетётся позади пелотона.

потому что плетётся позади пелотона.

А з ким змагання?

Это про чемпионат мира в «Формуле-1». Соревнования с другими гонщиками и командами.

Ну от як окремий модуль ваша аналогія працює, а в інтеграції ніяк. Немає аналогії змагань, пшик :-)

Ну конечно. Конкурентной среды нет. Ни проект, ни специалист ни с кем не конкурируют.

В статье однобоко все выставлено. При том, что часть проблем показана, как бы проблемой плохих технарей, но на самом деле является проблемой плохого менеджмента.
На счет как вы видите развитие и что вы читаете прям улыбнуло :)
Что читает среднестатистический сеньор/арихтектор? Документацию и невнятные статейки на непонятных сайтах :)
Ну и да, есть же такой момент, что 50% рост выручки при 100млн меньше чем 5% рост при 1 милиарде. Это я о чем? А о том, что какой то джун быстренько набирает обороты, но посади джуна который «в теме» и сеньора который ничего не понимает в новомодном фреймверке, то за спринт, количество и качество выполненых задач будет на стороне сеньора.

Так в тому то і біда. :( Дуже часто на співбесідах з’являються люди, з досвідом 3-5 років, які нічого не читають крім окремих статей, та стековерфлоу. Але кажуть: я можу вирішити будь яку задачу. Так, окрему конкретну задачу він вирішить, але коли він вирішить 50 задач, то виникне проблема. У тому що він зробив не буде загального підходу, архітектури, буде незрозумілий код, і т. д.
Я вже багато разів втикався з тим, що наприклад розробники з кваліфікацією мідл, не можуть побудувати складну систему. Вони звісно будують, але на якомусь етапі технічний борг настільки зростає, що чим далі, тим систему важче розвивати. І перемогти це може або підвищення кваліфікації, або купа грошей.

А про розвиток, я зверху відповів — це комплекс. Треба розуміти загальні підходи, методології (наприклад DDD, ООП, TDD, патерни і т.д) . Треба знати інструмент і технологію. Тобто прочитати документацію. Треба практично щось зробити, щоб використати отриманні знання. І в кінці отримати фідбек від колег, щоб зрозуміти, що ти зробив все так. Тоді ви будете розвиватись.

Мої герої: не читали, особливо нічого не створювали, не намагались комунікувати з колегами. Який може бути розвиток?

На самом деле работать с легаси проблематично. Многое еще зависит от того, для чего было разработано ПО. В случае с мобайл, там объективно меньше кода, но умудряются и там все испортить. Для бекенда или десктопа — там все на порядок сложнее. Но опять же, это все фиксится так или иначе определенными способами. Зависит от кастомера, ПМ и квалификации команды, все должно обговариваться. Так же, если Unit тесты отсутствуют как класс, как вы поймете, что отрефакторив что-то вы не поломали в другом месте. Если девелопер постоянно что-то ломает, это диагноз. Берясь что-то фиксить, надо разобраться, прийти с определенными предложениями к менедменту/кастомеру. Если девелопер эксперт — так и сделает. Все-таки надо исходить из текущих потребностей кастомера. Что-то сделать срочно сейчас — если это для демо, потом переделать. В общем, есть методики и что-то новое тут придумать сложно.
Про хинкали — это какой-то анекдот.
Про квалификацию — украинский рынок IT перегрет, нехватка квалифицированных кадров порождает массу перекосов как в одну, так и в другую сторону. Про это тут тоже говорено-переговорено. Ибо все аутсорс-компании ориентированы на доход, как, в прочем, и продуктовые тоже. Иначе что-то делать смысла не имеет — это очевидно.
Про левелы и лычки — все это решается достаточно просто, ходите на интервью. Если оно будет проведено квалифицированно — это вам даст массу информации для для размышления.

Про хинкали и есть анекдот :) Наподобие того, каким должен быть врач.

Профессор в мединституте:
— Cейчас мы с вами, товарищи студенты, пойдём в морг на практику.
В морге:
— Итак! Врач должен быть небрезгливым и внимательным!
С этими словами профессор берёт свой палец суёт в ж#пу трупу и облизывает палец. Все студенты поморщились, но повторили.
— Молодцы! Вы не брезгливые! Но врач должен быть ещё и внимательным! Совал-то я один палец, а облизывал другой
---------------------------------

Сейчас мы товарищи программисты сходим в хинкальню на практику ;) Проверим, насколько вы внимательны ;)

Анекдот — анекдотом, но на самом деле в ситуации с данным Senior dev плохо все. Плохо, просто потому что по итогу получается некачественный продукт. И это основной постулат, который для меня, во всяком случае, самый важный. От этого можно отойти только в ситуации, если надо что-то срочно показать, но потом обязательно найти время и зафиксить. Что, в основном, потом не делается. Отсюда техдолг и костыли.
Про баги.
С моей точки зрения и опыта — чтобы как можно быстрее войти в продукт и понять, как он работает, как раз начинать надо именно с них. Что товарищ не смог коммуницировать внутри команды, то тут скорее ему не хватило или желания или soft skills. Так бывает.
Далеко не во всех системах вам дадут что-то сильно переписать, в силу определенных факторов. А то, что все приходят и начинают хейтить архитектуру, так ведь проще. Если что-то отломалось, то как бы и не текущий дев виноват, ибо костыль оставили до него. В общем, можно спорить тут долго. Но что я хотел бы больше донести, если продукт вам нравится и вы хотите сделать что-то для него, то делайте и делайте это хорошо. Это уже про ответственность. В общем идеи из книги Робина Мартина «Clean code» в помощь.

Когда ivory tower architect, то винить программистов — как раз то, что доктор прописал.

Это как бы из статьи и не очевидно. Но, если разработчик уверен, что этот человек токсичен, то уходить надо, как можно быстрее. А чтобы не зависит или минимизировать потенциальные зависимости, надо следовать определенным правилам и здравому смыслу. Лично я сталкивался с разного рода товарищами и токсичными PM и лидами. Все это потом сказывается.

Да, если б я тоже таким умным был 8 лет назад.
Оно все учится на своих шишках.

Про Сеню очень зашло.
1) Посадить сениор разработчика фиксить баги в системе с кривой архитектурой — это само по себе зачёт. Человек, поскольку новый, объективно не может знать, где у вас там костыли понатыканы. И такую систему, в которой при исправлении багов в одном модуле, ломается другой, давно пора просто переписать.
Просто для инфы — сениор разработчик отличается от джуна тем, что его код создаёт на порядок меньше проблем на будущее. А не тем, что не ломает какие-то другие костыли, написанные джунам, которых в проекте быть было не должно в таком виде.
2) С хинкали поржал в голос. На то он и сениор, что должен точно знать, кому сколько хинкали должны принести в ресторане. Что ещё он должен знать? Может, почему у автомобиля CEO расход увеличился?

Ну в том то и дело, что не сеньйора, а «сеньойра». Сам что-то толковое написать он не мог. Сеньойрной была должность, чтобы продать ёё заказчику.
Ну а хинкали это про внимательность. Я чуть выше анекдот про врачей запостил. Программист однозначно должен быть внимательным к деталям.

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

К деталям, которые имеют значение. Потому что в окружающем нас мире деталей неисчислимое множество. Но внимание нужно к менее 1% из них. И хинкали в это число явно не входят.

Сам что-то толковое написать он не мог.

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

Я чуть выше анекдот про врачей запостил.

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

Ну компетентность и должность/доход вообще, чаще всего, мало связаны. Причём это везде так, не только в IT.

Обычно обратите внимание при каких условиях и возможностях кто-то чего-то добился. И обычно компетентности там достаточно на уровне: «ну не даун, — минимальный порог прошел».

Иначе не было бы у нас некоторых «великих» руководителей, с золотыми батонами, которые не могут вспомнить ёлку. Или прочих, с дворцами, сидящих на безлимитных нефтяных деньгах и считающих себя при этом великими гениями.

IT от этого всего тоже мало чем отличается. Я знаю одного руководителя, который когда-то мне сказал «используй всегда только LEFT JOIN и никогда INNER» (т.е. не важно вообще какие задачи должен решить запрос, — просто всегда LEFT). Ну а уровень его кода это вообще обнять и плакать.

Сейчас, насколько знаю, работает тех. лидом или что-то вроде того. Как? Очень просто, — по связям.

Для общего ознакомления рекомендую книгу «Малкольм Гладуэлл — Гении и аутсайдеры. Почему одним все, а другим ничего»

Ого, как точно описали одного знакомого мне «архитектора»! Значить проблема таки не единичная.

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

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

Лол, нет. Вы получите подтверждение тому, что у вас есть способность запоминать нужные ответы и крепкая задница, чтоб просиживать ее на экзаменах.

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

Единственный смысл, который есть в наличие сертификата, это то, что собрав много красивых цветных бумажек, компания может:
a) Показать что она состоятельна, так как у нее есть много этих бумажек
б) Получить различные партнерские скидки, которые требуют оных бумажек
в) Участвовать в торгах, которые требуют предоставить тех самых бумажек

P.S. Возможно, что Сеня просто пытался сложить в уме ту хитрую комбинаторику взаимозависимых багов, не понимая, что сокращая те баги — он сокращает доходы компании. Ну и просто ел на автомате. Надеюсь, что у Сени сейчас все хорошо и ему не нужно убирать баги за джунами.

Как минимум — полноценный синьор должен издать хотя бы одну публикацию, которая сделает его брендом.

Вот у меня публикация, но она не монетизируется. ЧЯДНТ?

Хороший вопрос. Чтоб на него ответить — нужно ее увидеть. Есть ли ссылка?

www.hillside.net/...​/2020/papers/poltorak.pdf
это получилось из первой статьи для доу
dou.ua/...​cles/telecom-application

сейчас написал вторую
dou.ua/forums/topic/32636
надо подумать, куда и как ее публикнуть

Спасибо)

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

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

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

Странный вопрос. Ты меня просил найти хорошие журналы — я нашел. Но смысл ты меня искать не просил.

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

А я вот не знаю: зачем некоторые конторы так требуют обучения, если под это обучение нет задач? Как скоро человек, что постоянно учится уйдет на +500 в другое место?

По причинам озвученным мной. Мне даже предлагали просто заплатить денег, если я пройду сертификацию от имени сторонней конторы.

Цікаво, що думає з цього приводу «нашепрекрасне»

потому что это мешает личной жизни

Какой подлый гребец, не одной работой живет, видите ли. Вы человека брали определенной квалификации, под определенные задачи. Если человек развивается — сам молодец, если нет — это его личное дело. Кроме задекларированных рабочих часов, человек не должен вам ни секунды своего времени.

Тоесть вы считаете, что вам должны платить, за то что вы учитесь? :))))

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

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

Тоесть вы считаете, что вам должны платить, за то что вы учитесь? :))))

Да. Иначе конторе надо будет хайрить дорогого специалиста, и платить ему, пока он войдет в курс проекта. Кстати, обычно это занимает больше времени, чем изучение новой технологии.

Саме так. Якщо компанія зацікавлена в розвитку працівника, вона буде оплачувати курси англійської, участь в конференціях, закупівлю необхідної литератури тощо. Якщо ж компанія — жлоб, вона буде видумувати різні приводи, щоб цього не робити й тільки нити, чому це люди, які витрачають свої вільний час та гроші на свій розвиток швидко міняють цю компанію, а в неї залишаються тільки ті, кого й так все влаштовує.

Саме так, якщо компанія це в першу чергу Команда, то і компанія і працівник зацікавлені у розвитку працівника. Якщо якась із сторін починає тягнути ковдру на себе — діла не буде, рано чи пізно співробітництво закінчиться.

Думаю нельзя рассматривать описанную ситуацию с отрывом от окружающей обстановки. Скорее всего этот сотрудник просто «выгорел». А вот почему, это уже вопрос к его руководству.

Джун читает, потому что ему еще читать и читать. Что читать человеку, который 5+ лет в своем деле? Клин код пятрый раз перечитать?

Да что угодно. Просто обычно при 5+ никого уже особо не заботит кто и что читает, вот совсем. Тут уже — «у тебя слабые soft skills» и т.п. методы воздействия на психику. А джуны — бывает и не читают паскудники, причем даешь книгу — но без толку. Я бы сказал ближе к мидлу только начинают читать, когда самим приходится тянуть задачи уже. P.S. сейчас штудирую Рейнхарда Клетте «Компьютерное зрение» обзавелся всем бумажным.

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

Плюс чтение напереде априори пустая трата времени. ибо мозг так не работает. соответсвенно кпд такого обучения 10-20%

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

Ну оКлетте мне нужен для общего понимание принципов. Например как работают те же детекторы границ. Конечно велосипеды писать смысла нет виду наличия OpenCV. Чем примечательны бесцелеры — в отличие от пописулек типа «клац-клац на пистоне с тензорфлоу» они не устаревают очень долго или никогда. Можно с одного фреймверков на другой пересесть если надо, когда знаешь что по чем — а вот если не в курсе что за алгоритмы и методы скрываются за библиотечными вызовами — все очень плачевно. Тут только с стековерфлоу куски кода скачивать и дебажить — подходит или нет. Тоже вариант конечно — но далеко не всегда прокатывает.

90% здесь не знает как работает интернет и тем не менее они с ним работают и получают деньги. Я к тому что любая задача должна быть оправдана. Знать алгоритм а должен лишь тогда когда планирую его модифицировать. В остальном мне хватает знаний его специфики.

Если учить все алгоритмы в МЛ то никакой жизни не хватит. ибо они все доменные. Проще говоря вам нужно выучить всю математику и всю физику + финансы и прочее.

Что касается детекторов границ то есть более 500 алгоритмов(которе только я слышал) которые их реализуют. Но их проблема в том что они не работают глобально. как и любой алгоритм. Это всегда костыли и палки работающие здесь и не работающие там. Именно по этому все ушли в нейронки по большей части. А классик CV остально для очень специфичных задач.

И это я еще молчу о том что есть большая разница между алгоритмом в книжечке и алгоритмом в реальной жизни который оптимизируется под конкретное железе и хрен вы поймете как он работает не будучи ембедед девом)

Так что подход для понимания крайне не очень.

Ну каждому свое. Мое мнение если не понимаешь закономерностей, процессов, алгоритмов и т.д. — то по сути остаёшься темным и вообще говоря «кодерком». Если понадобится создать сам фреймверк — не создашь и, очевидно, будут большие сложности при переходе с одного фреймверков на другой и т.д. С теми же нейронными сетями — какие мне использовать? Подойдёт ли скажем Перцептрон или нужны глубокие сети, сколько поколений надо для достижения достоверного результата и т.д. и т.п.

Вот в том и суть что вы вместо того что бы послушать мнение спеца из этой области занимаетесь ерундистикой.
И хотя вы хотите все понимать, явно не понимаете самой базы. Алгоритмы — аналитическое решение, МЛ — приближенное решение. Приближенное решение нельзя посчитать аналитически, впринципе имено по сему его так никто не решает.
Вы же говорите что хотите нейронку понять аналитически. Сие увы невозможно в этой вселенной. Ну а иначе все те кто занимается попытками обьяснить работу сеток просто дибилы.

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

Но дело ваше.. хотите угробить кучу времени впустую — дерзайте

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

Подскажете книгу, которая подскажет, как лучше Андроидную ливдату кастомизировать для трансмиттинга навигационных ивентов?
Или про флоу и чэннелы в Котлин в какой книге почитать?

Доклады и статьи от Романа Елизарова, а также диссертация Никиты Коваля (когда опубликуют)
Вашу ехидность я понимаю,но не поддерживаю.

Было бы хорошо, если вы перечислите хотя бы 10% из этого гигабайта того, что вы лично прочитали от начала и до конца. Иначе откуда такая уверенность?

Просто Сеня был очень голоден, и все.

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

По теме — команде было бы неплохо озаботиться автотестами.

И не по теме — чем дольше я работаю, тем меньше смысла вижу в книгах по технологиям. Документация и исходники ( если доступны ), наше фсьо. Было бы очень интересно узнать что читают коллеги для развития профессиональной квалификации.

Ну я вот сидел в эмбедеде, сейчас читаю DDD и микросервисы. Познавательно. Хотя, те же акторы с месседжингом у нас чуть ли не с начала 90х, а энтерпрайз вот только сейчас озарился неблокирующимися проакторами netflixtechblog.com/...​king-systems-45947377fb5c

А вы в работе это применяете или просто чтобы было? У меня вообще не получается вникать в то, что мне не нужно по работе или не интересно само по себе. Завидую людям, которые могут учить что-то про запас

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

Так медиум же, отличная площадка для таких вещей

Там страшное количество статей каждый день. Разве их кто-то читает все?

Статей очень-очень много, факт. Но люди то ориентируются по тегам и соот. Ваша статья, если все корректно будет сделано и оттегировано попадет ориентированной аудитории

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

У меня вообще не получается вникать в то, что мне не нужно по работе или не интересно само по себе.

Вот тот самый редкий случай, когда я согласен с Оксаной :)
Это, кстати, причина, почему я всегда слал всех ФААНГовских рекрутёров. До сих пор не понимаю, как умение решать литкод поможет лучше делать приложения под Андроид. Если бы это хоть немного ускоряло закрытие рабочих тасков, перерешал бы его давно весь.

Я сейчас специально устроился на работу на 4 дня в неделю, чтобы было время для изучения новых вещей.

энтерпрайз вот только сейчас озарился неблокирующимися проакторами

 Ну если забыть про существование J2EE и EJB — то видимо да.

Ну у Нетфликса озарение произошло в 2016 году. Akka тоже, вроде, маркетировали как прорыв. Асинхронные операции ввода/вывода еще в 200х были «в некоторых операционных системах». При этом эмбедед на таком сидит с начала 90х. Люди переоткрывают для себя месседжинг, и пишут EAI. Люди переоткрывают акторы, и пишут Reactive Manifesto. При том, что оно все живет в параллельном мире — только штору отдернуть надо.

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

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

Наверое, буду читать через одну (следующая — clean architecture, если зайдет) если не найдется хорошая новая работа раньше

Мартін взагалі гуру :-)
І Клепман теж норм.

Якби мене запитали яку книгу раджу прочитати розробнику від рівня мідл і вище, це «Ідеальний код» Маконнелла. Фактично кілька книжок по різним темам зібрані разом.

дааа, книжка с кабанчиком, Клепман могет

Дело не в еде. Данная ситуация показывает намного больше, чем кажется. Хороший разработчик должен быть вниматеьным к деталям, хорощо коммуницировать с коллегами.
Человек не обратил внимание, не запомнил, что заказывали колеги, хотя это было прямо перед его носом. Он не смог отличить 3-4 порции еды от одной. Он не задал вопрос окружающим, не предложил поделиться, потому как миска была значительно больше нормальной порции и т. д.

Эта бытовая ситуация проказывает, что человек невнимательный, некоммуникабельный и как говорится, варится в «собственном соку». Она просто напомнила о том, что и так все знали, но перестали обращать внимание.

Я тоже не вижу смысла в книгах по конкретным технологиям — знания могут устареть на момент выхода книги. Но вот знания по методологиям, подходам к написанию кода и тестированию, архитектурные паттерны и т.д. остаются актуальными десятилетиями. И такие книги необходимо читать.

По чтению — мейл-листы, исходники, доки и конечно — профессиональные коммьюнити.
Книжки разве что по технологиям «сбоку» основной квалификации.

Виходячи з назви статті чомусь думав що Сені таки дістався спорчений хінкалі. ))) А там весь ресторан проект закривати треба.

Данная статья в первую очередь для тех, что считает себя «самозванцем», чтобы рассказать о самозванцах настоящих.

Я недавно гортаючи простори фб наткнувся на чудовий пост на цю тематику:

«Сьогодні мені ставили двері і вчили мене стоїцизму. Два по ціні одного.

Їх було двоє, батько і син. Я їх покликав бо мені треба було швидко, а нормальні бригади розібрані на місяці наперед. Вони і справді приїхали швидко, практично на наступний день.

Синові було років чотирнадцять, але він працював не гірше за батька. Куди вже гірше.

Вони рознесли мені півстіни, заляпали монтажною піною все навколо, криво вкрутили замок і два рази їздили по матеріали, хоч перед тим прислали мені список що їм буде треба. Але я не про це.

Вони бачили, що виходить повний швах. Вони розуміли, що те, що вони роблять — погано. Неправильно, непрофесійно, жахливо. Але їм це ні разу не зіпсувало настрій. Весь час, поки доламували залишки мого коридору, вони посміхалися і обмінювалися своїми, тільки у їхній сім‘ї зрозумілими жартами.

А під кінець, коли отвір між стіною і дверима вже набув чіткої трикутної форми, батько ще й попросив надбавку. За те, що «демонтаж виявився складнішим, ніж він очікував». З посмішкою і нерозумінням, чому б я мав не погодитися. І знаєте, я погодився.

Не за зіпсовану стіну, не за розкидану всюди штукатурку, а за гарний урок.

Про те, що синдром самозванця можна побороти, навіть коли ти і є самозванець. Що перфекціонізм, який вгризається в кістки за кожен промах, це не природній стан. Можна просто робити погано і цим насолоджуватися. Ну, чи принаймні не звертати на це уваги.

У цей дивний час, коли мільйони білих комірців сидять на віддаленій роботі, намагаючись концентруватися і картаючи себе за те, що не можуть. Коли кожна несподівана зустріч ввижається звільненням за якісь ілюзорні промахи, коли мозок усоте прокручує власні репліки у провальних переговорах, провокуючи бажання більше ніколи не вмикати мікрофон.

Коли увесь світ зійшов з розуму, тільки батько і син, які ще здатні насолоджуватися життям попри все, дають мені надію на майбутнє. Завтра знову зійде сонце. Завтра знову народяться нові люди. І батько і син завтра так само будуть розбивати в друзки чийсь коридор. При цьому задоволено посміхаючись і перекидаючись одним їм зрозумілими жартами.

За таке просвітлення, вважай, ще мало заплатив."

www.facebook.com/...​ka/posts/3857424334280483

Саме так, не переймайтесь, якщо чогось не знаєте, усього знати не можна. :)

Але мова в першу чергу про адекватність: людина яка не вміє будувати, не може називатись будівельником. З іншого боку, якщо батько і син адекватно себе оцінюють, але продовжують робити те, що вони роблять, то це шахраї, які обманюють людей. Тому автора поста просто «розвели». Звісно добре якщо він від цього отримав задоволення, але так буває далеко не завжди.

Блін аж хінкалів захотілось:)

Про хинкали не понял.
То есть уволить за откровенно плохую работу почему-то не могли, а вот за то что «съел на тимбилдинге чужую еду» — сразу же?
И рубаха-парень на его месте и дальше бы бракоделил?

Дык, не новая позиция, были на Dou такие орелики, вот к примеру:

— Это правда, что вы оцениваете, насколько человек вписался в компанию, спрашивая, сколько он завел здесь друзей?

О.Р.: Да, это один из пунктов в нашем ежеквартальном опросе. И у нас достаточно высокое количество друзей у каждого человека в компании. Друг — это тот, с кем ты встречаешься вне работы. Для нас это важный показатель, потому что если у тебя много друзей в компании, то, во-первых, это значит, что тебе здесь нравится. Во-вторых, ты больше друзей сюда пригласишь. В-третьих, ты никуда не уйдешь. И самое лучшее, когда друзья из разных команд, тогда получается очень хорошее взаимопонимание, когда, например, продавец может просто подойти к инженерам и спросить, как это работает, а не думать, что он «альфа», а они гики. Хороший пример — наш ведущий продавец по глобальным аккаунтам Max James, который только что вернулся из отпуска. И в отпуск он ездил не на Гавайи или в Мексику. Он решил поехать в Киев на 10 дней, не для работы, а потому что у него среди наших киевских инженеров куча друзей.

dou.ua/...​views/rogynskyy-peopleai

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

Вы как-то странно прочитали эту ветку дискуссии. Я ничего не путаю. Я как раз обращаю внимание на комментарий Oleksandr Nogai в контексте неадекватности практики такого рода, обратите внимание как он обозначит корень проблемы:

То есть уволить за откровенно плохую работу почему-то не могли, а вот за то что «съел на тимбилдинге чужую еду» — сразу же?
И рубаха-парень на его месте и дальше бы бракоделил?

Я согласен, что это проблема и уволить такого гражданина стоило бы раньше. И то, что руководство этого не сделало, тоже несколько неадекватно. Но, как по мне, ставить её в один ряд с настолько жёстким примером неадекватности, как «вы должны дружить вне работы», это уже перегиб. Вот о чём я.
Хотя наверное это моё субъективное восприятие и на самом деле здесь аксиома Эскобара.

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

Я відповів вище. Ситуація просто нагадала про проблему, до якої усі звикли і намагались не звертати уваги.

Как вы оцениваете свою квалификацию?
Как вы учитесь и чего планируете достичь?

А как Вы оцениваете свою квалификацию задавая такие вопросы :-)?

P. S. Вопрос из контор где денег платить не будут.

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

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

Блин, мне кажется я даже знаю этого "Сеню"...Наслышан.

Группа разделилась на Senior и Middle. И ответы на второй вопрос четко коррелировали с ответом на первый.

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

Дуже неоднозначне твердження.
Самоосвіта і пов"язане з цим НЕ обов"язково займає багато часу, більше того, якщо це розмірений поставлений процес, то займатиме годину-півтори на день, які можна запросто виділити. Само собою, що якщо тобі треба опанувати нову технологію за тиждень перед співбесідою, то сім"я буде заважати.

Дуже часто сім"я створює основу, коли в тебе є визначені години в які ти повинен щось зробити і є години для роботи. Так от, розуміючи який час і на що має йти, набагато менше хочеться лінуватись і прокрастинувати ніж коли в тебе весь час вільний і знаєш, що в будь-який момент можна полежати на дивані.

Может пока мидлы самоосвищаються, сеньоры тащатся проект? ;)

Сіньйор який один раз щось вивчив, потім працює і не вчиться, так-собі сіньйор.

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

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

Дуже неоднозначне твердження.

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

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

В принципі згоден, все впирається в самоорганізацію і тайм-менеджмент.

Багато кому ( Мені в тому числі ), важко тримати режим і ефективно самоорганізовуватись щодня, особливо, якщо нема наблажаючихся дедлайнів. А сім"я може створити той фрейм, навколо якого можна щось ефективно будувати щодня.

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

Спорно. По своему опыту могу сказать обратное т.к. именно поддержка девушки, в последствии жены, и помогла))

Друга девушка вытянула из басиста в автотестера

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

нда мораль проста: сколько сотрудники не жалуйся руководителям все равно пока у них пельмень не сожрут, статья шлак

если чиня одно, можно что-то сломать и этого не заметить, значит Сене досталась галера с легаси говнокодом, низким % покрытия автотестами (если они вообще есть) и отсутствием сервера непрерывной интеграции. и уволить в первую очередь нужно было девелопмент менеджера или кто у них там главный по процессам, потому что он не смог организовать дев.процесс правильно. с другой стороны Сеня (или другие программисты) могли бы поставить вопрос об отсутствии CI/CD тулчейна и тестов.

Не, проще сказать что Сеня во всем виноват, так как съел чужие хинкали.

Я — король!

а я — Король :-)

кэп

капітан дирижабля — youtu.be/1YzfooJ7hFY?t=316

Олег Зигфридович? Вы ли это? :)

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

Вот к примеру, в истории с последним:
— я что-то плохо понял, а что тестов не было ? или % покрытия был плохой ?
или сами тесты были плохие ?
Потому что если бы было нормальное покрытие и нормальные бы тесты, то гениальный патч отправил был в мусор на уровне прогонки
Но вместо того, чтобы заниматься свои делом управленца — а именно, что навести порядок в команде и обеспечить минимальное к-во изготавливаемых продуктов кто-то занимался непонятно чем — от подбором задач и подсчетом хинкалий ?

совершенно аналогичная ситуация с архитектором.
Если он так себя ведет, то:
— команду не слушают на review и one-to-one сессиях
— никто не обращает внимание на то, что сей гражданин на совещаниях не спорит а говорит — я так сказал
— и самое главное всех устраивает вопиющий бардак, когда архитектура в теории — одна, а в реальности — другая, то есть грубо говоря каждый месяц маржа проекта ниже на раходы на так называемого архитектора
И так далее — вопиющая бездеятельность лиц, принимающих управленческие решения.

совершенно аналогичная ситуация с архитектором.

Не совсем так.
Смотрите. Чего, собссно, надо менеджеру?
Все эти технологии, тесты и прочая замануха? Нифига. Он даже может не знать, что это такое.
Единственное, что он хочет знать — это когда пофиксят вот этот баг или когда вот эту фичу допилят. Притом интересуется он этим только в том контексте, что это влияет на продажи его продукта. А как именно оно будет сделано — его вообще не парит.
И если этот архитектор может обеспечить указанные сроки — он менеджера будет устраивать на 100%. А то, что команде не нравятся авторитарные решения — дык проблемы индейцев шерифа не волнуют :)

Если было так, как Вы написали — я бы согласился бы.

Но давайте разберемся.
Дело в том, что исходя из данных рассказа и предоставленной информации, в том и соль, что НЕ может и НЕ делает.
Его работу выполняет кто-то из команды и реальная архитектура отличается от той, что нарисована у этого персонажа
Вот в чем соль то. Посмотрите к примеру:

Нередко программная система и архитектурная картинка отличались.

и автор прямо пишет, какие от этого были проблемы:

Однако финансовые ресурсы компании позволяли сглаживать дополнительным «железом» или людьми все недочеты.

Поэтому простите, не могу с вами согласится.

А то, что команде не нравятся авторитарные решения — дык проблемы индейцев шерифа не волнуют :)

это работает не всегда просто потому как нанимать другую команду чаще дорого чем на оборот

Шериф вполне начнёт волноваться, когда «индейцы» заявят ему, положив заявление оффер на стол, что не готовы больше работать со столь авторитарным вождём.

Волновать-то будет. Может быть. Но не архитекта, а менеджера. А архитекту-то что? Были одни индейцы, пришли другие :)

Так я об этом в конце статьи и написал :) Люди работали в структуре, потому как ей соответствовали. Если одну из сторон что-то не устраивает — всегда можно растаться. Если в структуре работает программист, который не умеет программировать, то это характеризует в первую очередь организацию и ее лидера, а не самого программиста.

Подписаться на комментарии