Pull to refresh
57
0
rimmer333 @rimmer333

User

Send message
Моё удивление в основном тому, что именно вимяне ходят и «говорят со всеми о Боге». От остальных столь трепетного отношения к отвертке я не наблюдаю.
Не хочу вступать в этот холивор, мой редактор — это мой редактор, я не рыцарь его ордена, чтобы ходить за него в крестовые походы. Мой общефилософский подход к вещам: если тебя куда-то изо всех сил тянут и что-то тебе предлагают и нахваливают на замену того, что у тебя и так есть и работает — слушать не стоит. Покуда сам я не найду свои причины пользоваться этой новой хренью, меня против моей старой хрени никто не переубедит. VIM я пробовал, не прижилось. Пробовал много других редакторов, некоторые успешнее, некоторые хуже. Когда-то считал, что круче редактора кода в IDE Delphi 6 вообще ничего на белом свете быть не может, даже HTML c джаваскриптами в нем писал. Много чего еще другого пробовал, под всеми осями. У меня был просто мегаредактор под линуксом (не вим, не скажу какой, там всё равно фишка-то не в нём самом была). С недавних пор нашел себе 2 оконных фаворита, могу vim, если в консоли, но предпочту nano, если есть. И вот меня удивляет эта странная укушенность именно vim-юзеров — топить за свою любимую тулзу там, где их не спрашивали, ругать то другое, в чем они сами не разобрались, и волочить всех против воли в свою религию. В двух конторах, где я работал, vim вообще стандартом был — ты получаешь курс обучения на входе и никакой поддержки на тему поставить что-то другое. Продуктивнее [одной кроссплатформной IDE] для меня в те дни ничего не было, я ставил её в юзерспейс и клал с прибором на мнение всех, кто говорил «Зря ты этой штукой пользуешься». Вышеприведенный рефакторинг, интеграция с гитом искаропки (с гитом, коего в одной из компаний и не знали (!), а я юзал его для себя, и это стало для многих открытием — мол, вон как с кодом оказца можно, зря мы это по старинке-то), да хотя бы и локальный сервер (с горячей клавишей запуска/останова для аллергиков на мышиные хвосты) — это всё в ходе демонстрации впечатляло, хотя у всяких тимлидов сначала вызывало вопрос «А чо не из командной строки?» а потом слегка уязвленное «Понапридумывают же». Могу и из командной, но есть инструменты, которые merge conflict понятнее покажут и быстрее разрешить помогут, чем если руками колупаться. Начальник вот пишет код на полумертвом TextMate на своём маке — я не лезу к нему и не советую своё, потому что понимаю, этот парень вот там умеет быстро. Я в своих редакторах умею быстро, и не надо мне всовывать ваш vim на основе того, что у вас быстро в моём редакторе не получается.
О, забыл Пензенский бульвар еще. Находясь в густо застроенном районе города, он не пересекается и не сливается ни с одной улицей, вещь-в-себе.
40 инженерных проездов Ульяновска — это так называемая промзона, там никто не живет. Есть примерно в том же районе города Киевский бульвар, который находится посреди жилого массива, является тупиком, но при этом имеет перекресток. Есть две улицы Лесных, в разных частях города. Писателей уважаем, в честь Гоголя назвали улицу и переулок, тоже в разных районах. Очень любим даты: кроме улицы 9 мая, имеем также улицу 8 марта, 1 мая (не путать с Первомайской), 9 января (WTF?), и 12 сентября. Потенциал был еще в датах, но что-то расслабились. Есть поселок УКСМ, в котором есть улица поселок УКСМ.
Интересным образом, у всякого мужчины наличествуют соски, которые ему, вершине эволюции, ни к чему. Так выходит, что в ходе развития человека из оплодотворенной яйцеклетки первые недели «включена» только женская часть генома, из-за чего закладываются и развиваются не только соски, но и половые губы, например. Впоследствии «включается» Y-хромосома и «исправляет» то, что получилось прежде, согласно плану строения мужчины — в частности, делает из половых губ мошонку (на ней есть «шов» посередине) и опускает в нее из юрюшной полости половые железы. Соски, правда, остаются.

