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

ща кто-то скажет "пишите лучше ТЗ/ТО/хотелки" но тогда получается что я все свое время будут тратить на это, опыт у меня есть но не на столько чтоб представить все возможные проблемы и их изложить, и придумать решения.

но как то же это дело решается??

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

DlTA
По второму вопросу могу сказать следующее:
оцениваете время на выполнение этой задачи собой + плюс накидываете немного на то, что человеку нужно будет разобраться или найти решение. Остальное - не оплачивается.
И срочные заказы лучше самому

у меня поддержка единого проекта, так что режим работы почти как "ходить на работу для обслуживания предприятия"
периодически всплывают косячки/доделки/новинки

ТЗ в любом случае писать.
Чтобы не проверять все руками, что он там наговнокодил -- прикручивай кодснифер на хук гита.
Так, если чел не допишет пробельчик где-то там, то он не сможет даже коммит (и/или пуш) сделать пока не исправит.
Нет гита? Прикручивай.
Ну а написанный алгоритм так и так придется проверять уже самому.

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

Но код может проходить линтер и юнит-тесты и быть совершенно бредовым.
И вот поэтому без обязательного code review перед вливанием feature-ветки в мастер жизни всё-таки нет.

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

это все еще куда не шло, хотя в моем варианте любой код перед отправкой многократно утюжится на локали

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

так вот все равно получается что время на кодинг у меня уменьшится как минимум в 2 раза, а у вас как?

воркфлоу полюбому must have:
cvs (git recommended)
task(bug) tracker [+ timetracker] - сразу лучше ставить время дедлайна (разумеется с запасом) но без дедлайна будет сидеть неделю и ковырять непойми что
code review изначально первых 10 решенных задач, нужно самому перелопатить и тыкнутьпальцем что делать не так. если человек после всего этого продолжает говнокодить, то скорее всего он неисправим и трудно будет все время
unit [+ functional] tests (recommended)
по желанию прикрутить чекалки кода как советовали выше.
ну и проговорить (можно сделать в электронном виде) конвенции программирования, а-ля как именовать переменные, создавать таблицы/поля/индексы в бд, структура проекта, куда и как создавать новые файлы

ок,
а как оценивать работу

и как расчитывать затраты на работу?

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


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

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

1, В первую очередь поговори с человеком.
2, Сборка каверзных вопросов включи в диалог(то что давалось тебе с трудом + возможно давалась другим) есть мнение самые "каверзные вопросы" на которые вы сами знаете ответы - нету не на форумах или они встречаются настолько редко что не находят внятные ответы.
3, Если провести опрос правильно хуже "вас" человека найти трудно...
4 Целеустремленность не мало важный фактор держите человека на уровне "прорыва" ~выплатами~ ~поощрениями~ небольшими но ведущими человека к ---- вознаграждению.
5, Мотивация если человек после разговора не горит "Программированием" ожидать от него чего то сложно.


Пунктов много...