Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 90
Именно, причем ширина должна со временем расти и перетекать в глубину.
Бывает полезно углубляться в языки, отличные от профильных, чтобы черпать новые идеи для реализации тех или иных вещей на профильных, либо (если на другом языке возможно решить задачу оптимальнее/элегантнее/и тд) делать симбиоз.
>причем ширина должна со временем расти и перетекать в глубину.
Как кислота из жил «Чужого» — растекаясь по полу, проедает в нем большую дыру. :)
Как кислота из жил «Чужого» — растекаясь по полу, проедает в нем большую дыру. :)
ИМХО несколько некорректный вопрос. Программист должен уметь обучаться, но при этом иметь глубокие знания в какой-либо «целевой» области.
Проголосовал за «глубину», ибо стараниями «широких» программистов и рождается Его Величество Говнокод.
Проголосовал за «глубину», ибо стараниями «широких» программистов и рождается Его Величество Говнокод.
Реквестую опрос: «Что важнее для программиста: правая или левая рука»
Я думал сначала добавить вариант «сбалансированно», но этот вариант был бы очевидным. Поэтому вопрос скорее, что важнее. В случае с руками можно сказать, что с точки зрения эффективности, правая для правши, так как при использовании одной руки будет гораздо сложнее научиться держать мышку левой, чем просто печатать правой.
Важнее, откуда они растут)
стооооп. Беркм прогера visual C++ и прогера Qt C++. Прогер будет рождать говнокод, если он от первого перешел ко второму? или наоборот?
Я голосовал за ширину т.к. технологии устаревают и в задницу я могу засунуть свои познания паскаля. А затра туда же может уйти и Qt если я уволюсь и не найду нормального работодателя. И снова буду искать должность имбидера на C++.
Я голосовал за ширину т.к. технологии устаревают и в задницу я могу засунуть свои познания паскаля. А затра туда же может уйти и Qt если я уволюсь и не найду нормального работодателя. И снова буду искать должность имбидера на C++.
Когда я волею судеб начал писать на php, я писал говнокод, потому как имел довольно поверхностные знания. Углубил знания путем разработки «just for fun», начал этой технологией зарабатывать. То же самое повторилось с руби. Поверхностные знания работодателю не нужны. Почему? Да потому что будет выходить говнокод.
Говнокод, по-моему, не относится к области знания языка/технологии/платформы. Это архитектура, стиль, образ мышления в конце концов, но не отсутствие знаний.
говоря опять о руби, программистов-новичков хорошо можно узнать, задав задачу, с которой справится какой-нибудь один не самый популярный метод массива из стандартной библиотеки. новичок начнёт делать свою реализацию, не зная о его существовании.
«широкоориентированность» и говнокод — не причина и следствие, а два идущих за руку друга. нелюбовь человека к глубокому изучению предмета всегда соседствует с нежеланием совершенствовать своё мышление и способности проектирования.
«широкоориентированность» и говнокод — не причина и следствие, а два идущих за руку друга. нелюбовь человека к глубокому изучению предмета всегда соседствует с нежеланием совершенствовать своё мышление и способности проектирования.
Но справедливо ли считать свою реализацию говнокодом? Для меня говнокод — это, прежде всего, код в котором невозможно разобраться (причём это может быть как «спагетти», так и нагромождение абстракций, классов, интерфейсов, паттернов), код который невозможно изменить, или, как в вашем примере, код, который невозможно заменить на вызов стандартного метода. Есть, конечно и другие признаки говнокода, и есть код попадающий под эти признаки, но говнокодом не являющимся, но читаемость и поддерживаемость, по-моему, определяющие. Если вы с первого взгляда (а не за час с дебаггером) определили, что код новичка делает и поняли, что он просто не знает о существовании такого метода и заменили его код на вызов метода за несколько секунд, не сомневаясь в том, что это нигде не аукнется, то, может быть, новичок не так уж плох?
Тоже не согласен, но это уже почти переход на личности. Допустим, я глубоко изучил PHP как язык и поверхностно нестандартные библиотеки (ну нельзя же знать всё). Тут мне поручили написать GUI приложение посложнее чем hello-world (тот же desktop-клиент для разрабатываемого мною REST-API на сайте). Без «широкоориентированности» я бы взял PHP-GTK или PHP-Qt и начал писать на нём. Код был бы близок к идеальному, но вот вздумай я им похвастаться на хабре… А так я возьму Python/PyQt или Mono/C#/GTK#, код не будет идеален, поскольку я полезу туда со своим PHP видением идеального кода, но почему-то мне кажется эти варианты будут лучше и их с меньшими проблемами сможет подхватить кто-то другой.
Тоже не согласен, но это уже почти переход на личности. Допустим, я глубоко изучил PHP как язык и поверхностно нестандартные библиотеки (ну нельзя же знать всё). Тут мне поручили написать GUI приложение посложнее чем hello-world (тот же desktop-клиент для разрабатываемого мною REST-API на сайте). Без «широкоориентированности» я бы взял PHP-GTK или PHP-Qt и начал писать на нём. Код был бы близок к идеальному, но вот вздумай я им похвастаться на хабре… А так я возьму Python/PyQt или Mono/C#/GTK#, код не будет идеален, поскольку я полезу туда со своим PHP видением идеального кода, но почему-то мне кажется эти варианты будут лучше и их с меньшими проблемами сможет подхватить кто-то другой.
Ни кто из нас не знает всех функций родного ему Framework-а. Написать аналог существующей — еще не значит написать кусок говнокода. Критерии качества кода — места его в системе, простота замены функции на нечто иное (например, на малоизвестную стандартную), декомпозиция решения (если это не две строки, а например 100) и т.д.
> «широкоориентированность» и говнокод — не причина и следствие, а два идущих за руку друга. нелюбовь человека к глубокому изучению предмета
Позвольте поспорить.
Что такое говнокод? Это сложный код — можно было бы написать чище, приятнее, удобнее для сопровождения.
Это можно было бы сделать как и по-другому сконструировав код, сделав его менее запутанным, так и использовав шоткаты языка, библиотеки или фреймворка вместо своего велосипеда.
И того два типа говнокода: запутанный код и велосипедостроение. И соответственно две части. Я их разделю, чтобы легче было обсуждать каждую отдельно.
Позвольте поспорить.
Что такое говнокод? Это сложный код — можно было бы написать чище, приятнее, удобнее для сопровождения.
Это можно было бы сделать как и по-другому сконструировав код, сделав его менее запутанным, так и использовав шоткаты языка, библиотеки или фреймворка вместо своего велосипеда.
И того два типа говнокода: запутанный код и велосипедостроение. И соответственно две части. Я их разделю, чтобы легче было обсуждать каждую отдельно.
(блин, стронг не закрыл, а предпросмотр не показал выделение вообще :( Сорри )
Первая часть.
Кто пишет запутанный код? Специально никто. Каждый пишет такой код, который сам считает хорошим/читаемым/удобным и т.п.
Тогда откуда появляется запутанный говнокод? Из-за разницы уровней девелоперов. Один знает два пути решения задачи и выбрал лучший. Другой знает 20, а два пути первого считает запутанными. Вот второй и говорит, что первый пишет запутанный говнокод.
Как избежать того, чтобы твой код называли запутанным? Получается, что надо знать как можно больше путей решения задачи, их плюсы и минусы.
И тут «широкие» программисты рулят и педалят. Посмотрев десятки языков, фреймворков библиотек они собрали в голове кучу способов решения множества задач. Достаточный объем чтобы не только писать приятный код, но и скептически хмыкать смотря на ваши стандартные библиотеки и фреймворки: «вот там-то это сделано намного приятнее».
Первая часть.
Кто пишет запутанный код? Специально никто. Каждый пишет такой код, который сам считает хорошим/читаемым/удобным и т.п.
Тогда откуда появляется запутанный говнокод? Из-за разницы уровней девелоперов. Один знает два пути решения задачи и выбрал лучший. Другой знает 20, а два пути первого считает запутанными. Вот второй и говорит, что первый пишет запутанный говнокод.
Как избежать того, чтобы твой код называли запутанным? Получается, что надо знать как можно больше путей решения задачи, их плюсы и минусы.
И тут «широкие» программисты рулят и педалят. Посмотрев десятки языков, фреймворков библиотек они собрали в голове кучу способов решения множества задач. Достаточный объем чтобы не только писать приятный код, но и скептически хмыкать смотря на ваши стандартные библиотеки и фреймворки: «вот там-то это сделано намного приятнее».
Вторая часть:
Тогда что насчёт велосипедостроения? Тут «широкие» проигрывают: «глубокий» девелопер, который использует фреймворк или язык уже много лет, знает больше ньюансов, да.
Но! Местные ньюансы скорее всего не оригинальны. Скорее всего они уже встречались в других языках и «широкий» скорее всего о них будет знать. Это не 100%. «широкий» конечно не найдёт все ньюансы, но и совсем нубом он точно не будет.
Всё таки проигрыш? Не совсем. «Широкий» будет гуглить также чтобы найти шорткаты, которых нет в местном языке и фреймворке! Он их видел в других языках. А когда не найдёт поплюется и создаст свой.
Таким образом «глубоким» придётся показать «широкому» несколько шорткатов, которые он не нашел, но! взамен он принесёт из других языков новые шорткаты, про которые «глубокие» и не подозревали.
Тогда что насчёт велосипедостроения? Тут «широкие» проигрывают: «глубокий» девелопер, который использует фреймворк или язык уже много лет, знает больше ньюансов, да.
Но! Местные ньюансы скорее всего не оригинальны. Скорее всего они уже встречались в других языках и «широкий» скорее всего о них будет знать. Это не 100%. «широкий» конечно не найдёт все ньюансы, но и совсем нубом он точно не будет.
Всё таки проигрыш? Не совсем. «Широкий» будет гуглить также чтобы найти шорткаты, которых нет в местном языке и фреймворке! Он их видел в других языках. А когда не найдёт поплюется и создаст свой.
Таким образом «глубоким» придётся показать «широкому» несколько шорткатов, которые он не нашел, но! взамен он принесёт из других языков новые шорткаты, про которые «глубокие» и не подозревали.
visual C++ и Qt C++ — заведомо плохое сравнение. вот если бы visual c++ и perl, это уже было бы корректнее.
Теорема.
Для программиста важнее «знать всего по чуть-чуть и умение быстро обучаться и при помощи гугла разобраться в любой теме за несколько дней».
Доказательство.
Предположим, что это не так, т.е. для программиста важнее «иметь глубокие знания в одной области, досконально знать несколько языков, технологий, фреймворков,…». Следовательно, программисту совсем не обязательно знать, например, как устроен процессор IA-32, и как вообще его код на языке высокого уровня представлен в процессоре. Но тогда он не сможет задумываться об оптимизации своего кода, не сможет использовать ассемблерные вставки и тд. А, значит, он вряд ли сможет писать действительно качественное ПО. Однако, программист ДОЛЖЕН писать качественное ПО (согласно аксиоме 3). Следовательно, наше предположение не верно.
Теорема доказана.
Для программиста важнее «знать всего по чуть-чуть и умение быстро обучаться и при помощи гугла разобраться в любой теме за несколько дней».
Доказательство.
Предположим, что это не так, т.е. для программиста важнее «иметь глубокие знания в одной области, досконально знать несколько языков, технологий, фреймворков,…». Следовательно, программисту совсем не обязательно знать, например, как устроен процессор IA-32, и как вообще его код на языке высокого уровня представлен в процессоре. Но тогда он не сможет задумываться об оптимизации своего кода, не сможет использовать ассемблерные вставки и тд. А, значит, он вряд ли сможет писать действительно качественное ПО. Однако, программист ДОЛЖЕН писать качественное ПО (согласно аксиоме 3). Следовательно, наше предположение не верно.
Теорема доказана.
Поправьте меня, если я не прав, но PHP довольно простой язык, имеющий очень узкую специализацию. И обучиться программированию на нем можно за три-четыре дня. Я же писал про более универсальные языки.
Как же вам в жизни повезло — вы не правили код тех, кто 3-4 дня назад «выучил» php.
Вы хотите сказать не обучиться программированию на нём, а изучить синтаксис, если уже неплохо знаешь, например, C++?
Изучить синтаксис — возможно. Вникнуть в идеологию языка (практически любого), научиться правильно и осмысленно его применять — нет.
Изучить синтаксис — возможно. Вникнуть в идеологию языка (практически любого), научиться правильно и осмысленно его применять — нет.
В принципе биндинги PHP существуют ко многим популярным библиотекам, включая различные GUI. Работа с ФС или БД от C сильно не отличается, разве что за памятью следить не надо. То есть как язык общего назначения он, в принципе, не хуже других «Си с классами»-подобных. Не без недостатков, но большинство из них свойственно всем языкам с подобным подходом и они, имхо, не настолько существенны, чтобы изучать новый язык (а, главное, имхо, его инфраструктуру) ради не критической разовой задачи типа парсинга сайта(ов), какого-нибудь бота, хрон-задач и т. п., и даже сетевых демонов.
Кодировать в процедурном стиле чётко сформулированные алгоритмы без обращения к стандартным библиотекам или к очень узкому их кругу — наверное можно и за 3-4 дня. Использовать, а главное к месту использовать, все фичи языка (не библиотек) такие как «магические методы», наследование, интерфейсы (включая стандартные типа Iterator или ArrayAccess), позднее статическое связывание, отражения, callable, анонимные функции и замыкания, типажи и т. п. — дико сомневаюсь. Плюс библиотеки, хотя бы стандартные. Сомневаюсь, что года хватит хорошо их изучить и научиться применять, даже не отвлекаясь на бизнес-код, то есть собственно решение задачи. И это при условии, что собственно программировать (из неформальной постановки задачи перейти к архитектуре и алгоритмам, пускай и нерациональным) человек уже умеет.
Кодировать в процедурном стиле чётко сформулированные алгоритмы без обращения к стандартным библиотекам или к очень узкому их кругу — наверное можно и за 3-4 дня. Использовать, а главное к месту использовать, все фичи языка (не библиотек) такие как «магические методы», наследование, интерфейсы (включая стандартные типа Iterator или ArrayAccess), позднее статическое связывание, отражения, callable, анонимные функции и замыкания, типажи и т. п. — дико сомневаюсь. Плюс библиотеки, хотя бы стандартные. Сомневаюсь, что года хватит хорошо их изучить и научиться применять, даже не отвлекаясь на бизнес-код, то есть собственно решение задачи. И это при условии, что собственно программировать (из неформальной постановки задачи перейти к архитектуре и алгоритмам, пускай и нерациональным) человек уже умеет.
Язык то может вы и выучите за 3-4 дня, в чем лично я сильно сомневаюсь. Но ведь знание language reference это только начало. Только потом вы откроете например github.com/symfony/FrameworkBundle и сразу же закроете со своими знаниями языка за 3-4 дня
Нет никакой связи между ассемблерными вставками и качеством кода. При доказательстве используется софистика, следовательно, вы ничего не доказали.
Нда, говорит по ходу железячник:-) Уж простите, но для того, чтобы хорошо водить не надо знать досканально устройство автомобиля, пилоту самолета не нужно знать устройство самолета, космонавту не требуется знание ракеты. Бред говорите, ассемблер в наше время нужно знать разве что железячнику, хоть сам и знаю, но современные компиляторы так соптимизируют, что самому удивиться можно.
Я знаю по крайней мере i386, но как-то мне эти знания не сильно пригодились для оптимизации, ибо в моей работе всегда найдутся более узкие средства, нежели мой программный код на C/C++.
Я знаю по крайней мере i386, но как-то мне эти знания не сильно пригодились для оптимизации, ибо в моей работе всегда найдутся более узкие средства, нежели мой программный код на C/C++.
Пилоту не нужно знать устройство самолета? Вы серьезно?
Нет, я понимаю, что знать, какой провод из миллиона куда идет, ему не нужно, но знать, почему может загореться двигатель, или почему может не открываться шасси надо.
По поводу оптимизации компиляторами — Бог его знает, как они оптимизируют. Конечно, если перед программистом стоит задача написания клиента БД, ему не стоит задумываться об ассемблере. Но если он пишет сервер БД, который должен каждую секунду обрабатывать 20000+ запросов, каждый из которых требует какого-нибудь поиска, или сортировки, ассемблер может ему пригодиться.
И вообще, знание основ архитектуры ЭВМ обязательно. Если кто-то пишет код на C++, но понятия не имеет, что такое конвейер, он и не знает, для кого этот код пишет. Все равно, что писать техническое задание, не зная кто его будет выполнять.
Нет, я понимаю, что знать, какой провод из миллиона куда идет, ему не нужно, но знать, почему может загореться двигатель, или почему может не открываться шасси надо.
По поводу оптимизации компиляторами — Бог его знает, как они оптимизируют. Конечно, если перед программистом стоит задача написания клиента БД, ему не стоит задумываться об ассемблере. Но если он пишет сервер БД, который должен каждую секунду обрабатывать 20000+ запросов, каждый из которых требует какого-нибудь поиска, или сортировки, ассемблер может ему пригодиться.
И вообще, знание основ архитектуры ЭВМ обязательно. Если кто-то пишет код на C++, но понятия не имеет, что такое конвейер, он и не знает, для кого этот код пишет. Все равно, что писать техническое задание, не зная кто его будет выполнять.
Про то и разговор, почему вылетела ошибка Segmentation Fault программисту надо знать, но это не говорит о том, что ему нужно знать ассемблер.
Опять же знание основ архитектуры и ассемблер это вещи слегка разные. Основы надо знать, но зачем ассемблер-то. Если не верите, возьмите компилятор Visual Studio 2010 к примеру, напишите сортировочку на С++ и на асме, сравните конечный код и стоит ли это того? (Хотя написать по разному можно, помнится в доке по PHP по тестам от разработчиков, PHP рвал по производительности C, вроде от 4й версии дока)
Ну к примеру я занимаюсь разработкой высоконагруженных вещей, модули для nginx и т.д., скорость работы очень и очень не хилая. И при этом ничего на асме не написано.
Опять же знание основ архитектуры и ассемблер это вещи слегка разные. Основы надо знать, но зачем ассемблер-то. Если не верите, возьмите компилятор Visual Studio 2010 к примеру, напишите сортировочку на С++ и на асме, сравните конечный код и стоит ли это того? (Хотя написать по разному можно, помнится в доке по PHP по тестам от разработчиков, PHP рвал по производительности C, вроде от 4й версии дока)
Ну к примеру я занимаюсь разработкой высоконагруженных вещей, модули для nginx и т.д., скорость работы очень и очень не хилая. И при этом ничего на асме не написано.
> Пилоту не нужно знать устройство самолета? Вы серьезно?
Пилоту не нужно знать устройство самолета. Ему нужно иметь отточенные до автоматизма навыки поведения в штатных и, тем более, нештатных ситуациях, и достаточно ума использовать эти навыки, а не рассуждать об устройстве сложнейшего, напичканного электроникой, агрегата. Почитайте того же Ершова.
Пилоту не нужно знать устройство самолета. Ему нужно иметь отточенные до автоматизма навыки поведения в штатных и, тем более, нештатных ситуациях, и достаточно ума использовать эти навыки, а не рассуждать об устройстве сложнейшего, напичканного электроникой, агрегата. Почитайте того же Ершова.
Теорию программирования любой программист должен знать «глубоко», а вот языки программирования можно и «широко», хотя желательно хотя бы один знать «глубоко» и если уж что-то в работе встретилось, изучать качественно, а не спросить где-нить на Stack Overflow 1 раз и забыть.
Важнее для кого? Для работодателя или для программиста?
как говорил один препод «надо знать немного обо всем и все о немногом»
В России для программиста важна не только широта, но еще и долгота! Европейские, Американские и другие долготы являются идеальными.
Лапы, крылья… главное хвост!
Широта, важно знать о существовании инструментов и библиотек (особенно Java) чтобы не писать велосипеды и грамотно спроектировать слои и каркас системы, потом работает API и документация, со временем придет и широта.
Однозначно глубина, «широкие» программисты всего лишь мартышки пригодные для поиска в гугле и набиванию кода. В гугле всего не узнаешь + умение быстро адаптироваться само придет со временем.
Мне кажется, что хороший программист знает практически досканально каку-то часть (язык, технологию) с который часто работает и без проблем может освоить поверхностно что-то новое а затем и углубиться в это.
Вопрос имхо не корректен. Хороший программист обладает обоими качествами, плохой — должен стремиться стать хорошим.
Вопрос имхо не корректен. Хороший программист обладает обоими качествами, плохой — должен стремиться стать хорошим.
Специалист – это человек знающий все больше и больше, о все меньшем и меньшем.
С другой стороны в эпоху постоянного прогресса, когда одна технология сменяет другую за десять лет сложно быть специалистом. Но не быть им еще хуже.
Думаю верный ответ – широта знаний, не только в области разработки, но и открытость суждения и быстрота обучения.
Умейте забывать быстрее, чем учитесь. Но забывать то, что хотите.
С другой стороны в эпоху постоянного прогресса, когда одна технология сменяет другую за десять лет сложно быть специалистом. Но не быть им еще хуже.
Думаю верный ответ – широта знаний, не только в области разработки, но и открытость суждения и быстрота обучения.
Умейте забывать быстрее, чем учитесь. Но забывать то, что хотите.
я бы отметил оба пункта
Запощу ссылку на очень радикальное мнение по теме: Теоретический минимум для программиста
Что самому человеку нравится и интересно.
Кому-то нравится постоянно изучать новые технологии и тенденции — широта охвата
А кто-то предпочитает знать свою область, но досконально.
Кому-то нравится постоянно изучать новые технологии и тенденции — широта охвата
А кто-то предпочитает знать свою область, но досконально.
Что для программиста важнее: вода или воздух?
«Кого ты больше любишь: маму или папу?»
Какой-то уж очень поверхностный и флеймообразующий опрос. И что мы узнаем в результате — что большинство предпочитает не углубляться?..
Посмотрите вот на эту матрицу — она даёт лучшее представление о «системе ценностей» программиста:
www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm
Посмотрите вот на эту матрицу — она даёт лучшее представление о «системе ценностей» программиста:
www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm
Я бы дал другое определение глубине = глубокое понимание процессов выбранной архитектуры. А язык — не важно.
Я за второй вариант, т.к. он более сбалансирован: если прочитать внимательно, то выбор этого варианта предполагает всестороннее (глубина) знание нескольких (широта) технологий, языков и т.д. :)
Умей делать что-то лучше большинства других и будешь зарабатывать деньги.
Только ситхи всё возводят в абсолют.
Программисты бывают разные. Для кого-то будет важнее глубина, для кого-то широта.
— функциональное программирование
— логическое программирование
— ассемблер, программирование микроконтроллеров
— написание шейдеров
— игростроение (алгоритмы ИИ, поиск путей, принятия решений и т.п.)
— 3D-графика
— статистические вычисления
— софт для медицинского, авиационного, промышленного оборудования
— системы реального времени
— системы автоматизированного управления
— …
— …
— разработка интернет-сайтов
поднимите руки из тех, кто проголосовал за первый вариант и способен за несколько дней с помощью гугла начать полезную деятельность в любом из перечисленных (хотя бы) направлений ;)
— логическое программирование
— ассемблер, программирование микроконтроллеров
— написание шейдеров
— игростроение (алгоритмы ИИ, поиск путей, принятия решений и т.п.)
— 3D-графика
— статистические вычисления
— софт для медицинского, авиационного, промышленного оборудования
— системы реального времени
— системы автоматизированного управления
— …
— …
— разработка интернет-сайтов
поднимите руки из тех, кто проголосовал за первый вариант и способен за несколько дней с помощью гугла начать полезную деятельность в любом из перечисленных (хотя бы) направлений ;)
А почему бы и нет?:)
Не на уровне гуру, но на уровне собрать рабочий прототип можно (собсно все перечисленные темы кроме пары пунктов делал в свое время)
Не на уровне гуру, но на уровне собрать рабочий прототип можно (собсно все перечисленные темы кроме пары пунктов делал в свое время)
Ну я проголосовал и всем выше перечисленным даже занимался ) Ну с небольшой правкой: шейдерами не занимался и софт делал не для медицинского оборудования, а для станков роботизированных, это все-таки чуток другое.
И то и другое — слишком банально!
Программист должен обладать глубокими ФУНДАМЕНТАЛЬНЫМИ знаниями, таких как построение и анализ алгоритмов и т. п.
И широта в быстро изменяющихся технологиях, таких как «ну вы сами знаете».
Программист должен обладать глубокими ФУНДАМЕНТАЛЬНЫМИ знаниями, таких как построение и анализ алгоритмов и т. п.
И широта в быстро изменяющихся технологиях, таких как «ну вы сами знаете».
Это вопрос-троллинг, когда пытаются бесконечный континуум свести к вилке ( В данном случуе усугубленный еще тем, что под КГУБИНОЙ стоит знание нескольких языков и технологий, что противоречит постановке вопроса.
Сильно затачиваясь на какой-то один инструмент. В нашем контексте «Глубина», программист рискует остаться не у дел, когда этот инструмент заменят на другой.
Всегда считал и до сих пор так думаю, что нужно знать что-то идеально (насколько это возможно). Быть в этом одним из лучших. Но с ростом ит, разумеется, нужно всегда быть на «волне», успевать за развитием старого и появлением нового.
Нельзя однозначно выбрать один из вариантов. В одной ситуации подходит первый вариант, в другой — второй.
В теории от специфики зависит, на практике надо оба варианта. Сначала второе а потом первое.
Я вот знаю основы многих языков, но чтоб реально все эти языки применять не хватает глубины. Я мог бы проектировать системы вообще вне языка, мог бы выбирать какой блок на каком языке писать. Но чтоб меня взяли на такую специальность, надо сначала набраться опыта в каком-то одном языке, и причём достичь результатов, а так кто мне доверит быть например тимлидом если я до этого не имел собственно опыта в простом кодерстве?
Я вот знаю основы многих языков, но чтоб реально все эти языки применять не хватает глубины. Я мог бы проектировать системы вообще вне языка, мог бы выбирать какой блок на каком языке писать. Но чтоб меня взяли на такую специальность, надо сначала набраться опыта в каком-то одном языке, и причём достичь результатов, а так кто мне доверит быть например тимлидом если я до этого не имел собственно опыта в простом кодерстве?
В книге «Программист-прагматик» эта тема рассматривается.
Цитаты:
Считается, что есть два типа людей. Одни любят изучать многое и поверхностно, другие выбирают пару дисциплин и изучают их очень глубоко. Первых обычно называют лисами, вторых — ежами.
Итак, как мы учимся? Что надо сделать для более эффективного процесса?
1. Включить режим лисы и составить карту территории. Наметить несколько мест, с которых стоит начать углубление в тему.
2. Попытаться понять связи между дисциплинами и последовательность их освоения. На высоком уровне это сделать достаточно просто.
3. Включить режим ежа и начать прорабатывать тему глубоко. Иногда придется прерываться, и переключаться на смежные темы, иначе более глубокие пласты недостижимы.
Цитаты:
Считается, что есть два типа людей. Одни любят изучать многое и поверхностно, другие выбирают пару дисциплин и изучают их очень глубоко. Первых обычно называют лисами, вторых — ежами.
Итак, как мы учимся? Что надо сделать для более эффективного процесса?
1. Включить режим лисы и составить карту территории. Наметить несколько мест, с которых стоит начать углубление в тему.
2. Попытаться понять связи между дисциплинами и последовательность их освоения. На высоком уровне это сделать достаточно просто.
3. Включить режим ежа и начать прорабатывать тему глубоко. Иногда придется прерываться, и переключаться на смежные темы, иначе более глубокие пласты недостижимы.
С мышлением в ширину проще найти работу. С мышлением в глубину найти работу сложней, но зато она будет высокооплачиваемой. Лично я за мышление в ширину, чтобы более устойчиво себя чувствовать на рынке труда.
Если упростить ситуацию до абсурда — в аутсорсовых «бодишопах» приветствуется глубина. В бухлагтерской фирме в 100 человек вас могут попросить и макрос в Excel набросать, и «CRM» написать.
Если еще более упростить, то в основном все мы знаем как «правильно», но всегда только знаем, а не ведем себя так, как советуем другим.
Перефразируя Гайя Кавасаки — "Эксперты — не способны делать, поэтому советуют. "
Перефразируя Гайя Кавасаки — "Эксперты — не способны делать, поэтому советуют. "
«ШИРОТА = Знать всего по чуть-чуть и умение быстро обучаться = при помощи гугла разобраться в любой теме за несколько дней» — это определение сильно попахивает и, по-моему, относится к стадии начального становления программиста.
Для профессионала-разработчика под определенные платформы — глубина, для профессионала-архитектора широта (но не та, определение которой дано в ответах к опросу). Для проекта — наличие обоих в нужной пропорции. Это как тура и слон. Вместе получаем ферзя.
Для профессионала-разработчика под определенные платформы — глубина, для профессионала-архитектора широта (но не та, определение которой дано в ответах к опросу). Для проекта — наличие обоих в нужной пропорции. Это как тура и слон. Вместе получаем ферзя.
при помощи гугла разобраться в любой теме за несколько дней
вот недавно хорошая фраза по этому делу была прочитана
Миф: теоретическая возможность доступа к информации равнозначна полному и безупречному знанию, а также базирующихся на нём навыках
хотя и автор того блога не сильно любим в интернетах
Зависит от времени. С опытом ширина должна уменьшаться, а глубина увеличиваться, как мне кажется
Знать все обо всем не получится в силу ограниченности ресурсов. Я бы сказал, что оптимальная пропорция широты: глубины составляет примерно 40:60.
Каждый решает для себя сам.
Глубина.
Ты можешь знать полумёртвый Делфи и забытый Кобол, но знать их хорошо и получать проекты в банках с оплатой более тысячы евро в день.
Широта.
А модешь знать обо всём понемногу и работать в этом банке в качестве CIO и иметь стабильную зарплату от 200 тысяч евро в год.
В любом из классов можно достичь мастерства 80lvl.
А можешь с пеной у рта дoказывать правоту одного из предложенных вариантов в комментариях на Хабре :)
Глубина.
Ты можешь знать полумёртвый Делфи и забытый Кобол, но знать их хорошо и получать проекты в банках с оплатой более тысячы евро в день.
Широта.
А модешь знать обо всём понемногу и работать в этом банке в качестве CIO и иметь стабильную зарплату от 200 тысяч евро в год.
В любом из классов можно достичь мастерства 80lvl.
А можешь с пеной у рта дoказывать правоту одного из предложенных вариантов в комментариях на Хабре :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что важнее для программиста?