LINUX.ORG.RU
ФорумTalks

Как перепрошить себе мозг?

 , ,


5

4

Есть ли какие-нибудь способы «удлинить» цепочку Цель - Действие - Достижение цели - Удовольствие? У меня большие проблемы с достижением мало-мальски долгосрочных целей. Стоит только приняться за одно из намеченных Больших Дел, как мозг начинает плакаться и канючить, прося привычную дозу условного дофамина.

Механизм такой:

1) Принимаюсь за работу

2) Начинается внутренний диалог на тему «ты какой-то фигнёй маешься», «да кому это нужно», «впустую тратишь время»

3) Настроение падает, работать не получается

4) Помаявшись, иду за привычной дозой дофамина: флужу в Сети, иду гулять и социобл**ствовать, наркоманить или/и пить

5) Понимаю, что снова профукал время, страдаю от этого

Когда положительная отдача (деньги, например) происходит сразу после выполнения работы - с мотивацией всё норм. Поэтому работаю на фрилансе, но это совсем не то, что мне нужно. Также, если удаётся войти в т.н. поток, то дофамин начинает выделяться просто по факту творчества, могу так работать много часов подряд не отрываясь. Но опять проблема: войти в поток почти не могу без допинга (алкоголь, стимуляторы, энергетики), мозг, опять же, куксится и ворчит, что без допинга «работа уже не та». Но здоровье у меня не железное, блин.

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

Deleted
Ответ на: комментарий от Serg_HIS

Да, я похоже когда-то прибегнул к прошивке, каюсь...

xwicked ★★☆
()

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

Tark ★★
()
Последнее исправление: Tark (всего исправлений: 3)

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

LupusAlbus
()

Нужны рабочие практические методы.

Жена, например

upcFrost ★★★★★
()

Смирись, ты просто тряпка.

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от Stahl

Разбивай задачу на мелкие. От выполнения каждой мелкой (но самодостаточной или хотя бы логически цельной) задачи будет тебе моральная плюшка. Разбивать задачи можно на сколь угодно малые «дозы».

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

DNA_Seq ★★☆☆☆
()

Электродрелью

J ★★★★★
()
Ответ на: комментарий от Tark

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

Deleted
()

Я знаю как для интеллектуалов избегать эту проблему.

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

По моему опыту в ЛОРе и в других местах, для славян это чуждо. Все хотят показать в отдельности, что у них пузо больше и могут сделать «ВСЁ САМИ»

Далеко за примерами ходить не нужно - это мёртворождённые проекты только на бумаге «МЦСТ» ну и вся высокотехнологичная продукция в принципе в наших странах.

По этому поводу классно рассказал в Камеди Клаб Павел Воля в теме «про сколково».

Serg_HIS
()
Ответ на: комментарий от stevejobs

так выглядит рай для нуба :) но у нубов и так голова пустая. там нечего облегчать.

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

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

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

. профессиональные водители не используют коробку-автомат

кто тебе это сказал.

профессиональные фотографы не используют автонастройку

а это кто тебе сказал.

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

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

а мелкие тесты просто не покажут проблему. приходится исхитряться и писать кучу эмуляторов

эмулятор чего ? Железки, которую никогда не видела ? Зашибенная идея. Что-то типа подметания вилкой. вообще-то, нормальные люди отлаживают алгоритмы на САПРах. Какбэ для этого оно и есть. Но вы то выше этого, конечно же.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

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

stevejobs ★★★★☆
()
Ответ на: комментарий от lenin386

это говорят профессиональные водители и профессиональные фотографы. просто ты в пролёте, или тупо троллишь, как обычно.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от stevejobs

прочитай определение TDD. никакими спецификациями там не пахнет. это типичная аджайловщина.

написание кода по ТЗ начинается с полного и глубокого исследования задачи. не отдельных частей, а всего проекта целиком, в полном объёме, и это не вариант с «забыванием» про что-то. это и есть составление настоящего ТЗ, а не юзерских фантазий на тему. затем идёт проработка глобальной архитектуры и плана реализации отдельных частей, разбиение задачи на независимые модули и только потом параллельное написание этих модулей разными программистами (или другими специалистами). написанное по ТЗ, это всё потом легко собирается в одно целое. и никакого экстремального программирования. экстремальное программирование - это ненормально. в нём нет планирования и ничего серьёзного такими методами не пишут. при правильном планировании проекта есть время на аналитику, есть время на программирование, есть время на отладку. это не отменяет юнит-тесты, но они выполняют лишь побочную работу, а не являются основой.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

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

Не надо путать профессиональных водителей с мамкиными шумахерами, которым яйца автоматика мешает.

Deleted
()
Ответ на: комментарий от Iron_Bug

это говорят профессиональные водители

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

и профессиональные фотографы

И профессиональные фотографы так не говорят. Полностью автоматические режимы используются в условиях очень ограниченного времени на подготовку к съёмке. В различных ситуациях, используются различные полуавтоматические режимы. Но полностью ручные режимы используются очень редко. Это либо какие-то очень тепличные очень отлаженные студийные условия, либо какая-то очень художественная фотография, за которую не платят, либо больные на всю голову люди корчат из себя Х.З. што.

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

