Что самое сложное в программировании

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

Мне очень понравилась ветка обсуждений на Quora.com: What is the hardest part about learning to program? Все 87 ответов я так и не прочитал, но понравившиеся, выделил в отдельную статью из 10 пунктов. Это вольный пересказ мнений многих разных людей. Если читателям будет интересно, я продолжу.

1. Разница между высокими стандартами и своими низкими умениями

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

Что касается необычайных преимуществ программирования, то вот они:

1. Проблемы в коде в корне отличаются от проблем в физическом мире. Починить неисправный код можно одной лишь силой ума, в отличии от, например, сломанной машины, которая требует покупки дорогих запчастей.
2. Профессионально расти можно только на границе зоны комфорта. Занимаясь незнакомыми вещами вы сделаете кучу ошибок, но зато и получите настоящие знания.
3. Ошибки в программировании — это не закрывающиеся двери перед вами, а ключи к обучению.

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

Если что-то пошло не так, не надо винить компьютер или программу. Не выясняйте с ними отношения. Просто задайтесь целью: “как это исправить”. Если вы хотите выяснять отношения с языками программирования, почему они такие глючные и ваша программа дает сбой — то вы выбрали не ту специальность.

3. Готовьтесь к худшим сценариям

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

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

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

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

Многие новички легко проходят разные курсы по программированию, но стоит им взяться за самостоятельную задачу, они впадают в транс. Или нет идей для написания, или есть идеи, но нет понимания как их реализовывать, с чего начать. Всё дело в том, что курсы дают вам синтаксическую грамотность, вы вроде бы помните разные команды типа len(), но не можете написать свою программу. И вам начинает казаться, что учебный курс был разводкой для лохов, где вас научили поверхностной ерунде, а саму суть оставили в секрете. И эта суть — это навык программно мыслить.

Логика программирования заключается в том, чтобы разбить большую задачу на маленькие подзадачи и последовательно реализовать их, а потом связать воедино. Программист — не тот кто на перегонки печатает текст кода со знанием всех команд, а тот, кто мыслит в логике программы. И когда у вас наконец получается сделать что-то самому, самостоятельно, этот момент невероятно вдохновляет и вы вспоминаете свою грандиозную идею, которая недавно казалась невыполнимой и думаете: “О-хо, теперь я смогу реализовать её!” Хотя, конечно, вам еще расти и расти до её реализации, но момент всё равно приятный.

6. Незнание, с чего начать

• Вы не знаете, какой язык начать изучать: C, Python, Java, PHP, C++, Ruby и еще миллион других языков.
• Вы не знаете, где изучать: по книге, онлайн материалам, или записаться на курсы.
• Вы не знаете, что изучать: мобильные приложения, Android, iOS, веб, фронтенд, бекенд, операционные системы, искусственный интеллект, машинное обучение, DevOps?
• Вы не знаете как учиться: читать книги, чужой код, взять кого-нибудь для совместного обучения, программировать соревновательно, напару, устроиться стажером?

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

Чтобы справиться с этим, следуйте этим советам:

• Найдите ментора (наставника), опытного и владеющего современными технологиями программиста, который поможет вам составить план обучения.
• Получайте отзывы на ваш код. Есть много путей как сделать что-то, и ещё больше путей, как сделать это неправильно. Хотя в интернете много замечательных ресурсов, всё же он не идеален. Поэтому, время от времени, показывайте свой код ментору, чтобы он подтвердил, что вы идёте по верному пути.
• Практикуйтесь, реализуя свои идеи. Следование обучающим руководствам быстро надоедает, поэтому, как только почувствуете, что достаточно познакомились с технологией, начинайте вместе с ней реализовывать что-то интересное для вас. Это повышает мотивацию и самооценку. Помните, что вы можете это сделать, вопрос только во времени и настойчивости.

• Изучайте весь стек. Со временем, осваивайте весь стек технологий. Например, если вы веб-программист, не ограничивайтесь только фронтендом. Имейте представление о бекенде, базе данных, сервере, сети. Имея цельное представление о разрабатываемом продукте, вы сможете стать продвинутым инженером, принимающим правильные решения.
• Будьте самообучаемыми. Программная разработка одна из самых динамично развивающихся отраслей во всём мире. Если фундаментальные принципы меняются редко, то инструменты — чуть ли не каждый день. Важно следить за всеми новинками и уметь самостоятельно осваивать необходимые для вас.
• Учитесь общаться и сотрудничать. Если вы умеете что-то хорошо делать, то для вашей компании вы полезная единица = 1. Но если при этом вы поддерживаете и вдохновляете ещё 10 человек, то вы превращаетесь в глазах руководства в = 11.

