Насколько вообще полезно изучение книг?

Добрый день

А насколько вообще полезно изучение "книг"? (бумажных сейчас вряд ли, поэтому в кавычках) Ну или вообще, теории? Вот мой личный опыт/мнение

Не, ну книгами конечно "интересуюсь", когда вижу ссылки на "крутых авторов" - обычно стараюсь скачать и глянуть. Но толку, прямо скажем, немного Увы, все сводится к "пролистыванию по диагонали", при этом в примерно половине случаев вспоминаю что это уже видел. Не помню книги которая меня бы действительно увлекла, и я бы читал ее запоем и восхищался - и это конечно плохо. Очень раздражают обильные благодарности "всем кто помогал" - пока добрался до сути, половину настроя уже растерял Если дальше какой-то мутный пример на злополучной жабе - то на этом все и кончается.

По содержанию заметны типовые варианты. Напр "фундаментальные знания". Кстати когда инета не было - "заходило" намного лучше (тот же Вирт). Должен ли нормальный программист знать алгоритмы сортировки? Смутно помню "пузырьковая" и "шейкер", но только названия, по сути знаю только "быструю" что пришлось когда-то писать. Ну вот совершенно тупой подход: освоить std::sort без всяких философий. Чем это плохо? Что мы теряем, и не являются ли все эти чтения чисто понтами? По моим наблюдениям в 98% случаев std::sort прекрасно проходит, никакие фундаментальные познания не нужны. Хотя 2% есть, напр косячат с транзитивностью. Из той же оперы дерево - та запомнил просто что std::set - красно-черное дерево, дежурное O = log(N) - и вся любовь. А если кто доклепается, то всегда можно задавить типа "профессионал не должен тратить свое время на такие детали". "Потому что работы очень много" (Ваня). "Коллеги не поймут" и.т.п.

Другая категория - эффективная разработка программного обеспЕчения. Здесь надо спокойно относиться к само-восторгам типа "какую крутую систему мы сделали!". Как и к упоминаниям о SmallTalk, Ada и, оказывается, Мухтар-то ..собака! Если научиться гонорировать всю эту хрень - такие книги бывают совсем не плохи. Иногда я замечал что они рассказывают вещи к которым я приходил через долгий (и не безошибочный) опыт. Так может внимательно посмотреть что еще говорят (типа "учиться на чужих ошибках")? Увы, это не работает.

Ну и, пожалуй, самая популярная категория: "сборник рецептов". Особенно если замешано API (напр OpenGL). Откровенно шкурный подход с целью продать "книгу". Ну конечно, "с примерами". Ну а "почему нет"? Что плохого в быстром старте с нуля - ведь для этого такие книги весьма полезны.

В общем

С бумагой в стране напряженка

0

Сообщение от Igor3D результат практически полностью зависит от этого, т.е. от предметной части, а не от умных книжек

Так как речь идёт о задаче для математика, то результат зависит от изучения умных книжек по математике. Вот если бы это была задача для программиста, то результат бы зависел от изучения умных книжек по программированию.

Сообщение от Igor3D Смотря что считать "идеей".

Например, обобщение монад до стрелок.
Программисты любят абстракции. Поэтому концепции, которыми они владеют, не зависят от предметной области.

0

Сообщение от Shamil1 Так как речь идёт о задаче для математика, то результат зависит от изучения умных книжек по математике. Вот если бы это была задача для программиста, то результат бы зависел от изучения умных книжек по программированию.

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

- с помощью сил движка физики (напр Bullet) заставить объект двигаться по заданному пути

Для кого такая задача? Конечно все равно делать (и отвечать) программисту, но все-таки интересно.

0

Сообщение от Катафалк Очень часто "чистый код" - это что то сродни религии. Спроси любого разраба - и он прочитает тебе лекцию как писать "чисто"

Далеко не любого. Несколько лет собеседовал кандидатов по 2-3 человека в неделю, иногда больше. Достаточно хорошо представляю картину в целом, от выпускника (или даже студента на подработку) до пенсионера. Приходят действительно "разрабы", а не инженеры. Лозунги, что нужно писать качественный код, произносят бодро, но когда прошу немного подробнее, сливаются. За все время из нескольких сотен кандидатов принял на работу едва десяток человек (правда, реально толковых). Даже пару миддлов удалось подобрать.

