Зачем мне знать, что замыкание называется именно замыканием?
Чтобы эффективно общаться с другими.
Пописывать статейки или преподавать — да. В реальной работе — нет.
Не представляю чтобы на meeting мы обсуждали проект на уровне — «тут нужно замыкание».
Повторю еще раз:
Только начинающие столь серьезно относятся к недавно зазубренным названиям. Полагаю потому, что им пока что больше нечего обсудить, нет опыта в более общих вещах.
Потому и тестирование описанное в статье под которой мы и беседуем — это тестирование для джуна/трейни. Оно даже миддла уже никак не характеризует.
А в промышленном программировании вы также поступаете? Выпускаете код, а когда прибегает пользователь с ошибкой из-за неучтённого случая, хлопаете себя по лбу и лезете исправлять код?
А при чем тут он?
Вы что, сами не видите какого огромное количество сырых продуктов выпускают на рынок? Ко всем им лично он имеет отношение?
Если речь не идет о выпуске миллионными тиражами, когда перепрошить потом дорого…
Если речь не идет о крайне дорогом исходе при одной-единственной ошибке…
То да, как правило, да, программы содержат кучи ошибок.
Заказчику/работодателю важнее снижение дорогущей себестоимости разработки, даже если возрастает риск ошибки.
Нет цели — «сделать безошибочно любой ценой».
У ошибки есть цена, у разработки с дополнительным тщательным тестированием есть цена. Заказчик выбирает между ними.
Более того, даже не всегда в деньгах дело.
Чаще более важный фактор — время разработки.
План запроса меняется автоматически в зависимости от статистики, то есть на разном объеме данных/разном содержимом может быть по разному.
Низкоуровневые знания, в которых не учтена статистика данных — тут слабый помощник. Ибо все ваши микрооптимизации могут быть в любой момент пересмотрены СУБД.
Гораздо полезнее предоставить СУБД правильные индексы — а дальше она сама разберется.
Ну а как влияют merge joins, nested loops — вы будете прекрасно понимать безо всяких o() на уровне интуиции уже после пары месяцев интенсивного написания/оптимизации запросов.
Примерно столько времени понадобилось одному из джунов (не самому таланливому в программировании), которого я натаскивал. Причем большую часть времени он сам учился. Я только советы общего характера давал типа «разбить запрос на отдельные части и посмотреть». После пары месяцев интенсива от такие стал оптимальные запросы писать — закачаешься.
Вспомните происхождение SQL — изначально он придуман вовсе не для программистов, а для менеджеров, чтобы сами себе отчеты строили, не отвлекая программистов.
Если человек заявляет, что он может программировать на некотором языке, то со связями слов с семантикой быть не должно. Иначе это прекрасный теоретик, может даже архитектор, но никак не программист.
Это показывает, что человек не преподаватель только и всего.
Скорее как раз, что терминология «от зубов отскакивает» и есть необходимое (не достаточное) условие хорошего чистого теоретика.
Архитекторы программных систем, не являющиеся программистами? Это фантастика. Такие вообще существуют? Сколько таких видели?
Собеседуемый кандидат вполне может оказаться амбициозным начинающим.
Не может.
Я выше расписал свою методу собеседования:
Беседа о реальных проектах. Какие там плюсы минусы в тех или иных решениях.
За первую минуту, человек без опыта сольется.
Более того, я наблюдал как собеседуют кандидатов менее опытные коллеги. Они действительно практикуют так как вы и описали — гоняют по тем вещам, что зубрили недавно в ВУЗе. Потому как это пока единственное, что они могут проверить у кандидатов.
Если мне зададут вопрос про что то типа полиморфизм — я просто попрошу (спокойным уверенным голосом, это важно), чтобы меня собеседовал старший разработчик. Всегда проканывало.
Почему вы решили, что ваш случай и статистика верны для всех?
А почему вы решили, что статистика иная?
Тут все верно. Но далеко не все пишут CRUD приложения.
Львиная доля программистов пишет вовсе не библиотеки сортировки.
Большинство пишет именно прикладные проекты, где нужен ввод-вывод (сеть, диски — где и находится основная часть тормозов). Даже, казалось бы, такие далекие от СУБД ребята как game developer, и те в подавляющем большинстве своем не пишут сами движков (где была бы полезна эта оптимизация «логарифм/квадратичный») и тормоза у них значительно зависят не столько от правильного цикла, сколько от грамотной работы с движком, что лежит за пределами их кода.
А что писали лично вы за последние 10 лет? Учебные/студенческие работы/курсовые/дипломные если не считать.
Языки программирования синтаксически сильно проще языков естественных, да еще и большинство трендовых — си-подобные, что еще больше снижает вероятность внезапно забыть семантику основных ключевые слов.
Простота языка программирования по сравнению с естественными языками позволяет автоматизму использования выработаться еще быстрее.
Зачем мне знать, что замыкание называется именно замыканием? Я его использовал еще за 20 лет до того, как узнал как оно называется.
Зарабатываю на программировании уже 20 лет.
В 99% случаев тормоза не имеют отношения к моей программе — в реальных проектах тормоза в СУБД, сети и пр. внешних факторах.
Просто «в вакууме» оптимизация алгоритма (логарифм/квадратичный и т.п.) сама по себе толку дает мало.
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
Кое-кто 2 тысячи лет назад уже и учение свое создал, и проповедовал по всей стране, и раскрутился, так что власти испугались, и был казнен всего-то в 33 года.
И в те времена это не было особо удивительным (удивительным является только степень распространенности его учения и как оно прошло через тысячелетия). Мужчина тогда считался мужчиной в 15.
А современные люди — какое там учение, они, оказывается, после 30 дозревают еще (как вино, что ли)
P.S.:
А если серьезно — то да, современные люди более инфантильны (можно почитать про особенности поколения Y).
Но раз на раз не приходится. Всех грести под одну гребенку — некорректно.
У меня есть знакомые: одна уехала из родительского дома в 15 лет учиться и с тех пор живет самостоятельно, обеспечивает родителей; другая уехала в 18 и родители вообще не помогали и не помогают (у них конфликт), моталась по съемным квартирам, как-то зарабатывала сама; другая в 40 лет сидит на шее у родителей, не работала и не работает (здорова, с вышкой), полагаю, и не будет (родители не олигархи, обычные).
А когда на senior-позицию приходят полные нули, что делать? Знакомый фронтендер периодически собеседует людей на позицию senior-ов. Люди говорят/пишут, что у них 3-5-10 лет опыта, но они не знают концепции замыканий.
Программирую еще с прошлого века.
Смотрю все пишут про какие-то умные замыкания. Не знаю этого термина.
Думаю, ну наверное некая умная концепция, может, буду использовать, пригодится. Надо почитать что это.
Читаю.
Ага. Использую, не зная как оно называется, уже лет 20 или поболее даже, оказывается.
Почему? Нас учили разным математическим моделям, а вовсе не тому как что называется в синтаксисе языка.
Внимание, вопрос:
Являюсь ли я недостойным должности сеньора, если 10 последних лет как проектирую highload-решения, которые держат высокие нагрузки на смешном железе?
По вашим фразам, цитирую, «Смотрю — топище расплывается от гордости, светится. Высокомерие так и льется из экрана. Рад, что съел очередного болвана, который не знает “базовых” вещей. Самоутвердился, можно искать следующего.», у меня складывается ощущение, что общаться с Вами собеседующему при дальнейшей работе, возможно, было бы непросто
Вам не составит труда ответить на пару простых вопросов, вы же профессионал.
Труда не составит, но незачем.
Я уже давно не смотрю на вирусы компьютеры знакомых только потому, что «тыж программист».
Серьезно, я даже джунов на собеседовании никогда не гонял на базовые знаний по virtual, static и singleton.
Мне всегда интересно узнать как человек оценивать с технической точки зрения выполненные им в других фирмах проекты (для студентов спрашиваю про курсовые/дипломные/пет-проекты).
Джунам давал задачу спроектировать в РСУБД модель.
Имхо это лучше характеризует «софтверного инженера», чем знание правильных названий синтаксических конструкций.
Языки программирования… довольно быстро можно выучить очередной язык программирования.
Имхо, только начинающие переоценивают знание языка программирования. Полагаю потому, что пока это наилучшее их достижение в ИТ, на которое потрачено много времени, отчего бы не похвастать знаниям.
Однако ничего такого волшебного в знании языка программирования нет. Ну примерно как слесарь тащился бы от того, что знает чем отличается рожковый ключ от накидного, а тот от головки.
То есть в кругу непрограммистов или студентов-айтишников ты может и полубог, раз хорошо знаешь язык программирования. Но по сравнению с другими твоими коллегами — знание языка программирования это ничего особенного. Ну такое же знание, как и знание чем отличается клик левой кнопкой мыши от клика правой кнопки мыши.
А вот то как человек понимает, к примеру, потенциальные узкие места в программе — что тормозит чаще всего именно ввод-вывод и т.п… — это реально полезные знания «софтверного инженера».
Тут недавно был перевод и у автора бомбило с убогости софта и окружающей действительности. Может все это от сениоров которые не знают virtual и отлично справляются с работой?
Это от требований бизнеса сделать все еще вчера и дешево, а требования бизнеса — от реалий в экономике и конкуренции.
Если тебе нужно срочно заткнуть дыру — то не до красивых абстракций.
Даже основывал 4 фирмы (2 с партнерами, 2 сам). Но когда доходит до того, что нужно менеджером быть, а не разработчиком — завязывал. Не нравится мне это — не писать код лично.
Вы намекаете на настоятельную необходимость выделенного архитектора в любом произвольном проекте?
Нет, это не так.
Выделенный архитектор нужен только в огромных проектах. Проектирование и создание кода одним человеком — вполне сочетается даже в группах программистов и в 50 человек (а это огромная сила, очень серьезные вещи куда как меньшим числом созданы).
Архитектор вовсе не продумывает все до последнего класса в системе. Свои куски разработчики вполне способны продумать сами.
У меня на придумки по архитектуре уходит процентов 10-40 рабочего времени в неделю.
Еще раз: «спец» не может вспомнить одну из основных синтаксических конструкций своего языка, название которой ему назвали
Назвали???
Начиная с определенного момента постоянной практики вырабатывается автоматизм использования понятия.
Это как в начале изучения иностранного языка вы все слова-предложения проговаривайте мысленно перед произнесением (иногда это заметно даже, губы шевелятся), а потом просто начинаете думать на иностранном языке. И, легко поняв суть на иностранном языке, при том вы можете столкнуться с проблемой подобрать подходящее слово для перевода на родной язык.
Да я свои пароли только тактильно помню — могу набрать их на клавиатуре вслепую, но не могу ни записать на бумаге ни произнести вслух.
P.S.:
джун, миддл, сеньор — это про уровень квалификации.
а системный архитектор — это про функционал, про должность.
данные понятия — вообще параллельны, они о разном. (кроме того факта, что архитектор как правило сеньор).
Пописывать статейки или преподавать — да. В реальной работе — нет.
Не представляю чтобы на meeting мы обсуждали проект на уровне — «тут нужно замыкание».
Повторю еще раз:
Только начинающие столь серьезно относятся к недавно зазубренным названиям. Полагаю потому, что им пока что больше нечего обсудить, нет опыта в более общих вещах.
Потому и тестирование описанное в статье под которой мы и беседуем — это тестирование для джуна/трейни. Оно даже миддла уже никак не характеризует.
А при чем тут он?
Вы что, сами не видите какого огромное количество сырых продуктов выпускают на рынок? Ко всем им лично он имеет отношение?
Если речь не идет о выпуске миллионными тиражами, когда перепрошить потом дорого…
Если речь не идет о крайне дорогом исходе при одной-единственной ошибке…
То да, как правило, да, программы содержат кучи ошибок.
Заказчику/работодателю важнее снижение дорогущей себестоимости разработки, даже если возрастает риск ошибки.
Нет цели — «сделать безошибочно любой ценой».
У ошибки есть цена, у разработки с дополнительным тщательным тестированием есть цена. Заказчик выбирает между ними.
Более того, даже не всегда в деньгах дело.
Чаще более важный фактор — время разработки.
Из моих знакомых те, кто работает по первой вышке — исключения.
Все больше вторая вышка стала призванием.
Или вообще вышка и профессия не связаны.
План запроса меняется автоматически в зависимости от статистики, то есть на разном объеме данных/разном содержимом может быть по разному.
Низкоуровневые знания, в которых не учтена статистика данных — тут слабый помощник. Ибо все ваши микрооптимизации могут быть в любой момент пересмотрены СУБД.
Гораздо полезнее предоставить СУБД правильные индексы — а дальше она сама разберется.
Ну а как влияют merge joins, nested loops — вы будете прекрасно понимать безо всяких o() на уровне интуиции уже после пары месяцев интенсивного написания/оптимизации запросов.
Примерно столько времени понадобилось одному из джунов (не самому таланливому в программировании), которого я натаскивал. Причем большую часть времени он сам учился. Я только советы общего характера давал типа «разбить запрос на отдельные части и посмотреть». После пары месяцев интенсива от такие стал оптимальные запросы писать — закачаешься.
Вспомните происхождение SQL — изначально он придуман вовсе не для программистов, а для менеджеров, чтобы сами себе отчеты строили, не отвлекая программистов.
Это показывает, что человек не преподаватель только и всего.
Скорее как раз, что терминология «от зубов отскакивает» и есть необходимое (не достаточное) условие хорошего чистого теоретика.
Архитекторы программных систем, не являющиеся программистами? Это фантастика. Такие вообще существуют? Сколько таких видели?
Не может.
Я выше расписал свою методу собеседования:
Беседа о реальных проектах. Какие там плюсы минусы в тех или иных решениях.
За первую минуту, человек без опыта сольется.
Более того, я наблюдал как собеседуют кандидатов менее опытные коллеги. Они действительно практикуют так как вы и описали — гоняют по тем вещам, что зубрили недавно в ВУЗе. Потому как это пока единственное, что они могут проверить у кандидатов.
Если мне зададут вопрос про что то типа полиморфизм — я просто попрошу (спокойным уверенным голосом, это важно), чтобы меня собеседовал старший разработчик. Всегда проканывало.
«Писать быстро без ошибок» — это утопия. Очень даже весомый кусок времени занимает не собственно написание, а отладка.
Индустрия не молода, так что статистики полным-полно.
Например:
coralogix.com/log-analytics-blog/this-is-what-your-developers-are-doing-75-of-the-time-and-this-is-the-cost-you-pay
А почему вы решили, что статистика иная?
Львиная доля программистов пишет вовсе не библиотеки сортировки.
Большинство пишет именно прикладные проекты, где нужен ввод-вывод (сеть, диски — где и находится основная часть тормозов). Даже, казалось бы, такие далекие от СУБД ребята как game developer, и те в подавляющем большинстве своем не пишут сами движков (где была бы полезна эта оптимизация «логарифм/квадратичный») и тормоза у них значительно зависят не столько от правильного цикла, сколько от грамотной работы с движком, что лежит за пределами их кода.
А что писали лично вы за последние 10 лет? Учебные/студенческие работы/курсовые/дипломные если не считать.
Простота языка программирования по сравнению с естественными языками позволяет автоматизму использования выработаться еще быстрее.
Зачем мне знать, что замыкание называется именно замыканием? Я его использовал еще за 20 лет до того, как узнал как оно называется.
В 99% случаев тормоза не имеют отношения к моей программе — в реальных проектах тормоза в СУБД, сети и пр. внешних факторах.
Просто «в вакууме» оптимизация алгоритма (логарифм/квадратичный и т.п.) сама по себе толку дает мало.
Оптимизировать нужно в связке в реальной среде. Куда больше реальной пользы приносит правильно написанный запрос к СУБД, чем правильно развернутый цикл.
Кое-кто 2 тысячи лет назад уже и учение свое создал, и проповедовал по всей стране, и раскрутился, так что власти испугались, и был казнен всего-то в 33 года.
И в те времена это не было особо удивительным (удивительным является только степень распространенности его учения и как оно прошло через тысячелетия). Мужчина тогда считался мужчиной в 15.
А современные люди — какое там учение, они, оказывается, после 30 дозревают еще (как вино, что ли)
P.S.:
А если серьезно — то да, современные люди более инфантильны (можно почитать про особенности поколения Y).
Но раз на раз не приходится. Всех грести под одну гребенку — некорректно.
У меня есть знакомые: одна уехала из родительского дома в 15 лет учиться и с тех пор живет самостоятельно, обеспечивает родителей; другая уехала в 18 и родители вообще не помогали и не помогают (у них конфликт), моталась по съемным квартирам, как-то зарабатывала сама; другая в 40 лет сидит на шее у родителей, не работала и не работает (здорова, с вышкой), полагаю, и не будет (родители не олигархи, обычные).
1) Уведомления отключаются на корню, если вам так надо.
2) В браузере есть все те же Adblock что и на десктопе.
Если у вас настолько древний JS, что не срабатывает реклама, то и сайты тоже коряво отрабатывают.
Это верно только с точки зрения индивидуума. Это не верно с точки зрения индустрии.
1) Чтобы думать о высоком нужны высокие доходы.
2) Если в индустрии высокие доходы туда ломится куча народа, которому нужны только деньги, а не высокое.
Программирую еще с прошлого века.
Смотрю все пишут про какие-то умные замыкания. Не знаю этого термина.
Думаю, ну наверное некая умная концепция, может, буду использовать, пригодится. Надо почитать что это.
Читаю.
Ага. Использую, не зная как оно называется, уже лет 20 или поболее даже, оказывается.
Почему? Нас учили разным математическим моделям, а вовсе не тому как что называется в синтаксисе языка.
Внимание, вопрос:
Являюсь ли я недостойным должности сеньора, если 10 последних лет как проектирую highload-решения, которые держат высокие нагрузки на смешном железе?
Полагаю все дело в этом:
Просто написано не на холодную голову.
Труда не составит, но незачем.
Я уже давно не смотрю на вирусы компьютеры знакомых только потому, что «тыж программист».
Серьезно, я даже джунов на собеседовании никогда не гонял на базовые знаний по virtual, static и singleton.
Мне всегда интересно узнать как человек оценивать с технической точки зрения выполненные им в других фирмах проекты (для студентов спрашиваю про курсовые/дипломные/пет-проекты).
Джунам давал задачу спроектировать в РСУБД модель.
Имхо это лучше характеризует «софтверного инженера», чем знание правильных названий синтаксических конструкций.
Языки программирования… довольно быстро можно выучить очередной язык программирования.
Имхо, только начинающие переоценивают знание языка программирования. Полагаю потому, что пока это наилучшее их достижение в ИТ, на которое потрачено много времени, отчего бы не похвастать знаниям.
Однако ничего такого волшебного в знании языка программирования нет. Ну примерно как слесарь тащился бы от того, что знает чем отличается рожковый ключ от накидного, а тот от головки.
То есть в кругу непрограммистов или студентов-айтишников ты может и полубог, раз хорошо знаешь язык программирования. Но по сравнению с другими твоими коллегами — знание языка программирования это ничего особенного. Ну такое же знание, как и знание чем отличается клик левой кнопкой мыши от клика правой кнопки мыши.
А вот то как человек понимает, к примеру, потенциальные узкие места в программе — что тормозит чаще всего именно ввод-вывод и т.п… — это реально полезные знания «софтверного инженера».
Это от требований бизнеса сделать все еще вчера и дешево, а требования бизнеса — от реалий в экономике и конкуренции.
Если тебе нужно срочно заткнуть дыру — то не до красивых абстракций.
Пишу. Мне это нравится.
Даже основывал 4 фирмы (2 с партнерами, 2 сам). Но когда доходит до того, что нужно менеджером быть, а не разработчиком — завязывал. Не нравится мне это — не писать код лично.
Вы намекаете на настоятельную необходимость выделенного архитектора в любом произвольном проекте?
Нет, это не так.
Выделенный архитектор нужен только в огромных проектах. Проектирование и создание кода одним человеком — вполне сочетается даже в группах программистов и в 50 человек (а это огромная сила, очень серьезные вещи куда как меньшим числом созданы).
Архитектор вовсе не продумывает все до последнего класса в системе. Свои куски разработчики вполне способны продумать сами.
У меня на придумки по архитектуре уходит процентов 10-40 рабочего времени в неделю.
Назвали???
Начиная с определенного момента постоянной практики вырабатывается автоматизм использования понятия.
Это как в начале изучения иностранного языка вы все слова-предложения проговаривайте мысленно перед произнесением (иногда это заметно даже, губы шевелятся), а потом просто начинаете думать на иностранном языке. И, легко поняв суть на иностранном языке, при том вы можете столкнуться с проблемой подобрать подходящее слово для перевода на родной язык.
Да я свои пароли только тактильно помню — могу набрать их на клавиатуре вслепую, но не могу ни записать на бумаге ни произнести вслух.
Я и есть.
P.S.:
джун, миддл, сеньор — это про уровень квалификации.
а системный архитектор — это про функционал, про должность.
данные понятия — вообще параллельны, они о разном. (кроме того факта, что архитектор как правило сеньор).