Комментарии 111
Любой минус можно превратить в плюс. Решать проблемы увлекательно, а решать их в фоне чертовски круто. Если вы программист, то вы столкнувшись с проблемой можете, изучить материалы по теме и пойти пить чай или играть в игру или выпить пива, вернувшись вы как правило будете знать решение своей проблемы. Если вы например работаете грузчиком, то столкнувшись с проблемой вы не сожмите ее решить выпив пива с друзьями.
Плюсую за все предложения в абзаце кроме последнего.
О как же вы не правы… ;-)
Если вы например работаете грузчиком, то столкнувшись с проблемой вы не сожмите ее решить выпив пива с друзьями.
О как же вы не правы… ;-)
Ну надо понимать, что для этого надо обладать серьезной внутренней дисциплиной, это работает не всегда и сразу оно так получаться не будет. Иначе бы у студентов дипломные проекты, а у аспирантов диссертации придумывались за игрой в доту. Я так понимаю, данная статья все же больше общеобразовательная для новичков.
Дело даже не в дисциплине, а в концентрации на проблеме, подсознание должно желать решить проблему, я не знаю как добиться этого, кроме как действительно желать. Конечно, я не утверждаю, что можно запустить игру/налить пива, а программа сама напишется и протестируется, над этим нужно работать и работать много, но перевести задачу в фон частенько бывает довольно полезно.
Программа это то, что преобразует исходные данные в результат.
Я бы сказал, что программа — это то, что решает проблему своего пользователя, человека или другой программы. Как писал Котлер, «Человек, который покупает у вас перфоратор — на самом деле покупает не перфоратор, а дырку в стене в нужном для него месте и в удобное для него время». Можно написать идеальную и никому не нужную программу программу. Соответственно, в условия я бы добаил еще ожидания пользователей и корректность поставленной задачи этим ожиданиям. Зачастую про пользователей программисты и думать не думают (простите за каламбур), и в итоге наши устройства заполнены приложениями, несущими боль и страдания.
Я бы сказал, что программа — это то, что решает проблему своего пользователя, человека или другой программы
Нет, программа решает проблему именно программиста. Проблему создания готового продукта.
Как писал Котлер, «Человек, который покупает у вас перфоратор — на самом деле покупает не перфоратор, а дырку в стене в нужном для него месте и в удобное для него время».
Все верно, а пользователь покупает приложение (и функции, которые оно даст), а не программу.
Да понятно, что задача программиста — писать хороший код в нужные сроки и т.п., но программист, который не думает о том, что находится за пределами его зоны ответственности, так и будет всю жизнь писать код по спецификации сверху. Мне кажется, при обучении программистов их нужно обязательно приучать к тому, зачем нужен их код, и как он будет использоваться.
что находится за пределами его зоны ответственности, так и будет всю жизнь писать код по спецификации сверху
А что еще программист должен делать? Или вы про карьеру до генерального директора собственного стартапа?
Ну Вы так говорите, как будто задача программиста — это только писать код. Вот тут в конце поста есть ссылка с примерным списком компетенций, предъявляемых к профессии «программист».
Программист прежде всего должен понять спецификацию, а иногда задать уточняющие вопросы. А затем написать хороший код и в нужные сроки. А иначе он не программист, а кодировщик.
Как писал Котлер, «Человек, который покупает у вас перфоратор — на самом деле покупает не перфоратор, а дырку в стене в нужном для него месте и в удобное для него время».
Ерунду писал ваш Котлер. Дырку в стене можно просверлить любым перфоратором, однако их продается over дофига моделей и каждая находит покупателя. В конце концов, для того, чтобы насверлить дырок, и повесить, например, карниз, достаточно вызвать специально обученного человека, который денег возьмет сильно меньше стоимости перфоратора. И хранить потом этот
Можно написать идеальную и никому не нужную программу программу.
Сегодняшние реалии таковы, что большинство существующих потребностей так или иначе удовлетворены и маркетологи выпрыгивают из штанов, чтобы придумать новые потребности и удовлетворить их. Ведь если разобраться, никаких особых преимуществ и 6 айфона ни перед 5 ни перед 4 нет. И речь не только про эппл. «Ну а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место нужно бежать вдвое быстрее.» Поэтому трата огромного количества ресурсов, человеческого труда и т.д. по сути спускаются в унитаз ради сохранения статус-кво, как бы это обидно не звучало.
Дырку в стене можно просверлить любым перфоратором, однако их продается over дофига моделей и каждая находит покупателя.
Ну так давайте представим воображаемый мир, где можно купить дырок в стене. Человек стоит перед выбором — купить набор дырок (по аналогии, например, с винтами разных размером и диаметров) и устанавливать их в стены при необходимости, или купить инструмент, который надо будет таскать за собой и использовать каждый раз, когда возникнет потребность в дырке. И что он выберет, зависит от того, какую свою проблему он хочет решить. Если ему нравится строительство, он, конечно, купит перфоратор, но просто потому, что не «получить удовлетворение от строительства» в магазине не продается.
Смысл цитаты был в том, что никто никогда не покупает что-то ради самой вещи, вещи выбирают, чтобы минимизировать усилия и ресурсы для достижения какого-то результата. Тот же айфон 6 покупается не для того, чтобы получить какую-то дополнительную функциональность, это уже давно элемент имиджа и статусности. Перефразируя цитату, «если бы человек мог напрямую купить +100 понтов, он бы напрямую купил понты и не покупал у вас айфон». Так что айфон — такой же инструмент для достижения цели, как и все остальное. В эту же категорию попадают и другие вещи, которые покупают просто потому, что могут.
Ну так давайте представим воображаемый мир, где можно купить дырок в стене.
Зачем представлять что-то воображаемое? Это наш мир. Дырки в стене вполне себе продаются, спуститесь к доске объявлений у своего подъезда или возьмите любую газетенку бесплатную у метро или в почтовом ящике (если к вам в подъезд ходят разносчики бумажного спама). Искать ключевые слова «муж на час». Однако перфораторы все еще продаются, причем, обычным гражданам, профессионально строительством не занимающимся.
Тот же айфон 6 покупается не для того, чтобы получить какую-то дополнительную функциональность, это уже давно элемент имиджа и статусности.
Я именно об этом речь и веду. Создана новая потребность. Бедным и нищим людям (только не обижайтесь на формулировку, это не с целью кого-то оскорбить, я сам себя к бедным отношу) внушили, что у них тоже может быть «элемент статусности», пусть и жрать, порой, нечего. Хотя, как может быть «элементом статусности» массовый продукт стоимостью в $1000 я решительно не понимаю. Элемент статусности — это подлинник Дали или тот же айфон, но в бриллиантах или часы, выпущенные ограниченной серией в 1000 экземплярах и т.д., т.е. нечто «эксклюзивное» и недоступное большинству, но никак не ширпотреб.
Сам по себе смартфон — очень удобная и полезная штука, которая решает реальные потребности… 20% владельцев. А 80% владельцев спустили ресурсы в унитаз (и используют только звонки и смс), т.к. это «стильно, модно, молодежно». Об этом я и пишу.
По вашему, каждый раз, когда мне нужна отвёртка или дрель или молоток, я должен куда-то там звонить, впадать в зависимость от какого-то человека, который неизвестно когда придёт, неизвестно как сделает и каждый раз это будет рандомный уровень
если же я купил себе инструмент, я ни от кого не завишу ни в плане времени, ни в плане качества, плюс я сам со своей же работы набираю экспы и каждый следующий раз делаю правильнее, что может быть выгоднее этого?
если же я купил себе инструмент, я ни от кого не завишу ни в плане времени, ни в плане качества, плюс я сам со своей же работы набираю экспы и каждый следующий раз делаю правильнее, что может быть выгоднее этого?
Ну, т.е. вам тоже не только дырка нужна, как нас тут уверяли ранее?
Нет, именно что
Ключевое слово здесь не только дырка, а еще и в удобное время и в нужном месте. Еще можно дописать — с минимальным повреждением окружающего.
Сегодня мне нужно дырку дома, завтра на работе, послезавтра на даче, а в воскресенье в гараже.
Способов получить всё это бысто и с нужным качеством исполнения, не покупая дрель или перфоратор, я не знаю.
дырку в стене в нужном для него месте и в удобное для него время
Ключевое слово здесь не только дырка, а еще и в удобное время и в нужном месте. Еще можно дописать — с минимальным повреждением окружающего.
Сегодня мне нужно дырку дома, завтра на работе, послезавтра на даче, а в воскресенье в гараже.
Способов получить всё это бысто и с нужным качеством исполнения, не покупая дрель или перфоратор, я не знаю.
ну так а если бы дырки продавались в магазине на вес, переносились в обычном кармане и «вставлялись» в стену как-то очень просто, например, приклеиванием, Вы бы покупали именно дырки, а не перфоратор, правда?
Хлеб продается в любом магазине. Какой хочешь сегодня можно купить. А у меня дома хлебопечка.
Ну потому что Вы этот хлеб как-то так делаете, видимо, что в магазине такой не продают. Вы предлагаете каждому писать софт под себя? :) Мы именно про софт говорили изначально.
Ну потому что Вы этот хлеб как-то так делаете, видимо, что в магазине такой не продают.
Продают. У меня гипермаркет с пекарней в 250 метрах от дома, он работает c 8 утра до 2 ночи. Проблемы купить какой угодно хлеб у меня нет. Но я хочу хлебопечку, а вы мне с Котлером усиленно пытаетесь хлеб продать.
Вы предлагаете каждому писать софт под себя?
Нет, я лишь сказал, что вы процитировали ерунду.
Но я хочу хлебопечку, а вы мне с Котлером усиленно пытаетесь хлеб продать.
Так Вы можете внятно сказать, зачем Вам хлебопечка? Она хлеб печет вкуснее или просто потому что хочу/люблю делать сам?
Так Вы можете внятно сказать, зачем Вам хлебопечка?
Вот видите, вы даже не понимаете моих потребностей, но уже утверждаете, что знаете, как их удовлетворить. Но, на самом деле, это неважно. Важны 3 вещи:
1. Я могу купить вкусный, устраивающий меня хлеб рядом с домом в любое время, когда я активен.
2. В магазин сходить 15 минут, печка печет 2-4 часа, у меня нет проблем со здоровьем, мешающих мне передвигаться по городу.
3. Я купил хлебопечку и пользуюсь ей, последний раз хлеб в магазине домой покупал 2 года назад.
Отсюда легко можно сделать вывод, что покупая хлебопечку я покупал не (только) хлеб и ваш Котлер не прав. Sapienti sat.
И самая большая беда, для меня, например, в том, что маркетологи этой ерундой засрали мозги производителям. Вместо хлебопечки они продают хлеб и найти печку с возможностью программирования ее как тебе нужно, а не как решил маркетолог, нереально. Либо ешь, что дают, либо сделай сам. Поэтому в сети полно рецептов типа: «для того чтобы сделать этот кекс, выберите программу для дефлопе, т.к. программа для кекса вам не подойдет». Поэтому в айфонах нет слотов для карт памяти, ешь, что дают, маркетолог подумал за тебя и решил, что тебе это не нужно. Ну и т.д.
Отсюда легко можно сделать вывод, что покупая хлебопечку я покупал не (только) хлеб и ваш Котлер не прав.
Вы так и не ответили на вопрос, который процитировали.
Стоимость хлеба получается как в магазине, или сильно дешевле? Какой период окупаемости хлебопечки?
Имхо некорректный вопрос т.к. рецептура изделия разная, в этом плюс хлебопечки — хлеб по индивидуальным пожеланиям.
А дешевле не выйдет — хлебозавод это опт и субсидирование государством некоторых видов хлеба.
А дешевле не выйдет — хлебозавод это опт и субсидирование государством некоторых видов хлеба.
Суть моих вопросов в том была, что хлеб — это лишь один из продуктов работы хлебопечки. Их целая куча: например, удовольствие от сделанного своими руками, независимость от супермаркета, индивидуальные предпочтения в сортах, коммерческая выгода, да или просто, простите, понты. И печку покупают, чтобы удовлетворить одну или несколько из этих целей, а не как «вещь в себе».
Я как-то не интересовался этим вопросом, стоимость меня меньше всего волновала.
Самй простой хлеб, это 500г муки, столовая ложка сахара, столовая ложка масла подсолнечного, чайная ложка соли и пакетик дрожжей. Вода бесплатная. Несмотря на простоту рецепта, получается очень вкусно. Стоимость продуктов можете прикинуть сами. Электроэнергии съест примерно 1 кВт⋅ч за выпечку.
Ну и печка, это не толькоценный мех хлеб, но и всякие куличи, кексы, тесто и даже варенье.
Самй простой хлеб, это 500г муки, столовая ложка сахара, столовая ложка масла подсолнечного, чайная ложка соли и пакетик дрожжей. Вода бесплатная. Несмотря на простоту рецепта, получается очень вкусно. Стоимость продуктов можете прикинуть сами. Электроэнергии съест примерно 1 кВт⋅ч за выпечку.
Ну и печка, это не только
А сейчас ответ будет и на тот случай, если это в буквальном смысле было сказано, и на тот, елси это метафора.
Хлебопечку не из-за окупаемости берут, имхо. Когда-то давным-давно в 90-е, мать пекла хлеб сама, в духовке, и это было дёшево и окупаться начало сразу же. Хлебопечка сейчас — это возможность начать печь хлеб быстро и без длительной подготовки.
Хлеб при этом получается такой, как задумал хлебопёк. Условно говоря, в нём не будет лишних консервантов, усилителей вкуса, ногтей пекаря, мышиных фекалий. Да, в обычном хлебе тоже нет усилителей вкуса (дорого), ногтей пекаря (ну, во всяком случае, мне никогда не попадались, хотя такие страшилки я слышал) или тем более мышиных фекалий. Если надо, это будет безглютеновый хлеб из нутовой муки, если надо — это будет французский круассан, или сырный хлеб, или бог знает что ещё.
Хлебопечка — это возможность выбора (и подгонки под свои требования) без грандиозных затрат по времени и сложной кривой обучения.
Хлебопечку не из-за окупаемости берут, имхо. Когда-то давным-давно в 90-е, мать пекла хлеб сама, в духовке, и это было дёшево и окупаться начало сразу же. Хлебопечка сейчас — это возможность начать печь хлеб быстро и без длительной подготовки.
Хлеб при этом получается такой, как задумал хлебопёк. Условно говоря, в нём не будет лишних консервантов, усилителей вкуса, ногтей пекаря, мышиных фекалий. Да, в обычном хлебе тоже нет усилителей вкуса (дорого), ногтей пекаря (ну, во всяком случае, мне никогда не попадались, хотя такие страшилки я слышал) или тем более мышиных фекалий. Если надо, это будет безглютеновый хлеб из нутовой муки, если надо — это будет французский круассан, или сырный хлеб, или бог знает что ещё.
Хлебопечка — это возможность выбора (и подгонки под свои требования) без грандиозных затрат по времени и сложной кривой обучения.
Вы занимаетесь схоластикой, как и упомянутый выше Котлер. Способов сделать дырку я вам уже привел. Тот же перфоратор можно одолжить у товарища или взять в аренду. Однако их покупают. И, что самое главное, покупают 100500 разных моделей и спорят, какой лучше. А дырку можно любым просверлить.
Можно продолжить и выяснить, что деньги, в общем-то, тоже никому не нужны. Всем нужны товары и услуги, которые на них можно купить. Аналогично с сексом, для удовольствия монтируем электрод в мозг, а для продолжения рода используем ЭКО. Ну и т.д.
Можно продолжить и выяснить, что деньги, в общем-то, тоже никому не нужны. Всем нужны товары и услуги, которые на них можно купить. Аналогично с сексом, для удовольствия монтируем электрод в мозг, а для продолжения рода используем ЭКО. Ну и т.д.
Можно продолжить и выяснить, что деньги, в общем-то, тоже никому не нужны.
Так оно и есть, в общем-то, если смотреть широко. :) Про это долго можно спорить, но оригинальная мысль была в том, что софт должен решать какую-то проблему, и когда программист об этом думает при разработке, софт получается лучше.
Так оно и есть, в общем-то, если смотреть широко.
Да, но, как говорят, дъявол в деталях. Знаете анекдот про то, что «теоретически мы миллионеры, а практически в семье...»?
Про это долго можно спорить, но оригинальная мысль была в том, что софт должен решать какую-то проблему, и когда программист об этом думает при разработке, софт получается лучше.
Я с этим не спорю. Я люшь отметил 2 вещи:
1. Сегодняшние маркетологи сначала создают «проблему», а потом ее решают.
2. Не нужно цитировать ерунду, даже если ее сказал известный человек ;)
1. Сегодняшние маркетологи сначала создают «проблему», а потом ее решают.
Так а Вас кто заставляет покупать софт, который лично Ваших никаких проблем не решает?
2. Не нужно цитировать ерунду, даже если ее сказал известный человек
Вы, видимо, совсем не поняли, что он сказал.
Меня? Вы, видимо, совсем не поняли, что я до вас пытаюсь донести.
Не понял, да. Я говорил про то, что софт никогда не покупают просто так, а только чтобы решить какую-то свою задачу, которую без этого софта либо решать слишком долго, либо не решить вообще. А Вы мне про то, что люди покупают хлебопечки. Покупают, да, тоже чтобы решить какую-то задачу. Где я не прав?
Не правы вы в том, что вместе с Котлером всегда предлагаете продавать результат (дырку). А я вам тут пытаюсь втолковать, что иногда людям нужен инструмент (перфоратор).
Зачем людям инструмент, если не для решения задач? Причем необязательно тех, для которых инструмент задумывался. К слову, коллекционирование перфораторов — тоже вполне себе задача, которую купленный перфоратор успешно решает.
Решает, но он не был для этого предназначен производителем. Это проблема, которая есть у потребителя и о которой производитель ничего не знает.
Если бы продавались дырки, а не перфоратор, то коллекционер перфораторов был бы в пролете, потому что производитель банально не знает, что перфораторы коллекционируют и что они нужны людям не только для дырок.
Если бы продавались дырки, а не перфоратор, то коллекционер перфораторов был бы в пролете, потому что производитель банально не знает, что перфораторы коллекционируют и что они нужны людям не только для дырок.
О да, это ещё одна из сложностей программиста — быть психологом и провидцем, чтобы угадать, какие интерфейсы придутся его пользователям по вкусу.
Извините, я увидел в картинке нечто иное:
Что немцу хорошо, то русскому — смерть. Это мое мнение по содержанию перевода.
В современных условиях я советую 4 принципа работы программистом в РФ
Перевожу последний пункт на язык попроще —
Никогда не говори
Все советы — для проектов, не нужных будущему. А таких — 90 процентов.
И самое главное.
В современных условиях я советую 4 принципа работы программистом в РФ
- Будь всегда администратором репозитория — иначе потеряешь работу
- Пиши так, чтобы читать код мог только ты — иначе потеряешь работу
- Оставляй всегда пару косяков — иначе потеряешь работу
- Минимальная единица планирования — неделя — иначе потеряешь работу
Перевожу последний пункт на язык попроще —
Никогда не говори
Тут работы на два часа
Все советы — для проектов, не нужных будущему. А таких — 90 процентов.
И самое главное.
Я программирую, потому что программируюПортос
Отличный саркастический коммент, жаль, что заминусовали :)
Но, пожалуйста, поясните пункт насчёт репозитория.
Но, пожалуйста, поясните пункт насчёт репозитория.
Я так полагаю, чтобы пресекать попытки присваивания другими твоих заслуг.
Вот вы смеётесь, но особенности ведения бизнеса в России никуда не поменялись и от них не сбежишь, будь ты хоть трижды системный архитектор или разработчик глубокого бэкенда. У нас вот в прошлом году проект отжали, вместе с контрактами и доступом к боевым серверам. У заказчика поменялась власть, готовый проект передали своим подрядчикам на поддержку — политика… (Дорабатывать? Зачем дорабатывать? Это ж трудиться надо… И что, что баги и фич не хватает?) Единственное, что у нас осталось — репозитории с исходным кодом. Потому что они были у нас :-)
— Пиши так, чтобы читать код мог только ты
— Оставляй всегда пару косяков
— Минимальная единица планирования — неделя
Вот слова не мальчика, но мужа.
— Оставляй всегда пару косяков
— Минимальная единица планирования — неделя
Вот слова не мальчика, но мужа.
НЛО прилетело и опубликовало эту надпись здесь
Программирование стало сложным сразу после того, как во главу угла были поставлены интересы серости. Пока программа вычисляла параметры ядерной реакции — программирование было удовлетворительно легким. Но с момента, когда результаты стало необходимо представлять в 32-битном 3D-изображении в реальном времени — программисты стали быстро седеть (некоторые — толстеть), потому что программы стали обрастать огромным наслоением «лишнего», тербующего постоянного обновления, поддержки, рефакторинга и т.п.
Содержание подменяется оболочкой. Посмотрите на статьи на хабре —почти все они многие из них посвящены новым интерфейсам с пользователем: все эти кнопочки, иконочки, картиночки и т.п. рендеринги. Я не отрицаю, что есть области, где визуальный и звуковой интерфейс имеет первостепенную важность, но не все же аспекты деятельности человека!
Конечно, когда вместо химической формулы, понятной только химику, программа выдает 3D изображение молекулы — это существенно усложняет жизнь программисту, но никак не облегчает жизнь химику и тем более не делает результат понятнее для профана. Зато картинка производит впечатление на инвесторов, менеджеров, покупателей и просто зевак (создающих сайтам ТИЦ, PR и другие «лайки») — соответственно возникают требования сделать в следующий раз «еще красивее, еще нагляднее, еще удобнее»… А это влечет разработку новых «инструментов»… и круг замыкается.
Сегодня я вообще не понимаю, как можно стать программистом — даже если понимать под «стать» всего-навсего изучение какого-либо языка с наиболее популярным фреймворком для него, то к моменту завершения изучения появляется новая версия языка и две или три версии фрейморка…
По-моему, необходимость обеспечить всех возможностью зарабатывать «легкие» деньги увела технологию программирования из предметной области в развлекательно-бесполезную, хотя это мало кем признается.
Содержание подменяется оболочкой. Посмотрите на статьи на хабре —
Конечно, когда вместо химической формулы, понятной только химику, программа выдает 3D изображение молекулы — это существенно усложняет жизнь программисту, но никак не облегчает жизнь химику и тем более не делает результат понятнее для профана. Зато картинка производит впечатление на инвесторов, менеджеров, покупателей и просто зевак (создающих сайтам ТИЦ, PR и другие «лайки») — соответственно возникают требования сделать в следующий раз «еще красивее, еще нагляднее, еще удобнее»… А это влечет разработку новых «инструментов»… и круг замыкается.
Сегодня я вообще не понимаю, как можно стать программистом — даже если понимать под «стать» всего-навсего изучение какого-либо языка с наиболее популярным фреймворком для него, то к моменту завершения изучения появляется новая версия языка и две или три версии фрейморка…
По-моему, необходимость обеспечить всех возможностью зарабатывать «легкие» деньги увела технологию программирования из предметной области в развлекательно-бесполезную, хотя это мало кем признается.
А что Вы понимаете под «легким»? Я бы не сказал, что программирование для вычисления параметров ядерной реакции было простым и доступным. Чтобы получить результат обсчета, нужно было написать дифур, запрограммировать его, а потом долго разбираться, где ошибка, в уравнении, коде или железе. Почитайте Turing's Cathedral, например, там это все в деталях описывается. Сейчас это сделает на матлабе любой студент-первокурсник, несоизмеримо быстрее и качественнее.
Я так понимаю, Ваше основное недовольство в том, что элитарное становится массовым. Ну так подобные метаморфозы происходили, происходят и будут происходить всегда почти во всех областях техники. Технологии как бы для того и создаются, чтобы упрощать жизнь людям. А Ваши аргументы звучат примерно так, что вот автопоилка на ферме слишком сложная, вот когда все руками делалось, тогда люди знали толк в коровах.
Эм, нет. Пролистайте, например, вот это. Не идеальный документ, но там кроме собственно написания кода к программисту предъявляется еще десятка два компетенций.
Я так понимаю, Ваше основное недовольство в том, что элитарное становится массовым. Ну так подобные метаморфозы происходили, происходят и будут происходить всегда почти во всех областях техники. Технологии как бы для того и создаются, чтобы упрощать жизнь людям. А Ваши аргументы звучат примерно так, что вот автопоилка на ферме слишком сложная, вот когда все руками делалось, тогда люди знали толк в коровах.
Сегодня я вообще не понимаю, как можно стать программистом — даже если понимать под «стать» всего-навсего изучение какого-либо языка с наиболее популярным фреймворком для него, то к моменту завершения изучения появляется новая версия языка и две или три версии фрейморка
Эм, нет. Пролистайте, например, вот это. Не идеальный документ, но там кроме собственно написания кода к программисту предъявляется еще десятка два компетенций.
Под легким я понимаю ровно то, о чем писал автор заметки — сопровождение, поддержка, улучшение и т.п.
Задача, решенная сегодня современными средствами никогда не может перейти в разряд «законченный продукт» — программа вынуждена непрерывно изменяться/обновляться, т.к. постоянно и непрерывно изменяются второстепенные (по отношению к задаче, решаемой программой) требования — глубина цвета, DPI дисплея, новые стандарты интерфейса и т.п.
Поэтому программист никогда не сможет сказать «я завершил работу над программой», даже если сама по себе задача действительно решена и удовлетворяет заказчика.
Задача, решенная сегодня современными средствами никогда не может перейти в разряд «законченный продукт» — программа вынуждена непрерывно изменяться/обновляться, т.к. постоянно и непрерывно изменяются второстепенные (по отношению к задаче, решаемой программой) требования — глубина цвета, DPI дисплея, новые стандарты интерфейса и т.п.
Поэтому программист никогда не сможет сказать «я завершил работу над программой», даже если сама по себе задача действительно решена и удовлетворяет заказчика.
Под легким я понимаю ровно то, о чем писал автор заметки — сопровождение, поддержка, улучшение и т.п.
Так ну вот я Вам описал схематично, как происходила разработка и поддержка обсчета сложных математических задач. Вы всерьез считаете, что это проще, чем посидеть и переверстать GUI под новый экран или сделать отображение каких-нибудь свистелок в 3D?
Поэтому программист никогда не сможет сказать «я завершил работу над программой», даже если сама по себе задача действительно решена и удовлетворяет заказчика.
А это не программисту решать. Работа над программой (видимо, все же «продуктом» в данном случае) будет завершена, когда slakeholder'ы (как это сказать по-русски?) решат, что она удовлетворяет основным бизнес-целям и требованиям. Ну а как они эти бизнес-цели определят, это уже другой вопрос.
Я не говорю проще или нет! Я говорю о том, что с каждым днем обязанностей, которые де-факто никому не нужны, все больше и больше — та же самая «переверстка GUI» — на примере MS Word кому конкретно в жизни помогла создавать тексты лучше, качественнее или производительнее? А ведь для того, чтобы MS Word получил «ленту» вместо «меню» пришлось трудиться огромной куче программистов, которые так и продолжают получать зарплату, непрерывно устраняя баги в этой ленте. (Лента — это образно, но аналогичных примеров полно и без нее).
Современное программирование стало трудным потому, что доля бессмысленного труда в нем постоянно растет. Лично меня бессмысленный труд всегда утомляет больше осмысленного, не знаю, как других…
Современное программирование стало трудным потому, что доля бессмысленного труда в нем постоянно растет. Лично меня бессмысленный труд всегда утомляет больше осмысленного, не знаю, как других…
Как раз суть программиста в постоянном изучении нового и применения этого на практике. Программирование — это творчество, что подразумевает изучение нового. Вы же путаете программиста с ремесленником (например, плиточник, у которого десятилетия не меняется принцип работы и инструменты). Безусловно и в программировании можно найти сферы, где работает принцип ремесленничества, где не нужно изучать что-то новое, например, программирование каких-нибудь аппаратных контроллеров. Вот в такую сферу вам надо уйти, если изучение нового доставляет вам проблемы.
Еще у меня возникло ощущение, что вы против новых идей в интерфейсах. Безусловно не все они удачны и удобны, но без этого мы бы все до сих пор сидели в командной строке.
Еще у меня возникло ощущение, что вы против новых идей в интерфейсах. Безусловно не все они удачны и удобны, но без этого мы бы все до сих пор сидели в командной строке.
не нужно изучать что-то новое, например, программирование каких-нибудь аппаратных контроллеров
Позвольте с Вами не согласиться. В embedded разработке тоже происходят изменения, контроллеры снимаются с производства, появляются новые, более мощные и дешевые. Также меняются средства разработки и отладки, даже в рамках одного производителя контроллеров. Может и ассемблер поменяться, хотя и не радикально. Конечно, эти изменения происходят реже чем в других областях разработки ПО, но они происходят и в последнее время эти изменения случаются все чаще. Так что совсем откосить от изучения чего то нового и при этом быть востребованным не получится. Да и вообще хороший профи в любой области должен учиться постоянно.
Согласен. Просто в этой сфере всё-таки реже происходят изменения. Просто не пришло в голову другой такой сферы, где изменения очень редки. Хотя, может быть на каком-нибудь заводе, где применяются станки с ЧПУ, можно найти такую работу. Стоимость таких станков очень большая, поэтому их там часто используют десятилетия без изменений. Вот и пожалуйста, работа где новые знания не потребуются очень долго.
С каких пор творчество стало изучением нового? Оно всегда было созданием нового!
Я говорил, что программирование это творчество. И не применяя какие-то новые подходы, создать что-то принципиально новое не получится. Также художник, когда рисует картины, он совершенствуется, открывает для себя какие-то новые техники рисования и т.д. Абсолютно схожие процессы происходят при программировании. Если вы 10 лет программировали один и тот же микроконтроллер, то это уже перестает быть творчеством. Поэтому неизбежно изучение новых библиотек, новых подходов, новых паттернов, чтобы не стоять на месте и продолжать совершенствоваться.
Мне помогла. В старом Ворде чёрт ногу сломит, в новом уже можно работать. Гораздо быстрее и приятнее.
При выборе между просто функциональной програмой и функциональной да ещё и красивой, я выберу красивую. Современный софт должен быть удобным, понятным, отзывчивым и приятным на вид. Это всё — юзабилити.
P. S. 5 лет работаю за деньги, с бессмысленным трудом не сталкивался. Приведите пример.
При выборе между просто функциональной програмой и функциональной да ещё и красивой, я выберу красивую. Современный софт должен быть удобным, понятным, отзывчивым и приятным на вид. Это всё — юзабилити.
P. S. 5 лет работаю за деньги, с бессмысленным трудом не сталкивался. Приведите пример.
Извиняюсь, что не в одном посте все сказал…
К аналогии автопоилки — если бы автопоилка в коровнике создавалась на тех же принципах, что и современные программы, она имела бы 946 кнопок с иконками в 64-битном цвете, каждое действие доярки сопровождала бы 7-канальным звуком, при этом все шланги были бы «приятного глазу коровы цвета», а о наполнении подойинка отправляла сообщение в фейсбук. И тогда я сказал бы «автопоилка бессмысленно сложная» — когда доили руками, было лучше.
Это немного не то, что сказали вы…
К аналогии автопоилки — если бы автопоилка в коровнике создавалась на тех же принципах, что и современные программы, она имела бы 946 кнопок с иконками в 64-битном цвете, каждое действие доярки сопровождала бы 7-канальным звуком, при этом все шланги были бы «приятного глазу коровы цвета», а о наполнении подойинка отправляла сообщение в фейсбук. И тогда я сказал бы «автопоилка бессмысленно сложная» — когда доили руками, было лучше.
Это немного не то, что сказали вы…
Так если Вы хотите сказать, что в настоящее время создаются продукты, подверженные creeping featurism, так я всецело согласен. Вот только это вряд ли вина программистов, это вопросы к маркетологам, аналитикам, менеджерам и прочим людям, которые собирают, анализируют и формулируют требования к разрабатываемому софту. Именно поэтому я вон выше и предлагал при обучении программистов заставлять их задумываться о том, как их поделки будут использоваться дальше, а не просто кодировать то, что было сказано.
Вот только это вряд ли вина программистов, это вопросы к маркетологам, аналитикам, менеджерам и прочим людям, которые собирают, анализируют и формулируют требования к разрабатываемому софту.А кто обвиняет программистов?!
Я говорю лишь о том, что их труд стал более сложным — статья-то ведь об этом!
А уж кого за это благодарить… Я назвал это «обслуживанием интересов серости». Извините, умных слов мало знаю, больше привык русскими простыми обходиться…
Я говорю лишь о том, что их труд стал более сложным — статья-то ведь об этом!
А уж кого за это благодарить… Я назвал это «обслуживанием интересов серости». Извините, умных слов мало знаю, больше привык русскими простыми обходиться…
Их труд просто стал немного другим. И для других задач требуются другие люди с другими навыками. Никто же не заставляет хардкорного линукс-кернел программиста формочки верстать. А если заставляют, ему несложно найти другое место, где будут ценить его навыки. Низкоуровневое программирование встроенных устройств, системное программирование, математические расчеты и все остальные «элитные» задачи то никуда не делись и не денутся никогда.
Я пытаюсь говорить по теме статьи. При чем тут то, что говорите Вы? Это верно, но к теме статье отношения не имеет.
Кернельщик в конечном итоге так же будет вынужден обслуживать запросы верхнеуровневщика, т.к. из-за бессмысленного GUI требования к ресурсам ядра могут кардинально измениться… но это так же не имеет отношения к теме.
Кернельщик в конечном итоге так же будет вынужден обслуживать запросы верхнеуровневщика, т.к. из-за бессмысленного GUI требования к ресурсам ядра могут кардинально измениться… но это так же не имеет отношения к теме.
Так Вы говорите — программирование нынче уже не то, теперь все формочки рисуют и кнопочки перекрашивают. А я Вам говорю, что тот хардкор, про который Вы писали с уважением, точно так же востребован, как и 50 лет назад. И учить таких специалистов тоже нужно.
Уважаемый, я говорю о том, почему программирование стало сложным — статью-то Вы прочли? Там сказано о тяготах программиста. Так вот, я продолжаю о тяготах: их усугубляет то, о чем я ранее уже сказал, а именно «обслуживание интересов серости».
Небольшая ремарка о матлабе. С интервалом в пару лет два доцента (один математик, другой физик) независимо сказали мне, что в матлабе есть баги, результат вычислений вызвал у них подозрения и они проверяли вычисления (один своей программой, другой изменив способ вычисления). Т.е. кроме умения пользоваться языком программирование или инструментом как матлаб, надо обладать знаниями чтобы понять результат.
Что-то вроде рассказа Роберта Шекли «Верный вопрос»:
Что-то вроде рассказа Роберта Шекли «Верный вопрос»:
Один на планете — не большой и не малой, а как раз подходящего размера — ждал ответчик. Он не может помочь тем, кто приходит к нему, ибо даже Ответчик не всесилен.
Вселенная? Жизнь? Смерть? Багрянец? Восемнадцать?
Частные Истины, полуистины, крохи великого вопроса.
И бормочет Ответчик вопросы сам себе, верные вопросы, которые никто не может понять.
И как их понять?
Чтобы правильно задать вопрос, нужно знать большую часть ответа.
А вот мне нравится визуализировать данные, и поэтому для меня хорошо, что это кому-то нужно :-)
Для меня самое сложное в разработке это не собственно программирование, а оценка сроков.
Потому что программерскую задачу я могу осилить изучив матчасть, изучив новую технологию, посидев пару дней в дебаггере или просто в конце концов сказав, что проблема не решаемая.
Почему-то об оценке сроков никогда не говорят, когда обучают программированию. Когда я вышел на свою первую работу, для меня это стало неприятным сюрпризом. Я как-то никогда не задумывался об этом ранее, программировал в свое удовольствие. За годы работы я так и не смог выработать какой-то рациональный подход к этому, и как бы я не старался, называю сроки с потолка и надеясь только на свою интуицию.
Потому что программерскую задачу я могу осилить изучив матчасть, изучив новую технологию, посидев пару дней в дебаггере или просто в конце концов сказав, что проблема не решаемая.
Почему-то об оценке сроков никогда не говорят, когда обучают программированию. Когда я вышел на свою первую работу, для меня это стало неприятным сюрпризом. Я как-то никогда не задумывался об этом ранее, программировал в свое удовольствие. За годы работы я так и не смог выработать какой-то рациональный подход к этому, и как бы я не старался, называю сроки с потолка и надеясь только на свою интуицию.
Ну и не переживай по этому поводу. На сомом деле оценить сроки в задаче, которую никогда не делал никто не может. Я так и говорю менеджеру, что сроки оценить не могу. Он конечно удивляется, но это уже его проблемы ;)
Почему-то об оценке сроков никогда не говорят, когда обучают программированию.
Ну потому что пошла дурная традиция считать, что задача программиста только в том, чтобы программировать. А если заменить «программиста», на «разработчика ПО», тогда сразу начинают казаться актуальными и курсы по работе с требованиями, основам управления проектами, тайм-менеджменту, и все остальные полезные штуки. Вот только где найти хороших преподавателей с такими навыками в ПТУ или каком-нибудь аграрном университете, кои сейчас массово «готовят» «программистов».
Оценку сроков легко сделать, если ты полностью контролируешь проект. А часто происходит, что приходится подстраиваться под реалии о которых никогда не задумывался. Задача с которой ты справляешься за пару часов при интеграции вдруг занимает пару дней. Хотя у меня самая большая проблема сесть и программировать, что нужно, а не то что ты хочешь.
По своему опыту могу предложить такой вариант оценки сроков:
— Полностью разбираем ТЗ и задаем все, даже глупые (если будут), вопросы заказчику.
— Разбиваем большие задачи на много мелких подзадач (чем подробнее декомпозиция тем лучше, но без фанатизма).
— Оцениваем каждую мелкую подзадачу по времени (при оценке мелких задач трудно пролететь по времени).
— Собираем общее время по всем задачам.
— Добавляем время на тестирование.
— Добавляем риски. Тут как раз учитывается необходимость изучения матчасти, новых технологий и прочее. У меня запас колеблется в пределах 10-25% в зависимости от проблематики задачи.
— Складываем все, что получилось (оценочное время, тестирование и риски) и получаем человеко-часы на решение задачи. От них уже определяем срок разработки.
С практикой, оценки будут становиться только точнее. То что мы посчитали может лечь и в политику ценообразования.
— Полностью разбираем ТЗ и задаем все, даже глупые (если будут), вопросы заказчику.
— Разбиваем большие задачи на много мелких подзадач (чем подробнее декомпозиция тем лучше, но без фанатизма).
— Оцениваем каждую мелкую подзадачу по времени (при оценке мелких задач трудно пролететь по времени).
— Собираем общее время по всем задачам.
— Добавляем время на тестирование.
— Добавляем риски. Тут как раз учитывается необходимость изучения матчасти, новых технологий и прочее. У меня запас колеблется в пределах 10-25% в зависимости от проблематики задачи.
— Складываем все, что получилось (оценочное время, тестирование и риски) и получаем человеко-часы на решение задачи. От них уже определяем срок разработки.
С практикой, оценки будут становиться только точнее. То что мы посчитали может лечь и в политику ценообразования.
От них уже определяем срок разработки.
сумма всех этих часов == срок разработки?
Срок разработки = сумма часовмагическая константа / sqrt(количество разработчиков),
Магическая константа выбирается от полутора до пяти.
Магическая константа выбирается от полутора до пяти.
Нет, не совсем.
К примеру у нас получилось 100 человеко-часов. У нас два программиста, которые работают по 5 часов в день над этим проектом.
Тогда срок разработки: 100 / (2 * 5) = 10 рабочих дней.
Человеко_Часы / Время_закрываемое_работниками_в_день.
К примеру у нас получилось 100 человеко-часов. У нас два программиста, которые работают по 5 часов в день над этим проектом.
Тогда срок разработки: 100 / (2 * 5) = 10 рабочих дней.
Человеко_Часы / Время_закрываемое_работниками_в_день.
И что, правда так работает? Я бы еще на 2-3 умножил. Или вот как г-н rusec ниже предложил, но с его подходом есть неслабый шанс получить за такие оценки в бубен от начальства.
Да работает. Из моей практики факт с планом расходится в пределах 5%, что я считаю очень хорошим показателем.
К тому же тут есть второй момент — продажа.
Эти расчеты показывают минимально допустимый срок и стоимость проекта (при принятом уровне рентабельности).
Если можешь продать заказчику этот проект в два раза дороже и в два раза дольше — то почему бы и не продать.
К тому же если клиент начнет продавливать на скидки, то ты всегда будешь знать границу, ниже которой от проекта надо отказываться.
К тому же тут есть второй момент — продажа.
Эти расчеты показывают минимально допустимый срок и стоимость проекта (при принятом уровне рентабельности).
Если можешь продать заказчику этот проект в два раза дороже и в два раза дольше — то почему бы и не продать.
К тому же если клиент начнет продавливать на скидки, то ты всегда будешь знать границу, ниже которой от проекта надо отказываться.
Могу предположить, что эти оценки Вы делаете для фиксированной команды и для более-менее похожих проектов. Угадал? Ну либо Вы реально гений планирования, что в риски закладываете 10-25%, и у Вас все сходится. В таком случае «респект и уважуха», как говорится. Но мне все же кажется, что тут без особых условий не обошлось. Уж слишком красиво получается. :)
Ну команда у нас действительно слаженная, уже более трех лет работаем в неизменном составе.
Основная направленность это доработка и сопровождение готовых проектов (от магазинов до CRM систем).
А вот с зоопарком платформ и фреймворков нам не повезло (а может и наоборот повезло) — так как проекты приходят к нам на доработку, то работаем с тем что есть. И ладно если используется какая-то популярная CMS, а то ведь есть и много самописных проектов.
В целом надо признать, что тут важна постоянная практика. Два года назад, когда только внедряли такой подход расчета проектов, о 5% погрешности приходилось только мечтать.
Один раз я пролетел примерно в два раза, благо что продали дороже — в минус не ушли.
Основная направленность это доработка и сопровождение готовых проектов (от магазинов до CRM систем).
А вот с зоопарком платформ и фреймворков нам не повезло (а может и наоборот повезло) — так как проекты приходят к нам на доработку, то работаем с тем что есть. И ладно если используется какая-то популярная CMS, а то ведь есть и много самописных проектов.
В целом надо признать, что тут важна постоянная практика. Два года назад, когда только внедряли такой подход расчета проектов, о 5% погрешности приходилось только мечтать.
Один раз я пролетел примерно в два раза, благо что продали дороже — в минус не ушли.
А, вот что еще меня смущает — в плане у вас нет никаких накладных расходов на интеграцию задач. Уж если строить классическое дерево декомпозиции, то в узлах его тоже работы небесплатные, причем довольно сильно. Ну и, я так понимаю, проекты у Вас не больше десятка человеколет и требования к ним у Вас не меняются по ходу выполнения. Верно?
А девять матерей у вас за месяц ребенка рождают?
Полученное время умножаем на полтора и заменяем единицы измерения на следующие.
4 часа => 6 дней
2 дня => 3 недели
Тогда есть шанс.
4 часа => 6 дней
2 дня => 3 недели
Тогда есть шанс.
Это если задачи вроде монотонно ложить кирпичи в стену.
А по-хорошему, нужно строить сетевой график выполнения задач. Ведь многие из них зависимы друг от друга и одна задача не может быть начата пока не выполнятся другие, потому же определить критический путь по графу и определять сроки.
Но… и тут засада, некоторые задачи ведь можно определить точнее а у других будет большой разброс по времени — эти рамки надо определять для каждой задачи в отдельности, там же и закладывать все возможные коэффициенты а время по критическому пути графа уже брать как есть.
В процессе выполнения задачи сетевой граф надо актуализировать, чтобы было понятно где еще время терпит а где надо бы ускорится. Ибо просто выполнять все задачи как можно быстрее — непродуктивно. Критичные по времени исполнения — только задачи на критическом пути, но может так статься что из-за задержки какой-то некритичной задачи сам критический путь внезапно поменяется.
А по-хорошему, нужно строить сетевой график выполнения задач. Ведь многие из них зависимы друг от друга и одна задача не может быть начата пока не выполнятся другие, потому же определить критический путь по графу и определять сроки.
Но… и тут засада, некоторые задачи ведь можно определить точнее а у других будет большой разброс по времени — эти рамки надо определять для каждой задачи в отдельности, там же и закладывать все возможные коэффициенты а время по критическому пути графа уже брать как есть.
В процессе выполнения задачи сетевой граф надо актуализировать, чтобы было понятно где еще время терпит а где надо бы ускорится. Ибо просто выполнять все задачи как можно быстрее — непродуктивно. Критичные по времени исполнения — только задачи на критическом пути, но может так статься что из-за задержки какой-то некритичной задачи сам критический путь внезапно поменяется.
Соглашусь с вами только отчасти.
Такой метод подойдет для оценки трудоемкости (а как следствие себестоимости) любых задач. Для решения задачи вам в любом случаи нужно будет решить все подзадачи, не важно можно ли их решать параллельно или последовательно.
Для оценки сроков выполнения задачи, если вы работаете один, то тоже не суть важна зависимость между подзадачами.
А вот если над задачей работают более одного человека, то да, можно и даже нужно построить такой граф. Хотя для управления проектом он будет более актуален, чем при оценке времени.
По терминологии (чтобы лучше понимать друг друга):
Под временем выполнения задачи — я понимаю как раз ее трудоемкость.
Под сроком выполнения задачи — период времени от начала разработки до реализации (запуска).
Такой метод подойдет для оценки трудоемкости (а как следствие себестоимости) любых задач. Для решения задачи вам в любом случаи нужно будет решить все подзадачи, не важно можно ли их решать параллельно или последовательно.
Для оценки сроков выполнения задачи, если вы работаете один, то тоже не суть важна зависимость между подзадачами.
А вот если над задачей работают более одного человека, то да, можно и даже нужно построить такой граф. Хотя для управления проектом он будет более актуален, чем при оценке времени.
По терминологии (чтобы лучше понимать друг друга):
Под временем выполнения задачи — я понимаю как раз ее трудоемкость.
Под сроком выполнения задачи — период времени от начала разработки до реализации (запуска).
Так мы вон выше разобрались, что у человека более-менее отлаженные проекты и хорошо сработанная команда. Это позволяет со временем добиться очень точных оценок даже при таком упрощенном подходе.
не ускориться, а перераспределить задачи. Ведь считается, что никто не тормозит просто так, что ему скажешь ускорься и он сразу вдруг всё сделает.
А что скажете на счет сроков ответа на вопрос о сроках в такой ситуации? И как задача изучения новых технологий и матчасти попала в риски?
Новые технологии и платформы попадают в риски по одно простой причине — не зная их вы не сможете дать адекватную оценку сроков реализации задачи в рамках этих систем. Поэтому оценка ведется на основе статистики ранее освоенных платформ, плюс закладываются повышенные риски.
Особенно это актуально для самописных систем.
Особенно это актуально для самописных систем.
с консультантом по компьютерам, который разрабатывает веб-приложения
Консультант по компьютерам! Охренеть просто!
Программировать легко. Тяжело потом исправлять ошибки.
Программирование — это автоматизация. Мало заставить автомат делать то, что нужно. Он автомат. Он не знает, что нужно вам, он вместо этого автоматически исполняет вложенную последовательность действий, а самому ему глубоко наплевать на то, что нужно нам.
И поэтому важно научить автомат ещё и не делать того, что он не должен. Отсюда — обработка исключений, фильтрация пользовательского ввода, вообще — уязвимости. Автомату всё равно. И вот это понять не так-то просто. Мне, по крайней мере, время потребовалось.
Программирование — это поэзия. Да! Поэзия математики. Поэтому мало просто заставить автомат работать именно так, как нужно. Нужно быть поэтом, внутри, чтобы программа работала для людей, на людей, ради облегчения жизни; нужно быть поэтом, чтобы написать понятную программу, ото взгляда на которую у коллеги не появится рвотный рефлекс; чтобы написать такую программу, которую было бы легко и приятно поддерживать.
В конечном счёте, программирование — образ мысли, образ жизни. Мало даже быть поэтом и уметь заставить автомат работать на тебя. Чтобы сделать что-то настоящее, долгоживущее (Windows XP, Linux, C/C++, C#, многотомные труды Кнута, «Совершенный код» и так далее...) нужно вот этим жить. Вот как-то так я думаю. Надеюсь, что не ошибаюсь.
Это сложно? Кому-то — да, сложно, а кому-то и нет, не сложно. Всё зависит от данных конкретных людей в данном конкретном месте и времени.
И поэтому важно научить автомат ещё и не делать того, что он не должен. Отсюда — обработка исключений, фильтрация пользовательского ввода, вообще — уязвимости. Автомату всё равно. И вот это понять не так-то просто. Мне, по крайней мере, время потребовалось.
Программирование — это поэзия. Да! Поэзия математики. Поэтому мало просто заставить автомат работать именно так, как нужно. Нужно быть поэтом, внутри, чтобы программа работала для людей, на людей, ради облегчения жизни; нужно быть поэтом, чтобы написать понятную программу, ото взгляда на которую у коллеги не появится рвотный рефлекс; чтобы написать такую программу, которую было бы легко и приятно поддерживать.
В конечном счёте, программирование — образ мысли, образ жизни. Мало даже быть поэтом и уметь заставить автомат работать на тебя. Чтобы сделать что-то настоящее, долгоживущее (Windows XP, Linux, C/C++, C#, многотомные труды Кнута, «Совершенный код» и так далее...) нужно вот этим жить. Вот как-то так я думаю. Надеюсь, что не ошибаюсь.
Это сложно? Кому-то — да, сложно, а кому-то и нет, не сложно. Всё зависит от данных конкретных людей в данном конкретном месте и времени.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему программировать так тяжело?