Спасибо за статью, а в особенности, за подкрепление основных тезисов генеративными котиками :)
От себя хотел бы добавить, что, как уже кто-то выше заметил, ваш «здравый смысл» очень похож на soft-skill «Критическое мышление». И, я в этом с вами полностью согласен, это самый ключевой навык любого профессионала. В своей практике управления разработчиками я всегда начинаю погружение в софт-скиллы с более простой формы, которую называю «Навык сомневаться»: – Сомневаться в своих убеждениям (Правильно ли я понимаю, что...?) – Сомневаться в корректности поставленной задачи (Какого результата требуется достичь, оптимальным ли путем мы пытаемся до него дойти?) – ... в оценке трудозатрат (Хватит ли времени на выполнение задания, если твой подход не сработает? Стоит ли заложить небольшой буфер на исследование вначале и на багфикс в конце?) и т.д.
Обычно, уже этого оказывается достаточно, чтобы слегка расшевелить молодых и горячих разработчиков, немного затормозить темпераментных и прорывных визионеров от продукта и основательно приземлить клиентский отдел.
Но, в более широком смысле, этот навык – это лишь один из кусочков пазла, который плохо работает без поддержки навыков коммуникации, эмпатии, лидерства и креативного мышления.
Основной вопрос, который меня мучает уже продолжительное время – как повлиять на развитие гибких навыков в ИТ в широком смысле и как прокачать их у конкретного человека или небольшой группы людей?
Не могу согласиться с вашим графиком уровня образованности студентов и потребностями рынка
график
На мой взгляд, потребность рынка на вашем графике содержит не ожидания от потенциальных работников по теоретическим и практическим навыкам, а качественный уровень компании, которая нанимает сотрудников. Это и уровень предлагаемых зарплат сотрудникам, и соц. пакет и общий уровень проектов, выполняемых компанией.
Во первых, ваша кривая рынка может быть смело продолжена в сторону крупных компаний-заказчиков, которым необходима серьезная экспертная оценка какой-либо деятельность, консалтинг, например.
Во вторых, кривую можно сегментировать относительно уровня выполняемых проектов.
Согласитесь, чем раньше студент начинает работать, тем скорее угол наклона его кривой уменьшается. В конечном итоге работа может заполнить все время и сотрудник перестанет заниматься саморазвитием, наращивая лишь практический потенциал.
Увеличить угол позднее становится трудно, молодые люди объективно проще обучаются.
Взять на работу высококвалифицированного с теоретической точки зрения сотрудника без опыта эффективнее с экономической точки зрения (с геометрической кстати тоже, катет < гипотенузы)
Итого, ваш подход: универ отстой, на работе меня всему научат подходит только нижней части рынка работодателей, привлекает низкоквалифицированных кадров, обеспечивает краткосрочную выгоду работнику и компании.
Пока вы так считаете, все интересные честные проекты в бизнесе будут проходить мимо вас прямо к нам ;)
23)… Я использую облако амазон и в любой момент могу развернуть там тестовое окружение, получить нужное количество ip и многое другое. Облака не во всех ситуациях выгодны помните об этом тоже.
Расскажите пожалуйста про облака поподробнее. По какой причине облако может быть не выгодно для веб разработки и зачем разворачивать тестовое окружение в амазоне?
И еще про Амазон: сколько у вас инстансов и примерно в какую сумму это выливается ежемесячно?
15) Имейте возможность принять или заплатить деньги любым способом. ...
Наверное вы имели в виду лишь различные способы проведения операций с деньгами, но по моему также важным вопросом является постоянная платежеспособность фрилансера. Расскажите как вы начинали? ;)
Спасибо. В любом случае статья получилась интересной и я с удовольствием осознал что большинство из ваших мыслей мне близки, и до идей которые вы излагаете так или иначе я тоже дошел в процессе своей работы.
Вы совершенно правы, они не скоты. Несомненно иногда проскакивают совсем уж лиственные породы деревьев, но в общем массе они знают чего хотят и требуют бережно относиться к их идеям и мыслям. О том, как отказываться от работы с заказчиком, потому что он бревно, и никакими разумными издержками этого не покрыть, я думаю вы тоже упомянете где нибудь (раз уж диалог с читателями планирует быть долгим :), но это тема для отдельного обсуждения.
Мне же хотелось дать вам обратную связь, чтобы следующие части были более структурированы, логичны и наполнены картинками и примерами. Я не зря делаю акцент на картинках, к которым вы как-то не привыкли: ) Читать полотна текста, пусть и написанного самым лучших рассказчиком, очень утомительно. Картинки разряжают текст, дают возможность глазам отдохнуть чуть чуть перед новым погружением в пучины ваших размышлений. Не говоря уже о том, что информацию можно представлять в различных формах, и иногда выбор удачной формы влечет за собой лучшее понимание содержания.
В целом статья написана живо, с юмором, Задорновым и вые зачеркиваниями, но я поставил вам минус. И вот почему:
1. Где картинки? Хоть одна. Хотя бы рядом с PERT диаграммой.
2. В чем состоит цель вашей статьи? 95% ваших читателей фейлят проекты потому что срываются сроки, но после прочтения Вашей статьи этот процент не уменьшится ни на йоту. Потому что вы не предлагаете решение. Разбить ТЗ на блоки или умножить время на 1.2, извините, но это же и так очевидно, имхо.
Статистику взял из кучи книг по управлению проектов, которые пришлось перелопатить.
3. Вау! Класс! Книжки! Куча! Управление проектами! Ссылки? Авторы? Названия? Ну вы понимаете, о чем я...
Не сочтите, меня за толстого тролля, но в этой статье нет ничего. Вместо абстрактных подсчетов стоимости проекта и процентов взятых с потолка приведите один пример. Понятное дело, что реальные ТЗ выкладывать сюда не стоит, но давайте вместе придумаем какой нибудь example.com, сроки которого сколько-то месяцев, а функциональность размазана на столько-то блоков? Расскажите, как правильно вытащить из заказчика всю нужную информацию за минимальное количество итераций. Поведайте о том, как добиться лучшего понимания у заказчика в вопросах взаимодействия различных частей проекта, чтобы когда на середине в его буйную голову постучится дрозд он осознавал какой объем работ придется переделывать. Как вовлечь заказчика в процесс разработки с целью получения быстрого отклика на неочевидные моменты реализации? Спасибо.
Как выпускник кафедры иформатики Мат-Меха этого года хочется отметить тот факт, что за все 5 лет в меня несколько раз пытались вложить инструментарий Java, но я так и не услышал ни слова о веб программировании.
Написание алгоритмически сложного кода — это конечно хорошо, но цикл то разработки с этого только начинается. А как же сопровождение, тестирование, внедрение, версионность и командный таск-трекинг?
Охотно верю что спецкурсы кафедры системного программирования могут покрыть все вышеперечисленные темы. Но хочется кричать и громко ругаться, когда понимаешь, что ваши коллеги с соседней кафедры приходят к пониманию процесса разработки только благодаря книжкам и методу научного тыка, хотя на мат-мехе столько светлейших умов!
Вокруг нас на факультете столько нерешенных полезных задач, взять хотя бы электронное расписание. Вот вам и пользователи системы, и тестировщики, а таск-трекер можно хоть на баобаб* вешать. Я уж не говорю о том, что пора бы познакомить студентов мат-меха с хорошо-сделанным местным веб-сайтом. А то стыд то какой, мат-мех лучше всех, а расписание в docx скачивать приходится.
Чтобы этот коммент влился в контекст вашей статьи рискну предложить вам в следующем году изобрести полезный для студентов студенческий проект. Уверен, он привлечет немалый интерес среди студентов 2 — 4 курсов
Спасибо за вторую интересную подборку, но, думаю многие согласятся, в вашей первой версии были очень полезные ссылки на RSS. Тут их чертовски не хватает = )
Не могу с Вами не согласиться в вопросе о полезности jQuery, хочу лишь заметить, что Вы скорее всего сначала читали документацию по jQuery, а лишь затем начали использовать методы, упомянутые выше.
То есть, иными словами, вы заранее знали, что делает метод attr, до того как встретили его в коде. И даже если бы Вы сначала с ним встретились, Вам все равно пришлось бы заглянуть в доки, чтобы удостовериться, что вы правильно поняли сферу его применимости.
Если весь код, который Вы так или иначе разрабатываете в каждом проекте полностью задокументирован, скорее всего наш спор останется за Вами.
Но много ли Вы знаете разработчиков, которые любят писать документации?
Есть всяческие phpjavaDocs, подгружение описаний методов в разных IDE, и тому подобные штуки, которые как раз и помогают находить баланс между длиной имени и описанием в комментах, но кажется, к этой священной войне они не имеют отношения ;)
Когда надо назвать метод «getElementsByTagName()», а когда — просто «byTag()»?
Изначально я конечно хотел не холиварить только про названия переменных, но можно и аккуратно пройтись по методам =)
byTag() — имхо, очень плохо по сравнению с getElementsByTagName(). По крайней мере по двум причинам —
1. метод с точки зрения семантики это скорее глагол, чем наречие. То есть get в названии метода собственно и характеризует действие, заложенное в реализации данной функции.
2. в слове Elements, точнее сказать, в последней букве, на мой взгляд, есть важная семантическая нагрузка названия метода. Множественное число дает понять, что метод вернет коллекцию (в достаточно широком смысле этого слова).
Итоги : в названии метода должен быть глагол, название не должно порождать неоднозначности в трактовке выходных параметров.
Мой выбор в таком случае getElemsByTag()
Я конечно сейчас балансирую на грани начала очередного холивара, но вам не кажется, что если вы знаете, что должно храниться в переменной, то придумать ей название не так уж и сложно?
Очень интересно было бы почитать пост о том, какие возможности дает Гугл по интеграции именно с учебным процессом. Можно ли моделировать общее расписание для всех преподавателей и всех курсов с поиском например по номеру аудитории или по дате проведения семинара и преподавателю. Как в Гугле хранить описания курсов и т.п.
Учился в Праге в Карловом университете прошлый семестр, и кажется, в Чехии на ЗАКОНОДАТЕЛЬНОМ уровне все вузы и колледжи должны иметь некую информационную систему, например вот такую.
Спасибо. Вот только я бы книжку Совершенный код поставил на первое место, а еще бы добавил примеров хорошего кода хотя бы по паре строчек на каждый пример плохого
Уот эти ребята
Правда мне сейчас начнут говорить что это не css вовсе, ведь тут есть и переменные, и функции.
А для особо страждущих — все отступы и пикселя можно задать в одном месте.
Правильнее было бы перестроить текст таким образом, чтобы совсем избавиться от этих запятых. Такая верстка немного портит впечатление от статьи в блоге о верстке.
Спасибо за статью, а в особенности, за подкрепление основных тезисов генеративными котиками :)
От себя хотел бы добавить, что, как уже кто-то выше заметил, ваш «здравый смысл» очень похож на soft-skill «Критическое мышление». И, я в этом с вами полностью согласен, это самый ключевой навык любого профессионала.
В своей практике управления разработчиками я всегда начинаю погружение в софт-скиллы с более простой формы, которую называю «Навык сомневаться»:
– Сомневаться в своих убеждениям (Правильно ли я понимаю, что...?)
– Сомневаться в корректности поставленной задачи (Какого результата требуется достичь, оптимальным ли путем мы пытаемся до него дойти?)
– ... в оценке трудозатрат (Хватит ли времени на выполнение задания, если твой подход не сработает? Стоит ли заложить небольшой буфер на исследование вначале и на багфикс в конце?)
и т.д.
Обычно, уже этого оказывается достаточно, чтобы слегка расшевелить молодых и горячих разработчиков, немного затормозить темпераментных и прорывных визионеров от продукта и основательно приземлить клиентский отдел.
Но, в более широком смысле, этот навык – это лишь один из кусочков пазла, который плохо работает без поддержки навыков коммуникации, эмпатии, лидерства и креативного мышления.
Основной вопрос, который меня мучает уже продолжительное время – как повлиять на развитие гибких навыков в ИТ в широком смысле и как прокачать их у конкретного человека или небольшой группы людей?
На мой взгляд, потребность рынка на вашем графике содержит не ожидания от потенциальных работников по теоретическим и практическим навыкам, а качественный уровень компании, которая нанимает сотрудников. Это и уровень предлагаемых зарплат сотрудникам, и соц. пакет и общий уровень проектов, выполняемых компанией.
Во первых, ваша кривая рынка может быть смело продолжена в сторону крупных компаний-заказчиков, которым необходима серьезная экспертная оценка какой-либо деятельность, консалтинг, например.
Во вторых, кривую можно сегментировать относительно уровня выполняемых проектов.
Согласитесь, чем раньше студент начинает работать, тем скорее угол наклона его кривой уменьшается. В конечном итоге работа может заполнить все время и сотрудник перестанет заниматься саморазвитием, наращивая лишь практический потенциал.
Увеличить угол позднее становится трудно, молодые люди объективно проще обучаются.
Взять на работу высококвалифицированного с теоретической точки зрения сотрудника без опыта эффективнее с экономической точки зрения (с геометрической кстати тоже, катет < гипотенузы)
Итого, ваш подход: универ отстой, на работе меня всему научат подходит только нижней части рынка работодателей, привлекает низкоквалифицированных кадров, обеспечивает краткосрочную выгоду работнику и компании.
Пока вы так считаете, все интересные честные проекты в бизнесе будут проходить мимо вас прямо к нам ;)
Расскажите пожалуйста про облака поподробнее. По какой причине облако может быть не выгодно для веб разработки и зачем разворачивать тестовое окружение в амазоне?
И еще про Амазон: сколько у вас инстансов и примерно в какую сумму это выливается ежемесячно?
Наверное вы имели в виду лишь различные способы проведения операций с деньгами, но по моему также важным вопросом является постоянная платежеспособность фрилансера. Расскажите как вы начинали? ;)
Вы совершенно правы, они не скоты. Несомненно иногда проскакивают совсем уж лиственные породы деревьев, но в общем массе они знают чего хотят и требуют бережно относиться к их идеям и мыслям. О том, как отказываться от работы с заказчиком, потому что он бревно, и никакими разумными издержками этого не покрыть, я думаю вы тоже упомянете где нибудь (раз уж диалог с читателями планирует быть долгим :), но это тема для отдельного обсуждения.
Мне же хотелось дать вам обратную связь, чтобы следующие части были более структурированы, логичны и наполнены картинками и примерами. Я не зря делаю акцент на картинках, к которым вы как-то не привыкли: ) Читать полотна текста, пусть и написанного самым лучших рассказчиком, очень утомительно. Картинки разряжают текст, дают возможность глазам отдохнуть чуть чуть перед новым погружением в пучины ваших размышлений. Не говоря уже о том, что информацию можно представлять в различных формах, и иногда выбор удачной формы влечет за собой лучшее понимание содержания.
выезачеркиваниями, но я поставил вам минус. И вот почему:1. Где картинки? Хоть одна. Хотя бы рядом с PERT диаграммой.
2. В чем состоит цель вашей статьи? 95% ваших читателей фейлят проекты потому что срываются сроки, но после прочтения Вашей статьи этот процент не уменьшится ни на йоту. Потому что вы не предлагаете решение. Разбить ТЗ на блоки или умножить время на 1.2, извините, но это же и так очевидно, имхо.
3. Вау! Класс! Книжки! Куча! Управление проектами! Ссылки? Авторы? Названия? Ну вы понимаете, о чем я...
Не сочтите, меня за толстого тролля, но в этой статье нет ничего. Вместо абстрактных подсчетов стоимости проекта и процентов взятых с потолка приведите один пример. Понятное дело, что реальные ТЗ выкладывать сюда не стоит, но давайте вместе придумаем какой нибудь example.com, сроки которого сколько-то месяцев, а функциональность размазана на столько-то блоков? Расскажите, как правильно вытащить из заказчика всю нужную информацию за минимальное количество итераций. Поведайте о том, как добиться лучшего понимания у заказчика в вопросах взаимодействия различных частей проекта, чтобы когда на середине в его буйную голову постучится дрозд он осознавал какой объем работ придется переделывать. Как вовлечь заказчика в процесс разработки с целью получения быстрого отклика на неочевидные моменты реализации? Спасибо.
Имхо, надо чаще встречаться, а то как то по моим ощущениям — не всё со всеми успел обсудить; )
Написание алгоритмически сложного кода — это конечно хорошо, но цикл то разработки с этого только начинается. А как же сопровождение, тестирование, внедрение, версионность и командный таск-трекинг?
Охотно верю что спецкурсы кафедры системного программирования могут покрыть все вышеперечисленные темы. Но хочется кричать и громко ругаться, когда понимаешь, что ваши коллеги с соседней кафедры приходят к пониманию процесса разработки только благодаря книжкам и методу научного тыка, хотя на мат-мехе столько светлейших умов!
Вокруг нас на факультете столько нерешенных полезных задач, взять хотя бы электронное расписание. Вот вам и пользователи системы, и тестировщики, а таск-трекер можно хоть на баобаб* вешать. Я уж не говорю о том, что пора бы познакомить студентов мат-меха с хорошо-сделанным местным веб-сайтом. А то стыд то какой, мат-мех лучше всех, а расписание в docx скачивать приходится.
Чтобы этот коммент влился в контекст вашей статьи рискну предложить вам в следующем году изобрести полезный для студентов студенческий проект. Уверен, он привлечет немалый интерес среди студентов 2 — 4 курсов
*баобаб — местное расписание матмеха
То есть, иными словами, вы заранее знали, что делает метод attr, до того как встретили его в коде. И даже если бы Вы сначала с ним встретились, Вам все равно пришлось бы заглянуть в доки, чтобы удостовериться, что вы правильно поняли сферу его применимости.
Если весь код, который Вы так или иначе разрабатываете в каждом проекте полностью задокументирован, скорее всего наш спор останется за Вами.
Но много ли Вы знаете разработчиков, которые любят писать документации?
Есть всяческие
phpjavaDocs, подгружение описаний методов в разных IDE, и тому подобные штуки, которые как раз и помогают находить баланс между длиной имени и описанием в комментах, но кажется, к этой священной войне они не имеют отношения ;)Изначально я конечно хотел не холиварить только про названия переменных, но можно и аккуратно пройтись по методам =)
byTag() — имхо, очень плохо по сравнению с getElementsByTagName(). По крайней мере по двум причинам —
1. метод с точки зрения семантики это скорее глагол, чем наречие. То есть get в названии метода собственно и характеризует действие, заложенное в реализации данной функции.
2. в слове Elements, точнее сказать, в последней букве, на мой взгляд, есть важная семантическая нагрузка названия метода. Множественное число дает понять, что метод вернет коллекцию (в достаточно широком смысле этого слова).
Итоги : в названии метода должен быть глагол, название не должно порождать неоднозначности в трактовке выходных параметров.
Мой выбор в таком случае getElemsByTag()
Учился в Праге в Карловом университете прошлый семестр, и кажется, в Чехии на ЗАКОНОДАТЕЛЬНОМ уровне все вузы и колледжи должны иметь некую информационную систему, например вот такую.
Правда мне сейчас начнут говорить что это не css вовсе, ведь тут есть и переменные, и функции.
А для особо страждущих — все отступы и пикселя можно задать в одном месте.