День шестьсот семьдесят шестой. #Оффтоп #КакСтатьСеньором
Сегодня начну серию постов, которую коротко можно озаглавить «Как Стать Сеньором». Я недавно наткнулся на лонгрид от разработчика, который описывает, что он узнал на пути к должности старшего разработчика. Выдержки из его статьи, по аналогии с #97Вещей, будут появляться на канале время от времени под тегом #КакСтатьСеньором. Но для начала давайте определимся…
Кто такой сеньор?
Начало.
Замечание: Сразу оговорюсь, что многое из нижеследующего описывает «сферического сеньора в вакууме». И, наверное, часть из этих характеристик невозможно дать самому себе, их должны дать вам ваши коллеги.
Существует распространенное заблуждение о том, кто такой старший (сеньор) разработчик. Одни скажут вам, что это разработчик с многолетним опытом, другие могут сказать, что «сеньорство» определяется «количеством исправлений багов в секунду». Нет, нет и нет.
Если вы почитаете вакансии на должность программиста, вы обнаружите закономерность: рекрутеры, похоже, определяют сеньора по количеству лет опыта в этой области. На самом деле это немного сложнее. Начнем с того, что сеньор НЕ:
- знает о языке программирования всё,
- знает ответы на все вопросы,
- является обладателем абсолютной истины.
Решение проблем
Одна из важнейших черт сеньора - способность быстро решать проблемы, а также:
- оставаться эффективным,
- не создавать ненужных источников ошибок,
- как можно меньше вредить существующей системе,
- видеть более широкую картину,
- подразумевать в решениях возможность расширения / повторного использования,
- принимать решения о возможных компромиссах.
На воплощение в жизнь идеального решения не всегда хватает времени или средств. Сеньор должен знать, какое неоптимальное решение можно принять сейчас, но чётко осознавать, что это быстрое решение на время, и его нужно исправить в будущем.
Технические навыки и опыт
Конечно, важно, чтобы сеньор обладал обширными техническими навыками. Но это не означает, что он знает наизусть все детали синтаксиса и может перечислить все доступные функции работы с массивами. Нет, эти знания больше о том, какие инструменты и паттерны существуют, чтобы можно было выбрать правильный вариант решения возникшей проблемы.
Часто у сеньора есть шестое чувство, когда дело касается возможных проблем. Это опыт, почерпнутый из предыдущих проектов. Сеньор иногда не может объяснить, почему один путь может быть хуже, но почти всегда уверен, почему это конкретное решение будет лучше. Также сеньору важно осознавать, чего он не знает, и при необходимости провести дополнительное исследование, чтобы узнать больше о проблеме.
Окончание следует…
Источник: https://dev.to/themarcba/what-is-a-senior-developer-really-59dg
Автор оригинала – Burk Hufnagel
Сегодня начну серию постов, которую коротко можно озаглавить «Как Стать Сеньором». Я недавно наткнулся на лонгрид от разработчика, который описывает, что он узнал на пути к должности старшего разработчика. Выдержки из его статьи, по аналогии с #97Вещей, будут появляться на канале время от времени под тегом #КакСтатьСеньором. Но для начала давайте определимся…
Кто такой сеньор?
Начало.
Замечание: Сразу оговорюсь, что многое из нижеследующего описывает «сферического сеньора в вакууме». И, наверное, часть из этих характеристик невозможно дать самому себе, их должны дать вам ваши коллеги.
Существует распространенное заблуждение о том, кто такой старший (сеньор) разработчик. Одни скажут вам, что это разработчик с многолетним опытом, другие могут сказать, что «сеньорство» определяется «количеством исправлений багов в секунду». Нет, нет и нет.
Если вы почитаете вакансии на должность программиста, вы обнаружите закономерность: рекрутеры, похоже, определяют сеньора по количеству лет опыта в этой области. На самом деле это немного сложнее. Начнем с того, что сеньор НЕ:
- знает о языке программирования всё,
- знает ответы на все вопросы,
- является обладателем абсолютной истины.
Решение проблем
Одна из важнейших черт сеньора - способность быстро решать проблемы, а также:
- оставаться эффективным,
- не создавать ненужных источников ошибок,
- как можно меньше вредить существующей системе,
- видеть более широкую картину,
- подразумевать в решениях возможность расширения / повторного использования,
- принимать решения о возможных компромиссах.
На воплощение в жизнь идеального решения не всегда хватает времени или средств. Сеньор должен знать, какое неоптимальное решение можно принять сейчас, но чётко осознавать, что это быстрое решение на время, и его нужно исправить в будущем.
Технические навыки и опыт
Конечно, важно, чтобы сеньор обладал обширными техническими навыками. Но это не означает, что он знает наизусть все детали синтаксиса и может перечислить все доступные функции работы с массивами. Нет, эти знания больше о том, какие инструменты и паттерны существуют, чтобы можно было выбрать правильный вариант решения возникшей проблемы.
Часто у сеньора есть шестое чувство, когда дело касается возможных проблем. Это опыт, почерпнутый из предыдущих проектов. Сеньор иногда не может объяснить, почему один путь может быть хуже, но почти всегда уверен, почему это конкретное решение будет лучше. Также сеньору важно осознавать, чего он не знает, и при необходимости провести дополнительное исследование, чтобы узнать больше о проблеме.
Окончание следует…
Источник: https://dev.to/themarcba/what-is-a-senior-developer-really-59dg
Автор оригинала – Burk Hufnagel
День шестьсот семьдесят седьмой. #Оффтоп #КакСтатьСеньором
Кто такой сеньор? Окончание.
Начало
Знание технологий
Хороший старший разработчик знает о доступных инструментах, даже если он их не использует и даже если точно не помнит, как они работают. Когда возникает проблема, он знает, что есть что-то, что может идеально подойти. Сеньор является экспертом в сопоставлении проблемы и идеального инструмента для её решения. Возможно, ему придётся провести небольшое исследование, чтобы убедиться, что конкретный инструмент подходит, но он знает, что нужно искать.
Особенно в начале нового проекта сеньор должен делать осознанный выбор в отношении того, какие варианты решения окупятся в долгосрочной перспективе.
От начала до конца
Старший разработчик способен выполнить каждый шаг на пути создания программного обеспечения:
1. Проанализировать проблему
2. Понять проблему
3. Сформировать жизнеспособное решение проблемы
4. Реализовать решение
5. Проверить решение
6. Интегрировать решение
7. Развернуть решение
Менторство
Ещё одно важное качество, которым должен обладать каждый сеньор, — это способность вести за собой других. Это означает:
- помогать им повысить свои навыки,
- направлять их на путь к лучшим решениям и объяснять почему одно решение лучше другого,
- помогать им, когда они попадают в тупик,
- не смотреть на них свысока,
- предоставлять им интересные и полезные ресурсы,
- поддерживать других,
- делиться тем, что знает,
- ценить успехи других, когда они того стоят.
Общение
Сеньор должен обладать хорошими коммуникативными навыками:
- Объяснить проблему кому-нибудь доступным языком (даже тому, кто не является техническим специалистом).
- Представить решение и объяснить, почему среди всех решений оно лучшее.
- Ориентироваться в офисной политике.
- Стараться оградить других разработчиков от неверных управленческих решений.
Скромность
Старший разработчик не всегда прав, и он должен это знать. Все делают ошибки, и когда человек допускает ошибку, он должен иметь смелость признаться в этом. Кроме того важно:
- повысить общую осведомленность о проблеме,
- принять на себя ответственность,
- проанализировать серьезность проблемы,
- выработать ряд вариантов решения проблемы,
- уметь обращаться за помощью и принимать помощь.
Кроме того, старший разработчик никогда не должен предполагать, что он всегда прав. Ему следует анализировать мнения других и быть готовым принять лучшее решение, даже если оно чужое. Однако также не следует допускать того, чтобы на это решение слишком легко влияли другие. Решение должно быть обдумано и должен быть выбран действительно лучший вариант.
Источник: https://dev.to/themarcba/what-is-a-senior-developer-really-59dg
Автор оригинала – Burk Hufnagel
Кто такой сеньор? Окончание.
Начало
Знание технологий
Хороший старший разработчик знает о доступных инструментах, даже если он их не использует и даже если точно не помнит, как они работают. Когда возникает проблема, он знает, что есть что-то, что может идеально подойти. Сеньор является экспертом в сопоставлении проблемы и идеального инструмента для её решения. Возможно, ему придётся провести небольшое исследование, чтобы убедиться, что конкретный инструмент подходит, но он знает, что нужно искать.
Особенно в начале нового проекта сеньор должен делать осознанный выбор в отношении того, какие варианты решения окупятся в долгосрочной перспективе.
От начала до конца
Старший разработчик способен выполнить каждый шаг на пути создания программного обеспечения:
1. Проанализировать проблему
2. Понять проблему
3. Сформировать жизнеспособное решение проблемы
4. Реализовать решение
5. Проверить решение
6. Интегрировать решение
7. Развернуть решение
Менторство
Ещё одно важное качество, которым должен обладать каждый сеньор, — это способность вести за собой других. Это означает:
- помогать им повысить свои навыки,
- направлять их на путь к лучшим решениям и объяснять почему одно решение лучше другого,
- помогать им, когда они попадают в тупик,
- не смотреть на них свысока,
- предоставлять им интересные и полезные ресурсы,
- поддерживать других,
- делиться тем, что знает,
- ценить успехи других, когда они того стоят.
Общение
Сеньор должен обладать хорошими коммуникативными навыками:
- Объяснить проблему кому-нибудь доступным языком (даже тому, кто не является техническим специалистом).
- Представить решение и объяснить, почему среди всех решений оно лучшее.
- Ориентироваться в офисной политике.
- Стараться оградить других разработчиков от неверных управленческих решений.
Скромность
Старший разработчик не всегда прав, и он должен это знать. Все делают ошибки, и когда человек допускает ошибку, он должен иметь смелость признаться в этом. Кроме того важно:
- повысить общую осведомленность о проблеме,
- принять на себя ответственность,
- проанализировать серьезность проблемы,
- выработать ряд вариантов решения проблемы,
- уметь обращаться за помощью и принимать помощь.
Кроме того, старший разработчик никогда не должен предполагать, что он всегда прав. Ему следует анализировать мнения других и быть готовым принять лучшее решение, даже если оно чужое. Однако также не следует допускать того, чтобы на это решение слишком легко влияли другие. Решение должно быть обдумано и должен быть выбран действительно лучший вариант.
Источник: https://dev.to/themarcba/what-is-a-senior-developer-really-59dg
Автор оригинала – Burk Hufnagel
День шестьсот восемьдесят четвёртый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
1. Разносторонний Рост
Ко второму году работы я уже знал все основы. Я собрал все низко висящие плоды, и мой рост замедлился. Возник большой вопрос: «Как расти дальше?» Я мало что мог сделать, чтобы улучшить свои навыки программирования. Большинство статей и блогов про методы написания более чистого кода, KISS, DRY, YAGNI и т.д. - являются микрооптимизациями. Почти ничего из этого не приносит большой пользы для роста (хотя это не значит, что их не стоит изучать совсем).
Я обнаружил кое-что интересное. Я разрабатываю ПО, но жизненный цикл разработки ПО является частью более крупного жизненного цикла: разработки продукта. Я решил пойти вширь, а не вглубь. Удивительно, но это помогло мне глубже понять то, что я делаю. Я выбрал три основных направления:
1) Изучение того, что делают люди вокруг меня
Поскольку мы не закрыты от общения с коллегами, имеет смысл лучше понять работу менеджеров продукта, продавцов и аналитиков. В конце концов, бизнес зарабатывает на продукте. Цель не в том, чтобы писать код, а в том, чтобы приносить прибыль бизнесу. Большинство крупных компаний не делают что-то одно, а это означает, что в одной и той же компании есть разные пути для извлечения прибыли. Все работники находятся по крайней мере на одном из путей, иначе они бы не работали в компании. Отслеживание этих путей, а также исследование пути, на котором нахожусь я, было очень ценно. Это помогло мне понять, насколько я важен, и какие рычаги я могу использовать, чтобы стать более эффективным. Иногда нужно упростить работу продажникам, чтобы они могли увеличить продажи. В другом случае нужно создать новый функционал для клиентов. В третьем - исправить функцию, которая постоянно ломается.
Менеджеры продукта - лучший источник этой информации. Они знают, как бизнес зарабатывает деньги, кто их клиенты и что им нужно. За год я довольно много встречался с коллегами. Второе преимущество этого - знание контекста работы других. Это помогло мне в общении. Например, один разговор помог мне понять, почему Саре из отдела продаж нужен инструмент массового обновления. В некоторых компаниях много сотрудников, и обновлять их по одному - проблема. Код, который я в итоге написал, буквально избавил Сару от мучений.
2) Тренировка правильных мыслительных привычек
Разработка ПО требует правильного мышления и принятия правильных решений. Написание кода — это реализация этих решений. Мыслительная привычка — это то, что ваш мозг делает регулярно. Это может быть размышление о X всякий раз, когда случается Y, или применение инструмента X к проблеме Y. Короче говоря, мыслительные привычки помогают размышлению. Я предположил, что, если изучить общие принципы, их можно будет применить и в разработке ПО.
3) Правильное мышление
Разработка ПО - отличная область для практики правильного мышления. Циклы обратной связи короче, и оценка правильности решения не занимает много времени. Я погрузился в изучение когнитивных наук. Это полезный навык, который стоит изучить. Он поможет и тому, чем я занимаюсь по работе, и принесёт дивиденды в жизни вообще. Подробнее об этом позже.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd#d46c
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
1. Разносторонний Рост
Ко второму году работы я уже знал все основы. Я собрал все низко висящие плоды, и мой рост замедлился. Возник большой вопрос: «Как расти дальше?» Я мало что мог сделать, чтобы улучшить свои навыки программирования. Большинство статей и блогов про методы написания более чистого кода, KISS, DRY, YAGNI и т.д. - являются микрооптимизациями. Почти ничего из этого не приносит большой пользы для роста (хотя это не значит, что их не стоит изучать совсем).
Я обнаружил кое-что интересное. Я разрабатываю ПО, но жизненный цикл разработки ПО является частью более крупного жизненного цикла: разработки продукта. Я решил пойти вширь, а не вглубь. Удивительно, но это помогло мне глубже понять то, что я делаю. Я выбрал три основных направления:
1) Изучение того, что делают люди вокруг меня
Поскольку мы не закрыты от общения с коллегами, имеет смысл лучше понять работу менеджеров продукта, продавцов и аналитиков. В конце концов, бизнес зарабатывает на продукте. Цель не в том, чтобы писать код, а в том, чтобы приносить прибыль бизнесу. Большинство крупных компаний не делают что-то одно, а это означает, что в одной и той же компании есть разные пути для извлечения прибыли. Все работники находятся по крайней мере на одном из путей, иначе они бы не работали в компании. Отслеживание этих путей, а также исследование пути, на котором нахожусь я, было очень ценно. Это помогло мне понять, насколько я важен, и какие рычаги я могу использовать, чтобы стать более эффективным. Иногда нужно упростить работу продажникам, чтобы они могли увеличить продажи. В другом случае нужно создать новый функционал для клиентов. В третьем - исправить функцию, которая постоянно ломается.
Менеджеры продукта - лучший источник этой информации. Они знают, как бизнес зарабатывает деньги, кто их клиенты и что им нужно. За год я довольно много встречался с коллегами. Второе преимущество этого - знание контекста работы других. Это помогло мне в общении. Например, один разговор помог мне понять, почему Саре из отдела продаж нужен инструмент массового обновления. В некоторых компаниях много сотрудников, и обновлять их по одному - проблема. Код, который я в итоге написал, буквально избавил Сару от мучений.
2) Тренировка правильных мыслительных привычек
Разработка ПО требует правильного мышления и принятия правильных решений. Написание кода — это реализация этих решений. Мыслительная привычка — это то, что ваш мозг делает регулярно. Это может быть размышление о X всякий раз, когда случается Y, или применение инструмента X к проблеме Y. Короче говоря, мыслительные привычки помогают размышлению. Я предположил, что, если изучить общие принципы, их можно будет применить и в разработке ПО.
3) Правильное мышление
Разработка ПО - отличная область для практики правильного мышления. Циклы обратной связи короче, и оценка правильности решения не занимает много времени. Я погрузился в изучение когнитивных наук. Это полезный навык, который стоит изучить. Он поможет и тому, чем я занимаюсь по работе, и принесёт дивиденды в жизни вообще. Подробнее об этом позже.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd#d46c
Автор оригинала – Neil Kakkar
День шестьсот девяносто второй. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.
Например, недавно я боролся с доменом с большим количеством сложной бизнес-логики. Нормой были пограничные случаи, и мы хотели разработать систему, которая успешно с ними справляется. Именно тогда я прочитал о предметно-ориентированном проектировании. Я смог мгновенно применить его на практике. Впоследствии я лучше усвоил эти концепции. Я приобрёл новую ментальную модель создания корпоративного ПО.
Второй способ поиска новых ментальных моделей – читать статьи, появляющиеся на специализированных ресурсах (например, на Хабре). Там вы можете подчерпнуть интересные идеи. Однако они намного менее эффективны, чем описанная выше техника. Единственная причина заниматься этим на постоянной основе – набирать багаж навыков. Это позволяет знать о методах решения проблем, поэтому, когда я сталкиваюсь с проблемой, я могу вспомнить, что где-то читал про метод, который может помочь.
Последний способ - это изучение новых языков. Изучение нового диалекта или новых функций языка принесёт гораздо меньше пользы, чем, скажем, изучение языка, абсолютно непохожего на ваш. Каждый язык имеет свой словарный запас и грамматику, и позволяет по-иному смотреть на вещи.
Когда управление памятью находится под вашим контролем, вы понимаете, как работают указатели и выделение памяти. Когда C# абстрагирует это, вы цените снижение сложности. Когда в функциональном языке используются фильтры и проекции, вы понимаете, как можно заменить циклы for. И тогда вы замечаете, что в ООП некоторые вещи становятся проще. Нет одного волшебного инструмента, который подошёл бы ко всему. Но несмотря на это, вам не нужно менять ваш инструмент. Вы можете адаптировать передовой опыт для решения ваших проблем: например, использовать функциональные парадигмы в ООП. Принципы важнее, чем способы их выражения.
3. Стратегии повышения эффективности повседневной деятельности
Другая сторона медали - привычки, позволяющие хорошо мыслить. Это начинается с того, что вы в течение дня замечаете мелкие нюансы, которые вызывают у вас раздражение: неэффективные собрания, тормозящая программа, какая-нибудь рутинная задача, требующая от вас постоянно выполнять одни и те же действия. Затем вы придумываете стратегию, как этого избежать. Эти мелкие улучшения часто недооцениваются.
Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.
Например, недавно я боролся с доменом с большим количеством сложной бизнес-логики. Нормой были пограничные случаи, и мы хотели разработать систему, которая успешно с ними справляется. Именно тогда я прочитал о предметно-ориентированном проектировании. Я смог мгновенно применить его на практике. Впоследствии я лучше усвоил эти концепции. Я приобрёл новую ментальную модель создания корпоративного ПО.
Второй способ поиска новых ментальных моделей – читать статьи, появляющиеся на специализированных ресурсах (например, на Хабре). Там вы можете подчерпнуть интересные идеи. Однако они намного менее эффективны, чем описанная выше техника. Единственная причина заниматься этим на постоянной основе – набирать багаж навыков. Это позволяет знать о методах решения проблем, поэтому, когда я сталкиваюсь с проблемой, я могу вспомнить, что где-то читал про метод, который может помочь.
Последний способ - это изучение новых языков. Изучение нового диалекта или новых функций языка принесёт гораздо меньше пользы, чем, скажем, изучение языка, абсолютно непохожего на ваш. Каждый язык имеет свой словарный запас и грамматику, и позволяет по-иному смотреть на вещи.
Когда управление памятью находится под вашим контролем, вы понимаете, как работают указатели и выделение памяти. Когда C# абстрагирует это, вы цените снижение сложности. Когда в функциональном языке используются фильтры и проекции, вы понимаете, как можно заменить циклы for. И тогда вы замечаете, что в ООП некоторые вещи становятся проще. Нет одного волшебного инструмента, который подошёл бы ко всему. Но несмотря на это, вам не нужно менять ваш инструмент. Вы можете адаптировать передовой опыт для решения ваших проблем: например, использовать функциональные парадигмы в ООП. Принципы важнее, чем способы их выражения.
3. Стратегии повышения эффективности повседневной деятельности
Другая сторона медали - привычки, позволяющие хорошо мыслить. Это начинается с того, что вы в течение дня замечаете мелкие нюансы, которые вызывают у вас раздражение: неэффективные собрания, тормозящая программа, какая-нибудь рутинная задача, требующая от вас постоянно выполнять одни и те же действия. Затем вы придумываете стратегию, как этого избежать. Эти мелкие улучшения часто недооцениваются.
Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День шестьсот девяносто девятый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
4. Следите за скоростью
Я заметил, что более медленный темп даёт прирост моей производительности. Хотите сделать больше? Не торопитесь. Вот что я имею в виду.
Я заметил, что люди спешат решать проблемы. Это может быть что-то, что они делали раньше, или что-то, на что у нас есть шаблон решения. Приятно щёлкать задачи, как орешки. Я тоже так делал раньше. Однако есть очень ограниченное количество случаев, когда это имеет смысл.
Каждый раз, когда я работаю над чем-то новым, я нахожу время, чтобы узнать кое-что о системе, с которой я работаю, и вещах, тесно связанных с ней. Если она слишком большая, я стараюсь учиться как можно больше. Каждый раз, когда я возвращаюсь к системе, я стремлюсь узнать больше.
Когда вы не торопитесь, у вас есть шанс поэкспериментировать, поучиться и обдумать логику. Значит останется достаточно времени, чтобы всё сделать. В условиях постоянной спешки сроки горят, и всё ваше внимание сосредоточено на завершении задачи. Защищать свой темп - значит не позволять дедлайнам овладевать вами. Часто для этого достаточно просто поговорить с вашим начальством.
Неторопливость может со стороны показаться бездельничаньем, но умение отстоять возможность работать в своём темпе - это суперсила. Это долгосрочное вложение в собственное развитие за счет краткосрочной эффективности. Когда я тороплюсь завершить задачу, мне гораздо труднее обнаруживать и исправлять ошибки. Я не трачу время на обдумывание правильных логических конструкций, а это значит, что мои предположения могут не соответствовать существующему коду, и именно в этом несоответствии кроется большинство ошибок. Я отстаиваю возможность работы в своём темпе, поэтому я могу выделить время, чтобы уделить больше внимания обучению, а не исполнению.
Один из моих любимых вариантов использования времени - экспериментирование. Иногда я обнаруживаю ошибку, которая не имеет для меня никакого смысла. Я понимаю, что запутался, но при этом нахожу ответ на Stack Overflow и продолжаю работу. Однако меня беспокоит то, что я не понял причину появления ошибки. Stack Overflow дал ответ, но не объяснение, что было не так в моём понимании логики работы программы. Чтобы укрепить свое понимание, мне нужно поэкспериментировать.
Если у меня нет свободного времени, мне некогда экспериментировать, а значит, я должен забыть об этой ошибке. И напротив, если есть возможность провести пару экспериментов, можно точно выяснить, чего я не понимал. Я люблю такие моменты, когда я узнаю что-то новое о системе. В следующий раз это сделает меня намного эффективнее.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
4. Следите за скоростью
Я заметил, что более медленный темп даёт прирост моей производительности. Хотите сделать больше? Не торопитесь. Вот что я имею в виду.
Я заметил, что люди спешат решать проблемы. Это может быть что-то, что они делали раньше, или что-то, на что у нас есть шаблон решения. Приятно щёлкать задачи, как орешки. Я тоже так делал раньше. Однако есть очень ограниченное количество случаев, когда это имеет смысл.
Каждый раз, когда я работаю над чем-то новым, я нахожу время, чтобы узнать кое-что о системе, с которой я работаю, и вещах, тесно связанных с ней. Если она слишком большая, я стараюсь учиться как можно больше. Каждый раз, когда я возвращаюсь к системе, я стремлюсь узнать больше.
Когда вы не торопитесь, у вас есть шанс поэкспериментировать, поучиться и обдумать логику. Значит останется достаточно времени, чтобы всё сделать. В условиях постоянной спешки сроки горят, и всё ваше внимание сосредоточено на завершении задачи. Защищать свой темп - значит не позволять дедлайнам овладевать вами. Часто для этого достаточно просто поговорить с вашим начальством.
Неторопливость может со стороны показаться бездельничаньем, но умение отстоять возможность работать в своём темпе - это суперсила. Это долгосрочное вложение в собственное развитие за счет краткосрочной эффективности. Когда я тороплюсь завершить задачу, мне гораздо труднее обнаруживать и исправлять ошибки. Я не трачу время на обдумывание правильных логических конструкций, а это значит, что мои предположения могут не соответствовать существующему коду, и именно в этом несоответствии кроется большинство ошибок. Я отстаиваю возможность работы в своём темпе, поэтому я могу выделить время, чтобы уделить больше внимания обучению, а не исполнению.
Один из моих любимых вариантов использования времени - экспериментирование. Иногда я обнаруживаю ошибку, которая не имеет для меня никакого смысла. Я понимаю, что запутался, но при этом нахожу ответ на Stack Overflow и продолжаю работу. Однако меня беспокоит то, что я не понял причину появления ошибки. Stack Overflow дал ответ, но не объяснение, что было не так в моём понимании логики работы программы. Чтобы укрепить свое понимание, мне нужно поэкспериментировать.
Если у меня нет свободного времени, мне некогда экспериментировать, а значит, я должен забыть об этой ошибке. И напротив, если есть возможность провести пару экспериментов, можно точно выяснить, чего я не понимал. Я люблю такие моменты, когда я узнаю что-то новое о системе. В следующий раз это сделает меня намного эффективнее.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День семьсот четвёртый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
5. Задавайте вопросы
Мы вообще не умеем задавать вопросы. Либо мы боимся, что вопрос выставит нас тупыми, поэтому вообще не задаём их, либо задаём вопрос с длинной преамбулой, которая нужна скорее для того, чтобы доказать, что мы не глупы, а не для того, чтобы уточнить вопрос. Но вы не можете считать вопрос глупым, пока не узнаете ответ.
Для полноценного понимания нужно задавать много вопросов. Начать сначала и постепенно латать дыры в понимании. Здесь помогут позитивные отношения в команде. Например, вот мой диалог с коллегой относительно программного обеспечения для упаковки:
- Что такое пакет?
- Это объединённый код, который можно установить в системе.
- Зачем нужны пакеты?
- Они дают единообразный способ получить все нужные файлы в нужном месте. Без них всё легко испортить. Необходимо убедиться, что каждый файл находится там, где он должен быть, настроены системные пути и доступны зависимые пакеты.
- Чем пакеты отличаются от приложений?
- Концепция очень похожая. Установщик Windows похож на диспетчер пакетов, который помогает устанавливать приложения. Аналогично пакеты dpkg и rpm похожи на .exe файлы, которые можно установить в системах Linux с помощью менеджеров пакетов apt и yum, в чём-то похожие на установщик Windows.
- Понятно. То есть setup.py в python каким-то образом конвертируется в dpkg? Как это работает?
- У нас есть python-debhelper, который запускает setup.py для преобразования.
- Интересно! Откуда ты это узнал?
- Файл debian/rules содержит инструкции по созданию пакетов dpkg.
Теперь я знаю, что пора посмотреть документацию. У меня достаточно деталей, чтобы разобраться в ней. Оказалось, что это было не так просто, как я думал, и задать вопрос не было глупой идеей.
Я выработал эту привычку: всегда полезно задать несколько хороших вопросов. Большинство из них зависят от контекста, но у меня есть один любимый общий вопрос: «Как вы узнали про X?» Когда я спрашиваю кого-то о чем-то, и они отвечают, то следующее, что я спрашиваю, - откуда они это узнали? Это помогает мне в следующий раз разобраться самому. Я сделал это в диалоге, приведённом выше, и узнал, что есть файл с инструкциями, которые я могу прочитать сам, и не отвлекать человека вопросами в следующий раз.
Ещё один хороший вопрос – спросить о что вас смущает или уточнить что-то, что для вас не совсем ясно. Лучше задать короткий вопрос, чем сделать неправильно и переделывать.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
5. Задавайте вопросы
Мы вообще не умеем задавать вопросы. Либо мы боимся, что вопрос выставит нас тупыми, поэтому вообще не задаём их, либо задаём вопрос с длинной преамбулой, которая нужна скорее для того, чтобы доказать, что мы не глупы, а не для того, чтобы уточнить вопрос. Но вы не можете считать вопрос глупым, пока не узнаете ответ.
Для полноценного понимания нужно задавать много вопросов. Начать сначала и постепенно латать дыры в понимании. Здесь помогут позитивные отношения в команде. Например, вот мой диалог с коллегой относительно программного обеспечения для упаковки:
- Что такое пакет?
- Это объединённый код, который можно установить в системе.
- Зачем нужны пакеты?
- Они дают единообразный способ получить все нужные файлы в нужном месте. Без них всё легко испортить. Необходимо убедиться, что каждый файл находится там, где он должен быть, настроены системные пути и доступны зависимые пакеты.
- Чем пакеты отличаются от приложений?
- Концепция очень похожая. Установщик Windows похож на диспетчер пакетов, который помогает устанавливать приложения. Аналогично пакеты dpkg и rpm похожи на .exe файлы, которые можно установить в системах Linux с помощью менеджеров пакетов apt и yum, в чём-то похожие на установщик Windows.
- Понятно. То есть setup.py в python каким-то образом конвертируется в dpkg? Как это работает?
- У нас есть python-debhelper, который запускает setup.py для преобразования.
- Интересно! Откуда ты это узнал?
- Файл debian/rules содержит инструкции по созданию пакетов dpkg.
Теперь я знаю, что пора посмотреть документацию. У меня достаточно деталей, чтобы разобраться в ней. Оказалось, что это было не так просто, как я думал, и задать вопрос не было глупой идеей.
Я выработал эту привычку: всегда полезно задать несколько хороших вопросов. Большинство из них зависят от контекста, но у меня есть один любимый общий вопрос: «Как вы узнали про X?» Когда я спрашиваю кого-то о чем-то, и они отвечают, то следующее, что я спрашиваю, - откуда они это узнали? Это помогает мне в следующий раз разобраться самому. Я сделал это в диалоге, приведённом выше, и узнал, что есть файл с инструкциями, которые я могу прочитать сам, и не отвлекать человека вопросами в следующий раз.
Ещё один хороший вопрос – спросить о что вас смущает или уточнить что-то, что для вас не совсем ясно. Лучше задать короткий вопрос, чем сделать неправильно и переделывать.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День семьсот десятый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
6. Замечайте Странности
Как-то раз работал я с датой в Python. Это были даты, которые наша поисковая система должна была индексировать, и мы хотели, чтобы они были в формате UTC. Поэтому добавил преобразование даты в UTC перед загрузкой. Для этого нужно было добавить к датам часовой пояс. Я создал такие дату и время:
Это довольно серьёзная ошибка. В библиотеке Pytz есть историческая информация о часовых поясах. До 1942 года смещение для часового пояса
Чтобы этого больше не повторилось, я начал тренировать «мускулы внимания». То есть замечать, что меня смущает. Не только при написании кода, но и во всём остальном. Каждый раз, когда я замечаю, что меня что-то смущает, я делаю паузу, и пытаюсь выяснить, в чём дело. Возможно, теоретически это звучит банально, но я надеюсь, что рассказанная выше история поможет вам понять важность этого приёма. Самое сложное теперь – это понять, что же конкретно вас смущает.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
6. Замечайте Странности
Как-то раз работал я с датой в Python. Это были даты, которые наша поисковая система должна была индексировать, и мы хотели, чтобы они были в формате UTC. Поэтому добавил преобразование даты в UTC перед загрузкой. Для этого нужно было добавить к датам часовой пояс. Я создал такие дату и время:
import datetimeВ моих тестах преобразованное время отличалось от ожидаемого на 23 минуты. Тогда я не придал этому значения, хотя это и смутило меня. Я просто поправил ожидаемое время на
from pytz import timezone
indexed_date =
datetime.datetime(2020, 11, 20,
12, 2, 0,
tzinfo=timezone('Asia/Kolkata'))
-23 минуты, чтобы тесты проходили. Да, я слышу, как вы осуждаете меня, это было однозначно хреновой идеей. Когда я это осознал, я уже не мог перестать думать об этом. До сих пор этот случай преследует меня. Как я мог позволить себе так «решить» проблему? Конечно, на код ревью кто-то из коллег прокомментировал это словами «это выглядит неправильно». Я был готов провалиться сквозь землю, и решил выяснить, что здесь пошло не так.Это довольно серьёзная ошибка. В библиотеке Pytz есть историческая информация о часовых поясах. До 1942 года смещение для часового пояса
Asia/Calcutta (Да, даже название города было другое) было +5:53:20. Когда часовой пояс из pytz передаётся в новую дату, библиотека не имеет информации о дате, чтобы выбрать актуальное на дату смещение, поэтому по умолчанию используется первое доступное смещение, что неверно. И в документации об этом упоминается. Правильный способ - использовать tzinfo.localize(), который выбирает часовой пояс соответственно дате:from pytz import timezoneЯ бы не узнал об этом, если бы не получил «пинка» от коллег на код ревью. Это выявило у меня довольно распространённый образ мышления: когда нас что-то смущает, мы стараемся «спрятать это под ковёр». С тех пор я был осторожен.
tz=timezone('Asia/Kolkata')
indexed_date = tz.localize(
datetime.datetime(2020, 11, 20,
12, 2, 0))
Чтобы этого больше не повторилось, я начал тренировать «мускулы внимания». То есть замечать, что меня смущает. Не только при написании кода, но и во всём остальном. Каждый раз, когда я замечаю, что меня что-то смущает, я делаю паузу, и пытаюсь выяснить, в чём дело. Возможно, теоретически это звучит банально, но я надеюсь, что рассказанная выше история поможет вам понять важность этого приёма. Самое сложное теперь – это понять, что же конкретно вас смущает.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День семьсот семнадцатый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
7. Станьте Мультипликатором Силы
В один прекрасный спринт я случайно почувствовал мощь Силы.
«Сила — это то, что даёт джедаю его могущество. Это энергетическое поле, создаваемое всеми живыми существами. Она окружает и пронизывает нас. Она связывает Вселенную воедино».
– Оби-Ван Кеноби, «Звездные войны»
Я думаю, что Оби-Ван Кеноби познал истину, хотя и не в той области. Это то, что я могу использовать в разработке программного обеспечения: стать мультипликатором силы.
В том спринте я сам многого не добился. Я написал совсем чуть-чуть кода. Зато я координировал, какие изменения должны выйти, когда (это был сложный спринт), тестировал изменения, делал много обзоров кода, вносил альтернативные предложения по дизайну и программировал в паре, когда это требовалось, и когда кто-то застревал, чтобы двигать весь процесс вперёд. Мы всё сделали, и в этом случае отход от деталей и более общий взгляд на проект помог мне легче принимать управленческие решения. Это был один из наших самых продуктивных спринтов.
«Сила — это то, что даёт разработчику его могущество. Это энергетическое поле, создаваемое всеми разработчиками и их инструментами. Она окружает и пронизывает нас. Она связывает код воедино».
Ладно, хватит про «Звёздные войны».
Разобраться в том, как стать мультипликатором силы, для меня важнее, чем взять в команду ещё 10 разработчиков. На практике хорошим множителем (или разделителем) силы является командная культура. Точно так же, как я могу создать привычки для улучшения моих результатов, так может сделать и вся команда. Это происходит из командной культуры. Ретроспективы, обзоры кода и эксперименты - это всё команда делает для формирования своей культуры. Культура постоянно меняется, поскольку члены команды приходят и уходят, добавляя свои личные штрихи.
Положительные примеры культуры умножают Силу. Я смог сделать то, что сделал, потому что наша культура позволяла это. Наша командная культура оценивает в спринте результаты команды, а не результаты отдельных разработчиков. Это позволило мне оптимизировать работу команды вместо того, чтобы сосредоточиться на себе. Команда формирует культуру, а культура формирует команду. Эта идея распространяется даже на города и народы:
«В обществе, существующем в условиях постоянной внешней военной угрозы, будут высоко цениться военные и боевые качества. В обществе с экономикой, основанной на совместном труде, будет осуждаться лень. В обществе с равными правами властность будет считаться отрицательной чертой характера. В индустриальном обществе с регламентированным рабочим графиком будет цениться пунктуальность, и т.д.».
– Иэн Бэнкс «Почему Культура побеждает»
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
7. Станьте Мультипликатором Силы
В один прекрасный спринт я случайно почувствовал мощь Силы.
«Сила — это то, что даёт джедаю его могущество. Это энергетическое поле, создаваемое всеми живыми существами. Она окружает и пронизывает нас. Она связывает Вселенную воедино».
– Оби-Ван Кеноби, «Звездные войны»
Я думаю, что Оби-Ван Кеноби познал истину, хотя и не в той области. Это то, что я могу использовать в разработке программного обеспечения: стать мультипликатором силы.
В том спринте я сам многого не добился. Я написал совсем чуть-чуть кода. Зато я координировал, какие изменения должны выйти, когда (это был сложный спринт), тестировал изменения, делал много обзоров кода, вносил альтернативные предложения по дизайну и программировал в паре, когда это требовалось, и когда кто-то застревал, чтобы двигать весь процесс вперёд. Мы всё сделали, и в этом случае отход от деталей и более общий взгляд на проект помог мне легче принимать управленческие решения. Это был один из наших самых продуктивных спринтов.
«Сила — это то, что даёт разработчику его могущество. Это энергетическое поле, создаваемое всеми разработчиками и их инструментами. Она окружает и пронизывает нас. Она связывает код воедино».
Ладно, хватит про «Звёздные войны».
Разобраться в том, как стать мультипликатором силы, для меня важнее, чем взять в команду ещё 10 разработчиков. На практике хорошим множителем (или разделителем) силы является командная культура. Точно так же, как я могу создать привычки для улучшения моих результатов, так может сделать и вся команда. Это происходит из командной культуры. Ретроспективы, обзоры кода и эксперименты - это всё команда делает для формирования своей культуры. Культура постоянно меняется, поскольку члены команды приходят и уходят, добавляя свои личные штрихи.
Положительные примеры культуры умножают Силу. Я смог сделать то, что сделал, потому что наша культура позволяла это. Наша командная культура оценивает в спринте результаты команды, а не результаты отдельных разработчиков. Это позволило мне оптимизировать работу команды вместо того, чтобы сосредоточиться на себе. Команда формирует культуру, а культура формирует команду. Эта идея распространяется даже на города и народы:
«В обществе, существующем в условиях постоянной внешней военной угрозы, будут высоко цениться военные и боевые качества. В обществе с экономикой, основанной на совместном труде, будет осуждаться лень. В обществе с равными правами властность будет считаться отрицательной чертой характера. В индустриальном обществе с регламентированным рабочим графиком будет цениться пунктуальность, и т.д.».
– Иэн Бэнкс «Почему Культура побеждает»
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
.NET Разработчик
День семьсот тридцатый. #ЗаметкиНаПолях Как Работает Git. Окончание Начало Версии Ветки Rebase Распределённость Мы наконец добрались до верхнего слоя определения Git (распределённая система контроля версий). Допустим, мы создали репозиторий на GitHub. Получить…
День семьсот тридцать третий. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
7. Об Управлении
В Bloomberg у нас есть три команды, и мы используем Jenkins для автоматического тестирования. Предстояла большая задача по обслуживанию Jenkins, и я решил взять её на себя. Задача подразумевала выяснение того, как реализовать изменения, организацию встреч для обсуждения улучшений и альтернатив и, наконец, координацию релиза. Однако, когда я брал задачу на себя, я и не знал, что именно я буду делать всё это. Я просто подумал, что это будет интересно.
Я написал в нашем групповом чате об альтернативах, которые я придумал. Пошло обсуждение, но разговор быстро прервался, возможно, потому что все были чем-то заняты. Я почувствовал, что не знаю, что мне теперь с этим делать. Поэтому решил заняться другими своими задачами в спринте.
Я рассуждал так: «Ну что ж, я попробовал. Когда-нибудь кто-нибудь ответит в чате, и тогда мы сможем продолжить разговор». Я играл роль хозяина задачи, но не взял её под свой контроль. Когда я это понял, это стало для меня откровением. Такое поведение - очень плохой способ управления. Все над чем-то работают, и их мысли заняты работой, а не моими проблемами. Поэтому я обязан привлечь их внимание к моей задаче.
Через два дня после первого разговора (именно столько времени мне потребовалось, чтобы подумать и понять, что я был неправ), я снова написал сообщение с объяснениями моих решений и описанием работ, которыми будет заниматься каждая из команд. Это стало уже вторым откровением: все согласились. Дело не в том, что им было всё равно, просто им было нечего добавить после первого разговора.
Я очень дорожу этим опытом. Он научил меня некоторым важным привычкам: всегда следить за собой, а если уж взял задачу на себя, это моя обязанность двигать её вперед. Не расслабляйтесь, играя роль начальника, делайте дело: будь то делегирование полномочий или выполнение работы самостоятельно.
Помимо этого, я открыл для себя ещё одну интересную вещь: надо ценить сюрпризы. Под сюрпризом здесь я имею в виду несоответствие между тем, что вы ожидали и тем, что произошло на самом деле. Это прекрасная возможность изменить мышление и получить новый опыт.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
7. Об Управлении
В Bloomberg у нас есть три команды, и мы используем Jenkins для автоматического тестирования. Предстояла большая задача по обслуживанию Jenkins, и я решил взять её на себя. Задача подразумевала выяснение того, как реализовать изменения, организацию встреч для обсуждения улучшений и альтернатив и, наконец, координацию релиза. Однако, когда я брал задачу на себя, я и не знал, что именно я буду делать всё это. Я просто подумал, что это будет интересно.
Я написал в нашем групповом чате об альтернативах, которые я придумал. Пошло обсуждение, но разговор быстро прервался, возможно, потому что все были чем-то заняты. Я почувствовал, что не знаю, что мне теперь с этим делать. Поэтому решил заняться другими своими задачами в спринте.
Я рассуждал так: «Ну что ж, я попробовал. Когда-нибудь кто-нибудь ответит в чате, и тогда мы сможем продолжить разговор». Я играл роль хозяина задачи, но не взял её под свой контроль. Когда я это понял, это стало для меня откровением. Такое поведение - очень плохой способ управления. Все над чем-то работают, и их мысли заняты работой, а не моими проблемами. Поэтому я обязан привлечь их внимание к моей задаче.
Через два дня после первого разговора (именно столько времени мне потребовалось, чтобы подумать и понять, что я был неправ), я снова написал сообщение с объяснениями моих решений и описанием работ, которыми будет заниматься каждая из команд. Это стало уже вторым откровением: все согласились. Дело не в том, что им было всё равно, просто им было нечего добавить после первого разговора.
Я очень дорожу этим опытом. Он научил меня некоторым важным привычкам: всегда следить за собой, а если уж взял задачу на себя, это моя обязанность двигать её вперед. Не расслабляйтесь, играя роль начальника, делайте дело: будь то делегирование полномочий или выполнение работы самостоятельно.
Помимо этого, я открыл для себя ещё одну интересную вещь: надо ценить сюрпризы. Под сюрпризом здесь я имею в виду несоответствие между тем, что вы ожидали и тем, что произошло на самом деле. Это прекрасная возможность изменить мышление и получить новый опыт.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День семьсот сорок восьмой. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
8. Смиритесь со страхом
В прошлом году я работал над второстепенным проектом, который провалился. Это был один из тех проектов, где я изучал новый язык, новый способ ведения дел и проверял гипотезу о нужности такого продукта на рынке. Мне было на удивление сложно продолжать работу над проектом, я чувствовал страх всякий раз, когда думал об этом.
Это был огромный клубок чувств, которые я не мог игнорировать. Но этот опыт помог мне начать замечать и менее выраженные приступы того же чувства, особенно на работе. Когда передо мной стоит грандиозная задача, и я еще не знаю, как её решить, это чувство возвращается. «Ой, как это будет работать? А как реализовать вот это? Я пока не знаю. Я ничего не знаю.»
Я научился принимать и мириться с этим чувством. Теперь это чувство возбуждает меня и стимулирует к действию. Это значит, что я узнаю что-то новое, получу новый навык и стану лучше как специалист. Я зашел так далеко, что начал отслеживать это в моём журнале: «Чувствовал ли я страх на этой неделе?» Если несколько недель подряд я вижу ответ «нет», это значит, что я слишком успокоился и не развиваюсь. Страх - это информация.
Этот мета-навык - замечать, что происходит в мозгу, - является мощным инструментом мониторинга и диагностики. Как Health Check периодически обследует и оценивает «состояние здоровья» программной системы, ведение и периодические обзоры журнала вашего состояния помогают мониторить и улучшают со временем ваше здоровье: умственное и физическое.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
8. Смиритесь со страхом
В прошлом году я работал над второстепенным проектом, который провалился. Это был один из тех проектов, где я изучал новый язык, новый способ ведения дел и проверял гипотезу о нужности такого продукта на рынке. Мне было на удивление сложно продолжать работу над проектом, я чувствовал страх всякий раз, когда думал об этом.
Это был огромный клубок чувств, которые я не мог игнорировать. Но этот опыт помог мне начать замечать и менее выраженные приступы того же чувства, особенно на работе. Когда передо мной стоит грандиозная задача, и я еще не знаю, как её решить, это чувство возвращается. «Ой, как это будет работать? А как реализовать вот это? Я пока не знаю. Я ничего не знаю.»
Я научился принимать и мириться с этим чувством. Теперь это чувство возбуждает меня и стимулирует к действию. Это значит, что я узнаю что-то новое, получу новый навык и стану лучше как специалист. Я зашел так далеко, что начал отслеживать это в моём журнале: «Чувствовал ли я страх на этой неделе?» Если несколько недель подряд я вижу ответ «нет», это значит, что я слишком успокоился и не развиваюсь. Страх - это информация.
Этот мета-навык - замечать, что происходит в мозгу, - является мощным инструментом мониторинга и диагностики. Как Health Check периодически обследует и оценивает «состояние здоровья» программной системы, ведение и периодические обзоры журнала вашего состояния помогают мониторить и улучшают со временем ваше здоровье: умственное и физическое.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar