Андрей

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

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

Насчет показа какого-нибудь ресурса с готовыми верстками - это мазохизм. Я такое тоже практиковал, но быстро отказался, ибо клиент выбирает что-то такое супер пупер, кучи элементов, в плане информационных блоков, виджетов и тд...а наполнять нечем, ладно у вас еще 6 разделов, а бывает так, что кроме адреса и телефона организации заказчик нифига дать не может, но шаблон выбирает под какой-нибудь крупный информационный ресурс, причем убирая все "лишние" блоки шаблон начинает превращаться в полное УГэ :) Либо он смотрит сайт и получается как в пункте 1.

Конечно, люди разные, но я не могу. Лучше это время тратить на личные проекты (опенсорс) и на развитие (новые языки, улучшать фундаментальные знания), либо еще на какое-то хобби (у меня это музыка, например). В долгосрочной перспективе это принесет больше пользы, а качество жизни будет выше. Работать на двух работах, совмещать работу/учебу - все это либо для очень-очень организованных людей (феноменально организованных, которые могут жить четко по плану каждый день), либо для тех, кто особо-то и не вникает (а это напрямую влияет на качество скилла). Кроме того, как не пытался, предел продуктивной работы в сутки - это порядка 6 часов. Все остальное не только не приносит удовольствия, так еще и по качеству получается хуже. Лучше делать одну задачу, "быть медленнее", но делать ее реально круто.

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

Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), - снизу.

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API - это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем UI. Объедините все прямоугольники с API и обзовите слоем сервисов.

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

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

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

Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

А дальше - детально прорабатывайте каждый маленький квадратик. Всё.

Воспользуюсь случаем передать привет своей семье написать пару замечаний.

1. Убрать отметку ответа решением
а) Не с руки бегать за пользователями, задающим вопросы, с требованием «анугад цени время других». Ни модераторам, ни отвечающим. В конце концов, расчёт на поисковую выдачу и долгую жизнь тем.

б) Зачастую знания и умения спрашивающего не дают ему возможность оценить верность ответа. Если учесть, что нередко правильные ответы даются с примесью WTF, то неумеренное эго автора вопроса бывает сильно уязвлено, и верный ответ остаётся за бортом. Не менее редко решением выбираются глупые ответы.
Думаю, FanatPHP может рассказать куда больше:)

Пример: Как работает свойство display с его разными значениями?
Хоть кол на голове теши — что проще, то и верно.

2. Ввести минусование ответов
Не всем, а как на стеке — только с рейтингом не менее ... (скажем, >20 по тэгу). Чтобы тупые ответы опускались вниз. Может, и скрывать ответы при наборе ... (скажем, -5) отрицательных отметок.

3. Рейтинг
Нередко встречаю умных и грамотных людей, не имеющих времени на надрачивание рейтинга. Как вариант, просто недавно зарегистрировавшиеся участники. Нужен механизм оценки «авторитетов» (в хорошем смысле этого слова) для повышения рейтинга.

4. Оценка комментариев
Достаточно часто комментарии дополняют ответ, делают его более объёмным, и заслуживают своей оценки. Почему нет возможности оценить такой вклад?

5. Ввести тэги по вопросам
Зачастую вопросы называют так, что найти их или очень трудно, или просто невозможно.
Пример: Как отследить появление новых элементов в DOM?
В итоге люди тратят время, в то время как ответы уже есть на Тостере Как отловить создание нового IFrame на странице?

Можно предлагать при публикации вопроса список тэгов и это (возможно) даст возможность найти ответ на вопрос до его опубликования. После публикации тэги могут выбрать остальные.
Другая польза от тэгов — поиск для повторных вопросов (см. ниже).

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

7. Плюсы для отвечающих
Почему бы не использовать связь с хабром для раздачи плюшек отвечающим? Например, членство, карму etc.

8. Библиотека решений
Иногда кажется, что грамотный и хорошо оформленный ответ просто тонет в куче мусора и нет никакого смысла ни в расписывании хода мыслей, ни в оформлении.
Пример #1: CSS: Почему происходит смещение изображения при line-height идентичной высоте блока?
Пример #2: Почему при добавлении тега appendChild'oм, контент не отображается?
Пример #3: Разница между background: url('...') и background: url(...)?
И много-много других, к которым я не имею никакого отношения.

Почему не сделать по тем же тэгам (см. п. «Ввести тэги по вопросам») ссылки на основные решения. Которые можно обсуждать, комментировать, модифицировать без принадлежности к авторам (просто список участников с вкладом в решение).

9. Технические доработки
Поиск — нет введённого запроса в поле поиска.
Ответ — нет горячих клавиш для форматирования.
Комментарий — нет возможности форматировать текст.
Комментарий — как быстро получить ссылку (тема + якорь)?
Текстовое поле для комментария — делаешь такие примеры codepen.io/cleric/pen/oBwqn и не понимаешь, почему его подстройка по высоте поля на Тостере не слишком-то корректно работает.
Поле с кодом — вроде несложно добавить white-space: pre-wrap; Для элемента pre, чтобы не было горизонтальной прокрутки для непереносимых строк.