Поскольку онтогенез считают этаким «кратким изложением» эволюции вида, получается, что первым выделился женский пол, а не мужской.
Эколог по образованию.

Вот тут методолгическая ошибка:
«Вклад самца в потомство гораздо ниже вклада самки.»


Это сейчас так происходит, это данность, уже образовавшаяся на настоящий момент эволюционно. Притом, это происходит в основном у разнополых видов, не у гермафродитов. Гермафродиты если и заботятся о потомстве — то разве только переносят его на себе или охраняют кладку яиц. Они не уходят в декрет на три года, не кормят малышей грудью денно и нощно, не страдают «Ох, из-за этих детей совсем уже из дома перестало выходить», итд. В оплодотворении пробегающих мимо сородичей большинству гермафродитов наличие потомства не помеха. Так что в мысленном реконструировании возникновения половой определенности организма использовать уже образовавщиеся следствия этой определенности — слабое доказательство.

Ни в коем случае не претендую на собственно знание и понимание того, как половая специализация возникла и почему она превалирует. Для меня это нерешенный вопрос, над которым интересно поразмыслить. Как закоренелый эволюционист, я пока предпочитаю для себя объяснение «Так получилось на данный момент» — ровно то же, которое объясняет, например, углерод в качестве основного биогенного элемента, белковую природу всей известной жизни, единство (с некоторыми исключениями) генетического кода и прочие эволюционные свидетельства.
Вот такая штука еще была github.com/jimeh/php-rack
Господи, да кто же говорит о методологиях тут? Если есть методология (или есть где ее изучить) — это прекрасно. Я ни разу не заикаюсь о том, как и когда что делать, как строить процессы, какую взять методологию — потому что тут ничего универсального не посоветуешь, это будет все равно написать статью «Если вы решили стать программистом, то какой язык выбрать». Статья — проповедь именно для вчерашних спецов, которым сказали: с завтрашнего дня ты руководишь отделом. Я сплошь и рядом вижу, что у многих это трансформируется в вывод «Буду делать, что делал всегда, за начальничью зарплату, отлично!». Нет, не выйдет — это другая работа, с такими вызовами, которых никогда не встретишь на прежнем месте, с другим кругом задач, для неё нужно перестроить своё восприятие работы.

Подход с изучением методологий опасен вещью, описанной в последнем разделе — руководитель может увлечься изучением методологий, посещением семинаров, разработкой процесса. Зачастую решения по наличествующим проблемам откладываются до изучения «волшебной» методики — мол, буду с сертификатом, тогда и буду всё правильно решать. За время обучения иногда происходит непоправимое.

Речь-то идет о готовности вчерашнего рядового поменять набор целей и задач в голове. Эта статья отвечает на вопросы будущего начинающего руководителя. А вот когда он уже начал руководить — тут найдутся советники посодержательнее меня.
Не знаю, в нашем тоже работает. Мне вообще повезло работать в компании, где большинство вещей устроены так, как я мечтал, и не так, как обычно этого ожидаешь от всех.
Вот это очень клево. А мысль про самурая у меня всегда была именно в этих словах :)
Ну тогда просто напишите, как надо, в этот же хаб.
Наверное, вы не видите заголовков, они предательски серые.
Если Вам надо обучить человека, то такой подход хорош. Если это уже middle и выше — то это перевод ресурсов. Когда начальник приходит к опытному сотруднику с заданием «ааааа сделай мне вот это не знаю как» — это провал. Всегда необходимо направляющее ТЗ, дабы наметить ход выполнения задачи. Никто не заставляет вас разжевывать, но все люди воспринимают реальность по-разному, потрудитесь хотя бы объяснить, чего вы ждете на выходе и в примерное число этапов, это облегчит жизнь человеку и повысит эффективность выполнения задания.

