Простите, но программирование — это всегда чертовски сложно. Если вам удалось что-то легко написать, то только потому что вас обманула IDE.
А так, главное в программирование такое же как и везде — четкое видение результата. Если оно есть, то код пишется легко и свободно, если программирование идёт с трудом, то значит либо цель поставлена плохо, либо это не ваше.
Получается, если программирование "всегда чертовски сложно", то оно всегда «идёт с трудом» по определению, не зависимо от «видений»? )
Иногда сталкивался с ситуациями когда результат ясен, но достижение результата дается тяжело, хотя бы по причине необходимости освоить новую, не очень простую предметную область.
Тут нет противоречия, объясню иначе. Вот есть проблема, вам она кажется трудной, если не невозможной. Но вот если вас о решении попросит девушка, которая вам нравится, то задача вдруг становится вполне решаемой. Просто девушка придаёт вам сил. Даже если трудно.
Поэтому, если программирование при решении задачи придаёт вам сил, значит это ваше, если отнимает силы — значит не ваше.
P.S.
Девушка вымышленная и вы не позволяете ей собой манипулировать.
минус, пожалуй, за p.s.? А то, что вы описали — это мотивация…
Ну программирование не особо от других специализаций отличается. И доктор и программист и космонавт и биохимик — все люди. И к сожалению большинство даже самой интересной работы — рутина. Программирование давно ушло из разряда исследований в обычное ремесло. R&D проектами не многие занимаются. Так что программирование — это по большей части рутина.
Кодинг-вот может быть и рутина, да и то где этот процесс поставлен на конвейер. А так, если устали — смените направление. Если вы фронт, то попробуйте bigdata, и наоборот.
ну я же не говорил что рутина невыносима, я говорю что практически любая проф. деятельность — это рутина. А рутина не может быть сложной по определению, она монотонная и утомительная.

Рутиной было бы сферическое программирование в вакууме. Положение спасают программисты. Они привносят первозданный хвос в этот процесс, делая его нескучным вплоть до адреналиновой интоксикации.
А какой весёлый/нескучный/ужасный код они пишут! Особенно этот подлец, Я-вчерашний.

Я думаю, рутина не будет столь удручать, если ты занимаешься своим проектом и реализовываешь какие-либо свои цели.
Категорически не согласен.
Программирование не сложная вещь. Абсолютно!
Сложно на Марс полететь. 50% полетов неудачные.
Сложно от ВИЧ вылечится. Высокая смертность.
Сложно ребенка аутиста вырастить.
Программировать не сложно.
Хотя задачи сложные бывают. Но когда мы летим на Марс, сложность зависит от многих факторов, на которые мы не влияем и часто даже незнаем. В итоге получаем 50% крушений.
Вот это сложно.
А в программировании, сегодня сложная задача, завтра решается в 10 минут написание кода.
Это не сложность.
А в программировании, сегодня сложная задача, завтра решается в 10 минут написание кода

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

Мне кажется, Вы путаете сложность с опасностью.
Нет, я не путаю.
Опасность это вообще не из этой оперы)
Давайте я переформулирую Вас же:
Сложно не на Марс полететь, сложно сделать программно-аппаратный комплекс, обеспечивающий комфортный и безопасный полёт, повысить отказоустойчивость техники и сделать работу систем жизнеобеспечения умнее.

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

Сложно ребенка аутиста вырастить. Но ещё сложнее просчитать и предотвратить, причём гуманистическими методами, проявление таких генетических дефектов в популяции.
Не хотите погуглить, как ошибки в программах привели к убыткам на миллиарды и к человеческим жертвам?
Программы тоже бывают неудачными, пожалуй даже чаще чем 50%.
Сложно от ВИЧ вылечится. Высокая смертность.

То что сложно сегодня, завтра обыденность. Буквально недавно появились новые антиретровирусные препараты и вакцины которые повышают устойчивость к вирусу до 99%. (у Шимпанзе во всяком случае). Да и вот только недавно у исследователей инструменты нормальные появились. Уж не говоря о том что начало изучению ДНК не сильно то и много, а вот уже и CRISPR, и вот уже у первого человека "пофиксили" ген.


По факту "сложность" тут — этические ограничения и очень долгий цикл от возникновения до проверки идей.


Сложно на Марс полететь. 50% полетов неудачные.

Как будто бы программирование тут не причем.


код то да, не сложно писать, сложность во всех остальных аспектах работы программиста.

Программировать просто. Сложно научиться программировать просто.
Логика программирования заключается в том, чтобы разбить большую задачу на маленькие подзадачи и последовательно реализовать их, а потом связать воедино.
согласен на 100%. Этот подход стоит использовать и в управлении проектом (макро). Видел сам, как опытные программисты впадают в уныние, когда перед ними стоит плохо описанная, большая задача. Если ее не разбить на мелкие, легко выполнимые задачи, то можно засесть в таком «болоте» надолго. И тут нельзя не отметить (из чистого прагматизма), что agile, как методика, делает именно это.
я недавно другу показал одну задачку которую сделал, для поступления в «школу повышения квалификации» так скажем) он сказал что нормальная задача, я подумал сначала, что это сарказм, т.к. он обычно любит принижать мои дела) но оказалось — серьезно говорит. Я ему говорю — а ты знаешь, я его к удивлению как-то легко сделал в 2 присеста. В первый к каждому пункту написал функции и протестировал. А во второй — соединил их в одну программу.
Друг резюмировал, что это как раз потому так легко получилось, что задача была чётко расписана по пунктам. и советовал мне всегда так делать )
На моё удивление, первый раз об этом подходе я узнал из «Совершенного кода». Вроде ничего сложного, однако, в университете такого не давали.

