Умеют же некоторые разводить на ровном месте стены текста, вместо простых ответов.
Итак, выявляем проблему:
Раз:
скорость работы миддла не удовлетворяла руководство, хотя качество его кода было высоким.
Два:
приводило к перманентному перенапряжению всех разработчиков.
Причина у этого одна, и называется она — спешка. Все вот эти вот «быстрей-быстрей, дедлайны горят!»
Решается она через приучение руководства планировать. Горят сроки? — Учитесь планировать.
И еще нужно учитывать существование определенного типажа руководителя — «всегда мало». Такой руководитель будет недоволен всегда — сделали проект за год — медленно, надо было за пол года. Сделали за полгода — медленно, надо было за месяц. Сделали за месяц — медленно, надо было за неделю. И т.д.
Состав команды, их реальная скорость разработки не играет никакой роли. Программистов всегда будут торопить, ставить неадекватные дедлайны, и ругать.
Таких руководителей надо уметь быстро выявлять и прощаться с ними.
Почему каждой компании нужны младшие разработчики
И дальше идет какая-то стена воды…
Джуны нужны в двух случаях:
1. Есть много рутинной работы
2. Способ проверки ИТ отдела. Если после появления джуна, в проекте стало больше багов и говнокода, а тимлид на это отвечает «ну это все новый джун» — значит, процесс разработки выстроен неправильно. В нормальном процессе, с ревью кода, с тестами, с CI/CD «система» не позволит плохому коду попасть в продакшен.
Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.
О боже, сколько можно пропагандировать это мировоззрение «хороший код vs требования бизнеса»
Классическая ситуация, в которую приходит компания, когда им «нет дела, до идеального кода, надо просто чтобы работало», это:
Закостыленный легаси проект
Старая команда, которая это писала — ушла, потому что одно дело — писать костыли, и другое дело — поддерживать и развивать проект написанный на костылях
Новых хороших разработчиков нанять невозможно — они сходу понимают суть работы, и отказываются
Разработка замедляется до уровня «одна фича в пол года»
Подбор команды — большая тема для отдельной статьи. Простое решение — воспользоваться услугами компаний, которые специализируется на запуске IT-проектов и смогут подобрать вам команду из необычных программистов, которые каждую новую версию делают профессионально, но при этом готовы к большим переделкам, так как запустили уже более десятка проектов.
Аутсорс — это самое дно разработки. Если уж советуете аутсорс как простое решение — добавляйте, что сразу нужно закладывать, что это будет прототип, который можно будет запустить, проверить метрики и интерес аудитории, а потом, в случае успеха — нужно будет писать проект нормально, с нуля.
Аутсорс как раз хорошая школа для всех, кто считает, что «хард скиллы не важны, важны софт скиллы» — вот там с вами будут вежливо общаться, будут делать только то, что вы захотите (если клиент не просит писать автотесты — их и не пишут), и будут максимально клиенто-ориентированными.
Вот только результатом (на большом отрезке времени) почему-то всегда недовольны…
Найти причины большого числа ошибок в каждой новой версии продукта
Много ошибок может быть только там, где не пишут тесты (или пишут для галочки). А тесты не пишут, когда «быстрей-быстрей, срочно-срочно!» — добро пожаловать в замкнутый круг. Впрочем, ничего удивительного — «Скупой платит трижды»
Внедрение CI/CD даст ускорение на 10-20%
Крупный проект был без настроенного CI/CD? Забавно. А куда смотрел тим-лид? Или компания захотела сэкономить, и взяла тим-лида по цене милда? Ну, в общем, как обычно.
P.S.
На мой взгляд инструкцию можно сократить до двух пунктов:
СЕО должен разбираться в разработке. Например, вырасти из программиста. Нет ничего печальнее, чем руководитель разработки, который ничего не понимает в разработке, и может полагаться только на то, что сказал тот или иной «синьер»
СЕО должен уметь общаться с владельцами бизнеса. С одной стороны, говоря им правду — что современная разработка, это сложно и дорого, и надо сразу «спуститься с небес и не ожидать чуда», но делать это так, чтобы желание финансировать проект не пропало. Как только СЕО стал соглашаться на неадекватные требования владельцев бизнеса (а они по умолчанию неадекватны — они далеки от разработки также, как луна от земли) — можно закрывать проект.
Я понимаю, что все это спорная вещь, и люди будут говорить — да ну нахер ваш F#. Можно по разному относиться, но один хороший F# разработчик реально может заменить двух средних сишарперов.
Большую роль для бизнеса играет заменяемость программистов — т.е. возможность в удовлетворительные сроки найти нового программиста.
С редкими же языками, работодатель становится заложником программиста — замену найти ему он не сможет (в адекватные сроки). В такой ситуации хорошо только программисту.
Если у тебя есть поле для экспериментов, например совсем свежий стартап, то можно взять неплохих сишарперов, научить их F#.
Не все согласятся.
Впрочем, это не отменяет того, что новые, более лучшие языки нужно пытаться создавать (как говорится — если не пробовать, то и не получится), и пропагандировать.
Быть одним из создателей языка программирования — это вершина карьеры софтверного инженера, и лучшая мечта, какая только может быть у программиста.
Очень субъективная точка зрения.
Для меня — язык программирования это просто инструмент. Инструмент для создания чего-либо. И то, что программист может сделать и сделал с помощью инструментов — вот это показатель.
Собственно язык программирования — это тоже продукт сделанный на других яп. Просто для узкой группы пользователей.
Теперь не надо мечтать открыть круто работающую систему, надо мечтать выклянчить себе релокейт и убедить толстосума из долины вложиться в какой-нибудь мусор, про который ты ухитрился рассказать ему первым.
Опять же, очень субъективно, и автор явно не пытался сделать что-то, что займет многие годы разработки в свое свободное время — потому что выдержать такой путь, не сдаться в пути, не опустить руки и не потерять мотивацию можно только тогда, когда главная мотивация — не деньги. Когда нравится сам процесс, и просто хочется что-то сделать свое.
Есть известное видео, общения Стив Джобса и Билл Гейтса, где их спрашивают — а что самое главное. И они оба отвечают в одном ключе — что главное — когда нравится заниматься тем, чем занимаешься. Потому что на пути будет 100500 трудностей, и деньги имеют решающее значение далеко не всегда.
P.S.
Статья вызывает следующую ассоциацию:
Воспитанный и умный человек попадает в гоп-компанию, где все говорят, что бухать это круто, и начинают хвалиться, кто сколько литров может выпить.
А потом, автор, пораженный до глубины души, возвращается в свой обычный круг общения, и говорит «а представляете, что они говорят?!» — да, представляем, и знаем, что это полная чушь. И спорить с ними смысла нет. Как там говорят — умный и так знает, а дураку объяснять бесполезно.
Живу с болями в пояснице уже 6 лет (после острой фазы, не считая еще лет 5 нарастания болей).
Чтобы я сказал себе лет 10 назад:
Подбери удобное кресло. Это действительно очень важно и на 90% избавляет от фоновых болей при сидячей работе. Практика показала, что самый лучший вариант — подбирать кресла на работе, так как там их обычно много разных (если у вас на работе только один тип кресел — не повезло).
Кто-то может возразить, что простые офисные кресла хуже каких-нибудь навороченных. Но вот моя практика показывает обратное. Мое текущее кресло, которое очень удобное и поясница на нем не болит — встретил именно на работе. После чего купил себе аналогичное домой. До этого сидел на классическом игровом кресле, которое и дороже, и вроде как должно лучше помогать, на деле — нет.
Завести привычку хотя бы час в день прогуливаться. Много лет пришлось промучиться с болями, прежде чем я заметил закономерность — если работаю в офисе, и езжу на работу по 2 часа в день — болей меньше. Стоит перейти на удаленку из дома — где постоянное сидение — боли сразу нарастают. Позже заметил разницу и между «часом езды в одном поезде», и «часом езды с двумя пересадками и пешими переходами» — последний намного лучше. А часовое стояние в поезде наоборот убивает поясницу.
Упражнения и зарядки тоже полезны, но очень много времени приходится потратить на то, чтобы подобрать именно те упражнения, которые будут помогать вам. Так что тут советовать что-то конкретное нельзя.
Бывает даже так, что одни упражнения вначале помогают. А через 3-4 года уже нет — боли наоборот только нарастают.
Ну и самое главное, помните — если у вас начались небольшие боли — и если ничего не делать — они будут только нарастать. И чем позже вы начнете заниматься своим позвоночником — тем сложнее будет восстановиться (хотя есть мнение, что восстановиться вообще нельзя, лично я способа восстановиться не нашел, нашел только способ как убрать боли и жить более-менее обычной жизнью, а про обычный спорт и тренажерные залы пришлось забыть). По этому даже небольшие боли в пояснице — это очень серьезный повод заняться собой.
Тем более, как написал вначале — простая покупка удобного кресла и регулярные прогулки уже сильно помогут вашей спине.
Ну автора конечно можно только пожалеть. Вроде позиционирует себя как знатного девелупера с опытом работы и при этом влететь как зеленый студент — это конечно что-то :)
А при чем тут опыт разработки и умение разбираться в людях?
Я в разработке с 2008 года, сталкивался с похожей у автора ситуацией в 2018. И что?
Начал следить за темой когда еще в Китае было около 1000 официально зараженных.
Вначале относился к этому с веселым скептицизмом, типа «еще один свиной грипп», но, чем дальше я наблюдаю за ситуацией — тем меньше у меня остается этого «веселья».
Помимо безмерного количества потраченного времени и нескольких сотен тысяч рублей — недавно ушла девушка (кому нужен парень, который вместо того, чтобы проводить свободное время как «нормальный человек», продолжает сидеть за компом)
Так что, сюжет «делали-делали и не сделали» — далеко не самый плохой.
Привыкнуть к такому шуму невозможно — негативный эффект от неблагоприятного окружения со временем только растет.
Соглашусь. Довелось поработать в опенспейсе на ~100 человек — через 3 месяца ужасной непродуктивной работы просто сорвался криком на тим-лида из-за мелочи. На этом работа в той компании и закончилась, к счастью.
В том то и дело — что где-то их держать так и так нужно — либо в голове, либо на бумаге, либо в коде.
И лично мне, сильно проще накидать 10 объектов сразу в коде, как-то их связать по-быстрому, и уже из получившегося — думать и развивать дальше.
Видимо я человек которому важно оперировать реальными сущностями. И сразу получать фактический результат. А не так, что «я в уме прикинул, все будет работать»
За последний год делал несколько попыток писать по TDD (т.е. вначале тесты) — и каждый раз ничего не получалось.
Все эти примеры, с элементарными объектами — все конечно здорово, но если в реальности мне нужно писать модуль, который будет состоять из десятков объектов, сотен публичных методов — все становится совсем непросто.
Ведь самое главное, в TDD — это на 100% понимать какие публичные методы будет иметь объект(ы) (и, соответственно, взаимодействовать с другими объектами), а это, при разработке больших модулей весьма сложно. Нет, можно конечно пару недель просидеть исключительно за листочками бумаги, и детально расписывать объекты и их взаимодействие, делать детализацию до каждого метода, и конкретного функционала… Но, извините меня, кто на работе такое может себе позволить — за пару недель не написать ни строчки кода?
Я вот не могу. Соответственно мой единственный путь — прикинуть примерную структуру — начать писать код, и следом на него тесты. Постепенно добавляя новый функционал, расширяя/изменяя существующий код и дописывая тесты.
P.S. Ну и на практике наибольшая сложность — в принципе доказать, что тесты нужны, когда руководство хочет только «быстрей-быстрей-срочно-срочно»
На собеседовании с копеечной зарплатой (а в России 95% зарплат копеечных, даже в ИТ), и вижу там требования супер-стар-сеньера — то ухожу с улыбкой «ну, удачи в поисках».
Мы, программисты, без работы в любом случае не останется.
Да ещё портфолио, а у тебя давно уже нет желания что-то писать для себя после работы, а если и пишешь, то абы как, лишь бы скорее закончить, иначе не закончишь никогда.
А вам точно нравится ваша работа?
Я как раз наибольшее удовольствие от программирования получаю дома, когда пишу что-то для себя.
И да, оно никогда не заканчивается (всегда есть что написать нового/переписать старого) — но если это приносит удовольствие — в чем проблема?)
В 2012 мой товарищ предложил мне заняться бизнесом по импорту автомобилей из Кореи.
Разработчик решил войти в банальный бизнес купи-продай? Там тысячи таких как вы. Шанс найти незанятую прибыльную нишу равен почти нулю.
Мне сразу пришла в голову мысль сделать софт для анонимизации и получения доступа к любым ресурсам в интернет
Уже теплее. Но это нормально, что не выстрелило. 90% идей не выстреливает, если не больше.
В 2015 мы с женой, по совместительству юристом, открыли компанию по оказанию юридических услуг.
Опять. Разработчик решил войти в нишу услуг?
ИТ это развивающаяся сфера. Машинное обучение — так вообще передовое. Выбирайте нормальные сферы для себя (разработчика) сферы. И пробуйте, пробуйте, пробуйте.
Конечно, все не так просто, как в историях успеха, но если не пробовать — то ничего точно не получится.
Не увидел совета (для всех очевидно?), что в именовании таблиц стоит хорошенько думать о префиксе, чтобы когда таблиц станет 100+ все они удобно группировались в виде:
Итак, выявляем проблему:
Раз:
Два:
Причина у этого одна, и называется она — спешка. Все вот эти вот «быстрей-быстрей, дедлайны горят!»
Решается она через приучение руководства планировать. Горят сроки? — Учитесь планировать.
И еще нужно учитывать существование определенного типажа руководителя — «всегда мало». Такой руководитель будет недоволен всегда — сделали проект за год — медленно, надо было за пол года. Сделали за полгода — медленно, надо было за месяц. Сделали за месяц — медленно, надо было за неделю. И т.д.
Состав команды, их реальная скорость разработки не играет никакой роли. Программистов всегда будут торопить, ставить неадекватные дедлайны, и ругать.
Таких руководителей надо уметь быстро выявлять и прощаться с ними.
И дальше идет какая-то стена воды…
Джуны нужны в двух случаях:
1. Есть много рутинной работы
2. Способ проверки ИТ отдела. Если после появления джуна, в проекте стало больше багов и говнокода, а тимлид на это отвечает «ну это все новый джун» — значит, процесс разработки выстроен неправильно. В нормальном процессе, с ревью кода, с тестами, с CI/CD «система» не позволит плохому коду попасть в продакшен.
О боже, сколько можно пропагандировать это мировоззрение «хороший код vs требования бизнеса»
Классическая ситуация, в которую приходит компания, когда им «нет дела, до идеального кода, надо просто чтобы работало», это:
Аутсорс — это самое дно разработки. Если уж советуете аутсорс как простое решение — добавляйте, что сразу нужно закладывать, что это будет прототип, который можно будет запустить, проверить метрики и интерес аудитории, а потом, в случае успеха — нужно будет писать проект нормально, с нуля.
Аутсорс как раз хорошая школа для всех, кто считает, что «хард скиллы не важны, важны софт скиллы» — вот там с вами будут вежливо общаться, будут делать только то, что вы захотите (если клиент не просит писать автотесты — их и не пишут), и будут максимально клиенто-ориентированными.
Вот только результатом (на большом отрезке времени) почему-то всегда недовольны…
Много ошибок может быть только там, где не пишут тесты (или пишут для галочки). А тесты не пишут, когда «быстрей-быстрей, срочно-срочно!» — добро пожаловать в замкнутый круг. Впрочем, ничего удивительного — «Скупой платит трижды»
Крупный проект был без настроенного CI/CD? Забавно. А куда смотрел тим-лид? Или компания захотела сэкономить, и взяла тим-лида по цене милда? Ну, в общем, как обычно.
P.S.
На мой взгляд инструкцию можно сократить до двух пунктов:
Большую роль для бизнеса играет заменяемость программистов — т.е. возможность в удовлетворительные сроки найти нового программиста.
С редкими же языками, работодатель становится заложником программиста — замену найти ему он не сможет (в адекватные сроки). В такой ситуации хорошо только программисту.
Не все согласятся.
Впрочем, это не отменяет того, что новые, более лучшие языки нужно пытаться создавать (как говорится — если не пробовать, то и не получится), и пропагандировать.
Очень субъективная точка зрения.
Для меня — язык программирования это просто инструмент. Инструмент для создания чего-либо. И то, что программист может сделать и сделал с помощью инструментов — вот это показатель.
Собственно язык программирования — это тоже продукт сделанный на других яп. Просто для узкой группы пользователей.
Опять же, очень субъективно, и автор явно не пытался сделать что-то, что займет многие годы разработки в свое свободное время — потому что выдержать такой путь, не сдаться в пути, не опустить руки и не потерять мотивацию можно только тогда, когда главная мотивация — не деньги. Когда нравится сам процесс, и просто хочется что-то сделать свое.
Есть известное видео, общения Стив Джобса и Билл Гейтса, где их спрашивают — а что самое главное. И они оба отвечают в одном ключе — что главное — когда нравится заниматься тем, чем занимаешься. Потому что на пути будет 100500 трудностей, и деньги имеют решающее значение далеко не всегда.
P.S.
Статья вызывает следующую ассоциацию:
Воспитанный и умный человек попадает в гоп-компанию, где все говорят, что бухать это круто, и начинают хвалиться, кто сколько литров может выпить.
А потом, автор, пораженный до глубины души, возвращается в свой обычный круг общения, и говорит «а представляете, что они говорят?!» — да, представляем, и знаем, что это полная чушь. И спорить с ними смысла нет. Как там говорят — умный и так знает, а дураку объяснять бесполезно.
Чтобы я сказал себе лет 10 назад:
Кто-то может возразить, что простые офисные кресла хуже каких-нибудь навороченных. Но вот моя практика показывает обратное. Мое текущее кресло, которое очень удобное и поясница на нем не болит — встретил именно на работе. После чего купил себе аналогичное домой. До этого сидел на классическом игровом кресле, которое и дороже, и вроде как должно лучше помогать, на деле — нет.
Упражнения и зарядки тоже полезны, но очень много времени приходится потратить на то, чтобы подобрать именно те упражнения, которые будут помогать вам. Так что тут советовать что-то конкретное нельзя.
Бывает даже так, что одни упражнения вначале помогают. А через 3-4 года уже нет — боли наоборот только нарастают.
Ну и самое главное, помните — если у вас начались небольшие боли — и если ничего не делать — они будут только нарастать. И чем позже вы начнете заниматься своим позвоночником — тем сложнее будет восстановиться (хотя есть мнение, что восстановиться вообще нельзя, лично я способа восстановиться не нашел, нашел только способ как убрать боли и жить более-менее обычной жизнью, а про обычный спорт и тренажерные залы пришлось забыть). По этому даже небольшие боли в пояснице — это очень серьезный повод заняться собой.
Тем более, как написал вначале — простая покупка удобного кресла и регулярные прогулки уже сильно помогут вашей спине.
А при чем тут опыт разработки и умение разбираться в людях?
Я в разработке с 2008 года, сталкивался с похожей у автора ситуацией в 2018. И что?
Вначале относился к этому с веселым скептицизмом, типа «еще один свиной грипп», но, чем дальше я наблюдаю за ситуацией — тем меньше у меня остается этого «веселья».
Думаю, что будет проще сослаться на пока единственный пост на пикабу
P.S. Надеюсь оставляя ссылку никакие правила не нарушаю)
Помимо безмерного количества потраченного времени и нескольких сотен тысяч рублей — недавно ушла девушка (кому нужен парень, который вместо того, чтобы проводить свободное время как «нормальный человек», продолжает сидеть за компом)
Так что, сюжет «делали-делали и не сделали» — далеко не самый плохой.
Соглашусь. Довелось поработать в опенспейсе на ~100 человек — через 3 месяца ужасной непродуктивной работы просто сорвался криком на тим-лида из-за мелочи. На этом работа в той компании и закончилась, к счастью.
И лично мне, сильно проще накидать 10 объектов сразу в коде, как-то их связать по-быстрому, и уже из получившегося — думать и развивать дальше.
Видимо я человек которому важно оперировать реальными сущностями. И сразу получать фактический результат. А не так, что «я в уме прикинул, все будет работать»
Все эти примеры, с элементарными объектами — все конечно здорово, но если в реальности мне нужно писать модуль, который будет состоять из десятков объектов, сотен публичных методов — все становится совсем непросто.
Ведь самое главное, в TDD — это на 100% понимать какие публичные методы будет иметь объект(ы) (и, соответственно, взаимодействовать с другими объектами), а это, при разработке больших модулей весьма сложно. Нет, можно конечно пару недель просидеть исключительно за листочками бумаги, и детально расписывать объекты и их взаимодействие, делать детализацию до каждого метода, и конкретного функционала… Но, извините меня, кто на работе такое может себе позволить — за пару недель не написать ни строчки кода?
Я вот не могу. Соответственно мой единственный путь — прикинуть примерную структуру — начать писать код, и следом на него тесты. Постепенно добавляя новый функционал, расширяя/изменяя существующий код и дописывая тесты.
P.S. Ну и на практике наибольшая сложность — в принципе доказать, что тесты нужны, когда руководство хочет только «быстрей-быстрей-срочно-срочно»
Российские магазины не в курсе про падение цен :)
Это лишь значит, что про срочность вам наврали)
Менеджеры любят так делать — нагнетать сроки и дедлайны, чтобы разработчики были в тонусе (или в стрессе).
Ой, не льстите себе.
На собеседовании с копеечной зарплатой (а в России 95% зарплат копеечных, даже в ИТ), и вижу там требования супер-стар-сеньера — то ухожу с улыбкой «ну, удачи в поисках».
Мы, программисты, без работы в любом случае не останется.
А вам точно нравится ваша работа?
Я как раз наибольшее удовольствие от программирования получаю дома, когда пишу что-то для себя.
И да, оно никогда не заканчивается (всегда есть что написать нового/переписать старого) — но если это приносит удовольствие — в чем проблема?)
Разработчик решил войти в банальный бизнес купи-продай? Там тысячи таких как вы. Шанс найти незанятую прибыльную нишу равен почти нулю.
Уже теплее. Но это нормально, что не выстрелило. 90% идей не выстреливает, если не больше.
Опять. Разработчик решил войти в нишу услуг?
ИТ это развивающаяся сфера. Машинное обучение — так вообще передовое. Выбирайте нормальные сферы для себя (разработчика) сферы. И пробуйте, пробуйте, пробуйте.
Конечно, все не так просто, как в историях успеха, но если не пробовать — то ничего точно не получится.
users
user_group
user_status
…
products
product_type
product_status
…
Иначе, когда таблиц становится много, а названия идут в разнобой — product_type, status_product — становится ужасно неудобно с ними работать.