"У вас все ужасно, нужно переделать" - это классический паттерн поведения молодого специалиста, который только пришел в компанию. У всех есть история как условный "студент" после ВУЗа приходит на рабочее место, и начинает жаловаться, что используются старые технологии, методологии не соответствуют современным требованиям и т.д.
Обычно более опытные коллеги понимающе улыбаются и ничего не делают, через некоторое время специалист притрется и поймет, что есть очень много причин почему система работает именно так, а не иначе, многие из них даже не заметны сразу.
Но бывает так, что "новичок" попадает в струю, когда есть руководитель, который вместо разумного сдерживания порывов нового специалиста, поддерживает инициативу. В большинстве случаев это приводит к тому, что ничего хорошего не получается. И если повезет, то компания потеряет деньги, но не бизнес. А в худшем случае может развалиться и вся работающая система.
Многие думают, что в реальной жизни опытный руководитель никогда не допустит такой ситуации. Но на практике любая смена руководства в точности повторяет этот паттерн. Приходит новая "метла" и начинает менять сложившуюся структуру. Это дорого, неэффективно, бессмысленно, но повторяется из раза в раз.
Мой подход всегда сводится к эволюционным подходам, когда определяются новые вектора развития и постепенно корректируется существующая система. Это проще и для самой команды (понятно, что и как делать) и для бизнеса (не приходится разово вливать кучу денег). Но очень плохо с позиции имиджа "решенца проблем", многим кажется, что они и сами бы сделали ровно так же. И результат достигается как бы сам собой.
Но это и есть профессионализм, когда система работает, развивается гладко, без громких факапов, когда команда работает в хорошем, спокойном темпе, а не бегает с выпученными глазами. Поэтому если все идет ровно - это и есть "правильно".
Обычно более опытные коллеги понимающе улыбаются и ничего не делают, через некоторое время специалист притрется и поймет, что есть очень много причин почему система работает именно так, а не иначе, многие из них даже не заметны сразу.
Но бывает так, что "новичок" попадает в струю, когда есть руководитель, который вместо разумного сдерживания порывов нового специалиста, поддерживает инициативу. В большинстве случаев это приводит к тому, что ничего хорошего не получается. И если повезет, то компания потеряет деньги, но не бизнес. А в худшем случае может развалиться и вся работающая система.
Многие думают, что в реальной жизни опытный руководитель никогда не допустит такой ситуации. Но на практике любая смена руководства в точности повторяет этот паттерн. Приходит новая "метла" и начинает менять сложившуюся структуру. Это дорого, неэффективно, бессмысленно, но повторяется из раза в раз.
Мой подход всегда сводится к эволюционным подходам, когда определяются новые вектора развития и постепенно корректируется существующая система. Это проще и для самой команды (понятно, что и как делать) и для бизнеса (не приходится разово вливать кучу денег). Но очень плохо с позиции имиджа "решенца проблем", многим кажется, что они и сами бы сделали ровно так же. И результат достигается как бы сам собой.
Но это и есть профессионализм, когда система работает, развивается гладко, без громких факапов, когда команда работает в хорошем, спокойном темпе, а не бегает с выпученными глазами. Поэтому если все идет ровно - это и есть "правильно".
👍80👎8❤4
Еще один паттерн антиповедения "мне надо сначала объяснить". Суть в том, что задавать вопросы - нормально, но до тех пор пока их мало, и они сразу подразумевают вилку ответов (т.е. человек не просто "тупо" задает вопросы, а пытается самостоятельно найти ответ, прежде чем задать вопрос).
Есть же такие люди, которые действуют по принципу "задать вопрос проще, чем попытаться разобраться самому", такие люди тянут из команды соки, постоянно чего-то "искренне" не понимают и если им сделать замечание, что прежде чем задать вопрос нужно попытаться найти ответ самому, воспринимают это в штыки.
Правильно заданный вопрос содержит половину ответа, а вопрос, который влечет за собой необходимость уточнять и уточнять что имелось в виду - явный признак того, что сотрудник из серии "мне надо сначала объяснить". Особенно если суммарное время, потраченное на ответы, больше чем польза, принесенная сотрудником.
Есть же такие люди, которые действуют по принципу "задать вопрос проще, чем попытаться разобраться самому", такие люди тянут из команды соки, постоянно чего-то "искренне" не понимают и если им сделать замечание, что прежде чем задать вопрос нужно попытаться найти ответ самому, воспринимают это в штыки.
Правильно заданный вопрос содержит половину ответа, а вопрос, который влечет за собой необходимость уточнять и уточнять что имелось в виду - явный признак того, что сотрудник из серии "мне надо сначала объяснить". Особенно если суммарное время, потраченное на ответы, больше чем польза, принесенная сотрудником.
👍41❤22
"План, что и говорить, был превосходный: простой и ясный, лучше не придумать. Недостаток у него был только один: было совершенно неизвестно, как привести его в исполнение."
Льюис Кэрролл
Льюис Кэрролл
❤33👏9😁7👍5🔥5🤯2😍1
Понедельник день тяжелый, давайте для разминки дам пару простых вопросов:
1. У нас есть два скрипта, запуск которых крутится в бесконечном цикле. Первый запускается раз в Х минут, второй раз в Y минут, можно ли так подобрать X и Y, чтобы скрипты запускались хотя бы раз в день, но не запускались вместе (одновременно, т.е. исполнение одного скрипта не накладывалось на исполнение второго. Они исполняются заведомо меньше минуты).
Отсчет минут идет всегда от одного момента. Т.е. если X == Y, то скрипты запустятся вместе
2. Можно ли средствами крона запускать скрипт один раз в 9 минут, без пропусков и увеличенных интервалов?
1. У нас есть два скрипта, запуск которых крутится в бесконечном цикле. Первый запускается раз в Х минут, второй раз в Y минут, можно ли так подобрать X и Y, чтобы скрипты запускались хотя бы раз в день, но не запускались вместе (одновременно, т.е. исполнение одного скрипта не накладывалось на исполнение второго. Они исполняются заведомо меньше минуты).
Отсчет минут идет всегда от одного момента. Т.е. если X == Y, то скрипты запустятся вместе
2. Можно ли средствами крона запускать скрипт один раз в 9 минут, без пропусков и увеличенных интервалов?
👍1
На самом деле, на бытовом уровне люди больше склоняются к концепции "один инструмент для всего", чем "для каждой задачи свой инструмент". Это происходит на интуитивном уровне, думаю, что этому даже есть какое-то разумное объяснение.
Например, люди предпочтут один мощный смартфон взамен фотоаппарата, медиаплеера, телефона и портативной игровой приставки.
Тоже самое с github, вместо хранилища "кода", дополнительно он становится хранилищем "знаний" и это удобно, как по мне. Поэтому я решил подобрать несколько репозиториев которые содержат "знания", способные помочь на пути саморазвития.
1. Любимая тема всех разработчиков - какой путь изучения выбрать, есть целый репо, который содержит ответ
https://github.com/kamranahmedse/developer-roadmap
2. Второй любимый вопрос - где взять литературу, и вот репо с бесплатными книгами (правда по архитектуре там нет, эта тема впринципе плохо раскрыта)
https://github.com/EbookFoundation/free-programming-books/blob/main/books/free-programming-books-ru.md
3. По архитеутре можно глянуть пример дизайна системы (как раз архитектурный взгляд)
https://github.com/donnemartin/system-design-primer
4. 30-ти секундные сниппеты, примеры коротких кусков кода, которые могут пригодится на практике
https://github.com/30-seconds/30-seconds-of-code
5. На закуску практические реализиации идей, по разным тематикам (можно построить свой клон одного из популярных проектов)
https://github.com/codecrafters-io/build-your-own-x
#ссылки #знания
Например, люди предпочтут один мощный смартфон взамен фотоаппарата, медиаплеера, телефона и портативной игровой приставки.
Тоже самое с github, вместо хранилища "кода", дополнительно он становится хранилищем "знаний" и это удобно, как по мне. Поэтому я решил подобрать несколько репозиториев которые содержат "знания", способные помочь на пути саморазвития.
1. Любимая тема всех разработчиков - какой путь изучения выбрать, есть целый репо, который содержит ответ
https://github.com/kamranahmedse/developer-roadmap
2. Второй любимый вопрос - где взять литературу, и вот репо с бесплатными книгами (правда по архитектуре там нет, эта тема впринципе плохо раскрыта)
https://github.com/EbookFoundation/free-programming-books/blob/main/books/free-programming-books-ru.md
3. По архитеутре можно глянуть пример дизайна системы (как раз архитектурный взгляд)
https://github.com/donnemartin/system-design-primer
4. 30-ти секундные сниппеты, примеры коротких кусков кода, которые могут пригодится на практике
https://github.com/30-seconds/30-seconds-of-code
5. На закуску практические реализиации идей, по разным тематикам (можно построить свой клон одного из популярных проектов)
https://github.com/codecrafters-io/build-your-own-x
#ссылки #знания
GitHub
GitHub - kamranahmedse/developer-roadmap: Interactive roadmaps, guides and other educational content to help developers grow in…
Interactive roadmaps, guides and other educational content to help developers grow in their careers. - kamranahmedse/developer-roadmap
👍48🔥8🤡2
В этом месяце сложилась драматическая ситуация вокруг подписки PRO. По правилам самый активный контрибьютер месяца получает PRO.
В этом месяце было минимальное количество правок и победа досталась очень легко... Но кому?
С одной стороны mdlufy сделал 8 коммитов, а NimRoen сделал больше правок (точнее выиграл по количеству удалений)
По правилам коммиты участвуют для получения stream и workshop, а активность при получении PRO. Поэтому в этом месяце подарочный сертификат PRO уходит NimRoen.
В этом месяце было минимальное количество правок и победа досталась очень легко... Но кому?
С одной стороны mdlufy сделал 8 коммитов, а NimRoen сделал больше правок (точнее выиграл по количеству удалений)
По правилам коммиты участвуют для получения stream и workshop, а активность при получении PRO. Поэтому в этом месяце подарочный сертификат PRO уходит NimRoen.
💩18😁5👍4🤡3🥰1🤔1
Статья об основах веб-архитектуры, подойдет для новичков. Содержит много упрощений, некоторые на грани ошибок. Например, слоистую архитектуру перемешали с луковой. Но в целом статья годная.
https://www.freecodecamp.org/news/an-introduction-to-software-architecture-patterns
https://www.freecodecamp.org/news/an-introduction-to-software-architecture-patterns
freeCodeCamp.org
The Software Architecture Handbook
Hi everyone! In this handbook you're going to learn about the vast, intricate field that is Software Architecture. This is a field that I found both confusing and intimidating when I was first starting my journey into coding. So I'll try and spare yo...
🔥16👍4
Итак, конкурс на лучший пятничный юмор.
Продолжи историю "Сидят в баре два программиста, один смеётся, второй грустный, бармен спрашивает почему ты такой грустный?" ...
Ваши варианты в комментарии )
Продолжи историю "Сидят в баре два программиста, один смеётся, второй грустный, бармен спрашивает почему ты такой грустный?" ...
Ваши варианты в комментарии )