А блок-схемы вы рисовали? В принципе, разрисовать алгоритм в виде блок-схемы высокого уровня (а-ля "по этому и этому вычислим вот это с помощью вот этого алгоритма") вполне себе является разбиением задачи на подпункты. Другое дело, что обычно блок-схемы дают только для нижнего уровня :(

Особой разницы не вижу. Единственное отличие для «верхнего» уровня — это то, что каждый блок состоит на самом деле из алгоритма «нижнего» уровня. Если я вас правильно понял

У меня всегда такая проблема. И в работе и в жизни и вообще(( даже не знаю что делать.

Иногда полезно вспоминать истоки, чтобы не потерять смысл развития. Пиши ещё!

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

Очень улыбнула картинка про яму страданий. Я наверное еще только-только из этой самой ямы начал выбираться.
а я в ней как раз, надеюсь скоро выбраться))
У меня почему-то не было ни ямы страданий, ни ощущение прекрасного. Работаю себе и работаю. В меру дурак, в меру умен. Всегда так было.
в положении равновесия ты значит)
почему-то так сложилось, что я могу продуктивно кодить только в подобии «биполярного расстройства», когда кидает из эйфории в депрессию и обратно.
А что именно в депрессию кидает? Вот меня, например, не столько неудачно решенная задача или вообще нерешенная, сколько отсутствие понимания и результата продвижения(карьерного горизонтального хотя бы). Я как бы фронтендер, был фулстэк, ну как фул — CMSы. Сейчас пытаюсь вкатиться хоть в что-то модное, реакты\вуе и тп. А главная проблема — раз, не успевают уроки за ростом и «развитием» фреймворка; два, вообще непонимание окружения, много серверной части или пограничной с ней. И вот это вот просто унижает, добивает меня. Руки опускаются когда я несколько часов трачу на то, чтоб обновить deprecated пакеты, заставить работать вебпак и т.д. и т.п. Точное следование самому подробному уроку не помогает. А когда добираешься до задачи понимаешь уже, что тут нужен какой-то бек, в котором нет желания разбираться, если ты пытаешься быть фронт.
в депрессию кидает неконтролируемая длительная работа в «эйфории». То что вы пишете, очень знакомо для меня тоже. Особенно потому, что у меня есть идеи, которые я не смог реализовать в CMS и поэтому полез в разные курсы, еще долго не мог определиться и всего понемногу изучил. В конце лета познакомился с фреймворком Meteor.js — это был большой сдвиг, когда я смог наконец сделать full-stack приложение )
Точное следование самому подробному уроку не помогает.

а с каких пор оно должно помогать? Это урок. Там обычно учат делать что-то одно и оно чаще не прибавляет понимание того как это работает. Читайте документацию, следите за изменениями фреймворка в ишус трекерах/пул реквестах (благо сейчас это просто), читайте исходники (если совсем круто хотите знать инструмент, чаще это не нужно).


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

Пишите бэк на nodejs, сейчас к тому же есть масса serverless решений.


Меня к примеру в уныние и тоску повергают люди которые хотят развиваться но ничего для этого не делают. И таких много. А еще — часто проблема не в том что "технологий много и быстро развиваются" а скорее в хайпе. Технологии достаточно медленно развиваются и концепции в целом имеют более цикличный характер. Сейчас модно то что было модным 10 лет назад просто в другом контексте.

Мне понравился посыл в статье «старайтесь понимать весь стек». Нет никакого рокет сайнса в том, чтобы фронтендеру писать / понимать ещё и бекенд на nodejs. Язык там один и тот же, немного разное окружение.
Возможно вы ещё находитесь в точке отсчёта. Я вот уже лет 15 погружаюсь в эту «яму» :-)
Я как десять лет занимаюсь программированием и особой разницы в восприятии себя в профессиональном плане не замечаю.

Просто прекрасно понимаю, что при должном упорстве моем и планировании почти любая задача посильна. Всегда только встает вопрос, а сколько времени это займет: неделя, месяц или вовсе полгода?

Могу конечно лениться как последний разгильдяй, находиться в прокрастинации перед новой для меня сложной задачей, но при этом не считаю себя ничтожеством или еще кем-то нехорошим =)

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

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

Какая яма? Зачем? Почему?
То что я чего-то не знаю не повод себя угнетать и никогда им не станет.
Никогда не боялся показать себя дураком. Спокойно задаю глупые вопросы, дабы потом поумнеть.
Ну вот я например любительски занимаюсь программированием. Когда попытался устроиться — не взяли. Стал наверстывать, наверстывать (читать книги, проходить курсы), — всё равно не взяли. И вот тут то и понимаешь, что в яме. Все потраченные усилия как будто были зря (из той точки отсчёта).
Так может дело не в вас? Мне сложно судить, ибо мне сказочна повезло и первая работа нашла меня сама. Я даже не ожидал на тот момент, что буду работать, ибо учился в универе.