Оффтоп: в конце концов пришлось прекратить эти бесплодные потуги и организовать целевую подготовку студентов для себя.

Сообщение от Катафалк По факту же 90% всей этой чистоты нафиг не нужно в большинстве проектов

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

К тому же писать чистый код не труднее, чем грязный, если разработчик обучен этому (для этого правильные книги незаменимы). Тут почти как с обычными текстами: если человек грамотен, он сразу пишет без ошибок, ему незачем их сначала делать, потом выискивать и исправлять.

Сообщение от Катафалк Все это исключительно религиозные верования, что якобы "чистый код" приводит к более качественному продукту, меньшему количеству багов и т.д. ... К качеству приводит мозг в голове разраба, а если мозга нет, то никакой чистый код ему не помешает наговногодить.

Религиозные верования заполняют вакуум там, где отсутствуют реальные знания. Вопросами качества продукта занимается раздел программной инженерии, который так и называется: Quality Assurance, QA. Незнакомые с программной инженерией часто уверены, что QA - синоним тестирования, но это разные вещи.

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

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

Сообщение от Катафалк Если для программиста код - самоцель, то перед нами говнокодер.

Говнокодер по определению он лишь в том случае, если генерирует говнокод, независимо от его целей. Если же он качественно решает поставленную задачу, то он красавчик.

1

Сообщение от steelcraft Приходят действительно "разрабы", а не инженеры.

Не вижу ничего плохого в слове "разраб". Что смущает в Ваших рассуждениях - так это никаких проблем с "задачей", впечатление что прекрасно известно "что" нужно (с)делать, вопрос лишь "как", т.е. насколько чист код и все такое. Ну слава богу что люди живут так хорошо, но у меня все совсем не так.

Изначально задача - это "хотелка", вполне ясно "для чего это", какой ф-ционал требуется. Но не более того. Как/чем это делать - хз. Многие придерживаются принципа "все уже давно написано", т.е. нужно лишь "прикрутить" нужные либы/тулзы, в этом собсно и заключается работа программиста. Некоторые даже застревают в этом на всю жизнь. Но это работает не всегда. Часто до "кода" еще очень далеко, неясно вообще что делать, с какой стороны подойти, если удается найти хоть какие-то работы/статьи - уже успех, а какие-то open-sources - еще лучше, даже если там не очень "чистый" код.

Вижу что Вам такие проблемы чужды. Поэтому мои симпатии скорее на стороне Катафалк'а

0

Сообщение от Igor3D Изначально задача - это "хотелка", вполне ясно "для чего это", какой ф-ционал требуется. Но не более того. Как/чем это делать - хз.

Есть такая инженерная дисциплина, называется "Программная инженерия" (не путать с тем странным предметом, который преподается во многих учебных заведениях). Образовательный стандарт для нее описан в документе ISO/IEC TR 19759, в котором собраны лучшие практики ведущих производителей софта. На всякий случай, если кто-то вдруг его до сих пор не изучил, в двух словах: в нем перечислены 15 разделов программной инженерии, вкратце изложены проблемы, которыми занимается каждый раздел, и приведена "дорожная карта" для его изучения, причем в виде очень удобной матрицы.

Ну и еще есть отечественный национальный стандарт РФ ГОСТ Р ИСО/МЭК 12207-2010". Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств" (на самом деле нифига не отечественный, просто перемаркированный соответствующий стандарт от ISO/IEC, как и прочее импортозамещение; впрочем, по мне это даже лучше). По сути это и есть подробное руководство "Как/чем это делать".

Ну и как вишенка на торте - методики MBSE, которые при правильном применении очень помогают в нетривиальных разработках.

Сообщение от Igor3D Вижу что Вам такие проблемы чужды. Поэтому мои симпатии скорее на стороне Катафалк'а

Это естественно, общая беда сближает. Впрочем, я почему-то не очень огорчен, для обмена симпатиями есть другие ресурсы.

