Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Мне в моем образовании больше всего нехватает умения писать тексты.
В образовании других — непонимание теории множеств, математической логики, теории категорий и функционального программирования.
В образовании других — непонимание теории множеств, математической логики, теории категорий и функционального программирования.
И оригинал — муть без капли нового смысла, «чтобы быть хорошим инженером, нужно уметь читать, писать и общаться с другими», но перевод — просто запредельный, и сверху еще сдобрен примечаниями переводчика. Ализар ушел на GT, но дело его живет.
Простой вопрос — если все так очевидно, то почему вновь испеченные инженеры НЕ умеют читать, писать технические тексты, и общаться?
Претензии к переводу принимаю без слов, а вот насчет оригинала — поосторожнее бы, все таки его не выпускник техникума писал, Джек весьма авторитетен в определенных кругах.
Претензии к переводу принимаю без слов, а вот насчет оригинала — поосторожнее бы, все таки его не выпускник техникума писал, Джек весьма авторитетен в определенных кругах.
Так это же «гуманитарные» занятия. Это надо нетехническую литературу читать, на пары по русскому ходить — кошмар студента технаря. Ну и «классы исчисления» вместо «занятий матанализом» — это просто перл. (На мой взгляд, calculus = «практикум по матанализу»)
В серьезной дискуссии принято обсуждать сами идеи, а не носителей этих идей, будь они авторитетными или нет, так что будь он хоть новым Буддой — если он говорит очевидные вещи, он говорит именно их.
Новоиспеченные инженеры не умеют читать и писать потому, что на них есть спрос даже в таком виде. Не будет спроса — быстро научатся. Другой вопрос, что очень много инженерной работы требует в первую очередь хорошего знания предметной области, а затем уже социальных навыков и умения хорошо писать. На одного «писателя» приходится 10 разработчиков, которые и делают основную часть работы, а для «писать» нанимается технический писатель, который и доводит всю документацию до ума.
Я не пытаюсь умалить важность умения грамотно сделать презентацию или хорошо выступить перед аудиторией, но это все — скорее вишенка на торте, чем основные навыки инженера. В первую очередь, нужно уметь задачи решать в своей области, и у многих новоиспеченных инженеров проблемы как раз с этим.
На мой взгляд, инженерному образованию в России не хватает в первую очередь практики, обязательной для всех. Немецкие технические ВУЗы отправляются всех своих студентов на целый семестр практики, которую студенты проходят в реальных фирмах, занимаясь реальными задачами. Прямо сейчас в нашем отделе R&D работают 5 студентов: один портирует coreboot и SeaBIOS на наши платы, другой пишет библиотеку для взаимодействия с board features на C# и демо-программу для нее, третий занимается подбором подходящего чипа SuperIO для новых моделей процессоров без поддержки шины LPC, четвертый и пятый разрабатывают пост-кодер для USB Debug Port. Работают они наравне со всеми (за исключением количества часов в неделю), выступают на совещаниях, делают презентации, но в первую очередь — работают над своими проектами. И успех их, как инженеров, зависит именно от качества работы, а не от умения писать или делать презентации.
Новоиспеченные инженеры не умеют читать и писать потому, что на них есть спрос даже в таком виде. Не будет спроса — быстро научатся. Другой вопрос, что очень много инженерной работы требует в первую очередь хорошего знания предметной области, а затем уже социальных навыков и умения хорошо писать. На одного «писателя» приходится 10 разработчиков, которые и делают основную часть работы, а для «писать» нанимается технический писатель, который и доводит всю документацию до ума.
Я не пытаюсь умалить важность умения грамотно сделать презентацию или хорошо выступить перед аудиторией, но это все — скорее вишенка на торте, чем основные навыки инженера. В первую очередь, нужно уметь задачи решать в своей области, и у многих новоиспеченных инженеров проблемы как раз с этим.
На мой взгляд, инженерному образованию в России не хватает в первую очередь практики, обязательной для всех. Немецкие технические ВУЗы отправляются всех своих студентов на целый семестр практики, которую студенты проходят в реальных фирмах, занимаясь реальными задачами. Прямо сейчас в нашем отделе R&D работают 5 студентов: один портирует coreboot и SeaBIOS на наши платы, другой пишет библиотеку для взаимодействия с board features на C# и демо-программу для нее, третий занимается подбором подходящего чипа SuperIO для новых моделей процессоров без поддержки шины LPC, четвертый и пятый разрабатывают пост-кодер для USB Debug Port. Работают они наравне со всеми (за исключением количества часов в неделю), выступают на совещаниях, делают презентации, но в первую очередь — работают над своими проектами. И успех их, как инженеров, зависит именно от качества работы, а не от умения писать или делать презентации.
Умение писать в первую очередь означает отсутствие каши в голове — способность последовательно и четко проходить по своим мыслям, излагая их. Это умение пригодится инженеру на таких этапах как «постановка задачи», «анализ алгоритма», «отладка» и так далее. Есть ведь даже такой метод — рассказывать свое видение проблемы резиновому утенку. При этом мысли упорядочиваются, а несообразности — всплывают.
Ну давайте по теме без ссылок на авторитеты.
Если Вы можете себе представить грамотного толкового разработчика, способного сделать схему и отладить ее либо написать/портировать программу, но при этом не способного внятно и толково объяснить суть своей работы, основные принципы, положенные в основу и методы их реализации, причем обяснить как в виде выступления, так и в виде печатного выступления, то Ваша фантазия явно превосходит мою. Как очень верно заметил в коменте gbg, изложение своих мыслей на бумаге прежде всего необходимо для присведения в порядок самих мыслей — отсутствие каши в голове.
Наверняка многие сталкивались с ситуацией, когда попытка объяснить коллеге суть возникшей у Вас проблемы приводит в процессе объяснения к сакраментальной фразе «О, я понял в чем дело» и это связано с процессом осмысления проблеммы именно при переводе в артикуляционную форму.
Продолжаем разговор по теме.
«На одного «писателя» приходится 10 разработчиков, которые и делают основную часть работы, а для «писать» нанимается технический писатель, который и доводит всю документацию до ума» — на мой взгляд (конечно, абсолютно неправильный — копирайт Потапенко) не вполне верный подход. Ни один технический писатель не сможет довести документацию до ума, если об этом не позаботился разработчик, поскольку он (писатель) не является специалистом в данной узкой предметной области. (Типичный пример — то, что я в термине Calculus не увидел матана. Хотя его в школе разве проходят? Уже не помню). Он може привести документацию в соответствие к некоторым требованиям по оформлению, но если Вы, как разработчик, невнятно описали логику работу узла устройства, он ничего не сможет сделать.
Что же касается успеха и от чего он зависит — вопрос непростой. Разумеется, и я с Вами полностью согласен, прежде всего надо уметь решать задачи. На этом все и заканчивается, если Вы работаетет в абсолютом вакууме, однако в реальной жизни есть продолжение. Поэтому, после решения задачи, необходима полная и исчерпывающая техническая документация, которая решает ряд сопряженных задач:
1) Если ваша продукция предначена другим разработчикам, то Вы ее просто не продадите без документации
2) Если Ваша продукция предназначена конечному потребителю, то Вы не продадите ее в тех количествах, в которых могли бы
3) Даже если это внутренняя продукция, либо она применяется в закрытом режиме и пользуется устойчивым спросом (например клавиатура — никто особо не задумывается, что там внутри) — хорошая документация пригодится Вам самому, когда придется модифицировать продукт, или на его основе делать новый, потому что Вам не придется мучительно вспоминать «А почему тут сделано именно так и что будет, если чуть изменить код».
Так что несомненно успех инженеров зависит от первой части, а успех проекта и компании в целом — и от второй в немаловажной степени. Но, по-моему, это совершенно очевидные вещи, «муть без капли нового смысла», хотя почему-то о ней приходится дискутировать.
Если Вы можете себе представить грамотного толкового разработчика, способного сделать схему и отладить ее либо написать/портировать программу, но при этом не способного внятно и толково объяснить суть своей работы, основные принципы, положенные в основу и методы их реализации, причем обяснить как в виде выступления, так и в виде печатного выступления, то Ваша фантазия явно превосходит мою. Как очень верно заметил в коменте gbg, изложение своих мыслей на бумаге прежде всего необходимо для присведения в порядок самих мыслей — отсутствие каши в голове.
Наверняка многие сталкивались с ситуацией, когда попытка объяснить коллеге суть возникшей у Вас проблемы приводит в процессе объяснения к сакраментальной фразе «О, я понял в чем дело» и это связано с процессом осмысления проблеммы именно при переводе в артикуляционную форму.
Продолжаем разговор по теме.
«На одного «писателя» приходится 10 разработчиков, которые и делают основную часть работы, а для «писать» нанимается технический писатель, который и доводит всю документацию до ума» — на мой взгляд (конечно, абсолютно неправильный — копирайт Потапенко) не вполне верный подход. Ни один технический писатель не сможет довести документацию до ума, если об этом не позаботился разработчик, поскольку он (писатель) не является специалистом в данной узкой предметной области. (Типичный пример — то, что я в термине Calculus не увидел матана. Хотя его в школе разве проходят? Уже не помню). Он може привести документацию в соответствие к некоторым требованиям по оформлению, но если Вы, как разработчик, невнятно описали логику работу узла устройства, он ничего не сможет сделать.
Что же касается успеха и от чего он зависит — вопрос непростой. Разумеется, и я с Вами полностью согласен, прежде всего надо уметь решать задачи. На этом все и заканчивается, если Вы работаетет в абсолютом вакууме, однако в реальной жизни есть продолжение. Поэтому, после решения задачи, необходима полная и исчерпывающая техническая документация, которая решает ряд сопряженных задач:
1) Если ваша продукция предначена другим разработчикам, то Вы ее просто не продадите без документации
2) Если Ваша продукция предназначена конечному потребителю, то Вы не продадите ее в тех количествах, в которых могли бы
3) Даже если это внутренняя продукция, либо она применяется в закрытом режиме и пользуется устойчивым спросом (например клавиатура — никто особо не задумывается, что там внутри) — хорошая документация пригодится Вам самому, когда придется модифицировать продукт, или на его основе делать новый, потому что Вам не придется мучительно вспоминать «А почему тут сделано именно так и что будет, если чуть изменить код».
Так что несомненно успех инженеров зависит от первой части, а успех проекта и компании в целом — и от второй в немаловажной степени. Но, по-моему, это совершенно очевидные вещи, «муть без капли нового смысла», хотя почему-то о ней приходится дискутировать.
Если Вы можете себе представить грамотного толкового разработчика, способного сделать схему и отладить ее либо написать/портировать программу, но при этом не способного внятно и толково объяснить суть своей работы, основные принципы, положенные в основу и методы их реализации, причем обяснить как в виде выступления, так и в виде печатного выступления, то Ваша фантазия явно превосходит мою.
Мало что бывает фантастичнее, чем реальная жизнь. Если в вашем примере предположить, что толковый разработчик говорит и думает на испанском, а объяснить ему нужно немецким заказчикам за 60, которые плохо понимают по английски, причем желательно еще вчера и по телефону — получится ситуация, которую я иногда наблюдаю у себя в отделе. И ничего, справляемся.
Он может привести документацию в соответствие к некоторым требованиям по оформлению, но если Вы, как разработчик, невнятно описали логику работу узла устройства, он ничего не сможет сделать.
Логика работы узла описывается не словами, а чертежами и кодом, которые не нуждаются в переводе. Вся остальная документация, application notes, datasheets и прочее такое готовится инженерами совместно с отделом тестирования и отделом QA, и твое конкретно умение писать полезно, но решающим фактором не является. Не умеешь — поясни тому, кто умеет, вместе у вас все получится.
Моя основная мысль — не отрицая важности умения писать и взаимодействовать с людьми, нельзя требовать эти умения от инженера, иначе вам нужен уже не просто инженер, а мастер на все руки, за совсем другие деньги.
Я достаточно грамотный программист. И в своем старом коде более-менее без проблем могу разобраться. Но тексты писать не умею. И это мне сильно мешает в работе. Кстати, метод с утенком мне тоже слабо помогает.
Значит, Вам повезло.
Я не так давно смотрел на свой код, который написал в августе на скорую руку и, естественно, без коментариев, и пытался вспомнить, почему младший разряд передаю на внешнюю шину не как все, а через ножку общего назначения. Не вспомнил, убрал эту фичу, получил исключение адресации, тут же понял для чего было сделано и вернул на место и добавил комментарий. И это код 3-х месячной давности всего лишь.
Как говорила моя учительница по литературе «Плохой карандаш лучше хорошей памяти»
Я не так давно смотрел на свой код, который написал в августе на скорую руку и, естественно, без коментариев, и пытался вспомнить, почему младший разряд передаю на внешнюю шину не как все, а через ножку общего назначения. Не вспомнил, убрал эту фичу, получил исключение адресации, тут же понял для чего было сделано и вернул на место и добавил комментарий. И это код 3-х месячной давности всего лишь.
Как говорила моя учительница по литературе «Плохой карандаш лучше хорошей памяти»
Как будто автопереводчиком переведено.
Да, взято автопереводом и слегка причесано, ну совсем слегка.
Не делайте так никогда, пожалуйста. Я на втором абзаце не вынес и полез читать оригинал, потому что из перевода не понятно вообще ничего.
Так значит пост удался — он Вас заинтересовал и Вы обратились к оригиналу ))
Хотя постараюсь делать все-таки более литератуное изложение. Просто опасался, что где нибудь неправильно пойму, изложу своими словами и вложу в уста Джека совершенно несвойственные ему мысли, поэтому постарался оставить максимально близко к подстрочнику — видимо, неудачная практика.
Хотя постараюсь делать все-таки более литератуное изложение. Просто опасался, что где нибудь неправильно пойму, изложу своими словами и вложу в уста Джека совершенно несвойственные ему мысли, поэтому постарался оставить максимально близко к подстрочнику — видимо, неудачная практика.
Может быть идея была и хорошая, но получились «гуртовщики мыши», к сожалению.
Ну не «класс» же! Курс или предмет.
А мне не хватает чистой человеческой математики. Меня все время учили паять, проектировать схемы и т.п. У нас было очень и очень много практики. Я видел столько железяк во время обучения, сколько не увидел за всю свою карьеру сервисного инженера и инженера технической поддержки.
Теперь же я немножко подрос и сейчас я проектирую ПО. Мышление, которое мне поставили безграничной практикой очень мне помогает, но мне не хватает математики.
Теперь же я немножко подрос и сейчас я проектирую ПО. Мышление, которое мне поставили безграничной практикой очень мне помогает, но мне не хватает математики.
Тэг «встроенные системы». Но почему?
Чего не хватает инженерному образованию
Качественной практики, и базы передаваемого опыта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чего не хватает инженерному образованию