Но бывают такие регионы, где очень трудно найти постоянную стабильную работу IT-шнику. Где недостаток рабочих мест. Тут только по фриланс подаваться или любую работу брать, лишь бы выжить.
Согласен, это может очень угнеть, но веру в себя терять не стоит =)
я в Москве пытался. Как я понял, там требования высокие, на некоммерческие проекты не смотрят даже, и я не смог сориентироваться, как там начать карьеру. Вот, сейчас в Питере…
А за вас рад конечно, что у вас нет болезненных эмоций при работе :)
Ну честно говоря есть, порой очень матерюсь, когда пишут говнокод и ты наследуешь его, вынужден его дорабатывать.
Особенно матерюсь, когда мой код начинают дорабатывать люди, которые не особо разбираясь впихнут кусок говнокода. Приходится потом рефакторить в рамках смежных задач.
Порой случается ошибка в ТЗ и приходится переделывать много, иногда играем с тестировщиками в пинг-понг с целью: кто прав, кто виноват.
Стресса хватает, но это даже весело. Особенно когда что-то на проде ломается и надо шустро починить, быстрая доза эйфории =)
По моему опыту, картинка циклическая. Как только столкнетесь с изучением новой технологии, все повторится.
Вот только она периодическая до бесконечности. Я когда берусь за новую технологию всегда себя так ощущаю)
Есть только две трудные задачи в области информатики: инвалидация кеша и придумывание названий
Простите, может я не в теме. А что сложного в инвалидации кэша?
Ето одна из многих известных цитат про програмирование. Кажеться сказал Фил Карлтон. Вот есть подборка:
habrahabr.ru/post/275841
А к теме что сложного, вот неплохие статьи:
habrahabr.ru/post/120471
eax.me/caching-is-hard
Про цитату не знал. А касательно инвалидации, в силу специфики проектов, над которыми работаю, первая ассоциация — инвалидации процессорного кэша (ну, того, который L1, L2 etc). А в ней ничего сложного обычно нет. В любом случае, спасибо за разъяснение (-:
А в ней ничего сложного обычно нет

ну как сказать, конкретно в этом случае сложность в том как уменьшить количество кэш мисов.

Ну, как сказать, всё-таки это проблема разработчиков железа, программист на неё не влияет. Да и на некоторых задачах вытеснение случайной строки кэша бывает лучше для производительности чем всякие хитроумные алгоритмы.
Даже программистам на java, которых от железа отгораживает виртуальная машина, чтобы писать действительно производительные программы, полезно знать о протоколах когерентности кэша и писать код так, чтобы избегать cpu contention. Для системных же программистов это знать и применять обязательно.
Прикладным программистам надо знать размер кэшлайна, чтобы не допускать false sharing без необходимости. Системному программисту необходимо кроме того знать, в каких случаях железо не обеспечивает когерентность, чтобы при необходимости обеспечить её программно. Как поможет знание алгоритмов вытеснения и протоколов когерентности, реализованных в конкретном CPU, мне, честно говоря, непонятно.
Могу предоставить только один случай, когда знание алгоритма вытеснения и протокола когерентности, реализованных в конкретном CPU, может помочь — если вы ищете баги в реализации контроллера кэша.
Вы меня извините, конечно, но я считаю что эту фразу обязательно должен знать любой, кто занимается нашим ремеслом Программиста/ИнженераПО :)
Очевидно, что для этого придётся видеть будущее. Но на самом деле, статистика и некоторая эвристика даёт весьма не плохой результат. У нас на курсе декан говорил «Есть задачи простые, тривиальные и ещё не решённые». И в общем-то так и есть. И щепотка мерзости перфекционистам: теоретические пределы нигде ещё не достигнуты. Ни энтропийное кодирование, ни помехоустойчивое, ни криптография — пределы где-то там вроде есть, даже вроде есть рецепт, но как-то до него не добраться. Вот не получается.
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery
Есть только две трудные задачи в области информатики: инвалидация кеша и придумывание названий

