Сравнение на 5 из 5 просто. В конторах с серьезной инженерией точно так же есть аналитики, архитектор и далее по тексту. И математик есть, и технолог даже. Никто не пилит серьезный (и коммерчески успешный) rocket science в одиночку в гараже.
Опыт вникания нужно экстраполировать на отношения между любыми коллегами. Каждый должен понимать, чем живут другие. Иначе получается не команда, а пачка премудрых пескарей по норам. Имел несчастье оказаться в такой. Ну и продукт будет так себе.
Но изменились ли стандарты за это время? Идею декомпозиции кода формализовала Банда Четырех аж в 1994 году. Потом в 2000 году Мартин формализовал свой SOLID. То есть 10 лет назад уже были вменяемые гайды на написание чистого кода - но в энтерпрайзе их предпочитали не замечать.И до сих пор предпочитают, но сейчас уже бОльшему числу людей понятно что так жить нельзя.
Ой как жизненно. Работал я в одной конторе и своими глазами видел адовый говнокод десятилетней выдержки за авторством людей, который на момент моего присутствия были уже начальниками отделов и департаментов.
Кроме шуток - это сильно меня впечатлило. После такоого я, честное слово, стараюсь писать код так, чтобы меня спустя 10 лет никто плохим словом не поминал.
Ну то есть, резюмируя, вы уходите от именно беседы. И двигаетесь по направлению к Яндексу и его фрейдовской фиксации на литкоде и собесам в 5 этапов. Колесо изобретено.
Прямой путь к постоянному регрессу. И с QA быстро отношения испортятся. Они взяли на проверку кейс А, а вы попутно нарефакторили еще и кейсы В и С, на которые ресурсы никто не выделял.
Я связываю вал статей про выгорание с общей инфляцией корпуса специалистов в IT. Как известно, стать сеньором-помидором теперь можно всего за 3 месяца курсов. Как следствие - квалифицированный разработчик вместо разработки занимается подтиранием слюней за курсантами-разрабами, курсантами-QAшниками, курсантами-аналитиками и даже курсантами-ПМами. И тут реально вопрос, как не взвыть волком.
Меня не покидает ощущение, что эти регулярные рейтинги языков являются студенческими курсовыми работами по теме умения сбора и агрегации открытых данных. Потому что вроде работа проведена, результат есть (зачет получен) - а применимость его нулевая. Ну вот кто задается вопросом "питон или джаваскрипт или может быть джава", кроме очередных вайтишников? Это же инструменты из разных областей.
Все равно что сравнивать популярность танков и легковых машин. Легковушки явно популярнее - но какая нам польза от этого знания?
Видимо, в вашем представлении "правильный" рынок IT - это когда каждый с нуля изобретает велосипеды. Каждая контора пишет свою ОС, свои протоколы, электронику себе сама паяет - и поэтому всем позарез нужны исключительно программисты-доктора наук, а манки-кодеры отсутствуют как класс
Но за границами мира пони и единорогов вполне нормально, когда десяток человек в гугле изобретает свой Golang, а миллионы им пользуются. Проблема тут только у обитателей мира пони и единорогов, которым не нравится, что не каждый разраб может изобрести свой голанг, перемножая трехмерные матрицы в уме.
Перефразируя Карлина: "Рынок в порядке. Это у вас проблемы"
Да, все так. Но мысль-то Ваша в чем, кроме смакования слов "манки кодинг", пошлого снобизма и поглаживания ЧСВ? Рынок таков, что на 1 системного программиста нужно 100 программистов-ремесленников без умения перемножать матрицы. Нам всем следует за это перед Вами извиниться?
НИИ битком забиты физиками и математиками - джунами которые неспособны открыть теорему или частицу а могут только писать водянистые документы из-под палки.
Действительно, вот лузеры. Я сегодня открыл 2 штуки пока на работу шел - делов-то.
Также - если заказчик самостоятельно внятно составил свои требования, которые понятны команде разработчиков, QA и дизайнеров, то зачем тратить деньги на аналитика?
А если младенец сам умеет готовить еду и гулять, то можно не тратить деньги на няню. Но увы. Часто вам такие заказчики попадались?
У меня есть опыт работы в команде без аналитика вообще. Жить-то, конечно, можно, но быстро приходим к тому, что аналитиком становится самый грамотный разработчик или QA. Естественно, без всяких доплат.
Хорошая практика: делать подробное описание, которое включает в себя причины, по которым нужна эта задача, и описание решения с пояснением, почему задача решалась именно таким путем.
Противоречит первому же пункту. Если изменения действительно вносятся атомарно, то их не приходится сопровождать портянкой чейнжлога. Иначе автоматически возникают или вопросы к декомпозиции задачи, или к невменяемому неймингу, или к оверхеду в решении.
Какая животрепещущая лично для меня тема. К сожалению, за 7 лет в разработке встретилось всего пара аналитиков, которым по итогу работы хотелось пожать руку. Остальные по факту оказывались джунами-копирайтерами, которые только и могли что переносить мысль "делайте хорошо, плохо не делайте" из головы заказчика в задачу в джире.
Для себя выделил 3 критических пункта:
В разработке ПО нет слова "подразумевается". Подразумеваться могут только стандарты вроде использования HTTP в рестовой архитектуре. Поэтому в ТЗ должны быть даже те вещи, которые лично вам кажутся трижды очевидными. Разработчик не имеет (пока) доступа к вашему разуму.
Нужно обязательно хотя бы в общих чертах понимать архитектуру современных систем, модели и протоколы их взаимодействия. Иначе в ТЗ гарантированно будет оторванная от реальности дичь и испорченные отношения с инженерами
В статье сказано про "энциклопедию проекта" - а я добавлю, что еще необходим и глоссарий проекта. Одна и та же вещь в разных местах проекта должна называться одинаково. Это должно быть закреплено на самом верху и строго соблюдаться повсеместно.
Негатив в комментах связан с тем, что обобщена частность. Сейчас действительно выделился класс систем, для построения которых скорее нужен бэкендер-аналитик нежели олдскульный бэкендер-хардкорщик.
Например, все мы наблюдали взрывной рост приложений, предлагающих доставку продуктов из супермаркета. Так вот соль такой системы в грамотно спроектированном домене и в архитектуре, заточенной под постоянное горизонтальное расширение. То есть сначала очень плотная работа по аналитике, а потом довольно рутинная, но аккуратная разработка (то самое перекладывание джейсонов). Прорывных алгоритмов тут ноль, инженерного новаторства ноль. Просто грамотный ремесленный труд и сборка продукта из готовых кирпичиков.
Другой полюс - это фреймворки, либы, высококритичные приложения. Тут софт-скиллы скромно уходят на второй план, и вылезает реальная потребность в computer science.
Описанное вами умозаключение есть "ошибка выжившего". Универсальным советом это быть никак не может. Особенно с учетом всех рисков.
Меня вот поражают эти советы стажерам идти во фриланс.
Во-первых, там за дешманский фриланс конкуренция ничуть не меньше, чем за джуновские позиции.
Во-вторых, кто является заказчиком дешманского фриланса, если не кроила? Тут скорее соберешь портфолио историй "как меня кинули".
В-третьих, это в целом равносильно совету новичку-охотнику пойти на медедя в одиночку с ножом. Ага, зато портфолио соберешь.
Сравнение на 5 из 5 просто. В конторах с серьезной инженерией точно так же есть аналитики, архитектор и далее по тексту. И математик есть, и технолог даже. Никто не пилит серьезный (и коммерчески успешный) rocket science в одиночку в гараже.
Опыт вникания нужно экстраполировать на отношения между любыми коллегами. Каждый должен понимать, чем живут другие. Иначе получается не команда, а пачка премудрых пескарей по норам. Имел несчастье оказаться в такой. Ну и продукт будет так себе.
Но изменились ли стандарты за это время? Идею декомпозиции кода формализовала Банда Четырех аж в 1994 году. Потом в 2000 году Мартин формализовал свой SOLID. То есть 10 лет назад уже были вменяемые гайды на написание чистого кода - но в энтерпрайзе их предпочитали не замечать.И до сих пор предпочитают, но сейчас уже бОльшему числу людей понятно что так жить нельзя.
Ой как жизненно. Работал я в одной конторе и своими глазами видел адовый говнокод десятилетней выдержки за авторством людей, который на момент моего присутствия были уже начальниками отделов и департаментов.
Кроме шуток - это сильно меня впечатлило. После такоого я, честное слово, стараюсь писать код так, чтобы меня спустя 10 лет никто плохим словом не поминал.
А мне кейс очень даже понятен. Задан открытый вопрос - но внезапно ожидается конкретный ответ. Ну тогда это уровень "угадай, какое число я загадал".
А девушка или не девушка - в тот момент это был человек на зарплате, исполняющий свои профессиональные обязанности.
Ну то есть, резюмируя, вы уходите от именно беседы. И двигаетесь по направлению к Яндексу и его фрейдовской фиксации на литкоде и собесам в 5 этапов. Колесо изобретено.
Прямой путь к постоянному регрессу. И с QA быстро отношения испортятся. Они взяли на проверку кейс А, а вы попутно нарефакторили еще и кейсы В и С, на которые ресурсы никто не выделял.
Я связываю вал статей про выгорание с общей инфляцией корпуса специалистов в IT. Как известно, стать сеньором-помидором теперь можно всего за 3 месяца курсов. Как следствие - квалифицированный разработчик вместо разработки занимается подтиранием слюней за курсантами-разрабами, курсантами-QAшниками, курсантами-аналитиками и даже курсантами-ПМами. И тут реально вопрос, как не взвыть волком.
Меня не покидает ощущение, что эти регулярные рейтинги языков являются студенческими курсовыми работами по теме умения сбора и агрегации открытых данных. Потому что вроде работа проведена, результат есть (зачет получен) - а применимость его нулевая. Ну вот кто задается вопросом "питон или джаваскрипт или может быть джава", кроме очередных вайтишников? Это же инструменты из разных областей.
Все равно что сравнивать популярность танков и легковых машин. Легковушки явно популярнее - но какая нам польза от этого знания?
ошибся веткой
Видимо, в вашем представлении "правильный" рынок IT - это когда каждый с нуля изобретает велосипеды. Каждая контора пишет свою ОС, свои протоколы, электронику себе сама паяет - и поэтому всем позарез нужны исключительно программисты-доктора наук, а манки-кодеры отсутствуют как класс
Но за границами мира пони и единорогов вполне нормально, когда десяток человек в гугле изобретает свой Golang, а миллионы им пользуются. Проблема тут только у обитателей мира пони и единорогов, которым не нравится, что не каждый разраб может изобрести свой голанг, перемножая трехмерные матрицы в уме.
Перефразируя Карлина: "Рынок в порядке. Это у вас проблемы"
Да, все так. Но мысль-то Ваша в чем, кроме смакования слов "манки кодинг", пошлого снобизма и поглаживания ЧСВ? Рынок таков, что на 1 системного программиста нужно 100 программистов-ремесленников без умения перемножать матрицы. Нам всем следует за это перед Вами извиниться?
Действительно, вот лузеры. Я сегодня открыл 2 штуки пока на работу шел - делов-то.
А если младенец сам умеет готовить еду и гулять, то можно не тратить деньги на няню. Но увы. Часто вам такие заказчики попадались?
У меня есть опыт работы в команде без аналитика вообще. Жить-то, конечно, можно, но быстро приходим к тому, что аналитиком становится самый грамотный разработчик или QA. Естественно, без всяких доплат.
Противоречит первому же пункту. Если изменения действительно вносятся атомарно, то их не приходится сопровождать портянкой чейнжлога. Иначе автоматически возникают или вопросы к декомпозиции задачи, или к невменяемому неймингу, или к оверхеду в решении.
Какая животрепещущая лично для меня тема. К сожалению, за 7 лет в разработке встретилось всего пара аналитиков, которым по итогу работы хотелось пожать руку. Остальные по факту оказывались джунами-копирайтерами, которые только и могли что переносить мысль "делайте хорошо, плохо не делайте" из головы заказчика в задачу в джире.
Для себя выделил 3 критических пункта:
В разработке ПО нет слова "подразумевается". Подразумеваться могут только стандарты вроде использования HTTP в рестовой архитектуре. Поэтому в ТЗ должны быть даже те вещи, которые лично вам кажутся трижды очевидными. Разработчик не имеет (пока) доступа к вашему разуму.
Нужно обязательно хотя бы в общих чертах понимать архитектуру современных систем, модели и протоколы их взаимодействия. Иначе в ТЗ гарантированно будет оторванная от реальности дичь и испорченные отношения с инженерами
В статье сказано про "энциклопедию проекта" - а я добавлю, что еще необходим и глоссарий проекта. Одна и та же вещь в разных местах проекта должна называться одинаково. Это должно быть закреплено на самом верху и строго соблюдаться повсеместно.
Вы математиков ищите? Или вы тоже исповедаете замшелую точку зрения, что программист == математик?
Согласен с основным тезисом, но уверяю вас, что тысячи приложений успешно пишутся даже без тени знания о перемножении матриц.
Негатив в комментах связан с тем, что обобщена частность. Сейчас действительно выделился класс систем, для построения которых скорее нужен бэкендер-аналитик нежели олдскульный бэкендер-хардкорщик.
Например, все мы наблюдали взрывной рост приложений, предлагающих доставку продуктов из супермаркета. Так вот соль такой системы в грамотно спроектированном домене и в архитектуре, заточенной под постоянное горизонтальное расширение. То есть сначала очень плотная работа по аналитике, а потом довольно рутинная, но аккуратная разработка (то самое перекладывание джейсонов). Прорывных алгоритмов тут ноль, инженерного новаторства ноль. Просто грамотный ремесленный труд и сборка продукта из готовых кирпичиков.
Другой полюс - это фреймворки, либы, высококритичные приложения. Тут софт-скиллы скромно уходят на второй план, и вылезает реальная потребность в computer science.