Нигде не сказано «Дайте человеку задачу в виде общего направления без ТЗ». Уровень проработки при постановке задачи — да, индивидуальный. Я не могу дать один исчерпывающий 100% верный совет всем и каждому. Некоторым моим сотрудникам никогда даже не надо было говорить в каком направлении работать — они изначально настроены на один лад со мной и делают всё сами. Но главная тема всего абзаца, а не нескольких слов — прекратите попытки все рядовые операции делать самостоятельно, дайте это сделать вашим сотрудникам, научите их как сделать и не облажаться. Это не руководство в двух фразах, как наладить процесс обучения в любой компании.

Все те вещи, которые я перечислил в качестве человеческих проблем — разумеется, не каждодневный труд начальника, упаси боже. Такие ситуации могут случиться (а если руководить дольше нескольких месяцев — обязательно случатся хоть раз). Важно, во-первых, не спрятать голову в песок при их наступлении — именно о том и раздел — а во-вторых, понять, что это не что-то из ряда вон, что это неотъемлемая часть руководства как работы. Если получится предотвратить неприятные ситуации или допустить их наступление лишь однажды — ну что ж, отлично.

разбирать ссоры и претензии


Начальник не должен принимать чью-либо сторону. Он может обязать «разобраться с этим» вызвав обоих на ковер, но не более. Начальник нейтрален ко всем подчиненным, или любит одинаково всех, как кому нравится.


Не вижу противоречия вообще.

Только ситхи возводят все в абсолют.


Есть разница между абсолютом и последовательностью.

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


О необходимости это делать подчиненным нигде не сказано. Это необходимо делать начальнику. Также, follow-up — это не процесс принятия решений, а их «бухгалтерия», документирование, которое будет необходимо, если отдел растет и получает больше работы и ответственности (ну, если вас только не нанимали для плавного закрытия отдела).

Но книги по менеджменту и управлению людьми — последнее что стоит делать начальнику в СНГ, серьезно.


Не вижу, как приведенный кусок моей фразы иллюстрирует обратное.

Твердое решение — не всегда верное.


Что опять-таки не оспаривается в тексте статьи. Я не раз видел у других и сам испытывал страх перед необходимостью принять решение. Важно понимать, что затягивая вопрос, руководитель осложняет своё положение. Отличное решение — отлично, хорошее решение — хорошо, плохое решение — плохо, но лучше бы исправить, но отсутствие решения — это хуже всего.
Вообще, половину статьи можно разобрать на цитаты «как не стоит руководить людьми»


Всё же прошу привести примеры.
Изложили ясно, и я именно такой вариант и подразумевал. Code review и тестинг до релиза. Просто поэкономил букв. Нигде у меня не написано «Пусть его лажу видят все, пусть он страдает и пьет горькую», да и вряд ли у вас будут такие сотрудники.

Вокруг меня просто много примеров, когда начальник — это самый высокопроизводительный сотрудник, no matter what. Отдел по показателям считается в норме, потому что главный чувак молотит за четверых без сна и отдыха. Проблемы начинаются, когда он болеет или решается уйти в отпуск через 2.5 года — потому что оказалось, что он пытался руководить «личным примером», а команда по факту расслабилась, да и сам начальник сгорел. Первое, от чего хочется предостеречь — это от такого подхода.
Вы делаете новые фичи прямо на продакшене? Или всё-таки сначала отправляете свежий коммит на code review, а потом тестерам? Речь именно об этих операциях — проверьте то, что делает сотрудник до того, как оно дошло до истинного выполнения. Писать за сотрудника каждую строчку кода или аналитическую записку вы не сможете, времени не хватит. Но ловить проблемы до того, как от них пострадали клиенты — это практика более общая, находящаяся за пределами именно руководства. Уж об этом я стараюсь не писать.

В чем еще я оказался «илитарен»?
Рекомендую обратить внимание на этот генератор сложных бэкграундов glan.github.com/CSS-Patterns-Workbench/
Мне всегда было забавно проследить, как сложны в реализации наиболее просто формулируемые задачи, каких масштабов и коварства дьявол кроется в деталях.

Information

Rating
Does not participate
Location
Ульяновская обл., Россия
Date of birth
Registered
Activity