P.S. Я попробовал представить, что берусь, к примеру, за постройку железнодорожного моста, не имея специального образования и даже не зная сопромата. Испытал в точности такое ощущение:

вполне ясно "для чего это", какой ф-ционал требуется. Но не более того. Как/чем это делать - хз.

Разве что очень повезет нарыть "какие-то open-sources" подходящего вида. Но это не очень похоже на инженерный подход.

1

Сообщение от Igor3D с помощью сил движка физики (напр Bullet) заставить объект двигаться по заданному пути

Правильно ли я понял, что есть тело, которым можно управлять, прикладывая к нему вектор силы на некоторый период времени?

Сообщение от Igor3D Для кого такая задача?

Для физика.

Сообщение от Igor3D Конечно все равно делать (и отвечать) программисту, но все-таки интересно.

Написать программу для расчёта чего-нибудь (например, поля вокруг антенны) - нормальная темя для дипломной и/или кандидатской работы физика.

0

Сообщение от steelcraft Я попробовал представить, что берусь, к примеру, за постройку железнодорожного моста, не имея специального образования и даже не зная сопромата.

А почему Вы считаете что "хотелки" глупы/наивны? Пример приведен в посте #42 (движение объекта по заданному пути). Ну как-то на "постройку моста" это явно не тянет, наоборот, выглядит вполне реальной задачей, и даже довольно скромной, орден за нее точно не дадут.

Да, но тогда откуда сложности? Прежде всего надо понимать зачем здесь понадобился движок и силы физики, ведь если путь имеется - то почему бы просто не двигать по нему объект? Наивно полагать что проблема в "сопромате", т.е. в знании движка. Здесь как раз все хорошо, сложная математика, как положено, спрятана "под капотом", функции/методы для приложения сил легко находятся. Причем как они работают - тоже ясно, "по Ньютону". Используемые формулы

F = m * a;
V = V0 + a * t;

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

Тем не менее, задача далеко не проста, и я доволен не всем что сделал. Если начать тщательное обдумывание и анализ различных ситуаций - проблемы/трудности прут изо всех щелей. Обсуждать подробнее нет смысла т.к. не вижу никакого интереса с Вашей стороны. Хочу лишь заметить: ни о каком "коде" речь пока вообще не идет. Отсюда вывод:

Пока не достигнут требуемый функционал, чистота/грязнота кода никого не волнует

Кстати Ваш случай (величие КОДА) довольно редкий, чаще встречается перегиб в другую сторону. Не раз приходилось слышать пренебрежительное отношение к "кодированию" типа

Реализация/кодирование - ну это самое легкое

А иной раз и хамской форме

Программисты - тупицы, они не могут выучить даже закон Ома!

В общем, все хорошо в меру, без перегибов

0

Shamil1, я так понял, намек был на тупое отображение, а не физическую задачу.
Физик там не нужен, нужен мышегонятель.

0

Сообщение от Shamil1 Правильно ли я понял, что есть тело, которым можно управлять, прикладывая к нему вектор силы на некоторый период времени?

Правильно. Разумеется известны позиция, скорость тела и др

Сообщение от Shamil1 Для физика.

А что мы здесь хотим от физика? Чтоы он прочитал/напомнил курс 8-го класса?

0

Eddy_Em, я не совсем понял, что требуется сделать. Если нужно пинать тело каждый раз, когда отклоняется от маршрута, то можно обойтись без физики. Если нужно пинать тело так, чтобы оно двигалось по заданному маршруту, то, фактически, нужно воспроизвести в коде ту часть движка, которая за это отвечает (предсказывать реакцию тела на пинок).

0

Shamil1, я тоже сомневаюсь в верной трактовке, но подозреваю, что имелась в виду не серьезная задача, а бесполезная чушь вроде элементов компьютерных игр. Науки там вообще нет (т.к. теория игр к компьютерным играм отношения не имеет). Тем паче, если это делается "средствами движка".

0

Сообщение от Igor3D А что мы здесь хотим от физика? Чтоы он прочитал/напомнил курс 8-го класса?

