Комментарии 68
Как по мне: eat, sleep, code, repeat! – самое зло. Хватит на пару месяцев, потом еще столько же придется приходить в нормальное состояние. Но для некоторых только такой подход и работает, кстати
Тут главное грамотно подойти к планированию рабочего графика (в том числе и для всей команды).
Тогда необходимость работы 24/7 отпадет, и переживать за возможные недоработки не придется :)
Тогда необходимость работы 24/7 отпадет, и переживать за возможные недоработки не придется :)
Тогда уж: eat, sleep, solve problem, relax, solve problem, relax, repeate!
Проблема должна быть решена, а не «закодирована».
Проблема должна быть решена, а не «закодирована».
Зло, если так все время делать.
А иногда (разок в месяц) 2-3 дня нормально, причем за такие 2-3 дня можно запросто сделать недельную работу целого отдела. :-) После такого уже можно спокойно и размеренно наводить красоту в написанном.
А иногда (разок в месяц) 2-3 дня нормально, причем за такие 2-3 дня можно запросто сделать недельную работу целого отдела. :-) После такого уже можно спокойно и размеренно наводить красоту в написанном.
НЛО прилетело и опубликовало эту надпись здесь
Пф. И все эти советы идут в задницу, когда тебе 25 лет, у тебя ипотека и жена с маленьким ребенком, и ты сидишь один ночью и пилишь какое-нибудь приложение, которое поможет тебе заработать дополнительно 10-30к в месяц.
Это точно, но с другой стороны можно что-то более существенное сделать, если привлечь к работе дизайнера / проектировщика и часть задач по тестированию делегировать. Вопрос именно в эффективности
Потому что тебе 25 лет, в 45 такое фиг получится, потому что организм элементарно не будет успевать восстановиться.
PS начинающий программист сразу начинает писать код, опытный программист, прежде чем писать код, сначала тщательно обдумывает, как сделать это так чтобы не пришлось его потом переписывать (избежание ошибок на стадии проектирования).
PS начинающий программист сразу начинает писать код, опытный программист, прежде чем писать код, сначала тщательно обдумывает, как сделать это так чтобы не пришлось его потом переписывать (избежание ошибок на стадии проектирования).
НЛО прилетело и опубликовало эту надпись здесь
«Живу так лет 10 (с точностью до частичной подмены code на учёбу в вузе). Брат жив.»
Возможно дело в этом?
Возможно дело в этом?
НЛО прилетело и опубликовало эту надпись здесь
В образе жизни. Тут можно спорить, но я придерживаюсь мнения, что если не уделять время физической активности, со временем сил и на учебу/работу будет оставаться все меньше и меньше. А так же придерживаюсь мнения, что переключение контекста помогает отдохнуть психологически. Плюс увлечения не сосредоточенные в одной узкой области в конечном итоге расширяют кругозор.
Бывает в режиме «eat, sleep, code, repeat» делаешь 90% задачи. Главное выделить под это дело адекватное количество времени. Пишу это, потому что как раз в пятницу вечером решил изучить андроид и написать приложение с ассинхронными запросами по API. Включился в работу вечером и завершил в 5 утра, через 5 часов проснулся, несколько часов на кодинг, пару часов сна, doom4 и до 4 часов утра кодить. Устал жутко, зато сделал задел на будущее и в спокойном режиме смогу продумать все части проекта, что успел сделал в таком режиме нонстоп
Есть еще множество других увлекательных занятий помимо программирования: чтение, походы, садоводство, прогулки с собакой, катание на горных лыжах, гонки на мотоциклах и так далее. Список можно продолжать бесконечно.
Меня тут-же на хабре заминусили как-то, когда я посмел высказать эту мысль в подобной теме.
Меня тут-же на хабре заминусили как-то, когда я посмел высказать эту мысль в подобной теме.
у меня допустим график такой.
1) Работа 2) Потом пилю свой проект 3) Провожу время с женой. Причем очень часто жена вредничает, что я слишком много работаю и провожу слишком мало времени с женой. В итоге, у меня просто нет времени на какие-то свои дела и хобби. Ну разве, что в тренажерный зал хожу, но это опять же больше необходимость, чем хобби.
Правда раз в 3-4 месяца, забиваю на свой проект и примерно неделю занимаюсь чем-то другим. Но опять же работу и жену никто не отменял, в итоге, просто 4-5 часов, которые я могу куда-то сходить с друзьями и что-то поделать.
Конечно, можно назвать свой проект хобби, где я учусь новым штукам и познаю мир программирования, но это очень спорно.
1) Работа 2) Потом пилю свой проект 3) Провожу время с женой. Причем очень часто жена вредничает, что я слишком много работаю и провожу слишком мало времени с женой. В итоге, у меня просто нет времени на какие-то свои дела и хобби. Ну разве, что в тренажерный зал хожу, но это опять же больше необходимость, чем хобби.
Правда раз в 3-4 месяца, забиваю на свой проект и примерно неделю занимаюсь чем-то другим. Но опять же работу и жену никто не отменял, в итоге, просто 4-5 часов, которые я могу куда-то сходить с друзьями и что-то поделать.
Конечно, можно назвать свой проект хобби, где я учусь новым штукам и познаю мир программирования, но это очень спорно.
А каким ещё хобби Вы мечтали бы заниматься помимо своего проекта, если не секрет? (^_^)
PS например, у меня в качестве Хобби:
— WolfGL-3D основанный на исходниках Wolfenstein 3D (а точнее форк от newWolf)
— мод к King's Bounty
— чтение книг
— просмотр аниме (^_^)
— чтение манги
— игры
— просмотр Игры Престолов
— просмотр фильмов
PS например, у меня в качестве Хобби:
— WolfGL-3D основанный на исходниках Wolfenstein 3D (а точнее форк от newWolf)
— мод к King's Bounty
— чтение книг
— просмотр аниме (^_^)
— чтение манги
— игры
— просмотр Игры Престолов
— просмотр фильмов
Не боитесь пустить корни и прирасти к креслу? )
Это и есть Ваши хобби????? Извините, но я Вам сочувствую…
Я так понял, что у многих айтишников даже хобби завязано на мониторе. Но, по опыту знаю, проблема придумывания виртуальных увлечений и «куда себя деть и чем заняться» резко исчезает с появлением семьи и детей.
Я так понял, что у многих айтишников даже хобби завязано на мониторе. Но, по опыту знаю, проблема придумывания виртуальных увлечений и «куда себя деть и чем заняться» резко исчезает с появлением семьи и детей.
Мне кажется хобби — это то, на что приятно тратить время. Разве есть разница к чему оно привязано (монитору, спортивным снарядам, WD-40, людям), если это приносит удовольствие? И, как мне кажется, «проблемы придумывания» у хобби быть не может — либо оно есть, либо его нет.
Я так понял,
а на основании чего? Вот у нас в Приморье, если встретишь туриста в тайге, во многих случаях это окажется человек так или иначе связанный с IT.
НЛО прилетело и опубликовало эту надпись здесь
Да оратор выше что-то сморозил не то. Дети и семья время требуют и его обязательно нужно выделять, но они и больше дисциплинируют, что способствует. Если они мешают… то что-то у человека не то. Скорее всего — с головой. Поэтому если не тянет — то лучше и не нужно.
В любом случае, как это может быть определяющим фактором для хобби — хоть убей, но не пойму.
НЛО прилетело и опубликовало эту надпись здесь
Попробую пояснить.
Если для человека дети — отвлекающий фактор, то они явно не его цель (т.е. он не готов распределить на них часть времени как на другие цели), но если они у него есть… где-то он накосячил :-D
У меня примерно также, только вместо п.2 у меня 4-х месячная дочь, а через месяц получу ключи от новой квартиры и надо будет ремонт делать. Так-что у меня даже на тренажёрку времени нет. От окончательной потери хоть какой-то физической формы помогает зарядка по утрам, велосипед и пешая доставка себя на работу и обратно.
Но факт в том, что помимо программирования должны быть в жизни и другие вещи.
Но факт в том, что помимо программирования должны быть в жизни и другие вещи.
С одной стороны советы капитанские, но к сожалению все в той или иной мере присутствуют в повседневной работе.
Пока свой проект не начал приносить какую-то прибыль, не представляю как можно избежать этих проблем.
Пока свой проект не начал приносить какую-то прибыль, не представляю как можно избежать этих проблем.
> 3. UI можно сделать и самому
Если это внутреннее корпоративное приложение, такой подход вполне работает. Конечно, про юзабилити думать надо, но и нанимать дизайнера нарисовать обычные формы и таблицы — перебор.
> 6. «Стэлс-режим» или «Alone In The Dark»
Мне больше помогли статьи о том, как надо (и не надо) делать, и книги вроде Clean code, чем работа в команде. После прочтения и опыта в команде можно и самому писать хороший код, даже если проект для себя.
Если это внутреннее корпоративное приложение, такой подход вполне работает. Конечно, про юзабилити думать надо, но и нанимать дизайнера нарисовать обычные формы и таблицы — перебор.
> 6. «Стэлс-режим» или «Alone In The Dark»
Мне больше помогли статьи о том, как надо (и не надо) делать, и книги вроде Clean code, чем работа в команде. После прочтения и опыта в команде можно и самому писать хороший код, даже если проект для себя.
>UI можно сделать и самому…
Совершенно не понятно, почему бы это разработчику не быть одновременно немного дизайнером. Автор позиционирует эти две сферы человеческой деятельности как противоположные и несовместимые. Вероятно, все зависит от конкретного разработчика, конкретного проекта, конкретного заказчика. Автор, видимо, сам не сталкивался с реалиями разработки ПО, поэтому берет на себя смелость давать подобные советы.
Совершенно не понятно, почему бы это разработчику не быть одновременно немного дизайнером. Автор позиционирует эти две сферы человеческой деятельности как противоположные и несовместимые. Вероятно, все зависит от конкретного разработчика, конкретного проекта, конкретного заказчика. Автор, видимо, сам не сталкивался с реалиями разработки ПО, поэтому берет на себя смелость давать подобные советы.
При этом, автор приведя пример «плохого» интерфейса, не продемонстрировал пример хорошего. А ссылка которую они привёл — бестолковая и бесполезная, ибо содержит лишь кучу слов и ни одной иллюстрации с примером хорошего интерфейса.
Я подозреваю, что имело в виду то, что типовой программист делает интерфейс для программы, а дизайнер (хороший) для человека, т.к. ему неважно как программа работает. Хреновый дизайнер делает для красоты.
Но это всё ерунда на самом деле. Небольшая утилита с 3,5 кнопок не нуждается в дополнительных людях, а серьёзное приложение должно разрабатываться с проработки архитектуры программы, и(!) архитектуры пользовательского интерфейса. И только когда эти 2 архитектуры будут определены — надо приступать к написанию кода.
Но это всё ерунда на самом деле. Небольшая утилита с 3,5 кнопок не нуждается в дополнительных людях, а серьёзное приложение должно разрабатываться с проработки архитектуры программы, и(!) архитектуры пользовательского интерфейса. И только когда эти 2 архитектуры будут определены — надо приступать к написанию кода.
Программист обычно хорошо понимает предметную область, поэтому ориентируется в программе не с точки зрения какого-то сферического юзабилити в вакууме, а знает какие функции более востребованы, какие именно задачи они решают и какой подготовкой будет обладать использующий их персонал. Программист проводит за отладкой программы кучу времени, поэтому имеет представление об удобстве интерфейса именно как конечный пользователь. А вообще, фронтенд это такая штука, где прийти к более-менее оптимальному решению обычно удается только в процессе работы. Автор описал нам полного дебила, который накидал на форму кучу контролов и инфантильно радуется. С другой стороны где-то есть мудрые дизайнеры интерфейсов, которые не зная как работает программа и какие задачи она решает с первого раза безошибочно продумывают интерфейс не смотря на все правки которые обычно возникают в процессе разработки любого продукта, даже серьезного приложения. Это какой-то мир единорогов и розовых пони, где заказчик не вмешивается в процесс разработки, ТЗ не меняются по десять раз, менеджеры не подписывают кучи допсоглашений, все делается в срок и в продакшен не попадают плохо протестированные модули. Для кого эта статья? ИМХО для того, кто видел работу программерской конторы только по телевизору.
Зависит от организации работы. Например, однажды работал в месте, где IT Бизнес Аналитик, неделями согласует с заказчиком и с разработчиками документ с полным и подробным описанием того что хочет заказчик, а затем на финальном документе ставят подписи и печати.
В сфечиреской разработке в вакууме дизайнер интерфейсов не должен знать, как работает программа. Ему ставится задача создать максимально удобный для пользователя интерфейс, с помощью которого он может решать конкретные задачи. Предполагается, что программа эти задачи решать может, в ней нет костылей, накладывающих какие-то ограничения и/или условия. Опять-же в грамотно построенном приложении интерфейс никак не влияет на функционирование, что развязывает дизайнеру руки. Хочет — консоль, хочет — веб страничка, хочет — формочка с одной кнопкой «Сделать мне хорошо».
Мы все понимаем, что реальность имеет отличия и не в лучшую сторону, особенно в наших краях, где для экономии бюджета руководители оплачивают труд одного программиста считая, что он и разработчик, и тестировщик и дизайнер, а иногда ещё и маркетолог.
Мы все понимаем, что реальность имеет отличия и не в лучшую сторону, особенно в наших краях, где для экономии бюджета руководители оплачивают труд одного программиста считая, что он и разработчик, и тестировщик и дизайнер, а иногда ещё и маркетолог.
>В сфечиреской разработке в вакууме дизайнер интерфейсов не должен знать, как работает программа. Ему ставится задача создать >максимально удобный для пользователя интерфейс, с помощью которого он может решать конкретные задачи
Какие конкретные задачи? Дизайнер в этих задачах ничего не понимает и не разбирается. Вы понимаете, что задачи бывают сложнее, чем скроллить мышкой странички в браузере? Дизайн приложения вырабатывается годами, а у некоторых десятилетиями. Чтобы дизайнер выработал тот же опыт общения с программой, что и программист с тестировщиком, его надо погрузить в предметную область и посадить
на место диспетчера/бухгалтера/какого-то работника.
Какие конкретные задачи? Дизайнер в этих задачах ничего не понимает и не разбирается. Вы понимаете, что задачи бывают сложнее, чем скроллить мышкой странички в браузере? Дизайн приложения вырабатывается годами, а у некоторых десятилетиями. Чтобы дизайнер выработал тот же опыт общения с программой, что и программист с тестировщиком, его надо погрузить в предметную область и посадить
на место диспетчера/бухгалтера/какого-то работника.
Какие конкретные задачи? Дизайнер в этих задачах ничего не понимает и не разбирается.
Вот в этом основная проблема. Программист решает задачу разработки, а для дизайнер должен решить проблему пользователя, это разные задачи.
Дизайнеры приборной панели авто могут понятия не иметь о конструктиве двигателя, объёме багажника и расположении генератора под капотом. Они решают где разместить отверстия вентиляции, ручки управления мультмедиа-системой, какой формы будет руль и каким цветом подсвечиваются приборы.
Вы смеётесь? Вы поищите в интернете примеры дизайнерских решений в автомобилестроении. Эти прототипы доживают только до выставки, в серию идут решения инженеров. Чтобы дизайнер смог спроектировать рабочее место водителя грузовика, он должен сам уметь управлять грузовиком и иметь в этом солидный опыт. А чтобы размышлять о решетках вентиляции, нужно иметь представление об аэродинамике, понимать как прокладываются жгуты проводов, как лишнее отверстие в панели приборов влияет на её прочность
и безопасность. «Решить проблему пользователя» без подобного багажа знаний невозможно, и разумеется инженер решает её успешнее художника-декоратора.
и безопасность. «Решить проблему пользователя» без подобного багажа знаний невозможно, и разумеется инженер решает её успешнее художника-декоратора.
В качестве дополнения, замечу, что есть промышленный дизайн и есть просто дизайн.
Прототипы на выставках сделаны в первую очередь дизайнерами, а промышленный дизайн — это несколько иная предметная область, где дизайнер знает теормех и, возможно, сопромат.
С точки зрения ПО — дизайнер это плохой человек, правильный человек -UI/UX -который рисует не кнопочки, а сценарии работы с программой и подтягивает под эти сценарии кнопки.
А сами сценарии — воплощение работы с предметной областью, как раз
Прототипы на выставках сделаны в первую очередь дизайнерами, а промышленный дизайн — это несколько иная предметная область, где дизайнер знает теормех и, возможно, сопромат.
С точки зрения ПО — дизайнер это плохой человек, правильный человек -UI/UX -который рисует не кнопочки, а сценарии работы с программой и подтягивает под эти сценарии кнопки.
А сами сценарии — воплощение работы с предметной областью, как раз
Это не означает, что он плохой, просто, если показать его другим экспертам, со 100% вероятностью они его улучшат
эх, самое хреновое, когда сам себя не сильно относишь к экспертам, в результате заводишь ревью, никто ничего не находит, а ты сам себе заводишь пачку замечаний… Печально становится: или лучше тебя нет, или на ревью забили.
А вот сейчас проект, на котором я один разработчик… Из-а вынужденных простоев (зависимости по железу, FPGA) приходилось адски себя удерживать от перфекционизма. В результате получилась достаточно стройная система, на основании которой вышло уже три продукта, только, фактически, с эволюционными изменениями ядра.
>Это не означает, что он плохой, просто, если показать его другим экспертам, со 100% вероятностью они его улучшат
Да щас прям. С 50% вероятностью его ухудшат. Ну а то, что ж я за эксперт, если не найду в чужом коде косяков? Каждому охота повыпендриваться, «а вот я бы тут сделал фабрику фабрик, а вот эти методы можно сделать статичными» и в таком духе. Такие советы не делают код лучше, они делают видимость участия и высокого профессионализма советчиков.
Да щас прям. С 50% вероятностью его ухудшат. Ну а то, что ж я за эксперт, если не найду в чужом коде косяков? Каждому охота повыпендриваться, «а вот я бы тут сделал фабрику фабрик, а вот эти методы можно сделать статичными» и в таком духе. Такие советы не делают код лучше, они делают видимость участия и высокого профессионализма советчиков.
> 3. UI можно сделать и самому…
Ну, Gmail который год живет с UI, который иначе как написанным программистами не назовешь )
Ну, Gmail который год живет с UI, который иначе как написанным программистами не назовешь )
Как подметили выше, не факт, что другой разработчик как-то улучшит ваш код.
Был подобный случай: нужно было написать один достаточно сложный проект. Буквально за день до защиты было решено показать его одному программисту, который в моем кругу общения считается достаточно продвинутым. И что в итоге? «Зачем ты в public классе ты передаешь значение private полю через метод, можно же сделать его public и обращаться напрямую...», «Зачем ты сделала то-то так-то так-то, можно же было проще....» etc. В итоге, после его «набега», в исходниках явно «запахло»(и не горной лавандой) пришлось экстренно откатывать версию.
К чему все это? Да просто этой реальной историей я хотел показать, что вероятность улучшения вашего когда другим разработчиком явно не 100%.
Был подобный случай: нужно было написать один достаточно сложный проект. Буквально за день до защиты было решено показать его одному программисту, который в моем кругу общения считается достаточно продвинутым. И что в итоге? «Зачем ты в public классе ты передаешь значение private полю через метод, можно же сделать его public и обращаться напрямую...», «Зачем ты сделала то-то так-то так-то, можно же было проще....» etc. В итоге, после его «набега», в исходниках явно «запахло»(и не горной лавандой) пришлось экстренно откатывать версию.
К чему все это? Да просто этой реальной историей я хотел показать, что вероятность улучшения вашего когда другим разработчиком явно не 100%.
НЛО прилетело и опубликовало эту надпись здесь
У меня иногда бывает, что, когда отвлечешься, приходит неожиданное решение. Думаешь вроде бы вообще о другом, срабатывает какая-то странная ассоциация, и вот оно. Но это, конечно, случайности.
У меня тоже так бывает, да и думаю у многих. У меня даже есть теория, почему так происходит.
Когда занимаешься задачей, новые данные находятся в оперативной памяти, весь фокус внимания направлен на их восприятие и на текущий вариант решения (обычно на понимание того, как оно работает, или на поиск причины, почему не работает). А когда отвлекся (пошел прогуляться, или просто чай поставить и в окно посмотреть), то информация начинает переходить из оперативной памяти в долговременную, и появляются ассоциативные связи с уже известными понятиями и между новыми.
Ассоциативные сигналы, кончено, возникают постоянно, но когда внимание направлено на новую информацию, воспринимаются только наиболее сильные. Поэтому когда появляется знакомая задача, то и решение можно найти быстро.
Когда занимаешься задачей, новые данные находятся в оперативной памяти, весь фокус внимания направлен на их восприятие и на текущий вариант решения (обычно на понимание того, как оно работает, или на поиск причины, почему не работает). А когда отвлекся (пошел прогуляться, или просто чай поставить и в окно посмотреть), то информация начинает переходить из оперативной памяти в долговременную, и появляются ассоциативные связи с уже известными понятиями и между новыми.
Ассоциативные сигналы, кончено, возникают постоянно, но когда внимание направлено на новую информацию, воспринимаются только наиболее сильные. Поэтому когда появляется знакомая задача, то и решение можно найти быстро.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
6 «вредных» советов разработчику