Комментарии 23
Хороший разработчик в первую очередь должен уметь писать хороший код.
Очень хороший разработчик должен уметь писать плохой код. С полным пониманием того, какие углы срезал и какой ценой. Собственно, чтобы осмысленно писать плохой код, надо сначала научиться писать хороший. А чтобы научиться писать хороший код, надо написать много плохого. Собственно, Programming, Motherf*cker
Хороший разработчик должен уметь (по возможности) выбрать наилучший инструмент для решения конкретной задачи. И это не всегда будет тот инструмент, которым он сейчас хорошо владеет. Может оказаться доступным что-то иное, более эффективное, и стоит потратить время на его изучение.
Ну и лучше тот разработчик, который попробовал себя в самых разных (иногда даже радикально разных) областях разработки, а не "пилил" (пусть и достиг в этом неимоверного совершенства) всю жизнь примерно одно и то же.
Сомнительно.
Хороший разработчик не возьмется за задачу, которую не сможет сделать. На определенном уровне приходит понимание - все делать хорошо не получится. Если это не моя задача - пусть ее сделают другие профессионалы. Потому использовать инструмент, которым ты плохо владеешь для решения конкретной задачи... Нет, это скорее признак хорошего разработчика, а человека страдающего (а может быть и наслаждающегося?) юношеским максимализмом.
Да, должен быть баланс. Да, надо расти. Во всех направлениях. Правда злоупотреблять "радикально разными" точно не стоит. Скорее осваивать не тропинку, а сектор. Но в одном, когда-то давно выбранном направлении. И с каждым шагом тот сектор будет становиться все шире, и шире, и шире. И вот уже площадь этого сектора становится сильно больше площади круга, в котором мечутся постоянно меняющие направление...
Впрочем, вариант убежать далеко по узкой тропинке - он тоже допустим. Без такого варианта не было бы Эйнштейна и Теслы Как подавляющего большинства современных классиков практически в любой отрасли знаний.
что такое "хороший разработчик" можно обсуждать бесконечно долго, примерно столько же как "хорошая лошадь", разные проекты бывают со своими требованиями, но в той области, где Вы судя по всему работаете, есть хорошая метрика - как легко и быстро проходит отладка нового кода, если все уже продумано, и работает как ожидалось, это говорит о многом
Вам никогда не приходилось менять область деятельности? Мне вот приходилось. И, могу сказать, что это очень много дает. И в плане "невыгорания" и в плане расширения кругозора. Иногда это бывает и полезно и интересно.
И вот внезапно обнаруживается, что опыт разработки, накопленный в другой области внезапно оказывается полезным и в новой. Причем, не в плане именно кодирования, а плане каких-то общих подходов и алгоритмов - в том, чем разработка от кодирования отличается.
И в новой области могут быть какие-то новые инструменты. Вот ими не надо пренебрегать, натягивая сову знакомых инструментов на глобус новой области деятельности. С этим тоже сталкивался.
Вам никогда не приходилось менять область деятельности?
возможно вопрос ко мне тоже слегка относится, если так, то да конечно, стресса тоже выше среднего, embedded systems, и сети - супер долго, переключение между ответственными проектами одна из причин выгорания, обычно новые инструменты по мере необходимости
Вам никогда не приходилось менять область деятельности?
Радикально нет. Мой сектор колеблется от силовой и автоэлектрики, через промышленную электронику с микроконтроллерами, через телефонию и прочие связные темы, через VHDL, через сетевые интерфейсы разных генезов (CAN, ModBus, IEEE802.15, IEEE802.11) до BSP Linux и AOSP с драйверами (местами даже под Windows). И да, стаж на сегодня почти 25 лет. Как бы то не было это все же сектор.
Нет, я баловался конечно вебом, знаком с ООП, но это не те вещи, про которые я могу уверенно сказать "знаю". А вот чего-то типа JAVA, геймдева, мобильной разработки, финтеха, BigData, AI и прочих диаметрально удаленных тем у меня не было. Если честно, то и не стремлюсь. Своего сектора хватает с головой. И все время я в разработке или постановке на производство. Реально очень редко когда в сопровождении. И каждый раз при получении ТЗ задача кажется нерешаемой...
Да, безусловно - знание смежных отраслей помогает. Как и понимание ограничений того или иного решения. Но смежные отрасли все равно, как правило, имеют очень схожий инструментарий. Колун дровокола, топоры дровосека и плотника настолько похожи внешне, что для многих это просто топор. Хотя каждая из названных специализаций использует свой. И даже навык работы с инструментом у каждой свой (хотя, безусловно, и похожий). И да, валить лес топором сегодня стоит только в очень специальных случаях. Как правило бензопила справляется лучше. Тут все довольно очевидно.
Вообще я даже не знаю завидовать или сочувствовать тем, кто (вынужденно?) диаметрально меняет направление работы. Я никак не могу отделаться от мысли, что это просто ошибка планирования. Пусть и собственной жизни. Хорошо, когда она исправляется. Но хорошо ли то, что она исправляется на регулярной основе? Я не знаю и не берусь судить. Наверное, люди нужны разные. Собственно по этой причине мой спич и начался не с категорического "Нет!" а с нейтрального "Сомнительно".
Ну что сказать...
Еще до того, как совсем уйти в разработку, занимался написанием разного рода программ для анализа экспериментальных данных (это конец 80-х - ни про какие матлабы тогда не слышали еще). Статистический анализ, регрессионный анализ и т.п.
Потом ушел в разработку совсем и первое место работы - анализ торгов на товарной бирже. Выявление закономерностей всяких по позициям и т.п. Там тоже математики было - группы, множества и т.п. Ну и немного БД откуда данные брать.
Потом встрял в разработку системы мониторинга инженерного оборудования зданий. Это уже первая половина 90-х. В то время не то что аналогов не было, не было мысли что так вообще можно. Сейчас это назвали бы стартапом, тогда слов таких не было.
Все с нуля - архитектура, железо, софт, даже пользовательские интерфейсы (концепции) придумывали с нуля.
Занимался этим достаточно долго - система прошла очень длинный путь развития. От локальной до распределенной.
А потом вдруг позвали в банк. Центральные сервера на платформе IBM i. Тут много БД, много замысловатой бизнес-логики и высокие требования по эффективности. И выяснилось, что тут, конечно, есть привычные и С и С++, но писать все это на них дело очень муторное. А какой-то суперпроизводительности не получается по сравнению с существующим на этой платформе специально для этого предназначенным RPG - на нем все это пишется и проще и результат по эффективности хорош. Не стал упираться в С/С++, освоил RPG. Поому что на нем тоже самое проще делается. Хотя некоторые вещи до сих пор на С/С++. Там, где это выгоднее и удобнее, благо, тут есть замечательная вещь - интегрированная языковая среда (ILE) позволяющая в одной программе использовать одновременно несколько языков.
И могу сказать, что многие вещи, которые освоил на прошлой работе, пригодились и здесь Не в плане конкретного языка, но общих подходов. Как писать быстрый и эффективный код. Как организовать межпроцессное взаимодействие в распределенных системах... Много чего именно по общим принципам, подходам, техникам. Которое от конкретного языка не зависит... Да, была боль первые месяца полтора, когда во все это въезжал (с сама система ни на что не похожа), но все это преодолимо (и даже интересно - заставляет мозги на полную включать, а не просто по привычным дорожкам шариться).
И да. Многие задачи поначалу кажутся нерешаемыми (т.е. решение-то есть, но оно не удовлетворяет по скорости - никому не нужен процесс, который будет работать двое суток, а вот когда придумаешь как с другой стороны зайти и оно за 15 минут тоже самое делает - это радует).
Хорошо делай, не хорошо не делай.
Всегда было интересно узнать, как они понимают что уже сеньоры и могут раздавать "хорошие советы" ? Им их мама о том говорит ?
Хороший текст, полезно, со многим согласен, многое видел на практике. Но пожалуйста, прекратите (это просьба к будущим статьям на хабре) вставлять мемы, особенно гифки-мемы. Отвлекает жутко. Толи на мем смотреть, толи вчитываться.
Почему-то всегда думал, что для ИИ используют python, а не C++.
ИИ это не только обучить модельку и сделать презентацию. Как минимум, ИИ -- это огромное количество расчетов, для которых (внезапно) питон оказывается медленным. Так, например ядро Triton Inference Server почти на 90% написано на C/C++.
Кроме того, ИИ не только в облаках но и на устройствах, в том числе весьма ограниченных по производительности, где тоже нужно делать embedded решения.
Ну да, ну да... И жнец, и швец, и на дуде игрец. Знать всё и очень глубоко, чтобы заменить пять-шесть позиций в штате одной зарплатой... Вот это и называется "сверхэксплуатация". Непрерывно изучать супер-пупер костыли, которые отмирают через пару лет из-за появления супер-гипер костылей и при этом использовать 3% процента их возможностей... Плодить миллион ЯП под каждую конкретную задачу.... Пахать сутками напролет, зарабатывая кому-то немерянное бабло. Не пора ли в консерватории что-то подправить?
Где это разработчик получает неимоверное бабло? Неважно, хороший он разработчик или плохой? Разработчик - это наемный работник. Что считается "неимоверным баблом"? 😁 Для кого-то предел мечтаний - тыща баксов, для кого-то - десять (тысяч). Но это же копейки. Чтобы получать миллионы, надо быть не разработчиком...
Список технологий, который обязательно надо изучать, странный. Изучать регулярные выражения или запросы sql? Чего там изучать, тем более в эпоху чатгпт. Базы данных тоже далеко не везде нужны. Ну и прочее сомнительно, тем более для неначинающего разработчика
Понятно, что автор — большой поклонник фильма «Безумный Макс». Но с гифками в статье явный перебор. Это мельтешение просто мешает читать
Что значит быть хорошим разработчиком: 11 полезных советов от сеньора