Комментарии 68
Как по мне: eat, sleep, code, repeat! – самое зло. Хватит на пару месяцев, потом еще столько же придется приходить в нормальное состояние. Но для некоторых только такой подход и работает, кстати
Тут главное грамотно подойти к планированию рабочего графика (в том числе и для всей команды).

Тогда необходимость работы 24/7 отпадет, и переживать за возможные недоработки не придется :)
НЛО прилетело и опубликовало эту надпись здесь
Плохая погода – это уже единичный случай. Ну и тут вкусовщина играет роль. Мы скорее про общий подход :)
Тогда уж: eat, sleep, solve problem, relax, solve problem, relax, repeate!
Проблема должна быть решена, а не «закодирована».
Зло, если так все время делать.
А иногда (разок в месяц) 2-3 дня нормально, причем за такие 2-3 дня можно запросто сделать недельную работу целого отдела. :-) После такого уже можно спокойно и размеренно наводить красоту в написанном.
Живу так лет 10 (с точностью до частичной подмены code на учёбу в вузе). Брат жив.

Просто надо заниматься тем, что интересно.
Пф. И все эти советы идут в задницу, когда тебе 25 лет, у тебя ипотека и жена с маленьким ребенком, и ты сидишь один ночью и пилишь какое-нибудь приложение, которое поможет тебе заработать дополнительно 10-30к в месяц.
Это точно, но с другой стороны можно что-то более существенное сделать, если привлечь к работе дизайнера / проектировщика и часть задач по тестированию делегировать. Вопрос именно в эффективности
И где сейчас winamp? После того, как к его разработке были подключены дизайнеры, проектировщики, тестеры…
Потому что тебе 25 лет, в 45 такое фиг получится, потому что организм элементарно не будет успевать восстановиться.

PS начинающий программист сразу начинает писать код, опытный программист, прежде чем писать код, сначала тщательно обдумывает, как сделать это так чтобы не пришлось его потом переписывать (избежание ошибок на стадии проектирования).
Завидую. Мне 25, и я ощущаю разницу в реакции организма на ночные бдения сейчас и 10 лет назад.
«Живу так лет 10 (с точностью до частичной подмены code на учёбу в вузе). Брат жив.»
Возможно дело в этом?
В учёбе?

Так это ИМХО сорта одного и того же. Я ведь почти не читаю худлит (к сожалению), не езжу в путешествия, не занимаюсь садоводством, у меня нет лыж и велосипеда, и так далее.
В образе жизни. Тут можно спорить, но я придерживаюсь мнения, что если не уделять время физической активности, со временем сил и на учебу/работу будет оставаться все меньше и меньше. А так же придерживаюсь мнения, что переключение контекста помогает отдохнуть психологически. Плюс увлечения не сосредоточенные в одной узкой области в конечном итоге расширяют кругозор.
Не могу воспроизвести.

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

Переключение контекста, безусловно, полезно. Поэтому на работе один проект, а для хобби — другой :)

Расширение кругозора как самоцель я не очень понимаю, но читать статьи и книги не только по программированию, но и по всяким математикам, физикам и прочему подобному нахожу интересным и полезным. Но это, опять же, ИМХО далековато от путешествий-прогулок-собак.
Вы не поняли. Человек написал комментарий по поводу «ощущаю разницу в реакции организма на ночные бдения сейчас и 10 лет назад». Потому и ощущаете, что из-за компьютера не вылазите последние 10 лет.
И правда, не понял.

Тут уже, правда, другой вопрос — а успею ли я больше, если из-за компьютера вылазить? Ведь тогда и бдений-то не будет столько же, как минимум.
Бывает в режиме «eat, sleep, code, repeat» делаешь 90% задачи. Главное выделить под это дело адекватное количество времени. Пишу это, потому что как раз в пятницу вечером решил изучить андроид и написать приложение с ассинхронными запросами по API. Включился в работу вечером и завершил в 5 утра, через 5 часов проснулся, несколько часов на кодинг, пару часов сна, doom4 и до 4 часов утра кодить. Устал жутко, зато сделал задел на будущее и в спокойном режиме смогу продумать все части проекта, что успел сделал в таком режиме нонстоп
Есть еще множество других увлекательных занятий помимо программирования: чтение, походы, садоводство, прогулки с собакой, катание на горных лыжах, гонки на мотоциклах и так далее. Список можно продолжать бесконечно.
Меня тут-же на хабре заминусили как-то, когда я посмел высказать эту мысль в подобной теме.
у меня допустим график такой.

1) Работа 2) Потом пилю свой проект 3) Провожу время с женой. Причем очень часто жена вредничает, что я слишком много работаю и провожу слишком мало времени с женой. В итоге, у меня просто нет времени на какие-то свои дела и хобби. Ну разве, что в тренажерный зал хожу, но это опять же больше необходимость, чем хобби.

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

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