7. Много всего, вокруг самого программирования

Нередко программист в одиночку пытается создать и выпустить на рынок свой продукт. Вот тут и начинается самое сложное.

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

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

Заказ рекламы в google-ads и поиск лучших вариантов, налаживание каналов сбыта, а ещё эта ограниченность бюджета, которая связывает тебя по рукам и ногам…

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

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

Каждый раз, когда ты в идеале овладел какими-то навыками, ты узнаешь, что появилось что-то новое, намного лучше. И возникает парадокс Сократа: “я знаю, что ничего не знаю”. Постоянно нужно тратить много времени на изучение нового, а так как невозможно знать всё и быть специалистом во всём, то постоянно надо выбирать приоритеты — что для тебя первостепенней в данный момент, какая технология, какой подход.

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

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

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

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

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

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

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

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

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

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

UPD

11. Борьба с багами

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

Самое обидное, что они появляются когда вы вроде бы всё сделали правильно, и можно приступать к дальнейшим свершениям. Но вдруг программа перестает работать без видимых причин, или работает не так, как задумано. И приходится всё бросить и тратить несколько часов, а то и дней на поиск этой ошибки. Кажется, будто это время тратится впустую (ведь вы не занимаетесь созданием «нового», а ковыряетесь в «старом»). Чтобы пережить этот период нужно титаническое терпение.

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

12. Идти быстро и ломать вещи

Нужно развивать в себе особый склад характера, когда вы не боитесь идти вперед, не будучи заранее готовыми к этому. Старый девиз Фейсбука: «Идите быстро, ломайте вещи. Если вы ничего не ломаете, значит движетесь медленно».

• программирование
• обучение программированию
• логика мышления
• эмоции программиста

Когда меня спрашивают, что самое сложное в программировании ⁠ ⁠

Когда меня спрашивают, что самое сложное в программировании, я отвечаю — придумывать имена переменным.

MTFK 9 лет назад

есть интересная вещь, сперва я называл переменные абы как, потом давал названия по смыслу: «timeEvent, listenEvent, workCount, progressMaster» а потом начал давал имена знакомых, подружек и бывших, теперь я знаю, для чего каждая из них, где хранится мусор, какая динамичная, какая реальная, а какая для большого массива данных без смысла.

раскрыть ветку (0)
reav123 9 лет назад
Придумывать имена переменным, и инвалидировать кэш.
раскрыть ветку (0)
zombyy 9 лет назад
а я красавчик,я не понял ничего
lordofthebananas 9 лет назад

смотрел я один код на кодфорсе, я программированием не увлекаюсь, и разобрать чей то код толком не смогу, однако переменные huy, pizda, suka, jopa и т.п. сразу попадаются на глаза

Vydar 9 лет назад

На юрфаке похожая проблема — придумывать имена фигурантов дела. Особенно перед обедом: о/у ОУР Супов, ст. следователь Печенькин, обвиняемый Ананасов, потерпевший Холодцов.

Похожие посты
tproger.official 6 месяцев назад

Для таких людей есть отдельный котел⁠ ⁠

Показать полностью 4
3 года назад

А потом удивляешься, почему же не работает⁠ ⁠

Теперь честно стырено с ВК: тык

Geekabu 3 года назад

Программистское⁠ ⁠

Goganoid 5 лет назад

Вся логика JS в одном изображении⁠ ⁠

VestigialPeter 6 лет назад

Яндекс плохого не предложит⁠ ⁠

kitaetz 7 лет назад

[Основы] Часть 1. Для грудничков.⁠ ⁠

Предполагается, что пост http://pikabu.ru/story/hello_world_4265035 уже прочитан или у вас любой дистрибутив linux.

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

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

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

Instagram — всеми любимый хостинг фотографий еды и ёбл тупых пёзд. Да, он написан на питоне. Мало того, за фреймворк взят Django, до которого мы доползём, если кроме меня будут желающие ползти. Да ещё и HTTP-сервер они взяли Gunicorn, до которого мы так же доползём. В качестве БД они используют PostgreSQL — мою любимую РСУБД и именно поэтому до неё мы тоже, возможно, доползём.

