Да так и получается. Сначала просто пишешь код. Потом пишешь хороший код. Потом тебе говорят «слушай, у нас тут новенький, опыта нет, пусть пока под твоим присмотром кодит». Потом из команды уходит тимлид и тебя ставят на его место, а еще оказывается, что ты должен ходить по совещаниям, следить за продуктивностью команды и нести ответственность за ее косяки. А потом ты просыпаешься и понимаешь, что последний раз действительно кодил черт знает когда, потому что на это банально нет времени. Поздравляю — ты успешно перешел из программистов в менеджеры!
Есть другая сторона. Когда твой коллега ищет подарок племяннику на день рождения, ты говоришь ему: «Слушай, а купи настолку. Тут магазин в двух шагах, а я номер дам, тебе скидку по нему сделают». И все выиграли — твой коллега лишился головной боли, ты получил бонус на карточку, магазин продал коробку и получил нового клиента.
Как вы определяете, что надо улучшать? То есть, кто отвечает за предложения из серии «эй, а давайте поместим сюда фотографии играющих людей» или «эй, а давайте оставим книгу отзывов на кассе» — специально нанятый человек, или эта функция каким-то образом распределена по группе людей, или еще какой-то вариант?
Только первая ступень. И не буквально «приземлилась как на видео», а просто приняла вертикальное положение и погасила скорость перед приводнением в океан. Тестить посадку на землю побоялись, потому что инженеры оценивали вероятность успеха всего в 30-40%.
Английский в туристических местах знают абсолютно все. У меня есть опыт и 40-километрового забега по джунглям с проводником, говорящем только на тагальском, и 30-часового плаванья в лодке с местными рыбаками, говорящими черт их пойми на каком, так что любителям приключений все пути открыты =)
Я и не обещал идеальное английское произношение =) По поводу страшилок каждый для себя решит, могу только сказать, что за три месяца никаких особых проблем не было.
Жаждущие могут еще попробовать вариант с Филиппинами. Не знаю насчет языковых школ, но остальные условия выполняются — тепло, недорого, английский и ад с акцентами.
Это далеко не всегда работает. Поизучайте историю рынка текстовых редакторов — была тысяча и одна компания, которая приходила к вполне разумной мысли: «Эй, да ведь 80% пользователей текстовых редакторов используют только 20% функций!» И дальше они пытались сделать что? Правильно, маленький и легкий юзер-френдли текстовый редактор, в котором будут только 20% востребованных функций. А вот получилось сделать таких легких редакторов около нуля, потому что на практике из 80% пользователей каждый использует свои 20% функций, и продукт получается либо слишком нишевый, либо полнофункциональный, но тогда он превращается в «еще один текстовый редактор».
Мой посыл заключался в том, что это специализированный инструмент, и применять его надо только там, где надо, а не везде. Выразился, возможно, излишне категорично, но я тут ни при чем, это всё утро понедельника.
Статья от еще одного человека, не понимающего закон Парето (я об авторе, а не переводчике).
В большинстве случаев, около 80% результата происходят из 20% причин. Эти цифры могут меняться – иногда это 70/30 и иногда 90/10.
ДАЛАДНО?! Серьезно? 70/30 и 90/10? Один из самых важных аспектов в законе Парето, о котором никто не говорит (помимо того аспекта, что надо серьезно постараться, чтобы найти ситуацию, в которой закон Парето работает), заключается в том, что 80 и 20 — это разные вещи, и их сумма не обязана быть равной 100, как любят показывать в горе-статьях. И тогда внезапно оказывается, что если 20% усилий дают 80% результата, то 20% от этих 20% усилий дадут 80% от 80% результата, и вот уже мы получили соотношение 4/64, а это все еще закон Парето. А потом мы можем провернуть такой трюк еще разок, и вот наше соотношение 0.8/51. Один процент усилий дает половину результата, хе-хей. Но все упорно рассказывают про 80-20, 90-10 и 64.738-35.262.
Сейчас тоже делаем реалтайм-приложение с бэкендом на PHP и в поиске решения действовали, в общем, похожим образом. Изначально была идея сделать всё просто и изящно — PHP для обработки сообщений от клиента + Redis (в первую очередь из-за Publish/Subscribe из коробки) + Webdis в качестве транспорта сервер-клиент, но, увы, вебдис (пока еще?) не годится для продакшена и пришлось заменить его на Node.js+Sock.js.
А кто-нибудь пробовал вместо парного программирования использовать цикл код->рефакторинг->код->рефакторинг таким образом, что пишем код не заморачиваясь, а грядущие и грянувшие архитектурные проблемы выписываем в трекер и решаем в фазе рефакторинга? И, предвосхищая ответ, — что в этой схеме не работает?
ДАЛАДНО?! Серьезно? 70/30 и 90/10? Один из самых важных аспектов в законе Парето, о котором никто не говорит (помимо того аспекта, что надо серьезно постараться, чтобы найти ситуацию, в которой закон Парето работает), заключается в том, что 80 и 20 — это разные вещи, и их сумма не обязана быть равной 100, как любят показывать в горе-статьях. И тогда внезапно оказывается, что если 20% усилий дают 80% результата, то 20% от этих 20% усилий дадут 80% от 80% результата, и вот уже мы получили соотношение 4/64, а это все еще закон Парето. А потом мы можем провернуть такой трюк еще разок, и вот наше соотношение 0.8/51. Один процент усилий дает половину результата, хе-хей. Но все упорно рассказывают про 80-20, 90-10 и 64.738-35.262.