Вообще-то обучение на медицинских специальностях сильно отличается от обучения тому же программированию. После окончания 4-5 летнего обучения «на медицину» получаются общие специалисты, как и выпускаемые «программисты» того же уровня. Но потом в «медицине» начинается разделение и новое обучение, интернатура и ординатура, без чего медработников не допустят до чего-то серьезного, типа хирургии (но можно остаться в поликлинике). А программист может начать фигачить в продакшен с первого курса и даже раньше. Можно ли считать это недостатком — очень спорный вопрос. Все равно когда-то приходится начинать нести самостоятельную ответственность за свои действия. В этом случае программирование выгоднее отличается от медицины, т.к. нести ответственность в программировании начинают значительно раньше, ну и не тошнит, если вы понимаете о чем я )))
что многие так называемые самоучки на самом деле не горят желанием изучать все необходимое для работы
Позвольте поправить. Не только самоучки, но и вполне уважаемые доны, отучившиеся во всяких универах и много лет практикующих. Давайте без дискриминации. )))
Как понять, что тебе нужна многопоточность, если ты не знаешь о ее существовании?
Для меня самого секрет как я выбираю «ингредиенты». Для меня важнее «угадать» конфигурацию данных при передаче из одной системы в другую. Вполне возможно, что секрет кроется в том, что я пишу одну и туже программу, просто в разных модификациях. По аналогии — есть ДНК и из неё можно вырастить жука или кита. Я просто создаю условия, чтобы получались разные экземпляры. )))
я не спорю, что нужно знать, что есть алгоритмы. Я пытался расширить ваш комментарий. Просто думать только об алгоритмах мало. Очень много бизнес-задач не связаны ни с математикой, ни с алгоритмами от слова «никак» и несколько сортировок в программе на фоне общего объёма программирования — это ничтожная работа. В 99% случаев в бизнес-логике достаточно просто каких-то простых словарей и списков.
Вообще, знать надо такую кучу вещей, что прямо офигеваешь
Есть такое выражение «хвост виляет собакой». По аналогии это когда фреймворки и языки управляют программистом. Должно быть наоборот. Именно вы должны управлять процессом программирования, а не процесс программирования управлять вами. Не многопоточность всплыла в какой-то момент, а вы решаете «Так, мне тут нужна многопоточность» и подключаете её. Или «Для этих данных нужна реляционная модель» и подключаете MsSQL/MySQL/PostgreSQL. А тут у меня данные денормализированы. Тут мне нужен JSON/XML. На этом уровне модели мне нужно преобразование XML-JSON… какие тут у нас популярные библиотеки, протестируем… Эй, NuGet, maven, bower — по порядку рассчитайсь!
>> но цель бизнеса получение прибыли
Всё верно. Так учат в институте/универе на кафедре экономики. Такие темы — это уход от персонального разговора. На собеседовании тему надо держать вокруг себя. И если уж перед кандидатом ставят вопрос так, то в ответ хочется спросить «Какую прибыль по вашему предположению я должен приносить?». Интересно послушать пространный ответ )))
Я не отказываю. Только выражение «нести ответственность» вы трактуете со скрытым смыслом. HR несёт ответственность перед бизнесом, а не перед кандидатом. Кандидат так же как и бизнес имеет право выставить условия, а не просто соглашаться. Устройство на работу — это тоже бизнес. Поэтому не надо занижать чужие права.
>> Программистов давить: вы медленно пишете…
Шутите?))). Быстро получить неизвестное решение? Разве только сомнительного индусского качества. Согласен, что в профессии программиста есть две составляющие — продумывание решения и программирование. Писать можно быстро, если именно вы дали продуманное решение, которое понято и которое соответствует ТЗ. Но сколько вы на это потратили время? Такое нельзя предсказать за исключением однотипных задач. За продажи программист ответственности не несёт. Это ваша, менеджерская зона ответственности. А если менеджер обвиняет программистов в плохой продаваемости продукта, то, простите, это плохой менеджер. (Не имею ввиду лично вас)
>> Из менеджеров не уходят! Из них только выносят :)
Некоторых прямо с совещаний.
>> рука дрогнула и все.
Ну, разве что речь о нейрохирургах. Да и то у нейрохирургов сейчас масса компьютерного оборудования с таким набором фантастических свойств, но все благодаря программам, блокирующие не только дрожание рук хирурга. Все стало слишком связанным…
А в остальном все верно. )))
А у менеджеров нет стека? Побыл менеджером, принёс пользу, задрочил стек и… Куда? Шучу конечно, я был программистом, потом небольшим менеджером, потом плюнул на менеджера, не понравилось, вернулся программировать, очень доволен.
А по какой причине HR рассказывает бизнесу как выбирать кадры? Тем более, что программист делает работу, а HR не делает ни бизнес, ни работу.
Думаю, что каждый может высказать своё мнение, а учитывать его или нет пусть бизнес решает сам.
Вы же понимаете, что найти хорошее решение может даже и не профессионал?
Позвольте поправить. Не только самоучки, но и вполне уважаемые доны, отучившиеся во всяких универах и много лет практикующих. Давайте без дискриминации. )))
Для меня самого секрет как я выбираю «ингредиенты». Для меня важнее «угадать» конфигурацию данных при передаче из одной системы в другую. Вполне возможно, что секрет кроется в том, что я пишу одну и туже программу, просто в разных модификациях. По аналогии — есть ДНК и из неё можно вырастить жука или кита. Я просто создаю условия, чтобы получались разные экземпляры. )))
Есть такое выражение «хвост виляет собакой». По аналогии это когда фреймворки и языки управляют программистом. Должно быть наоборот. Именно вы должны управлять процессом программирования, а не процесс программирования управлять вами. Не многопоточность всплыла в какой-то момент, а вы решаете «Так, мне тут нужна многопоточность» и подключаете её. Или «Для этих данных нужна реляционная модель» и подключаете MsSQL/MySQL/PostgreSQL. А тут у меня данные денормализированы. Тут мне нужен JSON/XML. На этом уровне модели мне нужно преобразование XML-JSON… какие тут у нас популярные библиотеки, протестируем… Эй, NuGet, maven, bower — по порядку рассчитайсь!
«Ничто не ново — только мы»
Меня опыт научил двум вещам
— декомпозиция задачи
И
— как не надо делать
Мне кажется, что надо к таким вещам относиться веселее, что-ли. )))
Анекдот.
Приходит ветеринар к врачу. Врач спрашивает
— Ну, что у вас болит?
Ветеринар:
— Не, ну так каждый может!
Всё верно. Так учат в институте/универе на кафедре экономики. Такие темы — это уход от персонального разговора. На собеседовании тему надо держать вокруг себя. И если уж перед кандидатом ставят вопрос так, то в ответ хочется спросить «Какую прибыль по вашему предположению я должен приносить?». Интересно послушать пространный ответ )))
Шутите?))). Быстро получить неизвестное решение? Разве только сомнительного индусского качества. Согласен, что в профессии программиста есть две составляющие — продумывание решения и программирование. Писать можно быстро, если именно вы дали продуманное решение, которое понято и которое соответствует ТЗ. Но сколько вы на это потратили время? Такое нельзя предсказать за исключением однотипных задач. За продажи программист ответственности не несёт. Это ваша, менеджерская зона ответственности. А если менеджер обвиняет программистов в плохой продаваемости продукта, то, простите, это плохой менеджер. (Не имею ввиду лично вас)
>> Из менеджеров не уходят! Из них только выносят :)
Некоторых прямо с совещаний.
Ну, разве что речь о нейрохирургах. Да и то у нейрохирургов сейчас масса компьютерного оборудования с таким набором фантастических свойств, но все благодаря программам, блокирующие не только дрожание рук хирурга. Все стало слишком связанным…
А в остальном все верно. )))
Думаю, что каждый может высказать своё мнение, а учитывать его или нет пусть бизнес решает сам.