Мне больше по душе другая версия этого изречения (:
Есть только две трудности в программировании: инвалидация кеша, придумывание названий и ошибки на единицу

Пункт 2 рано или поздно каждый ощутит на себе.
Мне второй пункт напомнил Теда Нельсона:
«Хорошая новость про компьютеры: они всегда делают то, о чем вы их просите. Но есть и плохая: они всегда делают то, о чем вы их просите.»
Программа делает то, что написал программист, а не то что хотел написать © (Не_помню_кто)

Жаль, но в современном мире компьютеры делают не только то, о чем их просите вы, а ещё прорву разных дел, о которых его просили разработчики ОС и ПО, которое на ней установлено. И из-за этого бывает так, что криво написанное ПО "Х" ломает твою хорошую программу "У". Про IME и ему подобные просто молчу. Для простых программ, к счастью, такие проблемы обычно не актуальны, но бывает и иначе...

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

Пункт 2 привёл меня в программирование. Когда я понял, что все только в моих руках, что между идеей и реализацией стоит только моё незнание я начал постоянный ликбез, короче, очень увлекательно и некого винить.

очень позитивное толкование пункта 2) вроде там наоборот написано, что всё в руках компьютера))
шучу
И еще:

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery
не отвлекаясь от темы, считаю самым сложным (обобщая ессно) — знание предметной области.
Хотя описанные в статье вещи действительно не так очевидны и просты как кажутся.
забыл сказать — продолжайте! 8)
предметной области чего? сферы для которой софт пишешь?
Именно. Большая часть проблем от незнания контекста/предметной области. Ещё хуже, если человек не понимает чего-то, но при этом ни у кого не спрашивает/не уточняет неясные моменты. Как следствие, приходится переделывать по нескольку раз одно и то же.

Для этого существуют бизнес-аналитики. Хотя в общем знать область деятельности очень желательно, но не жизненно необходимо.

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

Не соглашусь, всё-таки всегда как раз гордился тем, что при должном желании, хороший Программист/Разработчик в принципе неплохо въезжает в любую Предметную Область.
Проекты бывают разные и каждый требует особых знаний, так что это скорее естественное умение в нашем ремесле — уметь понимать любую Предметную Область.
Программирование оторванное от мира не несет смысла.

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


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

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

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

Я в веб-разработке пытаюсь что-то делать. И там реально часто меняется. Вот вроде как с Express познакомился, а уже Koa актуальнее стала. Вроде недавно ангуляр2 вышел, а уже и 4й вышел… и т.д.

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


Например, берем Node, видим что она работает в одном потоке, код выполняется асинхронно, а связывающим звеном является event-loop. Это уже дает представление, о том как различные части программы могут взаимодействовать между собой, какие плюсы и минусы из этого можно получить. Берем экспресс, видим что API позволяет нам обрабатывать данные по средствам обратных вызовов, а часть типовой логики предлагается вынести в промежуточные обработчики запросов (middleware), и понимаем, что с чем и как должно работать тут, какие задачи могли возникнуть не только у вас (авторизация, рендер шаблонов и все такое), а следовательно для чего могут быть уже готовые решения на базе этого Express. Берем Koa, видим корутины и опять же делаем выводы о концепции библиотеки и с какой стороны лучше подходить к ее использованию, а дальше дело лишь за изучение API. И так далее, от общего к частному.

