Знаете, у меня в команде несколько очень хороших ребят, которые сейчас на последних курсах. Есть и такие, которые за несколько лет после универа стали отличными спецами.
И я, основываясь на своём опыте, уверен, что любого человека надо достаточно долго учить, прежде, чем он станет профессионалом.
А делить сотрудников на «полезных» и «бесполезных» считаю в высшей степени глупым. Если сотрудник бесполезен, то либо руководитель работает плохо (косяк руководителя), либо мы наняли не того человека (косяк руководителя).
А вообще, я Вам советую почитать что-нибудь по управлению командами. Например, начать с книги «Успешные проекты и команды» Демарко и Листера (aka Peopleware). Немного меняет взгляд на отдельных людей и команду в целом.
Я уже прокомментировал ниже. Я бы не назвал этих программистов «опытными». Это программисты — которые просто имеют «большой стаж работы», но так и не переросли состояние джуниора.
С другой стороны, я не исключаю, что это настоящие опытные профессионалы, которые пытаются донести до молодых (и не очень) перфекционистов простую мысль: код не должен быть «идеальным». Он должен быть структурирован (без излишеств), быть понятным и, главное, выполнять поставленную задачу.
Я думаю, что это признаки программиста, который так и остался начинающим, несмотря на свой стаж…
Кстати, про комментарии: я своих учу, что, надо комментировать только «нетрадиционные» решения и (увы, такое тоже случается) заплатки. Если в нормальном методе есть комментарий типа «дальше мы делаем что-то», то это что-то — первый и практически стопроцентный кандидат на вынос в отдельный метод.
Исключения портят привычку ;). Если на одном проекте можно, а на другом нельзя, возникает резонный вопрос: «а так ли уж нельзя?» Теоретически, прототип так писать можно, но только если есть уверенность, что руководство не «продавит» на «сохранить работающую функциональность». Выкидывать очень сложно, обычно.
Если для того, чтобы открыть на пару секунд две минуты делать надо — лишний раз задумаешься, надо ли.
Приведу пример — у меня компьютер сам выключается дома в 11 вечера. Причём, отменить это можно, просто набрав команду shutdown /a в течение одной минуты. Но, набирая её, ты должен понимать, что нарушаешь правила, тобой же установленные, и что для этого нужна веская причина. Я иногда это делаю, но, в большинстве случаев, понимаю, что действительно пора спать :).
Публиковал здесь с год назад примерно статью про поток. Думаю, дело не столько в усталости мозга (хотя с этим тоже, безусловно, согласен), сколько именно в отвлечениях.
Кстати, с интернетом бороться можно достаточно просто — прописываете в hosts доены любимых сайтов и заворачиваете их куда-нибудь. Например, на Localhost. И всё. Никаких фэйсбуков, ютюбов, твиттеров и лентару.
Я конечно чего-то в стартапах могу не понимать, но что-то мне подсказывает, что «выбрать средства разработки» и «определить архитектуру» — задачи ну никак не руководителя проектов.
Вообще, по названию — очередная лекция на тему people management, а по содержанию — чистый техноликбез. ИМХО, название «Как говорить на одном языке с разработчиком» гораздо больше подходит.
Спасибо за ссылку. Я этого пропустить по специфике работы не мог :). Это, правда, пока ещё только RC, не полноценный релиз.
Очень надеюсь, что это не будет всей информацией, которую по SL дадут на билде. И так уже сообщество в панике в связи со всякими громкими заявлениями про HTML5 и молчание про SL. Если не обнадёжат — Silverlight Три четверти программистов потеряет.:(
И ещё, уважаемое сообщество! Все склонны ошибаться. Идея интересная, лишние фичи можно убрать. Зачем сливать человеку карму? От того, что автор не сможет постить статьи в профильные блоги мир лучше уж точно не станет :).
P.S. С автором не знаком, личной заинтересованности нет ;)
Вы хотите, чтобы на сайт заходила куча народу, а не только десяток энтузиастов?
Зачем вы мешаете людям пользоваться вашим сервисом? Вспомните про бритву Оккама. Не плодите фичи. Отрежьте всё лишнее и оставьте главное — возможность делиться вопросами и смотреть их.
Достигнете две-три тысячи посетителей ежедневно и стабильно пару-тройку постов в день — сможете думать о дальнейшем развитии.
Все успешные начинания просты изначально. Советую потратить пару часов и прочитать Rework.
Не убивайте хорошую идею, сделайте сервис простым!
Ага. Статья-то отличная, но слишком уж кажется agile-центрированной, хотя специфики методологии, честно говоря, сразу не заметно. Есть ощущение, что, если автозаменой убрать слово Agile и заменить Scrum Master на, скажем, Project Manager, то смысл совершенно не изменится ;).
Показалось странным противопоставление «белого и пушистого» agile и грязного и страшного не-agile.
На мой взгляд, всё зависит от качества менеджера, который может любой agile превратить в ад для сотрудников: кучу требований и мероприятий, в которых они не видят смысла и ценности. В то же время, грамотный руководитель способен применять любую методологию, делая при этом так, чтобы команде было комфортно и гармонично работать.
Не в методологии дело а в качестве руководителя, в его навыках people management'а. Потому, что неумение работать с людьми для руководителя — профнепригодность. И никакая методология это не исправит.
Всё в порядке, автор делает бизнес. Смотрите на заголовок, о котором уже упоминали: «Стратегия успешного бизнеса». Это говорит о том, что целевая аудитория данного шедевра не программисты, а бизнесмены, которым кто-то когда-то нашептал, что «иметь вебсайт это круто, потому что у всех есть».
Бизнесмен, который, скажем, продаёт чапельники и никакого отношения к IT не имеет, увидит два маркера: «сайт» и «успешный бизнес», которые у него уже чётко ассоциируются, спасибо современным трендам. Вот и купит он эту книжку, прочитает пару страниц и решит, что это сильно сложно и требует специального образования. В результате — он приходит в веб-студию или нанимает собственного айтишника, который подкладывает эту книжку под монитор, чтобы было повыше. И польза абсолютно всем.
А вообще, я Вам и Вашим коллегам сочувствую. Если попробуете писать нормально, то, уверяю вас, сложных проблем станет гораздо меньше ;)
И я, основываясь на своём опыте, уверен, что любого человека надо достаточно долго учить, прежде, чем он станет профессионалом.
А делить сотрудников на «полезных» и «бесполезных» считаю в высшей степени глупым. Если сотрудник бесполезен, то либо руководитель работает плохо (косяк руководителя), либо мы наняли не того человека (косяк руководителя).
А вообще, я Вам советую почитать что-нибудь по управлению командами. Например, начать с книги «Успешные проекты и команды» Демарко и Листера (aka Peopleware). Немного меняет взгляд на отдельных людей и команду в целом.
С другой стороны, я не исключаю, что это настоящие опытные профессионалы, которые пытаются донести до молодых (и не очень) перфекционистов простую мысль: код не должен быть «идеальным». Он должен быть структурирован (без излишеств), быть понятным и, главное, выполнять поставленную задачу.
Кстати, про комментарии: я своих учу, что, надо комментировать только «нетрадиционные» решения и (увы, такое тоже случается) заплатки. Если в нормальном методе есть комментарий типа «дальше мы делаем что-то», то это что-то — первый и практически стопроцентный кандидат на вынос в отдельный метод.
На мой взгляд, Вы используете идеальный подход. После того, как всё продумано, код писать — одно удовольствие. Да и очень быстро получается.
Приведу пример — у меня компьютер сам выключается дома в 11 вечера. Причём, отменить это можно, просто набрав команду shutdown /a в течение одной минуты. Но, набирая её, ты должен понимать, что нарушаешь правила, тобой же установленные, и что для этого нужна веская причина. Я иногда это делаю, но, в большинстве случаев, понимаю, что действительно пора спать :).
Кстати, с интернетом бороться можно достаточно просто — прописываете в hosts доены любимых сайтов и заворачиваете их куда-нибудь. Например, на Localhost. И всё. Никаких фэйсбуков, ютюбов, твиттеров и лентару.
Вообще, по названию — очередная лекция на тему people management, а по содержанию — чистый техноликбез. ИМХО, название «Как говорить на одном языке с разработчиком» гораздо больше подходит.
Очень надеюсь, что это не будет всей информацией, которую по SL дадут на билде. И так уже сообщество в панике в связи со всякими громкими заявлениями про HTML5 и молчание про SL. Если не обнадёжат — Silverlight Три четверти программистов потеряет.:(
P.S. С автором не знаком, личной заинтересованности нет ;)
Вы хотите, чтобы на сайт заходила куча народу, а не только десяток энтузиастов?
Зачем вы мешаете людям пользоваться вашим сервисом? Вспомните про бритву Оккама. Не плодите фичи. Отрежьте всё лишнее и оставьте главное — возможность делиться вопросами и смотреть их.
Достигнете две-три тысячи посетителей ежедневно и стабильно пару-тройку постов в день — сможете думать о дальнейшем развитии.
Все успешные начинания просты изначально. Советую потратить пару часов и прочитать Rework.
Не убивайте хорошую идею, сделайте сервис простым!
На мой взгляд, всё зависит от качества менеджера, который может любой agile превратить в ад для сотрудников: кучу требований и мероприятий, в которых они не видят смысла и ценности. В то же время, грамотный руководитель способен применять любую методологию, делая при этом так, чтобы команде было комфортно и гармонично работать.
Не в методологии дело а в качестве руководителя, в его навыках people management'а. Потому, что неумение работать с людьми для руководителя — профнепригодность. И никакая методология это не исправит.
Бизнесмен, который, скажем, продаёт чапельники и никакого отношения к IT не имеет, увидит два маркера: «сайт» и «успешный бизнес», которые у него уже чётко ассоциируются, спасибо современным трендам. Вот и купит он эту книжку, прочитает пару страниц и решит, что это сильно сложно и требует специального образования. В результате — он приходит в веб-студию или нанимает собственного айтишника, который подкладывает эту книжку под монитор, чтобы было повыше. И польза абсолютно всем.