Пы.Сы. Отдельное спасибо Сергею Протько за веру в этот ресурс.

Ходить на «тренировочные» собеседования раз в полгода, чтобы это не казалось чем-то из ряда вон выходящим.

Вариант с обучением через верстку .psd макетов вас до "пика" не доведет. Максимум до уровня рядового "верстальщика". Сверстать статику может каждый второй, кто хоть иногда этим занимается. Если вы нацелены на реальный "пик", то вам надо учиться на основе живых примеров уровня www.awwwards.com www.cssdesignawards.com и www.thefwa.com
Копайтесь, смотрите что как сделано, пытайтесь сами воссоздавать отдельные куски "не смотря под капот" (то есть только на основе того, что вы видите, не залезая в F12). Но перед этим вам надо будет нагнать основы, то есть все что связано с css трансформами, нестандартными лэйаутами и другими трендами дизайна, а то иначе когнетивный диссонанс вам обеспечен. После этого будете долго практиковать анимации, свг, 2d-canvas и в самом конце возможно даже WebGL. Обязателен к употреблению codepen.io
Ну а если прочитав все это вы вдруг поняли, что вас на самом деле не интересуют всякие нестандартные промо-сайты, а вам просто надо уметь верстать странички для стандартных интернет-магазинов или еще чего подобного, то вам достаточно будет потратить 1-2 месяца на чтение вводных статей и начать штамповать сайты на бутстрапе. Вот.

Итак попытаемся разобраться и сделать это логично:
Мы любим фронтенд значит нам нужно что то на языке JavaScript - ищем на гитхабе проекты с большим кол-вом звездочек и все еще "живые":
github.com

Смотрим неколько проектов и смотрим там на контрибьюторов которые внесли много коммитов результат:
pazguille
getify
spicyj
hhaidar
nolimits4web

То же самое для html:
PaulKinlan
hubgit
Ms2ger
LeaVerou - обратите внимание это девочка и еще и из MIT
davelab6
enaqx

Попутно смотрим в какие группы эти ребята входят и отмечаем инетересные
reactjs
html5rocks
GoogleChrome

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

Слушать подкасты это и весело и полезно. Но выбрать для себя подходящий это та еще задача.

Порекомендую несколько, которые мне нравятся:
1) Разбор Полетов - о технологиях, гаджетах и программировании
2) Радио-Т - о технологиях и программировании + болтология :)
3) РадиоJS - о JS и фронтенде
4) Откровенно про IT карьеризм - разговорное шоу с интересными собеседниками, о программировании, карьере и всем-всем
5) RWpod - о рельсах, руби и пр.
6) RubyNoName - о рельсах, руби и пр. сейчас чуть заглохло
7) ruby5 - о рельсах, руби и пр. на английском

+ Бинарное Радио

1) tympanus.net/codrops (как указали в другом ответе)
2) habrahabr.ru/posts/frontend - нувыпоняли.
3) Подписаться и еженедельно читать фронт-енд дайджесты (ну или просто зайти на сайт и читать там выпуски):
a) javascriptweekly.com
b) css-weekly.com
c) tympanus.net/codrops/collective
d) habrahabr.ru/company/zfort - у них самые большие дайджесты, там до кучи еще и дизайн/новости/крутые сайты и прочее.
(соответственно ссылки во всех этих дайджестах часто повторяются, так что не пугайтесь объемам)
4) codepen.io - тут смотрите код, вдохновляетесь чужими работами и пилите свои.
5) Лезете в твиттер, подписываетесь на крутых разработчиков, там тоже проскакивает много годноты.

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

Расскажу как это работает у меня и какие видел реализации.

Вариант уно

• Фронтэндеры работают на Винде и Маке. Хотя сейчас потихоньку всех переводят их на Мак т. к. дизайнеры переходят с Фотошопа на Скетч.
  
• Дизайнеры работают в ФШ и Скетче. Но все больше переползают на скетч.
  
• Проектировщики работают на Винде и Маке. Делают прототипы в Акшуре. На выходе интерактивных html-прототип, который работает везде.
  
• Бэкэндеры работают на чем хотят. Большинство на Линкусе ибо работают уже с готовой версткой.
  

Примерный процесс:

1. Проектировщики делают скетчи, фигачат прототипы, продумывают функциональность и логику работы приложения. Затем интерактивный прототип презентуется перед всей командой (в дизайне ведь все разбираются). На этом этапе вся команда смотрит, чтобы не было принципиальных косяков и всё было реализуемо.
   
2. Макет передается дизайнеру. Совместно с проектировщиком они делают дизайн. Роль проектировщика — авторский надзор за реализацией его идей. Т. е. со стороны UX все конечные решения за проектировщиком, со стороны визуала все конечные решения за дизайнером.
   
3. Готовый дизайн передается фронтэндерам. Дизайнер следит, чтобы всё было ОК со стороны визуала.
   
4. Верстка передается бэкэнду. Дизайнер следит, чтобы все было хорошо со стороны визуала. Проектировщик следит, чтобы все работало корректно со стороны UX.
   
   

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

Далее все по схеме описанной выше.