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