В школьном учебнике физики задачи для физиков. Пусть для малоопытных/начинающих, но для физиков.

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

0

Сообщение от Igor3D А почему Вы считаете что "хотелки" глупы/наивны?

Я никогда так не считаю. А если вдруг начну так считать, это значит, что я утратил профессиональную пригодность как программный и системный инженер. Если создалось такое впечатление, значит, я плохо сформулировал мысль.

"Хотелки" - это пожелания заказчика, кем бы он ни был. Моя организация хозрасчетная, существует и развивается исключительно за счет прибыли, полученной от выполнения контрактов с заказчиком, а значит, его пожелания должны быть реализованы, если только они не противоречат законам природы, существующему законодательству и подобным объективным ограничениям.

Именно с работы над пожеланиями заказчика начинается проект. Проводится аналитическая работа, результатом которой является спецификация требований к системе (и к программному обеспечению как части системы). Многие не разобравшиеся в этом вопросе часто называют ее "техническим заданием" (или коротко ТЗ), но это неправильно.

Неспроста первая глава стандарта ISO/IEC TR 19759 (который должен быть настольной книгой каждого профессионального программного инженера) посвящена работе с требованиями. Именно на основе валидации бизнес-требований в конце проекта производятся приемо-сдаточные испытания системы, и если результат валидации отрицательный, заказчик не примет проект (а следовательно, не выполнит свои платежные обязательства). Сами понимаете, для исполнителя перспектива не радужная, поэтому с требованиями нужно работать максимально тщательно.

Если я сомневаюсь, что заказчик хочет именно то, о чем просит, у меня всегда есть возможность задать уточняющие вопросы (либо предложить альтернативное решение, которое я считаю более подходящим для данной проблемы). Но конечное решение остается за тем, кто платит деньги. По этой причине для меня не бывает "глупых/наивных хотелок" заказчика; если заказчик настаивает на чем-то, готов за это платить и это реально можно сделать, значит, это будет сделано, и точка.

Вот таким я вижу профессиональный подход к разработке.