Reddit — сервис смехуёчков, думаю, все о нём так или иначе слышали. Он написан также на питоне, но на Pyramid фреймворке, а не Django. В качестве БД используются две базы: Cassandra и PostgreSQL. В качестве кэша используется memcached и фейсбуковский mcrouter. В качестве брокера сообщений используется RabbitMQ. Исходный код находится в общем доступе здесь https://github.com/reddit/reddit

exchange.livejournal.com — биржа блогеров ЖЖ, которая недавно открылась. Почему она здесь? Потому что я участвовал в её разработке. Она также написана на Django с базой PostgreSQL.

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

Все куски кода будут являть собой скриншоты Jupyter Notebook, во-первых, потому что мне в нём удобно писать, во-вторых, потому что нечего копировать чужой код.

Питон — язык со строгой динамической типизацией. Что это значит?

— Если захочешь сложить число 5 со строкой ‘7’ — тебя наругают. Это называется строгой типизацией. Никаких преведений к «более общему» типу.

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

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

Есть также множественное присваивание, которое я настоятельно не рекомендую использовать бездумно (это касается неплоских типов данных, о которых поговорим как-нибудь позже):

С переменными, вроде, пока всё.

В отличии от Си-подобного синтаксиса, у нас нет ни фигурных скобок для выделения блоков, ни скобок для выделения условного выражения (на самом деле, ничего не мешает обернуть условие в скобки). Блоки выделяются ТОЛЬКО отступами. Здесь нет никаких switch, есть только if, elif и else. Следующий пример, думаю, объяснит всё за меня:

А теперь небольшой сюрприз. Несмотря на то, что язык имеет строгую типизацию, сравнения между некоторыми неодинаковыми типами данных (int, float, Decimal) поддерживаются. Например 5 == 5.0 вернёт True, несмотря на то, что 5 — это целое число, а 5.0 — с запятой. Но использование этого считается дурным тоном.

Если вы до этого дня не знали слово «итератор» и писали только циклы по индексам, вроде такого for(int i=0; i

Итак, в питоне цикл for проходит итератором по каждому элементу последовательности. Ему глубоко плевать, что внутри последовательности. Число, строка, чьи-то надежды и мечты.

Для обычных циклов по индексам существует генератор range. О генераторах тоже позже.

Функции в питоне объявляются двумя способами:

Однако, второй способ СТРОГО НАСТРОГО рекомендую использовать для определения обычных функций. Лямбда-функции (или безымянные функции) нужны только для того, чтобы передавать их аргументом в функции высшего порядка.

Тут, наверное, возникло сразу два вопроса:

Как можно передать функцию аргументом в другую функцию?

Что такое функция высшего порядка?

Т.к. питон — объектно-ориентированный, следовательно, всё в нём является объектом. И функция тоже. Аргументом в функцию может прийти любой объект, в т.ч. и функция:

В данном примере много чего интересного:

1) После определения функции (def) можно ввести так называемый docstring, который описывает то, что делает функция. При этом, этот докстринг сохраняется в атрибут __doc__ объекта функции (что только лишний раз говорит о том, что функция — объект)

2) __name__ атрибут содержит имя объекта (функции или класса)

3) h в этом случае — функция высшего порядка. Функция высшего порядка — это функция, которая принимает или возвращает другую функцию. Это пригодится для декораторов, о которых также позже.

Функции можно присваивать другим переменным:

Но имя (__name__) останется прежним, т.к. фактически, f и same_func только лишь ссылаются на функцию.

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

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

15 самых сложных вещей в профессии разработчика

Думаете, самая большая проблема — выучить новый язык? Опытные разработчики рассказывают, что действительно трудно в профессии.

Общение

Андрей Черабаев, разработчик в IT-компании MediaSoft:

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

И при этом нужно быть очень терпеливым, помнить, что люди разные: одни не понимают вас с первого раза, а другие любят объяснять по десять раз одно и то же. Сам этим страдаю.

Хаос из-за множества языков и фреймворков