PS например, у меня в качестве Хобби:
— WolfGL-3D основанный на исходниках Wolfenstein 3D (а точнее форк от newWolf)
— мод к King's Bounty
— чтение книг
— просмотр аниме (^_^)
— чтение манги
— игры
— просмотр Игры Престолов
— просмотр фильмов
Это и есть Ваши хобби????? Извините, но я Вам сочувствую…
Я так понял, что у многих айтишников даже хобби завязано на мониторе. Но, по опыту знаю, проблема придумывания виртуальных увлечений и «куда себя деть и чем заняться» резко исчезает с появлением семьи и детей.
Мне кажется хобби — это то, на что приятно тратить время. Разве есть разница к чему оно привязано (монитору, спортивным снарядам, WD-40, людям), если это приносит удовольствие? И, как мне кажется, «проблемы придумывания» у хобби быть не может — либо оно есть, либо его нет.
Я так понял,

а на основании чего? Вот у нас в Приморье, если встретишь туриста в тайге, во многих случаях это окажется человек так или иначе связанный с IT.

ПеИдане

вообще, конкретно там, много кто бродит, например пиджак Ремпеля :-D но это уже лютый оффтоп ;-)

У нас в походах вечером возле костра была шутка: «Поднимите руку кто не айтишник»
) у нас примерно так-же, но добавляется «и не связан с газпромом»
А, это объясняет, почему я семью-детей заводить не хочу — и так понятно, куда себя девать и чем заняться.

Даже страшно, столько всего умного вокруг, а я такой глупый.

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


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

Эм, почему если мешают, то что-то у человека не то?

Всё ведь зависит от целей человека. А отвлекающие факторы, гм, отвлекают.

Попробую пояснить.


Если для человека дети — отвлекающий фактор, то они явно не его цель (т.е. он не готов распределить на них часть времени как на другие цели), но если они у него есть… где-то он накосячил :-D