вот мне почему-то всегда трудно давалось осознание таких вещей, типа event-loop, хочется просто брать что-то и применять, не копаясь глубоко (
хотя умом понимаю, что много теряю от такого подхода
Мне наоборот кажется, что умение пользоваться тем же ангуляром без глубокого копания в шизофрении тех, кто его породил и прочих заумных вещах, не решающих напрямую проблемы бизнеса — это на порядок эффективнее с точки зрения затрат времени, чем когда ты вынужден прежде понять как очередное поделие устроено, что от него ожидать, а только потом его использовать. Это как с вождением машины — если нужнор просто перевозить груз или пассажиров по маршруту в рамках ПДД, то нафиг узнавать как там что под капотом устроено. В конце концов, я не автомеханик, а водитель.

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


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


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

Самое сложное в программировании — продвинуть в жизнь какую-то идею, отличную от «общепринятого мнения» и от «привычного порядка вещей». Даже если уже в прошлом такое успешно делал сто раз, всё равно и в 101-ый раз всё по новой.

Сам кодинг, технические сложности, дедлайны, недостаток знаний и опыта — это всё решаемо. Всегда можно сесть и ещё подумать, ещё получше разобраться. Но потом сдвинуть всю махину в правильную сторону — big deal.
продвинуть в жизнь какую-то идею, отличную от «общепринятого мнения» и от «привычного порядка вещей»

— создать успешный стартап? чтобы твои инновации получили признание?
сдвинуть всю махину в правильную сторону

— грамотный маркетинг имеешь ввиду?

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

По моему мнению самое сложное в медицине это не прекращать учиться и иметь стремление познавать новое и конечно труд и еще раз труд.


ну или так


По моему мнению самое сложное в индустриальном дизайне это не прекращать учиться и иметь стремление познавать новое и конечно труд и еще раз труд.


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

Самое сложное лично для меня это:
писать письма;
выяснять почему опять свалился девелоперский энв;
разбираться руководствуясь каким пунктом в спецификации тестировщик завёл тот или иной баг;
мягко объяснять бизнес-аналитику, что эта фича у нас исторически так работает и новую подобную фичу лучше реализовать в том же духе;
заводить дурацкие годовые цели и потом рассказывать менеджеру как я мощно их достиг;
И всё прочее в этом роде.


То есть, деятельность с программированием связанная весьма опосредованно.
А когда есть чё задевелопить, и задача понятна — это просто праздник какой-то. Отдых, можно сказать.

У меня 10 утра. Это относительно рано. Просто я рано лёг. Мне надо вставать и работать. Компьютерное кресло придвинуто к дивану. Самое сложное в программировании — вставать по утрам.

Программирование — фигня, поддержка — вот где весь гемор. Когда у каких-то уродов на противоположной стороне земного шара раз в неделю/месяц где-то что-то кривеет, и ты подозреваешь порчу памяти, и они уже истошно орут «FIX THIS ASAP!!!», а ты не можешь у себя это повторить, хоть убейся, то вот тут реально опускаются руки, и хочется послать всё это подальше, уволиться нахрен, и пусть кто угодно это чинит.
Много раз пытался научиться самостоятельно и постоянно видел, что чего-то не хватает. Сначала широты взгляда (было очень мало информации). Затем не было системы, не знал, как и в каком порядке работать с информацией. Постоянно возникали пробелы то тут, то там, забывал, где закрыл пробелы, а где нет, забывал решения, не вёл учёт.
Даже поступил в универ, думал, там дадут понимание, как учиться.
Выучить синтаксис какого-то языка и уметь пользоваться гуглом — ещё не всё, как и какие-то знания об алгоритмах и математике, статистике.
Самого главного, как проектировать приложение, как систематизировать его части, какие части вообще должны быть и как их связать между собой, вообще почти нигде не говорится.
Интуитивно понятно, что писать всё в одном файле, классе, нельзя. Но книги обычно начинают и заканчивают одной простынёй кода, где в начале идёт одно, потом другое, потом главная функция, которая порождает классы, описанные выше, какой-то цикл обработки событий или класс, в котором куча отдельных обработчиков у отдельных объектов, и в каком проценте файла что находится, начинаешь быстро теряться.
Когда проект начинает разрастаться до миллиона строк и сотни файлов, один человек уже с трудом справляется, где что лежит и как за что отвечает.
Я начинал с процедурного кода, в котором всё шло линейно, оказалось, так писать очень сложно. Потом стал фанатом функций, всё оборачивал в функции. После понял, что нужно писать классы и методы. Но сложность возросла многократно. А без понимания, как нужно проектировать, программисту сложно реализоваться.
Возможно, зря я отчислился с третьего курса, но когда преподаватель даёт задание спроектировать какую-то систему под определённый функционал, я ожидаю, что нам хотя бы дадут минимальную теорию. Для этого я в универ и шёл.
А вообще речь о программировании или обучении программированию?
речь вообще о программировании, но она ориентирована на тех, кто его изучает) я так понимаю
Другими словами: Поговорим о чистке зубов, а именно правильном пережевывании пищи, -так?
типа я не в тот хаб добавил статью? или теги не правильно написал? суть вопросов не до конца улавливаю
Минусы пытаюсь заработать.
Большое спасибо за статью. Для меня это сейчас очень актуально…
Что касается необычайных преимуществ программирования, то вот они:

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

если у вас было все идеально на учебе — то это было просиживание штанов а не учеба.
полусамостоятельное освоение предмета во время учебы не сильно отличается от полусамостоятельного освоения нового языка программирования на работе.
если инженер сделал макет и по нему что-то построили, а потом пришлось перестроить, это может оказаться очень даже затратно.
Программирование, в первую очередь, — интересно. Как можно так относиться к интересному занятию? «Ой, да оно сложное, ой, я не знаю, за что взяться, ой, меня не похвалили»
Делай, что интересно.
Потом подтяни скиллы, нужные для командной работы, — и вперед, можно зарабатывать деньги, делая то, что нравится.
«Проблемы в коде в корне отличаются от проблем в физическом мире. Починить неисправный код можно одной лишь силой ума, в отличии от, например, сломанной машины, которая требует покупки дорогих запчастей. „

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

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

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

Статья неплохая, но много сравнений идет в духе “простые проблемы в коде» и «сложные проблемы в реальном мире».
Речь идёт, вероятно, не о сложности исправления проблем, а о характере деятельности. Какая бы по сложности ошибка в коде не встретилась, решить её можно будет только интеллектуально.
Но ведь это не так?
У меня множество примеров, когда проблема интеллектуально легко решается, но требует множества денег на новое оборудование, на новые лицензии, на то, что нужно реорганизовать внутреннюю службу безопасности, то есть упирается в тоже, что и реальная жизнь — деньги и бюрократия.
Мы же обсуждаем не манкикодинг а полный цикл разработки?
но здесь эта метафора скорее приводится для новичков, которые только начинают изучать… хотя не знаю, посмотрите в оригинале, это самый первый ответ, может я неправильно перевел, или может у автора более точно описано
Имхо самое сложное это скачкообразное моральное подкрепление. Это значит что в любой деятельности есть что то типа прогресс бара, где сделал чуть чуть и видишь что 1% сделан и тебе приятно от этого и ты продолжаешь. В программировании при нахождении верного решения или места ошибки сразу же 100%, а до этого все твои миллион проб и неудач не принесли и 1%.
Эта причина почему область считается сложной чтобы пройти в ИТ нужно быть очень терпеливым, большинство просто не могут даже начать.
Так, у меня без получаса полночь — время вампиров и программистов. Можно более объективно посмотреть на статью. Итак:

Примите факт, что компьютер всегда прав, а вы — нет

Ой, не факт! Десять минут назад MS Edge отказался выходить в интернет. Единственный браузер, который не смог. Он прав? Нет! А что насчёт third-party решений? Например, поповеры в четвёртом бутсрапе, которые отказываются работать, если им в заголовок передать int, даже если оно преобразовано в строку? Компьютер не всегда прав. Поэтому, мы можем делать форки недоработанных пакетов, либо присоединяться к их разработке и скидывать патчи.

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

Контроль за эмоциями

Да, пусть ваш мат в четыре утра слышат соседи! Потому что потом они услышат вашу новую аудиосистему, купленную с очередного транша!

Самостоятельность

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

Невозможно всё знать

И не надо: в голове надо держать только то, что нужно для решения текущих задач. Об этом ещё Конан Дойл писал. Но вот если у вас заказ на допилку JS интерфейса, а вы решили подучить трюки на Nginx'е, то у вас проблемы! Бросайте эту затею и возвращайтесь к JS. И лучше-всего — к поставленной задаче. Аналогично, если вам нужно повесить событие на кнопку, и в своих поисках вы дошли до принципа заполнения памяти JS кодом, вы пошли явно не туда. Если задача не решается простыми средствами, нужно её разбить на подзадачи, либо изменить формулировку.

В реальной жизни не всё так идеально, как на учёбе

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

Балансирование между теорией и практикой

Во-первых, надо начать. А именно, найти самые простые материалы для начала работы. Простейшую статью по тому же WordPress. Сразу поставить LAMPP, сделать Hello World, задуматься над тем, как сохранить это приветствие в базе, перелопатить сотню сайтов, обнаружить, что монга и PostgreSQL не совсем подходят для решения поставленной задачи, вернуться к первому варианту, реализовать на третий день задумку и т.д.

Проблема программирования в том, что здесь нельзя сначала изучать, а потом внезапно сделать. Нужно начать делать, и когда не получится, начать изучать. Теория в начале не даёт понимания этого неповторимого чувства — извлечения кролика из шляпы. Т.е. ощущения создания чего-то из ничего. Сперва нужно осознать ту пустоту, с которой работаешь. Новичок будет думать, что для программирования уже есть своя инфраструктура: достаточно сказать пару слов, и процессор преобразует их в чудесный алгоритм. Либо, достаточно подвигать мышкой, и компьютер научится понимать этот жест и создаст логику. Это не так. Мы работаем всегда с чистым листом. Даже если это — чистый лист внутри фреймворка.
Компьютер не всегда прав.

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


Для этого есть тестировщики.

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


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


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

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


берите коммерческий проект в разработку.

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


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

Я не говорил, что не нужно доверять машине. В контексте статьи указаны «компьютер или программа». Вот программе не всегда нужно доверять. Но для тех, кто начинает, разумеется, нужно переломить себя. Многие ошибки, действительно, возникают по вине того, кто грешит на систему. Но это в начале пути — не тогда, когда человек покрывает тестами код, рефакторит без напоминания или дебажит несколько раз прежде, чем объявить о системной ошибке. В любом случае, нужно понимать грань между срывом на систему и бездумным доверием к окружению и железу. И, разумеется, разработчик должен учиться доверять себе. Истории о программерах, которые удивляются коду, заработавшему с первого раза — всего-лишь истории.

Что касается тестировщиков, то никогда ни один программист не сможет своим замыленным глазом предусмотреть все варианты использования конечным потребителем. Если только он не работает с одной кнопкой «ОК», и то не факт, что пользователь воспользуется ей правильно. Но, согласитесь, что разработчик не будет сидеть и писать обработчик множественных нажатий на эту кнопку. В большинстве случаев, он не сделает даже disabled статуса на кнопке после первого нажатия. По одной простой причине: сперва надо повешать на неё события, а потом уже применить все знакомые ему методы защиты. Но, опять же, если он будет ещё неделю перехватывать все кейпрессы и нажатие на кнопку из консоли, то он дурак. Сперва делается функционал, потом реализуются стандартные паттерны защиты. Если нужно что-то ещё, пусть заказчик ищет тестировщика или доплачивает разработчику за пользовательское тестирование. Что значит «перекладывать ответственность»? Тестирование интерфейса — это такая же оплачиваемая работа. И, кстати, в ней тоже есть свои методики и средства автоматизации. Если программист с ними не знаком, он не обязан проводить эти действия. Только хуже сделает.

Со стимулированием лени почти согласен. Почти — потому что я указал, что нужно не просто искать готовое решение, но и требовать объяснить принцип его работы. В любом случае, человек без наставлений и без поиска готовых решений повышать уровень не сможет. Я знаю много молодых людей, которые стесняются требовать от наставников информацию. Знаю людей, которым это не интересно. При этом, они прекрасно пользуются гуглом и годами сидят в маркетинговых фирмах. Сайт-визитка за 8 000, магазин — за 20 000, первая цифра — их белая зарплата, вторая — то, что они сверху получают в конверте. Скрипты они писать могут. Не программы.