— Появляется множество языков программирования и фреймворков, которые применяют повсеместно, как таблетки от всех болезней. И разработчику часто приходится сталкиваться с тем, что он должен хорошо знать слишком многое. Это и скриптовые языки на стороне фронта: HTML/CSS, JS, включая набор современных фреймворков BackBone.JS, AngularJS, ReactJS. Вместе с тем — языки С#, Java, Python и спецификации типа .Net Framework, JavaEE для серверной стороны. Добавим сюда знание баз данных и языка манипуляции с данными, стандартов сервисного взаимодействия. Этот огромный бум порождает хаос, и зачастую разработчики не усваивают тонкости языков или технологий.

Огромная нагрузка

— Сегодня в разработке приложений фичи продукта поставляются быстро, чтобы не заставлять пользователя ждать. Это порождает колоссальную нагрузку на программистов: то, что 10 лет назад разрабатывалось месяцами, сейчас реализуется в 2, а то и в 4 раза быстрее. Специалист, не умеющий применять паттерны проектирования (прототипирование, синглтон, адаптер, фасад, декоратор, архитектурный паттерн MVC), не сможет построить правильное веб-ориентированное приложение для широкой аудитории.

Не тратить драгоценные ресурсы на ненужные задачи

Юрий Пономарев, консультант центра технической поддержки компании «РДТЕХ»:

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

Бизнес-аналитики говорят, что исполнить запрос нельзя. Менеджер обещает премию тому, кто это откроет. Гугление по заголовкам файла каждый день приносит разный результат. Средства Windows не помогают понять содержимое. Средства сортировки падают при попытке его отсортировать. Средства распознавания форматов говорят, что там минимум 15 различных файлов. При передаче по сети корпоративный антивирус сходит с ума. На архив файла ругаются все почтовые системы, но он сжимается в 10 раз легко.

Старый разработчик пишет:

public static void main(String[] s) throws Exception VTDGenHuge vgh = new VTDGenHuge(); if (vgh.parseFile("C://TEMP//file_big",true,VTDGenHuge.MEM_MAPPED)) VTDNavHuge vn = vgh.getNav(); AutoPilotHuge aph = new AutoPilotHuge(vn); aph.selectXPath("//company/@Name"); int i = 0; while ((i=aph.evalXPath())!=-1) System.out.println(" element name is "+vn.toString(i)); > > > 

По имени компании разработчик находит ее почту, пишет письмо и выясняет, что это — вордовый файл с корпоративной отчетностью, который почему-то поместили в виде слайд-шоу в jpeg, а потом — несколько раз скопировали в XAML.

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

Смешанные принципы современных языков программирования

Юлиана Науменко, руководитель департамента развития софтверных решений ГК «Авилекс

— Яркий пример — язык программирования JavaScript. Центральное ядро в части организации строительных блоков — функции.

Но, если внимательно на это взглянуть, все не так просто:

• функция — элемент парадигмы функционального программирования;
• функция — классический элемент процедурного программирования;
• функция — объект.

