День шестьсот семьдесят шестой. #Оффтоп #КакСтатьСеньором
Сегодня начну серию постов, которую коротко можно озаглавить «Как Стать Сеньором». Я недавно наткнулся на лонгрид от разработчика, который описывает, что он узнал на пути к должности старшего разработчика. Выдержки из его статьи, по аналогии с #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