По поводу соответствия компетенций команды разработчиков решаемой задаче (тот самый случай, когда "Как/чем это делать - хз" процитирую один из принципов Agile Manifesto (моя команда работает в соответствии с этими принципами):

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

0

Сообщение от Shamil1 я не совсем понял, что требуется сделать.

Создал новую тему

Добавлено через 1 час 32 минуты

Сообщение от steelcraft По поводу соответствия компетенций команды разработчиков решаемой задаче (тот самый случай, когда "Как/чем это делать - хз" процитирую один из принципов Agile Manifesto (моя команда работает в соответствии с этими принципами): Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

В буржуйских книгах такие фразы, мягко говоря, раздражают. Какие "профессионалы" имеются ввиду? Те для кого программирование - работа (а не хобби)? Или "крутые программисты" (критерий "крутизны", впрочем, никогда не был ясен). "Мотивация" - имеется ввиду хорошая зарплата, или что? Ну конечно это "повышает шансы", но ничего не гарантирует. И добивает "полностью доверьтесь" - хотите остаться без штанов?

Возможно имелось ввиду типа "если не знаете как/чем - найдите того кто знает". Звучит разумно, но работает редко. Несомненно знающие живут на нашей планете, но область может быть узкой. Много спецов ваять UI, гонять тараканов по сети и.т.п. (впрочем и там "нюансы"). Но далеко не все задачи на уровне популярных либ что может освоить любой нормальный человек.

0

Неожиданно много вопросов в одном посте, и все интересные. С Вашего позволения я разобью ответ на две части, чтобы легче было читать.

Сообщение от Igor3D В буржуйских книгах такие фразы, мягко говоря, раздражают.

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

Сообщение от Igor3D Какие "профессионалы" имеются ввиду?

В первую очередь те, по отношению к которым нет желания заключать это слово в кавычки.

Wikipedia предлагает такое определение этого термина:

Профессиона́л — человек, сделавший определённое занятие (дело) своей профессией; человек, ставший в какой-либо области деятельности высококлассным специалистом; хорошо подготовленный для работы в определённой сфере специалист, имеющий навыки, квалификацию, а при необходимости и допуск к выполнению обязанностей по своей специальности.

Осталось лишь определить, что такое "хорошая подготовка" и навыки. К счастью, здесь давно все придумали за нас.

Есть такой термин - Body of knowledge, на русский обычно переводится как "совокупность знаний" или "свод знаний". Цитата из машинного перевода:

Совокупность знаний ( BOK или BoK ) — это полный набор концепций, терминов и видов деятельности, составляющих профессиональную область, как это определено соответствующим научным обществом или профессиональной ассоциацией .

Когда кто-то из доверяющих мне людей спрашивают, как можно освоить некоторую дисциплину наиболее быстро и при этом полно, я отвечаю: ищите соответствующий BOK. Например:

• для управления проектами - PMBOK (Project Management Body of Knowledge);
• для системной инженерии - SEBOK (Systems Engineering Body of Knowledge)

и так далее. Соответственно для программной инженерии это SWEBOK (Software Engineering Body of Knowledge), он же образовательный стандарт ISO/IEC TR 19759. Именно на его основе я оцениваю общие знания кандидатов на собеседованиях.

Разумеется, есть еще и специальные знания, специфические для более узких направлений. Например, если человек приходит собеседоваться на разработчика программ на языке C, дальнейшая речь пойдет по материалам стандарта языка ISO/IEC 9899:2018 (ну или более раннего, но в этом случае я ненавязчиво поинтересуюсь, какие такие срочные дела не позволили кандидату проглядеть стандарт за долгие 7 лет, истекшие с момента принятия предыдущей версии стандарта).

Конечно, на единственной программной инженерии свет клином не сошелся; как минимум есть еще Computer Engineering и Computer Science, каждая со своим образовательным стандартом. Этим дисциплинам я не обучаю, но имею хорошее представление и готов собеседовать по этим направлениям, если кандидат предпочитает их.

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

Добавлено через 7 минут
(Продолжение)

Сообщение от Igor3D Те для кого программирование - работа (а не хобби)?

Естественно, категория "яумамыпрограммист" к данной теме никакого отношения не имеет. Иметь программирование в качестве основного занятия - необходимое, но отнюдь не достаточное условие профессионализма (см. выше). Или, другими словами: для того, чтобы стать разработчиком ПО, недостаточно не уметь делать ничего другого; нужно еще уметь разрабатывать ПО.

Сообщение от Igor3D Или "крутые программисты" (критерий "крутизны", впрочем, никогда не был ясен).

Для меня один из естественных критериев "крутизны" - успешно пройти аттестацию в официально аккредитованной IT-компании по специализации, относящейся к разработке (последнее важно, поскольку IT - далеко не только разработка). Как вариант - крутые специалисты создают востребованные инструменты, пишут признанные сообществом книги/статьи, ведут блоги (не путать с графоманией и инфоцыганщиной). Но это уже высший пилотаж.

Сообщение от Igor3D "Мотивация" - имеется ввиду хорошая зарплата, или что? Ну конечно это "повышает шансы", но ничего не гарантирует.

Не только. Зарплата - материя тонкая, не зря она относится к "гигиеническим" факторам. Вообще я не фанат Хабра, но иногда ссылаюсь на некоторые статьи, подходящие под контекст беседы:

Зарплата - гигиенический фактор. Это буквально означает, что её повышение выше условно справедливого для работника уровня не приведёт к долгосрочному и пропорциональному повышению его производительности труда. А вот понижение - приведёт к ухудшению.

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

Сообщение от Igor3D И добивает "полностью доверьтесь" - хотите остаться без штанов?

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

Не могу предъявить бесспорные доказательства, но уж поверьте мне на слово: все мои заказчики поголовно до сих пор щеголяют в собственных штанах (по крайней мере, в рабочей обстановке; в тонкости их частной жизни никогда не вдавался). Наше многолетнее сотрудничество никак не повлияло на их гардероб (по крайней мере, в сторону его оскудевания).

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

Допускаю, что данная проблема актуальна для тех, кто черпает портфель заказов в разделе "Фриланс" форума. Но это очень частный случай.

Сообщение от Igor3D Возможно имелось ввиду типа "если не знаете как/чем - найдите того кто знает".

Искать тех, кто знает, - скорее моя задача как тимлида, поскольку именно мне предстоит работать с ними непосредственно. Но, как я уже упоминал, поиск здесь работает плохо (по крайней мере, у нас в провинции), гораздо проще отобрать неглупых ребят и научить всему необходимому.

1

Конечно можно поговорить о многом (напр о понятии профессионализма), но.. "длинные посты никто не читает" , поэтому постараюсь самое интересное

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

1. Ну опыт конечно, и это тесно связано с предметной частью. В каких проектах участвовал и с каким результатом - это важно. Отсутствие/недостаток опыта не "ставит крест" на человеке, но ограничивает обе стороны

2. Знание языка, но без фанатизма. Напр по моим наблюдениям злоупотребления с std::, дустом и (новыми) стандартами С++ носит массовый и злостный характер, нередко таких людей лучше избегать.

- читали Александреску? - да! - отлично, Вы нам не подходите!

Стандарт плюсов - довольно мерзкая вещь, достаточно если "открывал" и умеет пользоваться.

3. Умение работать с данными: классами и даже простыми структурами. От этого многое зависит

4. Инициативность, умение предложить решение. Не путать с "нагородить" т.е. предложить абы-что. Редкое и очень ценное качество

Ну а всякие там вумные книжки, монады и все такое... ну если читал - еще лучше. Но не читал - не беда

0

Сообщение от Igor3D Знание языка, но без фанатизма.

Ну вот возьмем, к примеру, мой любимый классический C, он у нас очень востребован для микроконтроллеров. Многие ошибочно считают, что он простой, потому что книжка (K&R, классика) довольно тонкая, ключевых слов мало, и даже основная часть стандарта всего 150 страниц (остальное библиотеки).

Если кандидат на собеседовании говорит, что он не читает стандарт, потому что у него огромный опыт (у некоторых он измеряется 20-30 годами) и он и так все уже знает, то он себя уже похоронил. Если 30 лет писать одну и ту же чушь, она с годами не становится лучше, это не коллекционный коньяк.

Еще пример: у меня в блоге в комментах один товарищ посмеялся над тем, что об указателях в C написана целая книга. Я знаю, что считают указатели примитивной темой лишь две категории: эксперты и кое-какеры, остальные относятся с должным почтением. Угадайте с трех раз, кто из них пожаловал ко мне (притягиваю я их, что ли...).

Сообщение от Igor3D Умение работать с данными: классами и даже простыми структурами. От этого многое зависит

Вы это прям на полном серьезе сейчас, на тему профессионализма? Не знать такие вещи даже маминому программисту стыдно. Это сразу пропуск на выход.

Сообщение от Igor3D Инициативность, умение предложить решение.

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

Сообщение от Igor3D Ну а всякие там вумные книжки, монады и все такое... ну если читал - еще лучше. Но не читал - не беда

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

P.S. В начале собеседования часто спрашиваю кандидата, какие книги он читал в последнее время. На основе ответа сразу делаю для себя прогноз итога собеседования, и через пару часов он почти в 100% случаев сбывается.

1

Сообщение от steelcraft Ну вот возьмем, к примеру, мой любимый классический C, он у нас очень востребован для микроконтроллеров. Многие ошибочно считают..

"С" не любят потому что говнокодить на нем затруднительно, все надо делать аккуратно и скрупулезно. А вот на плюсах - пожалуйста

Сообщение от steelcraft Умение работать с данными: классами и даже простыми структурами. От этого многое зависит Вы это прям на полном серьезе сейчас, на тему профессионализма? Не знать такие вещи даже маминому программисту стыдно. Это сразу пропуск на выход.

Сразу, к сожалению, не выйдет, проверить не так уж просто. Я имел ввиду взаимодействие/архитектуру классов, типа "кто кого знает", не сорит ли "фабриками" и все такое.

Сообщение от steelcraft Еще пример: у меня в блоге в комментах один товарищ посмеялся над тем, что об указателях в C написана целая книга. Я знаю, что считают указатели примитивной темой лишь две категории: эксперты и кое-какеры, остальные относятся с должным почтением. Угадайте с трех раз, кто из них пожаловал ко мне (притягиваю я их, что ли...).

Заинтриговали! Правду сказать, не вижу где здесь "должное почтение", ну адрес - он адрес и есть. На плюсах пошла мода всячески избегать "голых" указателей, ну это "наносное". Можно пример(ы) тонкостей? Спасибо

Сообщение от steelcraft P.S. В начале собеседования часто спрашиваю кандидата, какие книги он читал в последнее время. На основе ответа сразу делаю для себя прогноз итога собеседования, и через пару часов он почти в 100% случаев сбывается.

Так может Вы все уже решили и через пару часов лишь озвучиваете?

0

Сообщение от Igor3D "С" не любят потому что говнокодить на нем затруднительно, все надо делать аккуратно и скрупулезно.

Эх, Вашими бы устами да мед пить... Я ведь помимо собеседований еще и примеры кода своих поциэнтов должен смотреть. А настоящий говнокодер сделает свое дело на любом языке, буlь то хоть Rust или Ada. У меня скопилась роскошная коллекция примеров на С, хоть смейся, хоть плачь.

Сообщение от Igor3D Заинтриговали! Правду сказать, не вижу где здесь "должное почтение", ну адрес - он адрес и есть. На плюсах пошла мода всячески избегать "голых" указателей, ну это "наносное". Можно пример(ы) тонкостей? Спасибо

Для начала довольно "толстые тонкости", с подобных материалов я обычно начинаю знакомить студентов с продвинутым курсом С после базового: статья "Pointers Are Complicated, or: What's in a Byte?" (само название кагбэ намекает) и пара продолжений 1 и 2.

Еще есть как минимум пара достойных книг на эту тему. Дабы не провоцировать благородный гнев модераторов ссылками на сторонние ресурсы, если Вам реально интересна эта тема, посмотрите их в моем блоге, ссылка есть в моем профиле. Там собраны наиболее интересные статьи и книги из прочитанных мной. За последнее время я немного забросил его (много времени отнимает работа над собственной книгой), но намерен в ближайшее время прибраться там.

Сообщение от Igor3D Так может Вы все уже решили и через пару часов лишь озвучиваете?

В принципе да, и почти никогда не ошибаюсь. Но у меня железный принцип: я всегда даю шанс кандидату высказаться до конца, пока сам не иссякнет. У меня был крайне неприятный опыт, когда мне высокомерно отказали, даже толком не выслушав (на самом деле все в итоге кончилось хорошо: когда об этом узнало руководство, собеседующему крепко надрали задницу, меня разыскали и предложили условия гораздо лучше, чем я предполагал изначально; но осадочек-то остался).

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

P.S. Забыл еще упомянуть блог Дэна Сакса. В своем блоге я почему-то упоминал его довольно редко, интереснейших статей по С у него гораздо больше, в том числе об указателях.

0

Сообщение от steelcraft посмотрите их в моем блоге, ссылка есть в моем профиле.

Не увидел, "записей в блоге 0". Плиз "ткните носиком"

Сообщение от steelcraft Для начала довольно "толстые тонкости", с подобных материалов я обычно начинаю знакомить студентов с продвинутым курсом С после базового: статья "Pointers Are Complicated, or: What's in a Byte?" (само название кагбэ намекает) и пара продолжений 1 и 2.

Полагаю что не у всех студентов это вызывает энтузиазм Право же, слишком узко/специфично. Возможно для микроконтроллеров это "само то", тут не мне судить. Но знание таких вещей я лично не считаю "показателем класса".

Сообщение от steelcraft "Мало читает" не выглядит уважительной причиной отказа (хотя, сказать по совести, является первопричиной низкой квалификации).

А не переоценивается ли роль знаний? С тем что они необходимы никто не спорит, но эта палка о двух концах. Вот навскидку несколько перлов

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

А то что "не (есть) знание" как-то оценивается? Или оно вообще не нужно?

0