Pull to refresh

Comments 33

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

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

Я думаю, что это ошибочный совет. Нужно не перестать обращать внимание на это чувство, а использовать его, чтобы разобраться в чём дело. Ведь не спроста же оно возникло? Я недавно размышлял на тему возникновения этого чувства и пришёл к следующему выводу. Когда вы учитесь программировать по книгам или в институте, то при формулировке задачи пытаетесь найти набор ключевых слов, которые подскажут вам решение или применение тех или иных технологий. Но в задачах, которые вам попадаются в реальной жизни может не быть знакомых вам ключевых слов, либо они будут использованы в неверном контексте, что ещё больше сбивает с толку. Так что по-хорошему, чтобы вернуть себе чувство уверенности, нужно научится правильно интерпретировать задачу в свой опыт. А опыт у вас есть уже с рождения.
Добавлю: но не перестарайтесь с возвратом уверенности. Большая уверенность тоже плохо. Как говорится: лучше перебдеть, чем недобдеть.
Я уже давно замечаю, что хороший код и метафизика взаимосвязаны. :)
Идеальный код недостижим так же, как невозможно ответить на вопрос о первичности материи и духа)
Так его в принципе и невозможно написать, т.к. всё зависит от контекста. Так что хорошая постановка задачи всё-таки важнее. Выходит, что дух первичнее? )
Грубоватый вывод, но да, так. Я почти всегда был идеалистом
Никогда не понимал советов изучать новые языки. Если они в основном только синтаксисом отличаются, то это относится к мишуре, как сам автор и написал. Конечно, какая то польза будет, но будет и вред — начнешь путаться в синтаксисе. Видимо, автор тут плохо выразил свою мысль.
Я бы на его месте советовал изучать парадигмы программирования. А новый язык стоит изучать, если он построен на неизученной парадигме.
Хоть это и более долгий путь, но было бы также полезным поизучать другие отрасли программирования. Например, в геймдеве чаще предпочитается использование композиции вместо наследования, что позволяет избегать сложных иерархий классов и зависимостей.

C# и Java да, можно сказать только синтаксисом, но справедливо ли так говорить про Go и Haskell, например?

Об этом strannik_k и сказал — изменение парадигмы. C# и Java — ОО парадигма, Haskell — функциональная, Go — вообще говоря, процедурный.
UFO landed and left these words here
Да, отличаются синтаксисом, но зачем городить здоровенный огород на одном языке, если эту же задачу можно решить на другом языке парой-тройкой операторов. Можно ведь вообще только на Си прогать или на асме)
Платформа, например. Обычно, всё-таки, нельзя придти в проект на php/java/.net и сказать «а вот тут, мы будем использовать отдельную программу на питоне».
Разумное замечание, но внутри платформы тоже бывают языки с кардинально разной спецификой, скажем, c# (любимый) и APL касательно оперирования массивами
Rust отличается от «обычных ЯП» очень сильно. И не только синтаксисом, а парадигмой и мышлением. Требуется вывихнуть себе мозг для того, чтобы начать на нем программировать, но потом начинаешь получать кайф от того, что намного лучше понимаешь, как работает программы, где лежат данные, у кого на них есть ссылки и так далее.

Композиция вместо наследования много где предпочитается, это один из советов банды четырех.

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

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


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


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

Спасибо за перевод! Очень вдохновляющая статья.

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

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

Работая в одной команде и одном стеке технологий годами, можно застрять в развитии.

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

Ну и на своей работе, стараться выбирать себе задачи посложнее и требующие изучения новых областей. Так ваш профессиональный уровень быстро вырастет.
Интересный совет, это из личного опыта?
C чего начать? Как находить и забирать небольшие, но интересные проекты «на вечер»?
При условии отсутствия какого-либо опыта с фрилансом конечно же.
Не обязательно именно фриланс, можно к какой-то команде присоединиться парт тайм. Но всё зависит от области. Если это web, то на любой фриланс бирже можно найти небольшие задачки. Если это, к примеру, gamedev, то там сложно небольшие задания найти.
Да, из личного опыта.

Как начать — зарегистрироваться на бирже фриланса. Брать можно небольшие проекты, либо сайты «на поддержку». В основном заказчиков интересует, сколько часов в неделю можете работать. Кого-то может устроить неспешная работа по выходным и час-два в будни.
От себя могу порекомендовать брать эпизодически фриланс-проекты, даже если у вас есть постоянная работа.
Работая в одной команде и одном стеке технологий годами, можно застрять в развитии.
Я поэтому обычно советую менять место работы раз в пару лет. Это в любому случае хорошо бы делать, чтоб получить повышение з/п, так как редко можно особо большую прибавку выбить на текущем месте.

От себя могу добавить несколько пунктов:
1) Не растекайтесь мыслью по древу. Сконцентрируйтесь на 1 области. Не языке, а именно области. Сейчас всё очень компактно и локанично. Нету того, что все всё пишут на С и без него никуда.
2) Примите, как правило, что существуют реальные задачи, которые можно решить за 1-2-4 часа. Не превращайте изучение технологий в прожигание часов и дней. Если вы не можете что-то понять или выучить за 1-2-4 часа, то решайте конкретно эту проблему. А не "ночку посижу, поучу и пойму".
3) Отдыхайте. Человеческий мозг плохо работает после 3-4 часов неприрывной нагрузки.
4) Добейте уже до конца слепую печать. Если еще не добили.
5) Правило 21 дня. Привычка прививается за 21 день. Это касается всего. Иностранного языка, качества кода, питания, сна и вообще всего. Если у вас есть проблема в работе, то её можно исправить за 21 день. Если не исправилось, то значит проблема в другом.
6) Поборите рассеянность и перестаньте отвлекаться.
7) Не берите работу на дом.
Идеализированно получилось, но если убрать бытовые причины и ссоры с коллегами и коллективом, то работает.


Советы из статьи реально странные:"Я стал лучше программировать из-за того, что всё время стал учить С, писать GCC и читать СЕКП". Понятно, что чтобы лучше программировать нужно больше программировать. Но про перегорание не сказано. А оно лечится не просто. И посреди проекта взять и слинять на месяц никто не даст.

UFO landed and left these words here
по тексту скорее «костыли»…
А как Вы относитесь к мысли о том, что всё уже украдено написано до нас. И я думаю, что со мной многие согласятся в том, что разработка сейчас и разработка лет 10 назад — это две большие разницы. Сейчас всё сводится к банальному увязыванию между собой горстки библиотек и плагинов/экстеншенов к ним.
Если бы все было придумано до нас — ребята из DevExperts нe парились бы с алгоритмами поиска гонок в многопоточных приложениях (доклад с TMPA-2014) :) Да и банальные HtmlElements появились все же не 10 лет назад, если мне не изменяет память. JetBrains тоже время от времени что то придумывает и имплементирует (все тот же TMPA-2014) в области анализа языков.

Возможно, вы просто не в той области смотрите? Попробуйте посмотреть на область тестирования и верификации программного обеспечения. Там интересно и есть чем заняться.
Only those users with full accounts are able to leave comments. Log in, please.