да видел я таких, как ты. кстати, тоже лицо женского пола. Как она сказанула «но ведь прибор только на объекте, поэтому, вот у нас программа тут падает, но это фигня всё, поедем в командировочку, подсоединимся, всё запипикает». Сначала был шок, как будто БОМЖ из стены вылез, потом полдня всем офисом ржали.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 4)
Ответ на: комментарий от Iron_Bug

никакие САПРы для этого не нужны, да и не справятся они

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

lenin386 ★★★★
()
Ответ на: комментарий от Iron_Bug

написание кода по ТЗ

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Я уж не говорю о том, что когда у вас есть ТЗ, и есть реализация ТЗ погроммистом, то, извините, кто из этих двоих составляет документацию ? И что является первоисточником для составления документации - ТЗ или реализация ТЗ ? А кто даст гарантию, что погроммист всё реализовал прям по ТЗ. Тесты ? Полного покрытия тестами допустим для системы сложнее лопаты придумать невозможно. Вот так и начинается поиск виноватого. Давайте, покажите документ, как работают ваши алгоритмы. Так. Давайте проверим. Щто, не совпало ? Ах вы с###, и куда теперь засунуть ваши бумажки ? Где искать правду. Вот в этой бороде на сишечке, которую вы не отдаёте, да ? САПР - это ещё автоматическая генерация документации, гарантированно соответствующей действительности, прикинь, щто делается. Понимаешь, валить всё на погроммиста - это у серьёзных людей как-то не принято, не по зарплате ему вообще на такие вопросы отвечать.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 4)
Ответ на: комментарий от Iron_Bug

это вопрос не программирования вообще, а технологии составления ТЗ, которая в свою очередь исходит из организации бизнеса

я основываюсь на высоко итеративной аджайл технологии ведения процессов.

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

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

то есть если ты разрабатываешь кардиомплант - проходи мимо

а если разрабатываешь автоматизированную оплату интернета через мобильное приложение на андроиде - заходи

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

мы даже можем пожертвовать ими настолько, чтобы купить нормальных программистов, которые могут прочитать книжку Кента Бека под названием «Экстремальное программирование: разработка через тестирование» и понять, о чем там говорится :)

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

ах да, важный момент! Если мы говорим о техническом процессе

Вначале ты обязательно должен разработать платформу и вложить в это дочерта архитектурных усилий. Это изобретательская задача в первую очередь, с планированием любого вида (что ватерфолл, что аджайл) там плохо очень. «Будет выпущено, когда будет готово» - как говорят в Blizzard

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

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

или например, в качестве платформы для IDE я использую платформы IntelliJ IDEA и Eclipse. Опять же: однажды пишется база, и потом на неё десятилетиями наворачиваются плагины. Базу можно рефакторить, но изначальная аналитическая работа, «дух Эклипсы» никуда не денется

соответственно все программисты понимают «дух Джавы» и «дух Эклипсы» и действуют сообразно с этим видением мира.

а если ты говоришь о каких-то вещах вне технологической сферы, то к программисту они имеют мало отношения. Например, ты работаешь магазин «Тачки в кредит», и хозяева бизнеса намеряли, что нужно сделать интерфейс для одновременной покупки 5 тачек. Не 10, не 20, а ровно 5. Тебя как разработчика не должно волновать, почему столько, это дизайн решение бизнгес-аналитиков ;) А ты как разработчик просто открывашеь тесты и добавляешь еще один: «я покупаю 5 тачек и хочу чтобы полоска зеленая, я покупаю шесть тачек и хочу чтобы полоска красная», всё

stevejobs ★★★★☆
()
Ответ на: комментарий от Iron_Bug

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

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

помойму это плохо и некрасиво, так относиться к людям

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

высокорисковые продукты и услуги, особенно «проекты одного теста» (кардиоимпланты, автоматические тормоза в автомобиле, военные вещи когда после ошибки тебя расстреливают из калаша

Тут вопрос в том, кто такой «ты». Если ты - это имеется ввиду программист, то понимаешь в чём дело. Практика расстрела стелочников - это, конечно, любимое дело не только у нас. Но если по правильному, то не должна быть виновата мелкая букашка в крупном происшествии никогда. Такое просто должно быть исключено производственным процессом. Ошибка программиста не должна приводить ни к каким последствиям, да и сами ошибки должны были исключены и минимизированы, а если это не так, то виноваты разумеется те, кто так замечательно поставил дело. Когда мне говорят, что программист (низший исполнитель) убил ФОБОС-ГРУНТ, мне смишно. Не солдат виноват в терроре, хотя их и любят подставлять под наказание, но не правильно это, не верно.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 5)
Ответ на: комментарий от lenin386

Но если по правильному, то не должна быть виновата мелкая букашка в крупном происшествии никогда

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

Не солдат виноват в терроре.

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

Deleted
()
Ответ на: комментарий от lenin386

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

stevejobs ★★★★☆
()
Ответ на: комментарий от Deleted