Такой симбиоз порождает короткие, цепные и гибкие реализации, понимание которых порой приходит не сразу. Это замыкания, колбэки, применение анонимных функций (в C# — применение делегатов в событиях, таски и так далее).

Тесты, названия переменных, общение с коллегами

Кирилл Меженцев, программист группы разработки карты рассрочки «Совесть»:

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

Оценка задач

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

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

Сроки

Константин Коногорский, руководитель отдела разработки ПО в «ВИСТ Групп»:

— Очень часто приходят менеджеры и говорят: «Этот БелАз должен летать на высоте 10 метров над землей, достигая скорости в 10 узлов при идеальных погодных условиях. У тебя три дня. Мы уже всё продали, подписали контракты, получили деньги и премии. Теперь во всем виноват ты». Как правило, продажникам плевать, возможно это или нет, сколько реально потребуется времени, что у тебя пять дедлайнов на неделе. Программист, по их мнению, всемогущ и имеет 1024 часа в сутках. Как справляться? Берешь и делаешь.

Проблемы с документацией сторонних библиотек

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

Находить баланс

Евгений Ким, руководитель отдела разработки платформы RU-CENTER:

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

Богатство выбора

— Выбор сейчас действительно огромный. Можно пойти в backend-разработку, в тестирование, в мобильную разработку. В каждом направлении десятки технологий, и это может вскружить голову. Тут нужно брать и пробовать. И читать профильные ресурсы, такие как geekbrains.ru.

Переделывать

Елисей Самретов, разработчик мобильных продуктов FL.ru:

— Для меня самый ненавистный момент наступает, когда приходит менеджер с суперважной задачей «переделай это срочно». Как справляюсь? Закидываюсь таблетками. Шутка. Музыкой в айфоне и дедукцией Шерлока Холмса: разбиваю задачи на итерации, слежу за синхронизацией дизайна, логикой написания программы.

Рутина

Стас Жеребчук, frontend developer в Weblium:

— Сложнее всего просыпаться по утрам и начинать работать.

Что помогает? Смузи-машина. Что мотивирует? Осознание, что меня могут выгнать, если я не буду ничего делать.

А что для вас самое сложное?

Что самое сложное в работе программиста? Рассказывают выпускники и ученики JavaRush

Сидячий образ жизни, работа с устаревшим кодом и поиск багов — разработчики, как и люди других профессий, сталкиваются со сложностями в работе. Можно долго дискутировать о том, что самое сложное для программиста, а можно просто спросить мнение девелоперов. Нам было интересно узнать, что выводит разработчиков из себя, поэтому мы провели опрос и собрали результаты в этом тексте. В нашем опросе участвовали ученики и выпускники JavaRush — как те, кто еще проходит курс, так и те, кто уже устроился на работу. Это важно понимать, потому что мнение о сложностях в работе для этих категорий отличается. Вот такие, например, проблемы выделяют ученики JavaRush, которые пока что на пути к своей первой работе:Работающие программисты думают иначе: получая реальный опыт, мнение о сложностях в разработке у девелоперов меняется. Например, на первом месте для работающих программистов стоит проблема отсутствия спецификаций, а для учеников — работа с legacy-кодом.Для бэкграунда также добавим, что среди работающих выпусников JavaRush больше всего тех, кто устроился в продуктовую компанию, на втором месте — разработчики в аутсорсе и всего 3,8% девелоперов трудятся на ниве фриланса.Разберем сложности в работе подробнее — с комментариями разработчиков. А заодно узнаем, что девелоперам больше всего нравится в их работе и как сложились их отношения с удаленкой.

Отсутствие спецификаций

Отсутствие спецификаций, то есть описаний поведения программы, которую требуется разработать, — это первая проблема в списке сложностей для работающих программистов (ее отметили 69,2% разработчиков). Как мы упоминали выше, интересно то, что учащиеся и ищущие работу немного иначе представляют, какая проблема программирования будет главной. Для этой категории это работа с legacy-кодом (устаревшим кодом — ред.) — за нее проголосовали 45,5% опрошенных. Это различие в ответах говорит о том, что учащиеся не до конца понимают проблемы, с которыми столкнутся на практике. Среди учеников проблема отсутствия спецификаций стоит на втором месте (за нее проголосовали 36,4% людей).

Вот что рассказали программисты об отсутствии спецификаций: “Работаю недавно, как работает приложение пока понимаю плохо”, — говорит Денис. “Без понимания нюансов продукта и без должной спецификации, тяжело вносить изменения или рефакторить старый/специфический код”, — считает Андрей. “Сложно переключаться с задачи на задачу при отсутствии документации или спецификации”, — отмечает Роман. “Из-за неточного техзадания [приходится] придумывать решение, которое потом критикуется и требуется переделка”, — говорит Вероника. “Отсутствие внятного техзадания в 90% случаев”, — говорит Денис. “Нет четких технических заданий, заказчики сами не знают, чего хотят. Уже на стадии разработки задание может кардинально поменяться”, — добавляет Андрей.

Оценка сроков выполнения задач и работа с legacy-кодом

Невнятные дедлайны оказались на втором месте в списке сложностей работы программиста. За них проголосовали 42,3% работающих айтишников. В то же время, учащиеся поставили эту проблему всего лишь на пятое место (18,2% голосов). Чаще всего программисты жалуются на то, что работодатель неправильно оценивает сроки выполнения задач или на то, что имея мало опыта, сами не могут посчитать правильные сроки. “Иногда бываю не уверен в сроках, за которые выполню таск и ставлю больший estimate (оценку — ред.), хотя выполняю быстрее. Порой это напрягает клиентов”, — говорит Игорь. “Сроки выполнения устанавливаются с потолка и другими людьми, зачастую не имеющими отношения к разработке”, — говорит Денис. “Время на задачу, в которой нет опыта, трудно определить”, — добавляет Николай. Работа с устаревшим кодом набрала столько же голосов среди работающих программистов, сколько и размытые дедлайны — 42,3%. Напомним, что ученики поставили ее на первое место (45,5% голосов).

Слишком много митингов

Пожалуй, проблема с митингами в сфере IT-разработки усугубилась во времена пандемии. Митингов и так было много. Но из-за онлайн-формата стало еще сложнее вникать в суть разговоров. 38,5% работающих разработчиков отметили, что митинги усложняют их работу. В то же время, ученики отдали за них 18,2% голосов, вероятно потому, что не столкнулись еще с этой проблемой в реальности. “Много времени уходит на пустое общение, а дедлайны никто не отменял”, — говорит Петр.

Сидячий образ жизни

Постоянное сидение за компьютером попало на пятое место среди сложностей в работе программистов (34,6% голосов работающих девелоперов). Ученики и ищущие работу отправили эту сложность на четвертое место с 36,4% голосов. Программисты отмечали, что из-за сидячего образа жизни у них есть проблемы со здоровьем: шейный остеохондроз, “больная спина”, лишний вес.

Общение с другими людьми и поиск багов

Необходимость коммуницировать с другими людьми и искать ошибки набрали одинаковое количество голосов — по 23,1% среди работающих программистов и заняли пятое место в рейтинге сложностей. Интересно, что среди учащихся за проблему с общением не проголосовал никто. Это, скорее всего, связано с тем, что новички еще не успели поработать в айтишных командах. В то же время за поиск багов проголосовали 36,4% учеников и ищущих работу.

Офис или удаленка: что сложнее?

Хотя вначале карантина многие радовались удаленке, согласно нашему опросу недовольных этим форматом работы оказалось довольно много. Опрошенные отмечают, что им сложно сконцентрироваться в домашней обстановке, границы между работой и отдыхом размываются, трудно соблюдать work-life balance. Есть и недовольные офисом: их в основном напрягает то, что надо тратить несколько часов, чтобы добраться на работу и домой. “Недостаток офиса — время на дорогу. Недостаток удаленки — много соблазнов, которые могут отвлечь и то, что дом плавно превращается в офис”, — говорит Игорь. “В офисе большой объем лишнего общения”, — отмечает Денис. “Офис хуже, потому что я интроверт. Мне проще общаться с людьми виртуально”, — добавляет Александр. “Однозначно [труднее] удаленка. Переусложненные коммуникации, отсутствие контакта с командой. Средства удаленной связи не позволяют так же продуктивно решать поставленные задачи, как я это делаю в офисе”, — говорит Денис. “Работа в офисе сложнее в случае, если офис находится далеко, потому что долго добираться. Не хочется терять время. Но если офис под носом, то однозначно выберу офис. Там рабочая обстановка”, — говорит Владислав.

Бонусы работы программистом: высокая зарплата, творчество и карьерный рост

Для баланса мы спросили участников опроса о преимуществах работы программистом. Чаще всего разработчики отмечали высокую зарплату, хорошие условия труда, интерес к работе, перспективы карьерного роста и возможность релокейта в другие страны. “Постоянные логические задачки, комфортные условия и хорошие зарплаты”, — говорит Игорь. “Высокая зарплата в обмен на возможность решать интересные задачи. Очень серьезные возможности для роста”, — говорит Денис. “Творческая, спокойная, размеренная, а главное — интересная работа”, — Роман. “Я ощущаю радость от создания чего-либо нового или починки старого. Программирование — это вечный пазл с тысячей решений, дофаминовый наркоман во мне доволен. На текущий момент это, наверное, самое простое из созидательных занятий после жарки яичницы”, — Денис. “Интересные задачи, хорошие условия труда (заработная плата, культура и рабочая атмосфера в IT компаниях), возможности для постоянного развития и обучения”, — Алексей.

“Можно работать 24 часа в сутки, а можно работать головой. Профессия программист как раз об этом. Ты сам (в зависимости от поставленной задачи) определяешь, что тебе нужно делать, когда и в каком объеме. Все, что нужно — это компьютер, голова и эта самая задача”, — Артур. А как по-вашему, что самое сложное в работе программиста? А что самое приятное? Ждем вашего мнения в комментариях 😉