Comments 32
Никогда не понимал разделения на кодинг и программирование. IMHO, это просто стадии развития программиста.
Работа джуниуром — это легко, но если хочется двигаться дальше, то придется включать голову.
Работа джуниуром — это легко, но если хочется двигаться дальше, то придется включать голову.
Ну, например, я бы сформулировал так:
Кодинг — умение воплотить алгоритм, используя определенный язык.
Программирование — умение создать алгоритм.
Кодить довольно просто — запомнил синтаксис, и вперед.
Программировать сложнее. Нужно думать не только, как достичь результата, но и сделать это оптимальным образом (зависит от обстоятельств).
Кодинг — умение воплотить алгоритм, используя определенный язык.
Программирование — умение создать алгоритм.
Кодить довольно просто — запомнил синтаксис, и вперед.
Программировать сложнее. Нужно думать не только, как достичь результата, но и сделать это оптимальным образом (зависит от обстоятельств).
А где в вашей схеме находятся:
1. Умение соблюдать соглашения по коду, комментировать код, коммиты, писать юнит-тесты и т.д.
2. Умение создавать читаемый код и работать в команде.
3. Знание типовых проблем и стоимости их решения.
4. Владение навыками защитного программирования.
5. Просто широкий кругозор — знания из смежных областей.
6. Умение пересматривать свой опыт.
1. Умение соблюдать соглашения по коду, комментировать код, коммиты, писать юнит-тесты и т.д.
2. Умение создавать читаемый код и работать в команде.
3. Знание типовых проблем и стоимости их решения.
4. Владение навыками защитного программирования.
5. Просто широкий кругозор — знания из смежных областей.
6. Умение пересматривать свой опыт.
Запомнил синтаксис и вперед — вот это как раз и есть джуниор. Опыта набраться шансов пока не было, но начинать с чего-то надо. То, что отдельные личности застревают на этом уровне на всю жизнь, не превращает кодинг в какое-то отдельное направление разработки.
Между джуниором и действительно высококлассным программистом существует градиент промежуточных стадий. Что дает потенциальную возможность презрительно отзываться о тех, кто находится на более низких уровнях профессионального развития, как о «кодерах». Но это уже не про программирование, а про почесывание самомнения.
Между джуниором и действительно высококлассным программистом существует градиент промежуточных стадий. Что дает потенциальную возможность презрительно отзываться о тех, кто находится на более низких уровнях профессионального развития, как о «кодерах». Но это уже не про программирование, а про почесывание самомнения.
Нанимал пачку джуниоров и синьоров — иные синьоры хуже иных джуниоров. Так что это никак не относится к опыту.
Просто люди выдавали себя не за тех, кем являлись.
У меня вот тоже был как-то момент, когда я пытался сунуться в php-прграммисты, имея хорошее резюме и довольно большой опыт, но совсем в другой сфере. Да, опыта мне хватило, чтобы за неделю с нуля нахвататься основ и выполнить тестовое задание. Но на собеседовании, полагаю, произвел как раз впечатление «хуже иных джуниоров». Правда и претендовал далеко не на сеньора.
У меня вот тоже был как-то момент, когда я пытался сунуться в php-прграммисты, имея хорошее резюме и довольно большой опыт, но совсем в другой сфере. Да, опыта мне хватило, чтобы за неделю с нуля нахвататься основ и выполнить тестовое задание. Но на собеседовании, полагаю, произвел как раз впечатление «хуже иных джуниоров». Правда и претендовал далеко не на сеньора.
Смогли бы вы ответить на вопрос: «Чем список отличается от массива?»
Вот никогда не понимал, почему вопросы такого типа являются безусловным маркером уровня программиста. Загуглить ответ — 5 минут, прочесть и понять, ну пусть еще час. При наличии опытного товарища, ответ на вопрос займет 15 минут. И что спрашивается, показывает если соискатель ответил? и что знание ответа на этот вопрос дает? Книжку Кормена прочел два с половиной года назад, за два этих года ну ни разу, кроме как на собеседованиях, это сакральное знание не понадобилось.
И предвещая вопрос, я примерно мидл в фулстак разработке.
И предвещая вопрос, я примерно мидл в фулстак разработке.
Это антимаркер, потому как вопрос уровня старших классов средней школы. И если претендент не знает даже таких очевидных вещей, то в лучшем случае его стоит расспросить подробнее.
Отсутствие ответа на этот вопрос — индикатор того, что знания структур данных у человека нулевые.
Senior Developer должен иметь представление о том что это такое.
Наличие ответа — не индикатор ничего. Всего лишь возможность продолжить дискуссию.
Senior Developer должен иметь представление о том что это такое.
Наличие ответа — не индикатор ничего. Всего лишь возможность продолжить дискуссию.
> Вот никогда не понимал, почему вопросы такого типа являются безусловным маркером уровня программиста. Загуглить ответ — 5 минут, прочесть и понять, ну пусть еще час. При наличии опытного товарища, ответ на вопрос займет 15 минут.
Если программист не знает, как устроены и чем отличаются структуры данных в его языке, значит он не может делать между ними осмысленный выбор и пишет код как придётся, а не как надо. Поэтому работать работу скорее возьмут его опытного товарища.
Если программист не знает, как устроены и чем отличаются структуры данных в его языке, значит он не может делать между ними осмысленный выбор и пишет код как придётся, а не как надо. Поэтому работать работу скорее возьмут его опытного товарища.
На каком языке и в каком контексте? :)
Безотносительно языка.
Как так-то?
Если вообще… То мне придётся вспомнить то, что изучал более 20 лет назад в чистом виде, без привязки к языку и контексту никогда не использовал. И не уверен, что вспомню что-то похоже на ту правильную формулировку, которую ожидает вопрошающий. Меня такой вопрос на собеседовании напряжёт, и даст понять, что меня тут заранее не уважают.
Но всё же, мой ответ был бы в духе «список — структура с последовательным доступом, а массив с произвольным», хотя я точно знаю, что в C# внутри List лежит Array…
Если вообще… То мне придётся вспомнить то, что изучал более 20 лет назад в чистом виде, без привязки к языку и контексту никогда не использовал. И не уверен, что вспомню что-то похоже на ту правильную формулировку, которую ожидает вопрошающий. Меня такой вопрос на собеседовании напряжёт, и даст понять, что меня тут заранее не уважают.
Но всё же, мой ответ был бы в духе «список — структура с последовательным доступом, а массив с произвольным», хотя я точно знаю, что в C# внутри List лежит Array…
Меня такой ответ вполне устроил бы. Даже если бы вы на доске нарисовали квадратики со стрелочками — тоже. Далее можно было бы обсуждать детали реализации в том языке, на который идет собеседование. Но это было бы уже что-то вроде вопроса со звездочкой.
Огромное множество кандидатов с 15 или 20 годами опыта вообще не представляют что это такое.
Огромное множество кандидатов с 15 или 20 годами опыта вообще не представляют что это такое.
Безотносительно языка я бы сказал, что у массивов предполагается фиксированный размер с возможной многомерностью, а у списков переменный размер и одномерность. Собственно, это всё, что можно сказать про различия массивов и списков не вдаваясь в детали конкретной реализации.
А вот тут я бы поспорил…
Я не вспомню «чистое» определение, но, насколько я помню, и то и то может иметь динамический размер и разница у них в организации доступа и добавления элементов.
В том же курсе, вроде как, рассматриваются очереди и стэки…
А ещё можно повспоминать про сложность обращения к элементу и сложность вставки/удаления…
А список бывает ещё и связный и кольцевой…
Эх, с понимающим кандидатом есть что обсудить ;)
Я не вспомню «чистое» определение, но, насколько я помню, и то и то может иметь динамический размер и разница у них в организации доступа и добавления элементов.
В том же курсе, вроде как, рассматриваются очереди и стэки…
А ещё можно повспоминать про сложность обращения к элементу и сложность вставки/удаления…
А список бывает ещё и связный и кольцевой…
Эх, с понимающим кандидатом есть что обсудить ;)
А вы смогли бы задать этот вопрос в коде? потому что я с php давно знаком, но голых списков там не помню.
На самом деле, уметь кодить необходимо и для QA, и для DBA, и для сисадмина. А вот умение организации сложной архитектуры, которая не тонет под своим весом, прерогатива программиста
Не согласен с картинкой йодовой. Не плохой дизайн ведет к спагетти коду, а отсутствие рефакторинга. А отсутствие рефакторинга — признак того, что либо кто-то ленится убирать пахнущий код, либо недостаточное покрытие тестами либо и то и другое.
Вы забыли самую главную причину — время на это не выделяется.
Время не выделяется — плохо работает техлид или тот, кто его функцию выполняет.
Рефакторинг — часть разработки. По договоренностью между коммандой и менеджментом время либо выделяется в виде отдельных задач, либо размазывается по бизнесс запросам. Причем первый вариант только в том случае, если менеджмент интересуется такими деталями (например если у комманды плохая репутация и ее нужно поправить).
Рефакторинг — часть разработки. По договоренностью между коммандой и менеджментом время либо выделяется в виде отдельных задач, либо размазывается по бизнесс запросам. Причем первый вариант только в том случае, если менеджмент интересуется такими деталями (например если у комманды плохая репутация и ее нужно поправить).
Ну вот опять, набежали комментаторы :), которые путают сложность решаемых задач с качеством подхода к работе.
Если не делать разделение на кодеров и программистов, то да, рулит именно самосознание и самодисциплина… Но профит-то не в том.
И дело даже не джниорах и сеньорах, ибо деление чаще всего только по опыту и желаемой зарплате.
Просто у кодера и программиста разные задачи. Если нужно превратить в код тонну более или менее качественного ТЗ — это работа кодера, и программист загнётся со скуки.
А если в ТЗ преимущественно «сделай мне красиво» :) — то для программиста, ибо кодер просто не будет знать, что делать.
Если не делать разделение на кодеров и программистов, то да, рулит именно самосознание и самодисциплина… Но профит-то не в том.
И дело даже не джниорах и сеньорах, ибо деление чаще всего только по опыту и желаемой зарплате.
Просто у кодера и программиста разные задачи. Если нужно превратить в код тонну более или менее качественного ТЗ — это работа кодера, и программист загнётся со скуки.
А если в ТЗ преимущественно «сделай мне красиво» :) — то для программиста, ибо кодер просто не будет знать, что делать.
UFO just landed and posted this here
С этой точки зрения даже и все олипиадники — кодеры.
Вот тут я с Вами абсолютно не согласен. ТЗ — это не только, что сделать, но и как. Уровень детализации качественно другой. А задачи олимпиадные как раз и расчитаны на то, чтобы придумать, как сделать. В этом вся их суть. Поэтому любой олимпиадник может выполнять работу кодера (но загнется от скуки), но далеко не каждый сможет решить даже простенькую задачку, даже если есть распечатка кода всех алгоритмов и структур данных.
Проблема со всеми этими «качественно другими уровнями детализации» в том, что никто не может их четко обозначить. Вон выше разделяют кодинг и программирование по уровню достижения оптимального результата, но это не решает проблему — все равно непонятно как это все оценивать.
Понятно, что границы размыты. Условно говоря, если мозг не задет при работе — это кодинг. Иначе программирование. По мере движения от одной крайности к другой — классификация становится все сложнее.
Но, если олимпиадное прогаммирование находится с той же стороны границы, что и перевод блок схемы в код на неком языке программирования, то я не знаю, что вообще находится по другую сторону границы.
Задет или не задет мозг — тоже мнение сугубо субъективное, опирающееся на опыт.
Как-то лет десять тому назад, кода я резче в суждениях, в рабочем проекте сложился довольно забавный расклад:
Я на автомате писал все предельно простыми конструкциями, обильно комментируя, попутно неторопливо размышляя о том, что же лучше использовать в конкретном случае, чтобы было как можно меньше проблем в будущем. Мой первый коллега, и строчки не мог написать без какого-нибудь выверта, после чего долго все дебажил. Другой коллега обожал фреймворки и библиотеки, радостно все это добро в проект, собирал все подводные камни, а через год автор забивал на библиотеку или серьезно ее переделывал и приходилось все переписывать.
Так вот, по изначальному мнению каждого из нас — двое других страдали какой-то ерундой.
С моей точки зрения, первый коллега маялся дурью от скуки, а второй просто не умел ничего делать сам. С точки зрения первого коллеги, я был унылым ретроградом. А с точки зрения второго, мы вместе с первым неэффективно расходовали рабочее время на велосипеды.
Тем не менее, через полгода совместной работы наши сильные черты стали дополнять друг друга. Второй коллега делал некритичные, но громоздкие участки проекта — разнообразные админки и редакторы, которые нужны и важны. Я писал основной код, а первый коллега занимался критическими участками, находя удачные решения, которые мы потом совместно приводили в порядок.
Но, повторюсь, первое впечатление у всех друг о друге было довольно негативным.
Как-то лет десять тому назад, кода я резче в суждениях, в рабочем проекте сложился довольно забавный расклад:
Я на автомате писал все предельно простыми конструкциями, обильно комментируя, попутно неторопливо размышляя о том, что же лучше использовать в конкретном случае, чтобы было как можно меньше проблем в будущем. Мой первый коллега, и строчки не мог написать без какого-нибудь выверта, после чего долго все дебажил. Другой коллега обожал фреймворки и библиотеки, радостно все это добро в проект, собирал все подводные камни, а через год автор забивал на библиотеку или серьезно ее переделывал и приходилось все переписывать.
Так вот, по изначальному мнению каждого из нас — двое других страдали какой-то ерундой.
С моей точки зрения, первый коллега маялся дурью от скуки, а второй просто не умел ничего делать сам. С точки зрения первого коллеги, я был унылым ретроградом. А с точки зрения второго, мы вместе с первым неэффективно расходовали рабочее время на велосипеды.
Тем не менее, через полгода совместной работы наши сильные черты стали дополнять друг друга. Второй коллега делал некритичные, но громоздкие участки проекта — разнообразные админки и редакторы, которые нужны и важны. Я писал основной код, а первый коллега занимался критическими участками, находя удачные решения, которые мы потом совместно приводили в порядок.
Но, повторюсь, первое впечатление у всех друг о друге было довольно негативным.
Sign up to leave a comment.
Кодинг — это просто, а вот программирование — совсем другое дело