Мне очень понравилась ветка обсуждений на Quora.com: What is the hardest part about learning to program? Все 87 ответов я так и не прочитал, но понравившиеся, выделил в отдельную статью из 10 пунктов. Это вольный пересказ мнений многих разных людей. Если читателям будет интересно, я продолжу.
1. Разница между высокими стандартами и своими низкими умениями
В статье «Никто не говорит об этом новичкам» рассказывается об общей проблеме людей, занятых творческим или интеллектуальным трудом. Программирование — сложный предмет, и обычно за него берутся способные, амбициозные и склонные к перфекционизму люди. На начальном этапе у них не будет хорошо получаться. Привыкшие к высокой планке, они будут расстраиваться. Внутренний голос будет постоянно нашептывать: “У тебя никогда и не получится, лучше оставь это дело”. В такие моменты думайте о том, что ваша самокритичность — это признак вашей экстраординарности, и верьте, что преодолеете этот “неумелый период”.
Что касается необычайных преимуществ программирования, то вот они:
- Проблемы в коде в корне отличаются от проблем в физическом мире. Починить неисправный код можно одной лишь силой ума, в отличии от, например, сломанной машины, которая требует покупки дорогих запчастей.
- Профессионально расти можно только на границе зоны комфорта. Занимаясь незнакомыми вещами вы сделаете кучу ошибок, но зато и получите настоящие знания.
- Ошибки в программировании — это не закрывающиеся двери перед вами, а ключи к обучению.
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. Балансирование между теорией и практикой
С одной стороны, можно много изучать теорию, годами читать что-то и думать что ты мало знаешь и ничего не делать. Это надоедает и перестаёт приносить пользу в какой-то момент.
С другой стороны, можно начать делать что-то, без знания теории, и быстро застрять или заблудиться в своём коде и его ошибках. Многие начинают делать что-то, опираясь только на обрывистые ответы с форумов, не понимая целой картины своего приложения и куда их приведет работа в конечном итоге (например, к неподдерживаемому, необновляемому коду).
Так вот, очень важно прочувствовать этот баланс минимальной теории и последующей за ней практики. Тогда и то, что вы пишете будет грамотным, и теория будет усваиваться в разы быстрее и интереснее, и будете гармонично обучаться во время работы.
Комментарии (105)
lxsmkv
04.10.2017 21:10+4Логика программирования заключается в том, чтобы разбить большую задачу на маленькие подзадачи и последовательно реализовать их, а потом связать воедино.
согласен на 100%. Этот подход стоит использовать и в управлении проектом (макро). Видел сам, как опытные программисты впадают в уныние, когда перед ними стоит плохо описанная, большая задача. Если ее не разбить на мелкие, легко выполнимые задачи, то можно засесть в таком «болоте» надолго. И тут нельзя не отметить (из чистого прагматизма), что agile, как методика, делает именно это.
rustamaha Автор
04.10.2017 21:20+1я недавно другу показал одну задачку которую сделал, для поступления в «школу повышения квалификации» так скажем) он сказал что нормальная задача, я подумал сначала, что это сарказм, т.к. он обычно любит принижать мои дела) но оказалось — серьезно говорит. Я ему говорю — а ты знаешь, я его к удивлению как-то легко сделал в 2 присеста. В первый к каждому пункту написал функции и протестировал. А во второй — соединил их в одну программу.
Друг резюмировал, что это как раз потому так легко получилось, что задача была чётко расписана по пунктам. и советовал мне всегда так делать )
Harr
04.10.2017 21:24На моё удивление, первый раз об этом подходе я узнал из «Совершенного кода». Вроде ничего сложного, однако, в университете такого не давали.
vesper-bot
05.10.2017 14:56+1А блок-схемы вы рисовали? В принципе, разрисовать алгоритм в виде блок-схемы высокого уровня (а-ля "по этому и этому вычислим вот это с помощью вот этого алгоритма") вполне себе является разбиением задачи на подпункты. Другое дело, что обычно блок-схемы дают только для нижнего уровня :(
Harr
05.10.2017 15:03Особой разницы не вижу. Единственное отличие для «верхнего» уровня — это то, что каждый блок состоит на самом деле из алгоритма «нижнего» уровня. Если я вас правильно понял
n_dufy
05.10.2017 23:59+1У меня всегда такая проблема. И в работе и в жизни и вообще(( даже не знаю что делать.
Alexsandr_SE
04.10.2017 21:55+1Еще хорошо помню, недавно было. Изучал самое начало, делал задание по видео (по сути потворить только), но как только дошел до CheckBox, все забросил и появилась (опять таки подсказывали в инете) нужная и полезная для себя программа. Вторая рождается уже, как впрочем и вопросы с нею, почему так работает правильно, а так нет. Но после этого все же вернусь обучаться дальше по сценарию :), может еще что-то попадется интересное.
Ohmu
04.10.2017 22:00+1Очень улыбнула картинка про яму страданий. Я наверное еще только-только из этой самой ямы начал выбираться.
SystemXFiles
05.10.2017 08:18+2У меня почему-то не было ни ямы страданий, ни ощущение прекрасного. Работаю себе и работаю. В меру дурак, в меру умен. Всегда так было.
rustamaha Автор
05.10.2017 08:45в положении равновесия ты значит)
почему-то так сложилось, что я могу продуктивно кодить только в подобии «биполярного расстройства», когда кидает из эйфории в депрессию и обратно.
sinneren
05.10.2017 16:24+1А что именно в депрессию кидает? Вот меня, например, не столько неудачно решенная задача или вообще нерешенная, сколько отсутствие понимания и результата продвижения(карьерного горизонтального хотя бы). Я как бы фронтендер, был фулстэк, ну как фул — CMSы. Сейчас пытаюсь вкатиться хоть в что-то модное, реакты\вуе и тп. А главная проблема — раз, не успевают уроки за ростом и «развитием» фреймворка; два, вообще непонимание окружения, много серверной части или пограничной с ней. И вот это вот просто унижает, добивает меня. Руки опускаются когда я несколько часов трачу на то, чтоб обновить deprecated пакеты, заставить работать вебпак и т.д. и т.п. Точное следование самому подробному уроку не помогает. А когда добираешься до задачи понимаешь уже, что тут нужен какой-то бек, в котором нет желания разбираться, если ты пытаешься быть фронт.
rustamaha Автор
05.10.2017 16:28в депрессию кидает неконтролируемая длительная работа в «эйфории». То что вы пишете, очень знакомо для меня тоже. Особенно потому, что у меня есть идеи, которые я не смог реализовать в CMS и поэтому полез в разные курсы, еще долго не мог определиться и всего понемногу изучил. В конце лета познакомился с фреймворком Meteor.js — это был большой сдвиг, когда я смог наконец сделать full-stack приложение )
Fesor
05.10.2017 18:37+1Точное следование самому подробному уроку не помогает.
а с каких пор оно должно помогать? Это урок. Там обычно учат делать что-то одно и оно чаще не прибавляет понимание того как это работает. Читайте документацию, следите за изменениями фреймворка в ишус трекерах/пул реквестах (благо сейчас это просто), читайте исходники (если совсем круто хотите знать инструмент, чаще это не нужно).
нужен какой-то бек, в котором нет желания разбираться, если ты пытаешься быть фронт.
Пишите бэк на nodejs, сейчас к тому же есть масса serverless решений.
Меня к примеру в уныние и тоску повергают люди которые хотят развиваться но ничего для этого не делают. И таких много. А еще — часто проблема не в том что "технологий много и быстро развиваются" а скорее в хайпе. Технологии достаточно медленно развиваются и концепции в целом имеют более цикличный характер. Сейчас модно то что было модным 10 лет назад просто в другом контексте.
Zoberg
08.10.2017 11:27+1Мне понравился посыл в статье «старайтесь понимать весь стек». Нет никакого рокет сайнса в том, чтобы фронтендеру писать / понимать ещё и бекенд на nodejs. Язык там один и тот же, немного разное окружение.
beeruser
06.10.2017 02:24+1Возможно вы ещё находитесь в точке отсчёта. Я вот уже лет 15 погружаюсь в эту «яму» :-)
SystemXFiles
06.10.2017 05:39+1Я как десять лет занимаюсь программированием и особой разницы в восприятии себя в профессиональном плане не замечаю.
Просто прекрасно понимаю, что при должном упорстве моем и планировании почти любая задача посильна. Всегда только встает вопрос, а сколько времени это займет: неделя, месяц или вовсе полгода?
Могу конечно лениться как последний разгильдяй, находиться в прокрастинации перед новой для меня сложной задачей, но при этом не считаю себя ничтожеством или еще кем-то нехорошим =)
В какой-то момент бывает радуюсь очень, что решил эту, будь она неладна, задачу, которая недели две насиловала мне мозг. Горжусь собой, но разве это возвышение себя Олимп, не думаю.
Много знаю людей, которые профессиональнее меня во многом, смотря на них, хочется расти дальше, но и вижу много людей, которые менее профессиональны и тут грустно, хочется как-то поделиться опытом, помочь.
Какая яма? Зачем? Почему?
То что я чего-то не знаю не повод себя угнетать и никогда им не станет.
Никогда не боялся показать себя дураком. Спокойно задаю глупые вопросы, дабы потом поумнеть.rustamaha Автор
06.10.2017 05:43+1Ну вот я например любительски занимаюсь программированием. Когда попытался устроиться — не взяли. Стал наверстывать, наверстывать (читать книги, проходить курсы), — всё равно не взяли. И вот тут то и понимаешь, что в яме. Все потраченные усилия как будто были зря (из той точки отсчёта).
SystemXFiles
06.10.2017 05:52+1Так может дело не в вас? Мне сложно судить, ибо мне сказочна повезло и первая работа нашла меня сама. Я даже не ожидал на тот момент, что буду работать, ибо учился в универе.
Но бывают такие регионы, где очень трудно найти постоянную стабильную работу IT-шнику. Где недостаток рабочих мест. Тут только по фриланс подаваться или любую работу брать, лишь бы выжить.
Согласен, это может очень угнеть, но веру в себя терять не стоит =)rustamaha Автор
06.10.2017 06:39я в Москве пытался. Как я понял, там требования высокие, на некоммерческие проекты не смотрят даже, и я не смог сориентироваться, как там начать карьеру. Вот, сейчас в Питере…
rustamaha Автор
06.10.2017 05:47А за вас рад конечно, что у вас нет болезненных эмоций при работе :)
SystemXFiles
06.10.2017 06:01+1Ну честно говоря есть, порой очень матерюсь, когда пишут говнокод и ты наследуешь его, вынужден его дорабатывать.
Особенно матерюсь, когда мой код начинают дорабатывать люди, которые не особо разбираясь впихнут кусок говнокода. Приходится потом рефакторить в рамках смежных задач.
Порой случается ошибка в ТЗ и приходится переделывать много, иногда играем с тестировщиками в пинг-понг с целью: кто прав, кто виноват.
Стресса хватает, но это даже весело. Особенно когда что-то на проде ломается и надо шустро починить, быстрая доза эйфории =)
timiskhakov
05.10.2017 10:32+2По моему опыту, картинка циклическая. Как только столкнетесь с изучением новой технологии, все повторится.
Kwisatz
05.10.2017 23:59+1Вот только она периодическая до бесконечности. Я когда берусь за новую технологию всегда себя так ощущаю)
myrkoxx
04.10.2017 22:21+9Есть только две трудные задачи в области информатики: инвалидация кеша и придумывание названий
marsianin
04.10.2017 22:24Простите, может я не в теме. А что сложного в инвалидации кэша?
myrkoxx
04.10.2017 22:50+2Ето одна из многих известных цитат про програмирование. Кажеться сказал Фил Карлтон. Вот есть подборка:
habrahabr.ru/post/275841
А к теме что сложного, вот неплохие статьи:
habrahabr.ru/post/120471
eax.me/caching-is-hardmarsianin
04.10.2017 23:02-2Про цитату не знал. А касательно инвалидации, в силу специфики проектов, над которыми работаю, первая ассоциация — инвалидации процессорного кэша (ну, того, который L1, L2 etc). А в ней ничего сложного обычно нет. В любом случае, спасибо за разъяснение (-:
Fesor
04.10.2017 23:25+2А в ней ничего сложного обычно нет
ну как сказать, конкретно в этом случае сложность в том как уменьшить количество кэш мисов.
marsianin
05.10.2017 09:09-3Ну, как сказать, всё-таки это проблема разработчиков железа, программист на неё не влияет. Да и на некоторых задачах вытеснение случайной строки кэша бывает лучше для производительности чем всякие хитроумные алгоритмы.
TheDeadOne
05.10.2017 11:21+4Даже программистам на java, которых от железа отгораживает виртуальная машина, чтобы писать действительно производительные программы, полезно знать о протоколах когерентности кэша и писать код так, чтобы избегать cpu contention. Для системных же программистов это знать и применять обязательно.
marsianin
05.10.2017 12:11Прикладным программистам надо знать размер кэшлайна, чтобы не допускать false sharing без необходимости. Системному программисту необходимо кроме того знать, в каких случаях железо не обеспечивает когерентность, чтобы при необходимости обеспечить её программно. Как поможет знание алгоритмов вытеснения и протоколов когерентности, реализованных в конкретном CPU, мне, честно говоря, непонятно.
marsianin
05.10.2017 12:26Могу предоставить только один случай, когда знание алгоритма вытеснения и протокола когерентности, реализованных в конкретном CPU, может помочь — если вы ищете баги в реализации контроллера кэша.
Deerenaros
05.10.2017 18:04+1Очевидно, что для этого придётся видеть будущее. Но на самом деле, статистика и некоторая эвристика даёт весьма не плохой результат. У нас на курсе декан говорил «Есть задачи простые, тривиальные и ещё не решённые». И в общем-то так и есть. И щепотка мерзости перфекционистам: теоретические пределы нигде ещё не достигнуты. Ни энтропийное кодирование, ни помехоустойчивое, ни криптография — пределы где-то там вроде есть, даже вроде есть рецепт, но как-то до него не добраться. Вот не получается.
nomoreload
05.10.2017 00:37+8There 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
Snart
05.10.2017 20:49+1Есть только две трудные задачи в области информатики: инвалидация кеша и придумывание названий
Мне больше по душе другая версия этого изречения (:
Есть только две трудности в программировании: инвалидация кеша, придумывание названий и ошибки на единицу
Ritorno
04.10.2017 22:28Пункт 2 рано или поздно каждый ощутит на себе.
Inine
05.10.2017 09:39+2Мне второй пункт напомнил Теда Нельсона:
«Хорошая новость про компьютеры: они всегда делают то, о чем вы их просите. Но есть и плохая: они всегда делают то, о чем вы их просите.»
Old_Chroft
05.10.2017 15:00+1Программа делает то, что написал программист, а не то что хотел написать © (Не_помню_кто)
vesper-bot
05.10.2017 15:03+1Жаль, но в современном мире компьютеры делают не только то, о чем их просите вы, а ещё прорву разных дел, о которых его просили разработчики ОС и ПО, которое на ней установлено. И из-за этого бывает так, что криво написанное ПО "Х" ломает твою хорошую программу "У". Про IME и ему подобные просто молчу. Для простых программ, к счастью, такие проблемы обычно не актуальны, но бывает и иначе...
Inine
05.10.2017 15:10+1Это да. Когда ide или ворд выкидывают очередной номер, или винда опять лезет обновляться без спроса, я начинаю брюзжать, что софт стал умнее, чем его авторы.
prodavecmacdonalds
05.10.2017 23:59+1Пункт 2 привёл меня в программирование. Когда я понял, что все только в моих руках, что между идеей и реализацией стоит только моё незнание я начал постоянный ликбез, короче, очень увлекательно и некого винить.
rustamaha Автор
06.10.2017 00:10очень позитивное толкование пункта 2) вроде там наоборот написано, что всё в руках компьютера))
шучу
myrkoxx
04.10.2017 22:51+7И еще:
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery
Godless
04.10.2017 22:53+1не отвлекаясь от темы, считаю самым сложным (обобщая ессно) — знание предметной области.
Хотя описанные в статье вещи действительно не так очевидны и просты как кажутся.rustamaha Автор
04.10.2017 23:01предметной области чего? сферы для которой софт пишешь?
Suvitruf
04.10.2017 23:20+1Именно. Большая часть проблем от незнания контекста/предметной области. Ещё хуже, если человек не понимает чего-то, но при этом ни у кого не спрашивает/не уточняет неясные моменты. Как следствие, приходится переделывать по нескольку раз одно и то же.
dmonk
05.10.2017 00:35Для этого существуют бизнес-аналитики. Хотя в общем знать область деятельности очень желательно, но не жизненно необходимо.
Fesor
05.10.2017 02:49бизнес аналитики должны помогать вам понимать проблемы бизнеса (не что делать, а зачем), а предметную область всей команде так или иначе нужно понимать что бы проблемы эти решать эффективнее.
movl
04.10.2017 23:17+2Уже как мантра звучит мнение о том, что постоянно нужно изучать новые и новые технологии. А учитывая контекст советов в данной статье, для меня это звучит как призыв поучаствовать в гонке за модой, так как зачастую ничего нового в этих "новых" технологиях нет. Не понимаю этого.
Если фундаментальные принципы меняются редко, то инструменты — чуть ли не каждый день. Важно следить за всеми новинками и уметь самостоятельно осваивать необходимые для вас.
Да, вы можете выбрать какую-то одну вещь и стать специалистом в ней, но тогда вы очень рискуете, что в это же время появилось что-то новое, многократно превосходящее вашу технологию и это нечто завоюет рынок, в то время как вы держитесь за старьё обеими руками.Инструменты решают лишь технические проблемы. И знание большого количества инструментов, не всегда ведет к пониманию концептуальной проблемы. Фундаментальные знания, напротив, позволяют широко мыслить о проблеме и приводят к правильному выбору инструментов для ее технического решения. Например, не нужно глубоко знать все языки, чтобы понимать какой лучше применить, для решения некой задачи, достаточно лишь понимать, на каких принципах основан язык, и на сколько хорошо эти принципы могут помочь для решения задачи, в контексте с прочими факторами. Следовательно важны базовые знания и понимание предметной области проблемы, а не знание конкретных технологий, которое очень быстро выветривается, если перестать этими технологиями пользоваться.
rustamaha Автор
04.10.2017 23:43Я в веб-разработке пытаюсь что-то делать. И там реально часто меняется. Вот вроде как с Express познакомился, а уже Koa актуальнее стала. Вроде недавно ангуляр2 вышел, а уже и 4й вышел… и т.д.
movl
05.10.2017 00:15+1Я не говорю, что не нужно актуализировать инструменты, особенно если они дают существенные преимущества для решения некоторых проблем. Но нужно стремиться к тому, что бы базовые знания, давали представление о технологии, а не непосредственное изучение конкретной технологии.
Например, берем Node, видим что она работает в одном потоке, код выполняется асинхронно, а связывающим звеном является event-loop. Это уже дает представление, о том как различные части программы могут взаимодействовать между собой, какие плюсы и минусы из этого можно получить. Берем экспресс, видим что API позволяет нам обрабатывать данные по средствам обратных вызовов, а часть типовой логики предлагается вынести в промежуточные обработчики запросов (middleware), и понимаем, что с чем и как должно работать тут, какие задачи могли возникнуть не только у вас (авторизация, рендер шаблонов и все такое), а следовательно для чего могут быть уже готовые решения на базе этого Express. Берем Koa, видим корутины и опять же делаем выводы о концепции библиотеки и с какой стороны лучше подходить к ее использованию, а дальше дело лишь за изучение API. И так далее, от общего к частному.
rustamaha Автор
05.10.2017 07:30вот мне почему-то всегда трудно давалось осознание таких вещей, типа event-loop, хочется просто брать что-то и применять, не копаясь глубоко (
хотя умом понимаю, что много теряю от такого подходаsenglory
05.10.2017 20:48+1Мне наоборот кажется, что умение пользоваться тем же ангуляром без глубокого копания в шизофрении тех, кто его породил и прочих заумных вещах, не решающих напрямую проблемы бизнеса — это на порядок эффективнее с точки зрения затрат времени, чем когда ты вынужден прежде понять как очередное поделие устроено, что от него ожидать, а только потом его использовать. Это как с вождением машины — если нужнор просто перевозить груз или пассажиров по маршруту в рамках ПДД, то нафиг узнавать как там что под капотом устроено. В конце концов, я не автомеханик, а водитель.
movl
08.10.2017 16:46+1Аналогии не всегда корректны бывают, но если говорить про вождение машины, то например умом вы должны понимать, что чем ниже передача, тем большее ускорение вы можете получить, допустим, при старте или двигаясь в гору. Совершенно не обязательно знать при этом как устроена коробка передач вплоть до каждого болта. Посмотрите на профессиональных гонщиков, они имеют ясное представление о том как давление в шинах или температура тех же покрышек влияют на управляемость, а это лишь малая часть из тех нюансов, касательно шин, за которыми постоянно нужно следить, для обеспечения максимальной эффективности их работы. И вовсе не обязательно понимать, каким образом скорость движения атомов, в некотором веществе, влияет на сцепление этого вещества с другим. Понимание некоторых вещей может приходить опытным путем и доведено до автоматизма, но теоретические знания позволяют иметь более широкое представление о каком-либо явлении и позволяют делать различные следствия, особенно когда теория начинает коррелировать с опытом.
Если говорить про первый ангуляр, то например не понимая того как работает digest-цикл, можно долго искать ответы на SO, почему некоторая последовательность вызовов не приводит к отображению результата на странице. Или не понимания того как происходит поиск изменений в данных для отображения, также долго можно разбираться, почему данные при определенных условиях начинают обрабатываться рекурсивно, блокируя при этом все остальное. Не говоря уже про более тонкие подходы к различным оптимизациям.
А судя по большому количеству статей по первому ангуляру в прошлом, изучение фреймворка предполагало понимание не этих базовых вещей, на которых он построен, а изучение различий между сервисом и фабрикой условно, что по сути различия между инстансом одиночки и классом, в сильном упрощении, но достаточном если знать особенности JS. И к вопросу об изучении фреймворка в принципе, если таким же образом упрощать прочие его особенности и накладывать на эти упрощения свои теоретические знания, можно быстро докопаться до сути вещей происходящих внутри всей этой магии. А понимание внутренних процессов инструмента, ведет к эффективному использованию его, и дает возможность делать очевидные выводы о работе тех или иных частей и предполагать различные следствия, для моментов, про которые в документации даже и сносок никаких может не быть.
wildraid
04.10.2017 23:55+2Самое сложное в программировании — продвинуть в жизнь какую-то идею, отличную от «общепринятого мнения» и от «привычного порядка вещей». Даже если уже в прошлом такое успешно делал сто раз, всё равно и в 101-ый раз всё по новой.
Сам кодинг, технические сложности, дедлайны, недостаток знаний и опыта — это всё решаемо. Всегда можно сесть и ещё подумать, ещё получше разобраться. Но потом сдвинуть всю махину в правильную сторону — big deal.rustamaha Автор
05.10.2017 00:02продвинуть в жизнь какую-то идею, отличную от «общепринятого мнения» и от «привычного порядка вещей»
— создать успешный стартап? чтобы твои инновации получили признание?
сдвинуть всю махину в правильную сторону
— грамотный маркетинг имеешь ввиду?
ru_vlad
05.10.2017 00:10+1По моему мнению самое сложное в программировании это не прекращать учиться и иметь стремление познавать новое и конечно труд и еще раз труд.
Fesor
05.10.2017 02:51+3По моему мнению самое сложное в медицине это не прекращать учиться и иметь стремление познавать новое и конечно труд и еще раз труд.
ну или так
По моему мнению самое сложное в индустриальном дизайне это не прекращать учиться и иметь стремление познавать новое и конечно труд и еще раз труд.
Словом вы поняли. Программирование тут отличается только большим количеством хайпа, и скил фильтрации и анализа информации очень хорошо помогает.
dmonk
05.10.2017 01:31+2Самое сложное лично для меня это:
писать письма;
выяснять почему опять свалился девелоперский энв;
разбираться руководствуясь каким пунктом в спецификации тестировщик завёл тот или иной баг;
мягко объяснять бизнес-аналитику, что эта фича у нас исторически так работает и новую подобную фичу лучше реализовать в том же духе;
заводить дурацкие годовые цели и потом рассказывать менеджеру как я мощно их достиг;
И всё прочее в этом роде.
То есть, деятельность с программированием связанная весьма опосредованно.
А когда есть чё задевелопить, и задача понятна — это просто праздник какой-то. Отдых, можно сказать.
werevolff
05.10.2017 03:20+3У меня 10 утра. Это относительно рано. Просто я рано лёг. Мне надо вставать и работать. Компьютерное кресло придвинуто к дивану. Самое сложное в программировании — вставать по утрам.
hdfan2
05.10.2017 07:04+5Программирование — фигня, поддержка — вот где весь гемор. Когда у каких-то уродов на противоположной стороне земного шара раз в неделю/месяц где-то что-то кривеет, и ты подозреваешь порчу памяти, и они уже истошно орут «FIX THIS ASAP!!!», а ты не можешь у себя это повторить, хоть убейся, то вот тут реально опускаются руки, и хочется послать всё это подальше, уволиться нахрен, и пусть кто угодно это чинит.
mad_god
05.10.2017 09:53+1Много раз пытался научиться самостоятельно и постоянно видел, что чего-то не хватает. Сначала широты взгляда (было очень мало информации). Затем не было системы, не знал, как и в каком порядке работать с информацией. Постоянно возникали пробелы то тут, то там, забывал, где закрыл пробелы, а где нет, забывал решения, не вёл учёт.
Даже поступил в универ, думал, там дадут понимание, как учиться.
Выучить синтаксис какого-то языка и уметь пользоваться гуглом — ещё не всё, как и какие-то знания об алгоритмах и математике, статистике.
Самого главного, как проектировать приложение, как систематизировать его части, какие части вообще должны быть и как их связать между собой, вообще почти нигде не говорится.
Интуитивно понятно, что писать всё в одном файле, классе, нельзя. Но книги обычно начинают и заканчивают одной простынёй кода, где в начале идёт одно, потом другое, потом главная функция, которая порождает классы, описанные выше, какой-то цикл обработки событий или класс, в котором куча отдельных обработчиков у отдельных объектов, и в каком проценте файла что находится, начинаешь быстро теряться.
Когда проект начинает разрастаться до миллиона строк и сотни файлов, один человек уже с трудом справляется, где что лежит и как за что отвечает.
Я начинал с процедурного кода, в котором всё шло линейно, оказалось, так писать очень сложно. Потом стал фанатом функций, всё оборачивал в функции. После понял, что нужно писать классы и методы. Но сложность возросла многократно. А без понимания, как нужно проектировать, программисту сложно реализоваться.
Возможно, зря я отчислился с третьего курса, но когда преподаватель даёт задание спроектировать какую-то систему под определённый функционал, я ожидаю, что нам хотя бы дадут минимальную теорию. Для этого я в универ и шёл.
Vlad_fox
05.10.2017 10:44+1Что касается необычайных преимуществ программирования, то вот они:
все перечисленные там преимущества относятся к любой человеческой деятельности — от вязания на спицах до инженерии
В реальной жизни не всё так идеально, как на учёбе
если у вас было все идеально на учебе — то это было просиживание штанов а не учеба.
полусамостоятельное освоение предмета во время учебы не сильно отличается от полусамостоятельного освоения нового языка программирования на работе.rustamaha Автор
05.10.2017 11:31если инженер сделал макет и по нему что-то построили, а потом пришлось перестроить, это может оказаться очень даже затратно.
guai
05.10.2017 12:01+2Программирование, в первую очередь, — интересно. Как можно так относиться к интересному занятию? «Ой, да оно сложное, ой, я не знаю, за что взяться, ой, меня не похвалили»
Делай, что интересно.
Потом подтяни скиллы, нужные для командной работы, — и вперед, можно зарабатывать деньги, делая то, что нравится.
saboteur_kiev
05.10.2017 12:51+1«Проблемы в коде в корне отличаются от проблем в физическом мире. Починить неисправный код можно одной лишь силой ума, в отличии от, например, сломанной машины, которая требует покупки дорогих запчастей. „
Совершенно несогласен. Сравнение неверное.
Сравнивается какой-то неисправный кусочек кода, который может исправить один программист, видимо в маленьком продукте, где кусок кода принадлежит именно этому проекту, с автомобилем, который является продуктом целого поколения, завода и различных мастеров.
Давайте сравним исправление кусочка кода и починку слегка изогнутого гвоздя, который собственно при небольшом владении руками можно и кривой забить без потери надежности сцепления.
Или сравним замену пробитой покрышки и исправление бага в коде, который связан с багой в проприетарном движке купленном за много денег, и который на самом деле связан с багом в платформе, на которой крутится этот движок. И посмотрим сколько инстанций нужно подключить чтобы устранить баг, или хотя бы найти адекватный воркэраунд.
Статья неплохая, но много сравнений идет в духе “простые проблемы в коде» и «сложные проблемы в реальном мире».Harr
05.10.2017 15:08+1Речь идёт, вероятно, не о сложности исправления проблем, а о характере деятельности. Какая бы по сложности ошибка в коде не встретилась, решить её можно будет только интеллектуально.
saboteur_kiev
05.10.2017 15:14+1Но ведь это не так?
У меня множество примеров, когда проблема интеллектуально легко решается, но требует множества денег на новое оборудование, на новые лицензии, на то, что нужно реорганизовать внутреннюю службу безопасности, то есть упирается в тоже, что и реальная жизнь — деньги и бюрократия.
Мы же обсуждаем не манкикодинг а полный цикл разработки?rustamaha Автор
05.10.2017 16:31но здесь эта метафора скорее приводится для новичков, которые только начинают изучать… хотя не знаю, посмотрите в оригинале, это самый первый ответ, может я неправильно перевел, или может у автора более точно описано
bro-dev
05.10.2017 17:02+1Имхо самое сложное это скачкообразное моральное подкрепление. Это значит что в любой деятельности есть что то типа прогресс бара, где сделал чуть чуть и видишь что 1% сделан и тебе приятно от этого и ты продолжаешь. В программировании при нахождении верного решения или места ошибки сразу же 100%, а до этого все твои миллион проб и неудач не принесли и 1%.
Эта причина почему область считается сложной чтобы пройти в ИТ нужно быть очень терпеливым, большинство просто не могут даже начать.
werevolff
05.10.2017 17:02-1Так, у меня без получаса полночь — время вампиров и программистов. Можно более объективно посмотреть на статью. Итак:
Примите факт, что компьютер всегда прав, а вы — нет
Ой, не факт! Десять минут назад MS Edge отказался выходить в интернет. Единственный браузер, который не смог. Он прав? Нет! А что насчёт third-party решений? Например, поповеры в четвёртом бутсрапе, которые отказываются работать, если им в заголовок передать int, даже если оно преобразовано в строку? Компьютер не всегда прав. Поэтому, мы можем делать форки недоработанных пакетов, либо присоединяться к их разработке и скидывать патчи.
Готовьтесь к худшим сценариям
Для этого есть тестировщики. По опыту могу сказать, что самая лажа начинается тогда, когда ты сидишь и пытаешься предусмотреть все линии поведения. В итоге, пишешь тонну ненужных валидаций и ограничений. Сперва пишем функционал, потом находим того, кто будет тестить, закрываем дыры, которые он обнаружил, и то не факт, что это нас спасёт от нестандартного поведения. В любом случае, есть паттерны, и если заказчик хочет, чтобы в его уникальном проекте была жопа, на которой в рамках капчи надо посчитать прыщи, пусть в неё и идёт.
Контроль за эмоциями
Да, пусть ваш мат в четыре утра слышат соседи! Потому что потом они услышат вашу новую аудиосистему, купленную с очередного транша!
Самостоятельность
Не совсем понимаю, как декомпозиция задач соотносится с самостоятельностью. Самостоятельность в программировании важна, но только в рамках пользования гуглом. На самом-деле, опытные программисты не любят, когда новички пристают к ним с вопросами, и им выгодно говорить о самостоятельности. Нифига это не так. Надо включить дурака и доканывать профи на форумах, выясняя как сделать задачу и как работает та функция, что применил профи.
Невозможно всё знать
И не надо: в голове надо держать только то, что нужно для решения текущих задач. Об этом ещё Конан Дойл писал. Но вот если у вас заказ на допилку JS интерфейса, а вы решили подучить трюки на Nginx'е, то у вас проблемы! Бросайте эту затею и возвращайтесь к JS. И лучше-всего — к поставленной задаче. Аналогично, если вам нужно повесить событие на кнопку, и в своих поисках вы дошли до принципа заполнения памяти JS кодом, вы пошли явно не туда. Если задача не решается простыми средствами, нужно её разбить на подзадачи, либо изменить формулировку.
В реальной жизни не всё так идеально, как на учёбе
Поэтому, бросайте заниматься ерундой и, пока учитесь, берите коммерческий проект в разработку. То, что не приносит никакого дохода, кроме стипендии, в реальных условиях будет забыто за несколько дней.
Балансирование между теорией и практикой
Во-первых, надо начать. А именно, найти самые простые материалы для начала работы. Простейшую статью по тому же WordPress. Сразу поставить LAMPP, сделать Hello World, задуматься над тем, как сохранить это приветствие в базе, перелопатить сотню сайтов, обнаружить, что монга и PostgreSQL не совсем подходят для решения поставленной задачи, вернуться к первому варианту, реализовать на третий день задумку и т.д.
Проблема программирования в том, что здесь нельзя сначала изучать, а потом внезапно сделать. Нужно начать делать, и когда не получится, начать изучать. Теория в начале не даёт понимания этого неповторимого чувства — извлечения кролика из шляпы. Т.е. ощущения создания чего-то из ничего. Сперва нужно осознать ту пустоту, с которой работаешь. Новичок будет думать, что для программирования уже есть своя инфраструктура: достаточно сказать пару слов, и процессор преобразует их в чудесный алгоритм. Либо, достаточно подвигать мышкой, и компьютер научится понимать этот жест и создаст логику. Это не так. Мы работаем всегда с чистым листом. Даже если это — чистый лист внутри фреймворка.Fesor
05.10.2017 18:56+1Компьютер не всегда прав.
комьютер делает то что ему сказали разработчики. Да, существуют баги на уровне железа но это можно воспринимать как те же сторонние библиотеки. Ну и подобными ошибками в большинстве своем можно пренебречь. А вот ошибки которые люди совершают — это естественный ход вещей.
Для этого есть тестировщики.
Да, это же так удобно перекладывать ответственность на других. При том что пофиксить то они не смогут. И многие баги даже не смогут найти просто потому что для этого нужно хорошо понимать нюансы технической реализации, а для проявления других нужно немало времени.
У большинства разработчиков очень плохо с анализом и управлением рисками. Кто-то просто забивает, а другие стараются минимизировать риски вместо того что бы минимизировать затраты на устранение последствий (то есть часто дешевле быстрее проблему задетектить и пофиксить нежели пытаться предугадать все )
Нифига это не так. Надо включить дурака и доканывать профи на форумах, выясняя как сделать задачу и как работает та функция, что применил профи.
Подобное стимулирует лень. И в итоге вы получите разработчика который при малейшей сложности не лезет разбираться, а сразу пихает свои вопросы и ожидает решения. Это не добавляет понимания и не даст человеку самостоятельно решить задачу.
берите коммерческий проект в разработку.
Что происходит когда новичек который только-только начинает учиться берет коммерческий проект. Вопервых чаще всего он не в состоянии его сделать и потому будет пытаться "на форумах" добиться от более опытных как же это все сделать. Поскольку обучение и работа будут отнимать у начинающего огромное количество времени, и поскольку проект коммерческий, дедлайны резко выбьют из разработчика всякое желание разбираться и он будет делать "абы работало".
Как итог — скорее всего проект будет зафэйлен, клиент недоволен, а разработчик получит лишь долю опыта которую мог бы получить напиши он некоммерческий проект например.
werevolff
05.10.2017 19:16+1Я не говорил, что не нужно доверять машине. В контексте статьи указаны «компьютер или программа». Вот программе не всегда нужно доверять. Но для тех, кто начинает, разумеется, нужно переломить себя. Многие ошибки, действительно, возникают по вине того, кто грешит на систему. Но это в начале пути — не тогда, когда человек покрывает тестами код, рефакторит без напоминания или дебажит несколько раз прежде, чем объявить о системной ошибке. В любом случае, нужно понимать грань между срывом на систему и бездумным доверием к окружению и железу. И, разумеется, разработчик должен учиться доверять себе. Истории о программерах, которые удивляются коду, заработавшему с первого раза — всего-лишь истории.
Что касается тестировщиков, то никогда ни один программист не сможет своим замыленным глазом предусмотреть все варианты использования конечным потребителем. Если только он не работает с одной кнопкой «ОК», и то не факт, что пользователь воспользуется ей правильно. Но, согласитесь, что разработчик не будет сидеть и писать обработчик множественных нажатий на эту кнопку. В большинстве случаев, он не сделает даже disabled статуса на кнопке после первого нажатия. По одной простой причине: сперва надо повешать на неё события, а потом уже применить все знакомые ему методы защиты. Но, опять же, если он будет ещё неделю перехватывать все кейпрессы и нажатие на кнопку из консоли, то он дурак. Сперва делается функционал, потом реализуются стандартные паттерны защиты. Если нужно что-то ещё, пусть заказчик ищет тестировщика или доплачивает разработчику за пользовательское тестирование. Что значит «перекладывать ответственность»? Тестирование интерфейса — это такая же оплачиваемая работа. И, кстати, в ней тоже есть свои методики и средства автоматизации. Если программист с ними не знаком, он не обязан проводить эти действия. Только хуже сделает.
Со стимулированием лени почти согласен. Почти — потому что я указал, что нужно не просто искать готовое решение, но и требовать объяснить принцип его работы. В любом случае, человек без наставлений и без поиска готовых решений повышать уровень не сможет. Я знаю много молодых людей, которые стесняются требовать от наставников информацию. Знаю людей, которым это не интересно. При этом, они прекрасно пользуются гуглом и годами сидят в маркетинговых фирмах. Сайт-визитка за 8 000, магазин — за 20 000, первая цифра — их белая зарплата, вторая — то, что они сверху получают в конверте. Скрипты они писать могут. Не программы.
Стажировка в коммерческих проектах приносит человеку больше пользы, чем разработка собственных CMS и ORM. Почти каждый с этого начинает. Но именно работа над коммерческим проектом, хотя бы стажёром, даёт опыт получения прибыли и развития нужных навыков. Никто не говорит о том, что новичок должен лезть в крутые проекты. Достаточно сделать за пару тысяч знакомой фирме сайт-визитку или прибиться стажёром в какую-нибудь команду.Fesor
05.10.2017 19:46не сможет своим замыленным глазом предусмотреть все варианты использования конечным потребителем.
Потому есть сказ о "трех амиго", dev + qa + product owner. Из того как вы это подаете создается ощущение что качество это целиком и полностью обязанность QA и разработчику об этом думать не стоит. Вопрос же в командной работе, когда разработчик смотрит с технической стороны вопроса, а QA с позиции пользователя. Да, без QA никуда, но хороший разработчик обязан уметь придумывать тест кейсы. Что до замыленнсти — если генерить тест кейсы на чужую часть работы — то выходит лучше. Что до автоматизации, то тут еще больше стирается грань между чисто dev и чисто qa.
Ну и еще ремарка про пограничные/негативные кейсы. Не стоит еще забывать про приоритизацию багов. На многие баги можно просто закрыть глаза в силу того, какой эффект они вызывают. Фиксить все не эффективно с экономической точки зрения.
чем разработка собственных CMS и ORM
я где-то что-то говорил про свои CMS/ORM?
Но именно работа над коммерческим проектом, хотя бы стажёром
тогда уточняйте что речь идет о работе в команде.
werevolff
05.10.2017 19:50Я вам никак не подаю. Подавать — обязанность официанта. Я вам говорю, что разработчик применяет знакомые ему паттерны защиты, либо добавляет защиту после пользовательского тестирования, либо по факту обнаружения проблемы. Или вы будете спорить с тем, что программист, который отрабатывает юзкейсы вместо реализации функционала — хреновый специалист?
werevolff
05.10.2017 20:03По работе в команде я и уточнил. При этом, правда, человек может иметь свой коммерческий проект. Он может быть поделкой на коленке, но приносить доход. Это тоже плюс.
В области автоматизации пользовательского тестирования, действительно, QA выходит на уровень скриптов. Но разработчик — хороший разработчик — никогда даже додуматься не сможет о некоторых вариантах использования. А вообще, нужно чётко разделять разработку на готовых шаблонах и командную разработку. Допустим, мы говорим о Web. Есть CMS, которые уже имеют в реализации часть защиты, как и расширения для них. Этого достаточно для того, чтобы один специалист смог написать и продать проект на этой CMS. Он не будет заморачиваться дополнительной защитой до момента возникновения бага. Есть разработка в команде, когда наличие пользовательского тестирования — обязательно. Это не означает, что в команде есть QA, но тестирование может проводить менеджер. Это обязательное условие, поскольку программист почти никогда не производит таких тестов. Как-правило, в командах без QA есть список известных багов, которые проверяются вручную перед релизом.
А теперь, внимание, всё выше изложенное — о коммерческой разработке. Отсюда следует простой вывод, что новичок не получит этого опыта вне коммерческой разработки. И отсюда же следует вывод, что он не обязан работать в команде. Он может делать проекты на CMS. Но, допустим, человек не делает ничего на CMS. Он пишет свои велосипеды. И смысла проверять качество этих велосипедов у него нет. Они не поедут, и денег за них он не получит. Одно вытекает из другого: нужно изучать готовые паттерны защиты от непредсказуемых действий. Не обязательно знать как поведёт себя пользователь. Достаточно знать, что надо вот тут сделать кнопку disabled после первого нажатия, а там применить ORM с экранированием спецсимволов, вместо прямого обращения к базе. Либо работать в команде, но там точно так же наставник скажет: «после нажатия замьють кнопку» или «нафиг ты делаешь коннект к мускулу? Мы используем эту ORM. Зачем? Чтобы не писать лишний код и не заботиться об эскейпе символов при защите от инъекций».
werevolff
05.10.2017 19:29Опять же, я знаю молодых людей, которые сразу после стажировки в небольших студиях начинали писать свои проекты. И сейчас проекты приносят доход. Хотя бы небольшой, но они полностью соответствуют коммерческому уровню: они имеют перспективы для получения грантов, привлечения инвесторов, либо подходят под стандартные схемы монетизации.
И я же видел молодых людей, которые приходили стажироваться и всё время кидали понты в духе: «да я написал плеер на дельфях». Или «У меня свой сайт — крутой». В итоге, когда они косячат, проверяются предметы их гордости, и оказывается, что плеер не работает, а сайт сделан на юкозе без изменения в коде и шаблонах — слишком сложно было залезть в код. А особый смак — когда оказывается, что поделка была курсовой работой, и человек за нерабочий продукт получил отличную оценку.
Разумеется, я выступаю за стажировку, за создание собственных коммерческих проектов и за активное участие молодых программистов в профессиональной разработке. Разумеется, последнее должно быть только в формате простой работы, рутины и т.д. В любом случае, это колоссальный опыт командной работы, опыт работы в различных методологиях организации процесса, опыт работы с контролем версий, опыт тестирования, опыт отчётности и первичные знания маркетинга в IT сфере.
senglory
05.10.2017 20:57+1а разработчик получит лишь долю опыта которую мог бы получить напиши он некоммерческий проект например.
Некоммерммерческий проект, в первую очередь — это отсутствие лица, заинтересованного в результате. Т.е. это возможность девелоперу с заумным видом ковырять в носу и пытаться разродиться никому на. не нужными фантазиями и идеями в стиле «что бы такое еще залепить чтобы круто было». Вы действительно считаете, что такая графомания может дать что-то более позитивное к продаваемому опыту чем умение выполнять в срок реальные поставленные задачи?rustamaha Автор
05.10.2017 23:55после «Атлант расправил плечи» я стал более критично относиться к «волонтерству», зачастую это и правда безответственность и ковыряние в носу. Быть оплачиваемым профи круче, и они же кстати если и делают что-то на общественных началах — это бывает хитом.
kubrakov
06.10.2017 07:52+1Починить неисправный код можно одной лишь силой ума, в отличии от, например, сломанной машины, которая требует покупки дорогих запчастей.
Едва ли это применимо к крупным проектам, где ошибка может потребовать оплаты дорогих человеко-часовrustamaha Автор
06.10.2017 07:53+1Да. Изначально статья была в разделе «обучение IT», она скорее на новичков рассчитана, и в их случае имеется ввиду наверное обучающие задачи… хотя хз) но звучит почти складно)
VladimirViatkov
06.10.2017 20:03-2Ребята, программисты, кто бы мог помочь с написанием интернет-магазина для сайта люстр, а то у нас только корпоративный/официальный сайт фирмы: www.lustry-gus.ru или подсказал бы как прикрутить карточки товаров, используем html, сайт писался в блокноте криворуким программистом, который так и не довел работу до конца.
PravdorubMSK
08.10.2017 12:59+1Эффект Даннинга-Крюгера сопровождает меня всю жизнь. И я очень злюсь, когда встречаю людей на первой стадии, т.е. слишком самоуверенных. Сейчас это всякие «сеньйоры» и «тимлиды», которые после пару лет входа в IT уже считают себя чуть ли не элитой разработки.
AlexZaharow
Простите, но программирование — это всегда чертовски сложно. Если вам удалось что-то легко написать, то только потому что вас обманула IDE.
А так, главное в программирование такое же как и везде — четкое видение результата. Если оно есть, то код пишется легко и свободно, если программирование идёт с трудом, то значит либо цель поставлена плохо, либо это не ваше.
Emulyator
Получается, если программирование "всегда чертовски сложно", то оно всегда «идёт с трудом» по определению, не зависимо от «видений»? )
Иногда сталкивался с ситуациями когда результат ясен, но достижение результата дается тяжело, хотя бы по причине необходимости освоить новую, не очень простую предметную область.
AlexZaharow
Тут нет противоречия, объясню иначе. Вот есть проблема, вам она кажется трудной, если не невозможной. Но вот если вас о решении попросит девушка, которая вам нравится, то задача вдруг становится вполне решаемой. Просто девушка придаёт вам сил. Даже если трудно.
Поэтому, если программирование при решении задачи придаёт вам сил, значит это ваше, если отнимает силы — значит не ваше.
P.S.
Девушка вымышленная и вы не позволяете ей собой манипулировать.
kxl
минус, пожалуй, за p.s.? А то, что вы описали — это мотивация…
rule
Ну программирование не особо от других специализаций отличается. И доктор и программист и космонавт и биохимик — все люди. И к сожалению большинство даже самой интересной работы — рутина. Программирование давно ушло из разряда исследований в обычное ремесло. R&D проектами не многие занимаются. Так что программирование — это по большей части рутина.
kxl
Кодинг-вот может быть и рутина, да и то где этот процесс поставлен на конвейер. А так, если устали — смените направление. Если вы фронт, то попробуйте bigdata, и наоборот.
rule
ну я же не говорил что рутина невыносима, я говорю что практически любая проф. деятельность — это рутина. А рутина не может быть сложной по определению, она монотонная и утомительная.
Danik-ik
Рутиной было бы сферическое программирование в вакууме. Положение спасают программисты. Они привносят первозданный хвос в этот процесс, делая его нескучным вплоть до адреналиновой интоксикации.
А какой весёлый/нескучный/ужасный код они пишут! Особенно этот подлец, Я-вчерашний.
n0str0m0
Я думаю, рутина не будет столь удручать, если ты занимаешься своим проектом и реализовываешь какие-либо свои цели.
evgenWebm
Категорически не согласен.
Программирование не сложная вещь. Абсолютно!
Сложно на Марс полететь. 50% полетов неудачные.
Сложно от ВИЧ вылечится. Высокая смертность.
Сложно ребенка аутиста вырастить.
Программировать не сложно.
Хотя задачи сложные бывают. Но когда мы летим на Марс, сложность зависит от многих факторов, на которые мы не влияем и часто даже незнаем. В итоге получаем 50% крушений.
Вот это сложно.
А в программировании, сегодня сложная задача, завтра решается в 10 минут написание кода.
Это не сложность.