Стажировка в коммерческих проектах приносит человеку больше пользы, чем разработка собственных CMS и ORM. Почти каждый с этого начинает. Но именно работа над коммерческим проектом, хотя бы стажёром, даёт опыт получения прибыли и развития нужных навыков. Никто не говорит о том, что новичок должен лезть в крутые проекты. Достаточно сделать за пару тысяч знакомой фирме сайт-визитку или прибиться стажёром в какую-нибудь команду.
не сможет своим замыленным глазом предусмотреть все варианты использования конечным потребителем.

Потому есть сказ о "трех амиго", dev + qa + product owner. Из того как вы это подаете создается ощущение что качество это целиком и полностью обязанность QA и разработчику об этом думать не стоит. Вопрос же в командной работе, когда разработчик смотрит с технической стороны вопроса, а QA с позиции пользователя. Да, без QA никуда, но хороший разработчик обязан уметь придумывать тест кейсы. Что до замыленнсти — если генерить тест кейсы на чужую часть работы — то выходит лучше. Что до автоматизации, то тут еще больше стирается грань между чисто dev и чисто qa.


Ну и еще ремарка про пограничные/негативные кейсы. Не стоит еще забывать про приоритизацию багов. На многие баги можно просто закрыть глаза в силу того, какой эффект они вызывают. Фиксить все не эффективно с экономической точки зрения.


чем разработка собственных CMS и ORM

я где-то что-то говорил про свои CMS/ORM?


Но именно работа над коммерческим проектом, хотя бы стажёром

тогда уточняйте что речь идет о работе в команде.

Я вам никак не подаю. Подавать — обязанность официанта. Я вам говорю, что разработчик применяет знакомые ему паттерны защиты, либо добавляет защиту после пользовательского тестирования, либо по факту обнаружения проблемы. Или вы будете спорить с тем, что программист, который отрабатывает юзкейсы вместо реализации функционала — хреновый специалист?
По работе в команде я и уточнил. При этом, правда, человек может иметь свой коммерческий проект. Он может быть поделкой на коленке, но приносить доход. Это тоже плюс.

В области автоматизации пользовательского тестирования, действительно, QA выходит на уровень скриптов. Но разработчик — хороший разработчик — никогда даже додуматься не сможет о некоторых вариантах использования. А вообще, нужно чётко разделять разработку на готовых шаблонах и командную разработку. Допустим, мы говорим о Web. Есть CMS, которые уже имеют в реализации часть защиты, как и расширения для них. Этого достаточно для того, чтобы один специалист смог написать и продать проект на этой CMS. Он не будет заморачиваться дополнительной защитой до момента возникновения бага. Есть разработка в команде, когда наличие пользовательского тестирования — обязательно. Это не означает, что в команде есть QA, но тестирование может проводить менеджер. Это обязательное условие, поскольку программист почти никогда не производит таких тестов. Как-правило, в командах без QA есть список известных багов, которые проверяются вручную перед релизом.

А теперь, внимание, всё выше изложенное — о коммерческой разработке. Отсюда следует простой вывод, что новичок не получит этого опыта вне коммерческой разработки. И отсюда же следует вывод, что он не обязан работать в команде. Он может делать проекты на CMS. Но, допустим, человек не делает ничего на CMS. Он пишет свои велосипеды. И смысла проверять качество этих велосипедов у него нет. Они не поедут, и денег за них он не получит. Одно вытекает из другого: нужно изучать готовые паттерны защиты от непредсказуемых действий. Не обязательно знать как поведёт себя пользователь. Достаточно знать, что надо вот тут сделать кнопку disabled после первого нажатия, а там применить ORM с экранированием спецсимволов, вместо прямого обращения к базе. Либо работать в команде, но там точно так же наставник скажет: «после нажатия замьють кнопку» или «нафиг ты делаешь коннект к мускулу? Мы используем эту ORM. Зачем? Чтобы не писать лишний код и не заботиться об эскейпе символов при защите от инъекций».
Опять же, я знаю молодых людей, которые сразу после стажировки в небольших студиях начинали писать свои проекты. И сейчас проекты приносят доход. Хотя бы небольшой, но они полностью соответствуют коммерческому уровню: они имеют перспективы для получения грантов, привлечения инвесторов, либо подходят под стандартные схемы монетизации.

И я же видел молодых людей, которые приходили стажироваться и всё время кидали понты в духе: «да я написал плеер на дельфях». Или «У меня свой сайт — крутой». В итоге, когда они косячат, проверяются предметы их гордости, и оказывается, что плеер не работает, а сайт сделан на юкозе без изменения в коде и шаблонах — слишком сложно было залезть в код. А особый смак — когда оказывается, что поделка была курсовой работой, и человек за нерабочий продукт получил отличную оценку.

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


Некоммерммерческий проект, в первую очередь — это отсутствие лица, заинтересованного в результате. Т.е. это возможность девелоперу с заумным видом ковырять в носу и пытаться разродиться никому на. не нужными фантазиями и идеями в стиле «что бы такое еще залепить чтобы круто было». Вы действительно считаете, что такая графомания может дать что-то более позитивное к продаваемому опыту чем умение выполнять в срок реальные поставленные задачи?
Fesor я прочитал первый комментwerevolff через призму юмора) особенно про капчу с прыщавой жопой)) зачем ты так серьезно отнесся?
это всё можно воспринимать и так и этак, если чуть угол зрения поменять. (всё то, о чём вы спорите)
А я вообще не понял, что за претензии у Fesor. Как бы не секрет, что в IT оплачиваемая стажировка может начинаться с абитуры.