Это не по-правильному, а по влажным мечтам мелких букашек, которые от ответственности за свою лажу разбегаются

Хех, товарищ. По отвественности и зарплата должна быть. А то видишь как выходит : внедряет систему директор, на сафари летает директор, а если косяк, то виноват программист.

Исполнение преступных приказов - тоже преступление

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

Не говоря уж о том, что солдат по своей инициативе или по своей тупости может натворить мрачных дел.

это уже другой случай.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 2)
Ответ на: комментарий от lenin386

По отвественности и зарплата должна быть

Кому должна? Зарплата устанавливается по согласию сторон.

Но наказание за него должны нести в первую очередь другие люди

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

это уже другой случай

Да нет, тот же самый.

Deleted
()
Ответ на: комментарий от Deleted

Кому должна? Зарплата устанавливается по согласию сторон.

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

Непонятно, с какого фига кто-то должен отвечать за ваши ошибки.

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

Да нет, тот же самый.

Нет, не тотже. Солдат развязать войну и устроить холокост не может в принципе, даже если он супернегодяй.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 4)
Ответ на: комментарий от lenin386

ой, ха-ха-ха

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

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

Ну и?

С какого перепугу бардак и невежество при проектировании системы, важной для безопасности - мои ошибки ?

Не ваши. А вот ошибки в коде - ваши.

Солдат развязать войну и устроить холокост не может в принципе

Он может устроить локальный холокост.

Deleted
()
Ответ на: комментарий от Deleted

То что работать всем влом, это не только твоя проблема.

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

Сам себя не заставишь, никто тебя не заставит.

Просто стань в очередь «делать» первым!

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

Как то так относится к твоей проблеме картинка.

Там же чётко нарисовано - все любят «бла-бла-бла», а работать, никто не любит.

Serg_HIS
()
Ответ на: комментарий от Deleted

Я так понял, вы не по доброй воле согласились на свою зарплату, а принуждению, например, жены?

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

Не ваши. А вот ошибки в коде - ваши.

Но мои ошибки в коде не должны приводить к 3.14Z--цу ! Если они к нему тем не менее приводят, значит, тут вина не только моя. А точнее, совсем не моя.

Он может устроить локальный холокост.

За локальный и ответственность локальная.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 4)
Ответ на: комментарий от lenin386

На свою зарплату я не соглашался. Я соглашаюсь, что она такая

Ясно, понятно.

Но мои ошибки в коде не должны приводить к 3.14Z--цу !

Математически доказать это осилите?))

За локальный и ответственность локальная

Ну вот и повесят его. А его командиров повесят трижды.

Deleted
()
Ответ на: комментарий от Deleted

Это не ответ, а отписка.

Режим троля видать включил :)

Никто тебе не даст волшебной словесной пизлюли как заставлять работать конкретно тебя. К каждому подход индивидуален.

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

Serg_HIS
()
Ответ на: комментарий от Deleted

Математически доказать это осилите?))

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

Ну вот и повесят его. А его командиров повесят трижды.

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от lenin386

очередная порция блаблабла от ленина386

Ок.

А о командирах ещё несколько поколений не забудут

Ну и?

Deleted
()
Ответ на: комментарий от Deleted

Это не чей-то заказ

Тогда опять повторюсь.

Команда - это не обязательно программисты.

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

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

Serg_HIS
()
Ответ на: комментарий от Deleted

Если найдёшь адекватного человека в команду, 100% у тебя в несколько раз улучшится настроение и производительность (минимум раза в 2).

У всех думаю без исключения тут проблема в том, что я писал выше. Но все почему-то метод работы в команде отметают как комаров. И сами не идут и других не зовут. Но я о том, что в итоге получается в итоге, писал выше (Павел Воля хорошо рассказал о том, что с таким подходом получается с нашими и вашими технологиями)

Serg_HIS
()
Ответ на: комментарий от Deleted

Ну и?

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от Deleted

Задача не сложная.

К стати тут ты можешь ошибаться.

После проделывания 50% работы (как тебе казалось раньше), увидишь, что работы ещё три товарных состава и один самосвал. И становится жутко скучно и тошно, что не позвал кого нибудь обсудить архитектуру и ещё какие-то нюансы, которые тебе казались понятными или не особо важными.

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

Товарищ Воля - популист, который даже не понимает, что в Сколково ничего не «придумывают». Там соединяют инвесторов со стартаперами, вообще-то. И вся его передачка, как и все телешоу - суть убогая постановка для плебса. Петросян и то поучительнее.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 3)
Ответ на: комментарий от Deleted

Работы хватает, но я бы не назвал её именно сложной. Она достаточно однообразная.

Если хочешь, давай разберёмся?

Есть задачи единообразные «routine» Это набивание единообразных данных, написание единообразных обработчиков и т.п.

Есть задачи сложные «complexity»

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

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

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

Или просто изучение новых технологий и разработка ранее не писаного кода, когда нет более ранних наработок в какой-то области.

Это всё сложные задачи от слова «сложение» в кучу разного и не похожего.

А рутинные - просто нудные.

Serg_HIS
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.