Да просто ваше предыдущее сообщение можно понять как «если человек не хочет заводить семью-детей, то у него что-то не то с головой». И это весьма распространенное мнение :)
О, спасибо, что пояснили здесь и чуть выше, а то я ведь вас так и распарсил :( symbix прав, больно распространённое мнение, prior probability высокая.

А так-то да, с учётом вашего пояснения не могу не согласиться!

Всегда пожалуйста!


ЗЫ А вот Juick и поинтач "на Вы" не располагал :-D

У меня примерно также, только вместо п.2 у меня 4-х месячная дочь, а через месяц получу ключи от новой квартиры и надо будет ремонт делать. Так-что у меня даже на тренажёрку времени нет. От окончательной потери хоть какой-то физической формы помогает зарядка по утрам, велосипед и пешая доставка себя на работу и обратно.
Но факт в том, что помимо программирования должны быть в жизни и другие вещи.
С одной стороны советы капитанские, но к сожалению все в той или иной мере присутствуют в повседневной работе.
Пока свой проект не начал приносить какую-то прибыль, не представляю как можно избежать этих проблем.
> 3. UI можно сделать и самому
Если это внутреннее корпоративное приложение, такой подход вполне работает. Конечно, про юзабилити думать надо, но и нанимать дизайнера нарисовать обычные формы и таблицы — перебор.

> 6. «Стэлс-режим» или «Alone In The Dark»
Мне больше помогли статьи о том, как надо (и не надо) делать, и книги вроде Clean code, чем работа в команде. После прочтения и опыта в команде можно и самому писать хороший код, даже если проект для себя.
>UI можно сделать и самому…
Совершенно не понятно, почему бы это разработчику не быть одновременно немного дизайнером. Автор позиционирует эти две сферы человеческой деятельности как противоположные и несовместимые. Вероятно, все зависит от конкретного разработчика, конкретного проекта, конкретного заказчика. Автор, видимо, сам не сталкивался с реалиями разработки ПО, поэтому берет на себя смелость давать подобные советы.
При этом, автор приведя пример «плохого» интерфейса, не продемонстрировал пример хорошего. А ссылка которую они привёл — бестолковая и бесполезная, ибо содержит лишь кучу слов и ни одной иллюстрации с примером хорошего интерфейса.
я всегда в таких темах люблю приводить пример креглиста, который имеет ущербный дизайн, но при этом шикарное юзабилити.
Я подозреваю, что имело в виду то, что типовой программист делает интерфейс для программы, а дизайнер (хороший) для человека, т.к. ему неважно как программа работает. Хреновый дизайнер делает для красоты.
Но это всё ерунда на самом деле. Небольшая утилита с 3,5 кнопок не нуждается в дополнительных людях, а серьёзное приложение должно разрабатываться с проработки архитектуры программы, и(!) архитектуры пользовательского интерфейса. И только когда эти 2 архитектуры будут определены — надо приступать к написанию кода.
Программист обычно хорошо понимает предметную область, поэтому ориентируется в программе не с точки зрения какого-то сферического юзабилити в вакууме, а знает какие функции более востребованы, какие именно задачи они решают и какой подготовкой будет обладать использующий их персонал. Программист проводит за отладкой программы кучу времени, поэтому имеет представление об удобстве интерфейса именно как конечный пользователь. А вообще, фронтенд это такая штука, где прийти к более-менее оптимальному решению обычно удается только в процессе работы. Автор описал нам полного дебила, который накидал на форму кучу контролов и инфантильно радуется. С другой стороны где-то есть мудрые дизайнеры интерфейсов, которые не зная как работает программа и какие задачи она решает с первого раза безошибочно продумывают интерфейс не смотря на все правки которые обычно возникают в процессе разработки любого продукта, даже серьезного приложения. Это какой-то мир единорогов и розовых пони, где заказчик не вмешивается в процесс разработки, ТЗ не меняются по десять раз, менеджеры не подписывают кучи допсоглашений, все делается в срок и в продакшен не попадают плохо протестированные модули. Для кого эта статья? ИМХО для того, кто видел работу программерской конторы только по телевизору.
Зависит от организации работы. Например, однажды работал в месте, где IT Бизнес Аналитик, неделями согласует с заказчиком и с разработчиками документ с полным и подробным описанием того что хочет заказчик, а затем на финальном документе ставят подписи и печати.
В сфечиреской разработке в вакууме дизайнер интерфейсов не должен знать, как работает программа. Ему ставится задача создать максимально удобный для пользователя интерфейс, с помощью которого он может решать конкретные задачи. Предполагается, что программа эти задачи решать может, в ней нет костылей, накладывающих какие-то ограничения и/или условия. Опять-же в грамотно построенном приложении интерфейс никак не влияет на функционирование, что развязывает дизайнеру руки. Хочет — консоль, хочет — веб страничка, хочет — формочка с одной кнопкой «Сделать мне хорошо».
Мы все понимаем, что реальность имеет отличия и не в лучшую сторону, особенно в наших краях, где для экономии бюджета руководители оплачивают труд одного программиста считая, что он и разработчик, и тестировщик и дизайнер, а иногда ещё и маркетолог.
>В сфечиреской разработке в вакууме дизайнер интерфейсов не должен знать, как работает программа. Ему ставится задача создать >максимально удобный для пользователя интерфейс, с помощью которого он может решать конкретные задачи

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

Вот в этом основная проблема. Программист решает задачу разработки, а для дизайнер должен решить проблему пользователя, это разные задачи.
Дизайнеры приборной панели авто могут понятия не иметь о конструктиве двигателя, объёме багажника и расположении генератора под капотом. Они решают где разместить отверстия вентиляции, ручки управления мультмедиа-системой, какой формы будет руль и каким цветом подсвечиваются приборы.
Вы смеётесь? Вы поищите в интернете примеры дизайнерских решений в автомобилестроении. Эти прототипы доживают только до выставки, в серию идут решения инженеров. Чтобы дизайнер смог спроектировать рабочее место водителя грузовика, он должен сам уметь управлять грузовиком и иметь в этом солидный опыт. А чтобы размышлять о решетках вентиляции, нужно иметь представление об аэродинамике, понимать как прокладываются жгуты проводов, как лишнее отверстие в панели приборов влияет на её прочность
и безопасность. «Решить проблему пользователя» без подобного багажа знаний невозможно, и разумеется инженер решает её успешнее художника-декоратора.
В качестве дополнения, замечу, что есть промышленный дизайн и есть просто дизайн.
Прототипы на выставках сделаны в первую очередь дизайнерами, а промышленный дизайн — это несколько иная предметная область, где дизайнер знает теормех и, возможно, сопромат.

С точки зрения ПО — дизайнер это плохой человек, правильный человек -UI/UX -который рисует не кнопочки, а сценарии работы с программой и подтягивает под эти сценарии кнопки.
А сами сценарии — воплощение работы с предметной областью, как раз
Это не означает, что он плохой, просто, если показать его другим экспертам, со 100% вероятностью они его улучшат

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


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

>Это не означает, что он плохой, просто, если показать его другим экспертам, со 100% вероятностью они его улучшат
Да щас прям. С 50% вероятностью его ухудшат. Ну а то, что ж я за эксперт, если не найду в чужом коде косяков? Каждому охота повыпендриваться, «а вот я бы тут сделал фабрику фабрик, а вот эти методы можно сделать статичными» и в таком духе. Такие советы не делают код лучше, они делают видимость участия и высокого профессионализма советчиков.
> 3. UI можно сделать и самому…

Ну, Gmail который год живет с UI, который иначе как написанным программистами не назовешь )
Как подметили выше, не факт, что другой разработчик как-то улучшит ваш код.
Был подобный случай: нужно было написать один достаточно сложный проект. Буквально за день до защиты было решено показать его одному программисту, который в моем кругу общения считается достаточно продвинутым. И что в итоге? «Зачем ты в public классе ты передаешь значение private полю через метод, можно же сделать его public и обращаться напрямую...», «Зачем ты сделала то-то так-то так-то, можно же было проще....» etc. В итоге, после его «набега», в исходниках явно «запахло»(и не горной лавандой) пришлось экстренно откатывать версию.
К чему все это? Да просто этой реальной историей я хотел показать, что вероятность улучшения вашего когда другим разработчиком явно не 100%.
Eat, sleep, code, repeat — это отлично.

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

1 августа 2012 г.

Местоположение

Россия

Сайт

1cloud.ru

Численность

31–50 человек

Дата регистрации

22 мая 2014