Про юмор могу сказать, что в каждой шутке есть доля правды. Автор статьи оассматривал программирование с точки зрения идеализма: искать наставника (куратора), самостоятельно искать ответы на вопросы, и т.д. ерунда это всё! Если поиск ответа в гугле занимает сутки, а профи знает решение, которое реплизуется за час, почему бы не подаставать профи с час, чтобы он всё рассказал? Кураторов у новичков нет. Иметь куратора — вредно. Нужно, чтобы код читало несколько разных человек. Если ни один из них не плюётся, код может быть неплохим. Ну и, разумеется, без реальной разработки программист учится не тому. Он может работать в каком угодно коллективе, изучать любые методологии. Пол дня заигрывать с девчонками-менеджерами, жрать шоколодки и пить чай, потом писать несколько строчек на HTML и идти домой. Или может изучать теории разработки, непрерывные и водопадные схемы интеграции. Может постоянно разбивать задачи на подзадачи и обнаружить в итоге целую гору незакрытых вопросов. Может, пока не перестанет заниматься ерундой и не пойдёт в крупный проект. Там его научат, что тестировать продукт он не может (поскольку не умеет и находится внутри процесса разработки, а QA — снаружи), задачи будет ставить менеджер, а по вопросам можно дёргать основного инженера.
после «Атлант расправил плечи» я стал более критично относиться к «волонтерству», зачастую это и правда безответственность и ковыряние в носу. Быть оплачиваемым профи круче, и они же кстати если и делают что-то на общественных началах — это бывает хитом.

Самое сложное в программировании это… программирование

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

Едва ли это применимо к крупным проектам, где ошибка может потребовать оплаты дорогих человеко-часов
Да. Изначально статья была в разделе «обучение IT», она скорее на новичков рассчитана, и в их случае имеется ввиду наверное обучающие задачи… хотя хз) но звучит почти складно)
Ребята, программисты, кто бы мог помочь с написанием интернет-магазина для сайта люстр, а то у нас только корпоративный/официальный сайт фирмы: www.lustry-gus.ru или подсказал бы как прикрутить карточки товаров, используем html, сайт писался в блокноте криворуким программистом, который так и не довел работу до конца.
Да уж… Тут любое решение будет лучше — даже Вордпресс с Вукоммерсом.
Ну т.е. имеет смысл сразу переделывать целиком? без каких либо доработок?
Как это ни смешно, но в данном случае будет проще переделать целиком.
У вас же там только набор картинок с названиями и контактные данные. Даже лайтбокса для картинок нет.
Эффект Даннинга-Крюгера сопровождает меня всю жизнь. И я очень злюсь, когда встречаю людей на первой стадии, т.е. слишком самоуверенных. Сейчас это всякие «сеньйоры» и «тимлиды», которые после пару лет входа в IT уже считают себя чуть ли не элитой разработки.

Самое сложное в программировании — нейминг

Самое сложное в программировании это…

придумывать имена переменных же

Самое сложное в программировании — это


  1. надо думать. много. не все это любят.
  2. надо иметь развитое абстрактное мышление. чтобы мыслить на уровне модулей и потоков данных. не всем это дано.
  3. надо учиться. всю жизнь, 5 лет в IT — это вечность. зачем, если вокруг столько куда менее напряжных профессий?
Какие ненапряжные профессии, смежные с программированием можете назвать?
Программирование, но не на дядю. Это идеальный, но практически недоступный для 99% разработчиков вариант. Это когда у тебя есть свой проект, свой код и ты получаешь за развитие проекта деньги.

Это типа менее "напряжная" профессия?

Учится, учиться и учиться! :)
Хорошая статья!
про «8. Невозможно всё знать»
У меня на собеседовании по java как то спросили теорему Чёрча-Росса в трех видах.
До сих пор чешу репу, — действительно ли я чего-то не знаю? :)
Невозможно все знать!
И возникает парадокс Сократа: “я знаю, что ничего не знаю”.

Но я же знаю, как говорил Сократ. А раз знаю что надо знать, значит буду знать!!

Меня всегда так перло с компьютеров и программирования, что даже неудачи меня мало смущали. Скорее проблемы в смежных областях напрягали, где не только программирование, но и «жизнь».
По-поводу того, что «компьютер всегда прав, а вы — нет» — вот прям сильно соглашусь.
Был на втором курсе предмет по основам программирования на Delphi, а я уже заблаговременно имел за спиной большой опыт в программировании. Так вот, одногруппники все время ныли «Почему он не запускается от того я не поставил один раз точку с запятой?», ну а я вот фразу нужную подобрать не мог:)
Подозревал, что комментов будет over 100500, но тема до сих пор не раскрыта!
для хабра же не много чуть больше 100 комментов
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.